From hadi@cyberus.ca Tue Oct 1 02:58:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 02:58:48 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g919wjtG021237 for ; Tue, 1 Oct 2002 02:58:45 -0700 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 FAA06726; Tue, 1 Oct 2002 05:58:39 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g919pTl17793; Tue, 1 Oct 2002 05:51:29 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 1 Oct 2002 05:51:28 -0400 (EDT) From: jamal To: Eric Lemoine cc: Eric Lemoine , Subject: Re: PATCH Re: udp weirdness In-Reply-To: <20021001063557.GA331@hookipa> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 447 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, 1 Oct 2002, Eric Lemoine wrote: > Jamal, > > Have you posted the right patch? ;-> I dont know what happened; patch below is what i was trying to post I deleted all the old patches this time to make sure ;-> > I see that sk->protinfo.af_inet.recverr is > still around. Here follows the patch that I think is the correct one. > Please confirm. Thx. > Yes it is correct but was missing one more bit from v6 added below. Alexey/Dave this is the correct version ;-> cheers, jamal --- linux/net/ipv4/ip_output.c 2002/09/29 08:50:36 1.1 +++ linux/net/ipv4/ip_output.c 2002/09/30 09:11:15 @@ -603,8 +603,8 @@ err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, skb->dst->dev, output_maybe_reroute); if (err) { - if (err > 0) - err = sk->protinfo.af_inet.recverr ? net_xmit_errno(err) : 0; + if (err > 0) + err = net_xmit_errno(err); if (err) goto error; } @@ -713,8 +713,8 @@ err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, output_maybe_reroute); - if (err > 0) - err = sk->protinfo.af_inet.recverr ? net_xmit_errno(err) : 0; + if (err > 0) + err = net_xmit_errno(err); if (err) goto error; out: --- linux/net/ipv6/ip6_output.c 2002/09/30 18:30:52 1.1 +++ linux/net/ipv6/ip6_output.c 2002/09/30 18:31:30 @@ -684,7 +684,7 @@ out: ip6_dst_store(sk, dst, fl->nl_u.ip6_u.daddr == &np->daddr ? &np->daddr : NULL); if (err > 0) - err = np->recverr ? net_xmit_errno(err) : 0; + err = net_xmit_errno(err); return err; } From kuznet@ms2.inr.ac.ru Tue Oct 1 06:54:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 06:54:25 -0700 (PDT) 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 g91DsLtG012338 for ; Tue, 1 Oct 2002 06:54:22 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id RAA19504; Tue, 1 Oct 2002 17:53:13 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210011353.RAA19504@sex.inr.ac.ru> Subject: Re: PATCH Re: udp weirdness To: hadi@cyberus.CA (jamal) Date: Tue, 1 Oct 2002 17:53:13 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: from "jamal" at Oct 1, 2 04:45:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 448 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! > be propagated back to the socket level; please review and probably > apply: That was tried and failed miserably ages ago. Applications become insane when getting this error from logging tons of useless messages to abort()ing and cpu hogging. From the other hand silent reaction to loss is almost exactly desired behaviour in presence of congestion in the most of cases. I have no idea, why that OSes work. Probably, they are so great that never lose packets. We do. Probably, the world has changed since that time, but I have no desire to repeat the experiment to be honest. Alexey From hadi@cyberus.ca Tue Oct 1 07:21:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 07:21:20 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91ELHtG012986 for ; Tue, 1 Oct 2002 07:21:17 -0700 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 KAA00161; Tue, 1 Oct 2002 10:21:16 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g91EE4618484; Tue, 1 Oct 2002 10:14:05 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 1 Oct 2002 10:14:04 -0400 (EDT) From: jamal To: cc: Eric Lemoine , Eric Lemoine , Subject: Re: PATCH Re: udp weirdness In-Reply-To: <200210011353.RAA19504@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 449 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 Alexey, I agree; so just ignore the patch. You know you could have saved me about an hour if you spoke earlier ;-> Eric, note what Alexey says. So to get enobufs please use the sockoption to set IP_RECVERR Someone should document this in the manpages. cheers, jamal On Tue, 1 Oct 2002 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > be propagated back to the socket level; please review and probably > > apply: > > That was tried and failed miserably ages ago. Applications become > insane when getting this error from logging tons of useless messages > to abort()ing and cpu hogging. From the other hand silent reaction > to loss is almost exactly desired behaviour in presence of congestion > in the most of cases. > > I have no idea, why that OSes work. Probably, they are so great that > never lose packets. We do. > > Probably, the world has changed since that time, but I have no desire > to repeat the experiment to be honest. > > Alexey > > > From cfriesen@nortelnetworks.com Tue Oct 1 07:26:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 07:26:58 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91EQstG013395 for ; Tue, 1 Oct 2002 07:26:55 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91EQ1b05317; Tue, 1 Oct 2002 10:26:01 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLKB8Y36; Tue, 1 Oct 2002 10:26:05 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1S392; Tue, 1 Oct 2002 10:26:05 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id E6BAB2E112; Tue, 1 Oct 2002 10:26:03 -0400 (EDT) Message-ID: <3D99B07B.7050901@nortelnetworks.com> Date: Tue, 01 Oct 2002 10:26:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: jamal , netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <200210011353.RAA19504@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: > That was tried and failed miserably ages ago. Applications become > insane when getting this error from logging tons of useless messages > to abort()ing and cpu hogging. From the other hand silent reaction > to loss is almost exactly desired behaviour in presence of congestion > in the most of cases. > > I have no idea, why that OSes work. Probably, they are so great that > never lose packets. We do. One of the principles of software design that I was taught was the principle of least surprise. If I'm looping on a sendto() with a blocking socket, I would expect the syscall to block until the packet has been handed off to the device driver. This may mean blocking until local congestion backs off. If I'm using non-blocking IO and there is local congestion, I would expect to get ENOBUFS or maybe EAGAIN/EWOULDBLOCK. The way we do it now means that we can chew up massive amounts of cpu creating packets in userspace and throwing them away in the kernel, with no way of knowing from userspace that it is happening. This just doesn't seem like the right thing to do. Chris From kuznet@ms2.inr.ac.ru Tue Oct 1 07:41:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 07:41:31 -0700 (PDT) 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 g91EfNtG013926 for ; Tue, 1 Oct 2002 07:41:24 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id SAA19721; Tue, 1 Oct 2002 18:40:12 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210011440.SAA19721@sex.inr.ac.ru> Subject: Re: PATCH Re: udp weirdness To: cfriesen@nortelnetworks.com (Chris Friesen) Date: Tue, 1 Oct 2002 18:40:12 +0400 (MSD) Cc: hadi@cyberus.CA, netdev@oss.sgi.com In-Reply-To: <3D99B07B.7050901@nortelnetworks.com> from "Chris Friesen" at Oct 1, 2 10:26:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 451 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 I'm looping on a sendto() with a blocking socket, I would expect the > syscall to block until the packet has been handed off to the device > driver. This may mean blocking until local congestion backs off. Feel free to implement. :-) > The way we do it now means that we can chew up massive amounts of cpu > creating packets in userspace and throwing them away in the kernel, with > no way of knowing from userspace that it is happening. What? If your applications is enough clever to handle ENOBUFS right, set IP_RECVERR and live in peace. Alexey From cfriesen@nortelnetworks.com Tue Oct 1 07:53:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 07:53:39 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91ErbtG014599 for ; Tue, 1 Oct 2002 07:53:37 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91Eqqb08453; Tue, 1 Oct 2002 10:52:52 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLKB8ZRM; Tue, 1 Oct 2002 10:52:56 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SPC7; Tue, 1 Oct 2002 10:52:56 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 7A7EE2E112; Tue, 1 Oct 2002 10:52:55 -0400 (EDT) Message-ID: <3D99B6C7.3010302@nortelnetworks.com> Date: Tue, 01 Oct 2002 10:52:55 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <200210011440.SAA19721@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: > Feel free to implement. :-) I may have to poke around...if nothing else I'll learn more about the networking code... > What? If your applications is enough clever to handle ENOBUFS right, > set IP_RECVERR and live in peace. The original poster was complaining about messages being silently dropped when there is congestion. If IP_RECVERR is turned on, would sendto() then return -1 so I know to try and read the error messages? I'm assuming I get ENOBUFS back in the ee_code field? Or can I get away with reading errno and ignoring the error queue? I've never used IP_RECVERR and there doesn't seem to be a lot of documentation about it. Chris From kuznet@ms2.inr.ac.ru Tue Oct 1 08:32:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 08:33:00 -0700 (PDT) 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 g91FWstG016070 for ; Tue, 1 Oct 2002 08:32:55 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id TAA19943; Tue, 1 Oct 2002 19:31:37 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210011531.TAA19943@sex.inr.ac.ru> Subject: Re: PATCH Re: udp weirdness To: cfriesen@nortelnetworks.com (Chris Friesen) Date: Tue, 1 Oct 2002 19:31:37 +0400 (MSD) Cc: hadi@cyberus.CA, netdev@oss.sgi.com In-Reply-To: <3D99B6C7.3010302@nortelnetworks.com> from "Chris Friesen" at Oct 1, 2 10:52:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 453 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! > > Feel free to implement. :-) > > I may have to poke around...if nothing else I'll learn more about the > networking code... It is difficult task, if possible at all. The main obstacle is that we must not block after select() succeeded, otherwise applications will lockup. Taking into account nature of datagram services (and generally of networking services, where routes change et al.) you do not know at time of select(), where the datagram will go. So, blocking can be made only based on a criterium not depending on this. We use sndbuf (like all the OSes). Actually, the problem with silent losses is solved by tuning SO_SNDBUF. Though it is not a complete solution (failing whith lots of senders), it solves all those bullshit problems with silent losses. People just do not care about this, so they get the thing which they deserve. > dropped when there is congestion. If IP_RECVERR is turned on, would > sendto() then return -1 so I know to try and read the error messages? Yes. > I'm assuming I get ENOBUFS back in the ee_code field? Or can I get away > with reading errno and ignoring the error queue? No, error queue should be read. But not all the errors are queued, only those which are supported asynchronously. ENOBUFS is still not. F.e. when packet is dropped lately (some qdiscs do this, dropping already queued packets to give place for another ones) ENOBUFS is not sent back. > there doesn't seem to be a lot of > documentation about it. Damn! (I'm sorry) It is documented _very_ well, thanks to Andi. I really hate this mode when people do not worrying even to look to manpages before pronouncing such statements. man recvmsg man ip Alexey From cfriesen@nortelnetworks.com Tue Oct 1 09:17:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 09:17:30 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91GHQtG023810 for ; Tue, 1 Oct 2002 09:17:27 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91GGie23826; Tue, 1 Oct 2002 12:16:44 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLKB872A; Tue, 1 Oct 2002 12:16:47 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SPNY; Tue, 1 Oct 2002 12:16:46 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id CCE512E112; Tue, 1 Oct 2002 12:16:45 -0400 (EDT) Message-ID: <3D99CA6D.5020808@nortelnetworks.com> Date: Tue, 01 Oct 2002 12:16:45 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <200210011531.TAA19943@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: > But not all the errors are queued, > only those which are supported asynchronously. ENOBUFS is still not. > F.e. when packet is dropped lately (some qdiscs do this, dropping already > queued packets to give place for another ones) ENOBUFS is not sent back. Hmm...so even with IP_RECVERR I may not be notified if the packet is dropped? >> there doesn't seem to be a lot of >>documentation about it. >> > > Damn! (I'm sorry) It is documented _very_ well, thanks to Andi. > I really hate this mode when people do not worrying even to look to manpages > before pronouncing such statements. > > man recvmsg > man ip Yes, I looked at both of those, and man udp as well. My point about a lack of documentation was more related to corner cases and exactly what gets returned when. The example above (where there are cases where no errors are returned even with IP_RECVERR turned on) is not mentioned anywhere in the documentation. I write code for a telephony softswitch. We are running a legacy app on top of an emulator on top of linux. I want to ensure that my packets either a) got out onto the wire, or b) my app got an error message back explaining why the message didn't get onto the wire so that it can decide how to proceed. Now my overall bandwidth requirements aren't too bad, but the traffic is bursty, with a batch of messages being sent in a tight sendto() loop. I do NOT want messages to be silently dropped in the kernel with no error returned. Chris From kuznet@ms2.inr.ac.ru Tue Oct 1 09:43:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 09:43:11 -0700 (PDT) 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 g91Gh6tG024457 for ; Tue, 1 Oct 2002 09:43:06 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id UAA20171; Tue, 1 Oct 2002 20:41:48 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210011641.UAA20171@sex.inr.ac.ru> Subject: Re: PATCH Re: udp weirdness To: cfriesen@nortelnetworks.com (Chris Friesen) Date: Tue, 1 Oct 2002 20:41:48 +0400 (MSD) Cc: hadi@cyberus.CA, netdev@oss.sgi.com In-Reply-To: <3D99CA6D.5020808@nortelnetworks.com> from "Chris Friesen" at Oct 1, 2 12:16:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 455 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! > Hmm...so even with IP_RECVERR I may not be notified if the packet is > dropped? Do you not jest occasionally? :-) "Even" sounds interesting, because this kind of errors cannot be reported _principially_ without IP_RECVERR, providing asynchronous error reporting. Packet can be dropped, damaged _after_ they are successfully queued to the device. And this need not to be emphasized in documentation on IP_RECVERR, except for a section "FUTURE DEVELOPMENT". > either a) got out onto the wire, or b) my app got an error message back > explaining why the message didn't get onto the wire so that it can > decide how to proceed. Then use IP_RECVERR. It reports all the errors which are detectable. Alexey From greearb@candelatech.com Tue Oct 1 09:43:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 09:43:16 -0700 (PDT) Received: from grok.yi.org (IDENT:+3kPCMZcqQIMGRTtx1WUDUzg3EUpwKJq@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91GhEtG024506 for ; Tue, 1 Oct 2002 09:43:14 -0700 Received: from candelatech.com (IDENT:Z1MlOQXjxRPsv8IjHRwTjKgD/07ZMtNR@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g91Gg9v13318; Tue, 1 Oct 2002 09:42:09 -0700 Message-ID: <3D99D061.1090208@candelatech.com> Date: Tue, 01 Oct 2002 09:42:09 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: Chris Friesen , hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <200210011531.TAA19943@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 456 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 kuznet@ms2.inr.ac.ru wrote: > Hello! > > >>>Feel free to implement. :-) >> >>I may have to poke around...if nothing else I'll learn more about the >>networking code... > > > It is difficult task, if possible at all. > > The main obstacle is that we must not block after select() succeeded, > otherwise applications will lockup. Taking into account nature of datagram > services (and generally of networking services, where routes change et al.) > you do not know at time of select(), where the datagram will go. > So, blocking can be made only based on a criterium not depending on this. > > We use sndbuf (like all the OSes). Actually, the problem with silent > losses is solved by tuning SO_SNDBUF. Though it is not a complete > solution (failing whith lots of senders), it solves all those bullshit > problems with silent losses. People just do not care about this, so > they get the thing which they deserve. Changing the size of the sending buffer will make you able to drop fewer packets in bursty behaviour, but it does not guarantee you anything, does it? For those of us wanting to write programs with very little slop in their behaviour, 'most of the time' is not good enough. I have not yet looked at the UDP code in detail, but it does appear we can know if a NIC accepts the packet for transmit or not. If it does not, then just don't dequeue off of the send list, retry it next time. I cannot see any logical reason that we cannot ensure that a packet is not at least given to the driver when accepted by sendto. As soon as I get my pktgen and send-to-self code cleaned up, I am planning to start working on making UDP reliably send packets, or return an error to the calling code. I will, of course, keep you informed if I actually get something working... Enjoy, Ben > > > >>dropped when there is congestion. If IP_RECVERR is turned on, would >>sendto() then return -1 so I know to try and read the error messages? > > > Yes. > > > >>I'm assuming I get ENOBUFS back in the ee_code field? Or can I get away >>with reading errno and ignoring the error queue? > > > No, error queue should be read. But not all the errors are queued, > only those which are supported asynchronously. ENOBUFS is still not. > F.e. when packet is dropped lately (some qdiscs do this, dropping already > queued packets to give place for another ones) ENOBUFS is not sent back. > > > >> there doesn't seem to be a lot of >>documentation about it. > > > Damn! (I'm sorry) It is documented _very_ well, thanks to Andi. > I really hate this mode when people do not worrying even to look to manpages > before pronouncing such statements. > > man recvmsg > man ip > > Alexey > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From cfriesen@nortelnetworks.com Tue Oct 1 09:59:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 09:59:51 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91GxntG025765 for ; Tue, 1 Oct 2002 09:59:49 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91Gwrb02265; Tue, 1 Oct 2002 12:58:53 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLKB88KP; Tue, 1 Oct 2002 12:58:57 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SPS1; Tue, 1 Oct 2002 12:58:56 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 25E732E112; Tue, 1 Oct 2002 12:58:56 -0400 (EDT) Message-ID: <3D99D44F.2010001@nortelnetworks.com> Date: Tue, 01 Oct 2002 12:58:55 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Ben Greear Cc: kuznet@ms2.inr.ac.ru, hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <200210011531.TAA19943@sex.inr.ac.ru> <3D99D061.1090208@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Ben Greear wrote: > I cannot see any logical reason that we cannot ensure that a packet is > not at least given to the driver when accepted by sendto. As soon as I > get my pktgen and send-to-self code cleaned up, I am planning to start > working on making UDP reliably send packets, or return an error to > the calling code. I will, of course, keep you informed if I actually > get something working... That would be fantastic. Chris From cfriesen@nortelnetworks.com Tue Oct 1 10:18:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 10:18:21 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91HIGtG026866 for ; Tue, 1 Oct 2002 10:18:16 -0700 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91HHWb08141; Tue, 1 Oct 2002 13:17:32 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9BXJP9K; Tue, 1 Oct 2002 13:17:35 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SPT6; Tue, 1 Oct 2002 13:17:35 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id E71F62E112; Tue, 1 Oct 2002 13:17:34 -0400 (EDT) Message-ID: <3D99D8AE.3070205@nortelnetworks.com> Date: Tue, 01 Oct 2002 13:17:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <200210011641.UAA20171@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev kuznet@ms2.inr.ac.ru wrote: >>Hmm...so even with IP_RECVERR I may not be notified if the packet is >>dropped? >> > > Do you not jest occasionally? :-) "Even" sounds interesting, because > this kind of errors cannot be reported _principially_ without IP_RECVERR, > providing asynchronous error reporting. The point that I fundamentally need IP_RECVERR for async errors is interesting, I'll have to look into that. Thanks for the pointer. > Packet can be dropped, damaged _after_ they are successfully queued > to the device. And this need not to be emphasized in documentation > on IP_RECVERR, except for a section "FUTURE DEVELOPMENT". This is certainly true, but I would hope that packets being damaged or dropped after being queued to the device would be a rare event. It would still be good to have them reported though. I understand the problems with regards to blocking sockets, since you can't block after the select() passes and select() doesn't know where the packet is going. It seems that it should be pretty straightforward to enable ENOBUFS for nonblocking sockets though--am I missing something? For now I'll play with SO_SNDBUF and IP_RECVERR. Thanks, Chris From hadi@cyberus.ca Tue Oct 1 11:02:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 11:02:52 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91I2jtG027586 for ; Tue, 1 Oct 2002 11:02:46 -0700 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 OAA16508; Tue, 1 Oct 2002 14:02:44 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g91HtQM19334; Tue, 1 Oct 2002 13:55:34 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 1 Oct 2002 13:55:24 -0400 (EDT) From: jamal To: Ben Greear cc: , Chris Friesen , Subject: Re: PATCH Re: udp weirdness In-Reply-To: <3D99D061.1090208@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 459 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, 1 Oct 2002, Ben Greear wrote: > get my pktgen and send-to-self code cleaned up, I am planning to start > working on making UDP reliably send packets, or return an error to > the calling code. I will, of course, keep you informed if I actually > get something working... If you want realibility then thats what TCP is for. I am curious why you would even want to retransmit a voice packet or why a local drop should be treated any different from a remote/network drop in a voice application ... When you fail in sendto/sendmsg, errno is set to ENOBUFS as long as you set IP_RECVERR in the socket options; you can also receive ICMP errors as described in the manpages (use a msg_control buffer and call recvmsg with MSG_ERRQUEUE). BTW, a good sample of an app that makes good use of ENOBUFS to do congestion control, IP_RECVERR and MSG_ERRQUEUE is the ping app in Alexeys iputils package. Why did i not remember all this before chasing the phantom with Eric is an indication i need to increase my cafeine consumption. cheers, jamal From cfriesen@nortelnetworks.com Tue Oct 1 11:37:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 11:37:39 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91IbYtG028930 for ; Tue, 1 Oct 2002 11:37:35 -0700 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91Iajb20474; Tue, 1 Oct 2002 14:36:45 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9BXJX0D; Tue, 1 Oct 2002 14:36:49 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SP8Y; Tue, 1 Oct 2002 14:36:49 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 73BC42E112; Tue, 1 Oct 2002 14:36:48 -0400 (EDT) Message-ID: <3D99EB40.8030006@nortelnetworks.com> Date: Tue, 01 Oct 2002 14:36:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: jamal Cc: Ben Greear , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev jamal wrote: > > On Tue, 1 Oct 2002, Ben Greear wrote: > > >>get my pktgen and send-to-self code cleaned up, I am planning to start >>working on making UDP reliably send packets, or return an error to >>the calling code. I will, of course, keep you informed if I actually >>get something working... >> > > If you want realibility then thats what TCP is for. There is a requirement to interwork with other equipment using UDP. > I am curious why you would even want to retransmit a voice packet or > why a local drop should be treated any different from a remote/network > drop in a voice application ... The legacy app generates batches of messages, and the emulator layer then sends them out in a tight loop on sendto(). I don't want packets to be silently dropped by the kernel because userspace is sending faster than they can get onto the wire during that tight loop. Eric's original testcase was a tight loop on sendto() resulting in userspace sending at a way higher rate than could be put onto the wire, so the kernel was silently dropping them. This is exactly what I want to avoid. > When you fail in sendto/sendmsg, errno is set to ENOBUFS as long as you > set IP_RECVERR in the socket options; you can also receive ICMP errors > as described in the manpages (use a msg_control buffer and call recvmsg > with MSG_ERRQUEUE). Okay, so with IP_RECVERR set the case that Eric saw will not happen? I mean that sendto() will return with -1 and errno set to ENOBUFS? > BTW, a good sample of an app that makes good use of ENOBUFS to do > congestion control, IP_RECVERR and MSG_ERRQUEUE is the ping app in Alexeys > iputils package. Why did i not remember all this before chasing the > phantom with Eric is an indication i need to increase my cafeine > consumption I'll take a look and try things out. Chris From hadi@cyberus.ca Tue Oct 1 11:42:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 11:42:52 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91IgntG029439 for ; Tue, 1 Oct 2002 11:42:50 -0700 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 OAA06351; Tue, 1 Oct 2002 14:42:49 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g91IZen19527; Tue, 1 Oct 2002 14:35:40 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 1 Oct 2002 14:35:39 -0400 (EDT) From: jamal To: Chris Friesen cc: Ben Greear , , Subject: Re: PATCH Re: udp weirdness In-Reply-To: <3D99EB40.8030006@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 461 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, 1 Oct 2002, Chris Friesen wrote: > to be silently dropped by the kernel because userspace is sending faster > than they can get onto the wire during that tight loop. > So what happens when you find packets being dropped? AFAIK, a dropped voice packet is as good as dead whether local or remote. > Okay, so with IP_RECVERR set the case that Eric saw will not happen? I > mean that sendto() will return with -1 and errno set to ENOBUFS? yes cheers, jamal From greearb@candelatech.com Tue Oct 1 11:55:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 11:55:22 -0700 (PDT) Received: from grok.yi.org (IDENT:7j8GuCDOJPZpaMqyYBhAHz5ipY6DCEta@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91ItCtG026093 for ; Tue, 1 Oct 2002 11:55:17 -0700 Received: from candelatech.com (IDENT:7ZM3In3GMZHz9sCBGglawMjMH4SHKx+p@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g91Iq2v00861; Tue, 1 Oct 2002 11:52:03 -0700 Message-ID: <3D99EED2.7020301@candelatech.com> Date: Tue, 01 Oct 2002 11:52:02 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: kuznet@ms2.inr.ac.ru, Chris Friesen , netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 462 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 Tue, 1 Oct 2002, Ben Greear wrote: > > >>get my pktgen and send-to-self code cleaned up, I am planning to start >>working on making UDP reliably send packets, or return an error to >>the calling code. I will, of course, keep you informed if I actually >>get something working... > > > If you want realibility then thats what TCP is for. > I am curious why you would even want to retransmit a voice packet or > why a local drop should be treated any different from a remote/network > drop in a voice application ... Don't worry so much about why I want to do this, just assume that I do! :) I have explained in the past, but since our needs are different, it does not seem to impress upon anyone (I want to send at high speeds, and detect every possible packet dropped by the network. If my local machine drops the packet, my detection of network-dropped packets is bogus...) The reason a local packet drop is different, is because it can be different. Any feedback of this nature that we can give to user-space can be used to make any recovery or throttling decisions better. I accept that I cannot guarantee a UDP packet is received by it's intended target, but I do not accept that the local machine cannot even guarantee that it has sent the packet onto the network. > > When you fail in sendto/sendmsg, errno is set to ENOBUFS as long as you > set IP_RECVERR in the socket options; you can also receive ICMP errors > as described in the manpages (use a msg_control buffer and call recvmsg > with MSG_ERRQUEUE). I will investigate the IP_RECVERR more closely, it may do just what I need. Thanks, Ben > > BTW, a good sample of an app that makes good use of ENOBUFS to do > congestion control, IP_RECVERR and MSG_ERRQUEUE is the ping app in Alexeys > iputils package. Why did i not remember all this before chasing the > phantom with Eric is an indication i need to increase my cafeine > consumption. > > cheers, > jamal > -- 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 Oct 1 11:56:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 11:56:54 -0700 (PDT) Received: from grok.yi.org (IDENT:aK5hxrhE5cl0g90noYplCu4IRrR/frN8@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91IuptG026456 for ; Tue, 1 Oct 2002 11:56:52 -0700 Received: from candelatech.com (IDENT:9grj9H6zoY5/RT6oJ8JeNY3g2iT9Utjb@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g91Isav01204; Tue, 1 Oct 2002 11:54:37 -0700 Message-ID: <3D99EF6C.9030509@candelatech.com> Date: Tue, 01 Oct 2002 11:54:36 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: Chris Friesen , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 463 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 Tue, 1 Oct 2002, Chris Friesen wrote: > > >>to be silently dropped by the kernel because userspace is sending faster >>than they can get onto the wire during that tight loop. >> > > > So what happens when you find packets being dropped? > AFAIK, a dropped voice packet is as good as dead whether local or remote. If it is dropped locally, you can re-send in way less than 1 milisecond, which is well within the realm of expected jitter. You can also back off for 5 miliseconds to alleviate congestion, which is still within acceptable jitter. If you think you sent it, but didn't actually send it, then it looks like your network is shitting, when in fact your local machine is acting shitty. Ben > > >>Okay, so with IP_RECVERR set the case that Eric saw will not happen? I >>mean that sendto() will return with -1 and errno set to ENOBUFS? > > > yes > > cheers, > jamal > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From cfriesen@nortelnetworks.com Tue Oct 1 12:04:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 12:04:14 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g91J4CtG026925 for ; Tue, 1 Oct 2002 12:04:12 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g91J3Oe08613; Tue, 1 Oct 2002 15:03:24 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLKB9A7R; Tue, 1 Oct 2002 15:03:26 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SQC2; Tue, 1 Oct 2002 15:03:26 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id A20462E134; Tue, 1 Oct 2002 15:03:25 -0400 (EDT) Message-ID: <3D99F17D.10802@nortelnetworks.com> Date: Tue, 01 Oct 2002 15:03:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: jamal Cc: Ben Greear , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev jamal wrote: > > On Tue, 1 Oct 2002, Chris Friesen wrote: > >> to be silently dropped by the kernel because userspace is sending >> faster than they can get onto the wire during that tight loop. > So what happens when you find packets being dropped? AFAIK, a > dropped voice packet is as good as dead whether local or remote. We do have some leeway in terms of latency, and delayed leaving the box is not the same as dropped. We know that call processing messaging can only ever go out one ethernet interface at a time, and we know that the call agent is guaranteed 90% of the userspace cpu time (scheduler changes). We certify the box for a certain engineered throughput, so we know the average packets/sec value. We also have total knowledge/control over the other apps running on the box in question. So really all I'm protecting against is from one single userspace app generating packets faster than the network can keep up. As long as I get EAGAIN/EWOULDBLOCK/ENOBUFS on my non-blocking socket then I'll just try again until it succeeds or I get a more serious error. So far this seems to be working nicely in 2.2, but we're just in the middle of a switch to 2.4 for the new release and I want to make sure I've got a handle on things. Thanks for your help, Chris PS. I realize that this design is simplistic, but we are severely constrained by the legacy app running on the emulator. From pb@bieringer.de Tue Oct 1 23:37:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Oct 2002 23:37:29 -0700 (PDT) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g926bMtG007278 for ; Tue, 1 Oct 2002 23:37:23 -0700 Received: (qmail 29466 invoked from network); 2 Oct 2002 06:37:15 -0000 Received: from pd950f7bf.dip.t-dialin.net (217.80.247.191) by mail.bieringer.de with SMTP; 2 Oct 2002 06:37:15 -0000 Date: Wed, 02 Oct 2002 08:37:09 +0200 From: Peter Bieringer To: Maillist netdev cc: Maillist USAGI-users , Maillist linux-ipv6 Subject: Description available for all IPv6 related proc settings? Message-ID: <13970000.1033540629@localhost> X-Mailer: Mulberry/3.0.0a4 (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="==========862390887==========" X-archive-position: 465 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 --==========862390887========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, during extending my HowTo: http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6.html I found not much information about neigh/* route/* Latest ip-sysctl.txt from kernel sources 2.5.39 is dated $Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $ already containing some IPv6 information (credits to Pekka), but not all. Would be very nice if someone is able to contribute more information... BTW: some still not full explained values also are shown here: http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-net.html Perhaps someone can send updates to me for this, too. Thank you very much, 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 --==========862390887========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE9mpQWe1eqe5WPQi0RApb8AJ9fFaY7wd7N1IoSxQZF6NvxbafKygCg7wbM eFsph4C+kMdQ2MP7yx4+Xa4= =U+Cb -----END PGP SIGNATURE----- --==========862390887==========-- From ajtuomin@tml.hut.fi Wed Oct 2 02:21:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 02:21:53 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g929LjtG014493 for ; Wed, 2 Oct 2002 02:21:46 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id MAA21681 for ; Wed, 2 Oct 2002 12:21:44 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma021665; Wed, 2 Oct 02 12:21:27 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g929LQ21004853; Wed, 2 Oct 2002 12:21:26 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g929LPF5017153; Wed, 2 Oct 2002 12:21:25 +0300 (EEST) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g929LBn8017152; Wed, 2 Oct 2002 12:21:11 +0300 (EEST) Date: Wed, 2 Oct 2002 12:21:11 +0300 From: Antti Tuominen To: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Cc: torvalds@transmeta.com Subject: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) Message-ID: <20021002092111.GB17010@morphine.tml.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev Hello Dave, Alexey, and all, I am part of the MIPL Mobile IPv6 for Linux Team at Helsinki University of Technology, and we have been working on an implementation of Mobility Support in IPv6 specification for the past 3 years. Now the code has matured to the point, that we feel confident enough to ask for kernel inclusion. Our implementation has been to several interop and conformance testing events, and has proven to be very compliant and to interoperate with all major vendors' implementations. Code has been tested on several UP and SMP configurations, and performs quite well. Implementation consists of two kernel modules, changes to IPv6 stack, and userspace configuration tools. First module provides support for 6over6 (IPv6 in IPv6) tunneling. Second module is the Mobile IPv6 module, and adds support for Mobile IPv6 Correspondent Node, Mobile Node, and Home Agent. IPv6 stack has been modified to provide some MIPv6 mandated features as well as hooks to our module. Latest code for 2.5 series can be pulled from our public BitKeeper repository (parent is http://linux.bkbits.net/linux-2.5): bk://bk.mipl.mediapoli.com/linux25-mipl Diff against latest BK bits can be downloaded from: http://www.mipl.mediapoli.com/download/linux-2.5+mipv6.diff Latest userspace tools are found at: bk://bk.mipl.mediapoli.com/mipv6-tools More information of the project can be found at our website: http://www.mipl.mediapoli.com/ The team continues the development work to have fully RFC compliant (when the specification moves to RFC) implementation of Mobile IPv6 in the Linux kernel, as well as work on improving the code. On behalf of the MIPL Team, Antti Tuominen -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From pekkas@netcore.fi Wed Oct 2 02:26:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 02:26:10 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g929Q3tG015760 for ; Wed, 2 Oct 2002 02:26:04 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g929Pb827895; Wed, 2 Oct 2002 12:25:37 +0300 Date: Wed, 2 Oct 2002 12:25:37 +0300 (EEST) From: Pekka Savola To: Antti Tuominen cc: davem@redhat.com, , , , Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) In-Reply-To: <20021002092111.GB17010@morphine.tml.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 467 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 MIPL implements an old version of MIPv6 (draft -15 or so). Or do you support -18 ? On Wed, 2 Oct 2002, Antti Tuominen wrote: > Hello Dave, Alexey, and all, > > I am part of the MIPL Mobile IPv6 for Linux Team at Helsinki > University of Technology, and we have been working on an > implementation of Mobility Support in IPv6 specification for the past > 3 years. Now the code has matured to the point, that we feel > confident enough to ask for kernel inclusion. > > Our implementation has been to several interop and conformance testing > events, and has proven to be very compliant and to interoperate with > all major vendors' implementations. Code has been tested on several > UP and SMP configurations, and performs quite well. > > Implementation consists of two kernel modules, changes to IPv6 stack, > and userspace configuration tools. First module provides support for > 6over6 (IPv6 in IPv6) tunneling. Second module is the Mobile IPv6 > module, and adds support for Mobile IPv6 Correspondent Node, Mobile > Node, and Home Agent. IPv6 stack has been modified to provide some > MIPv6 mandated features as well as hooks to our module. > > Latest code for 2.5 series can be pulled from our public BitKeeper > repository (parent is http://linux.bkbits.net/linux-2.5): > bk://bk.mipl.mediapoli.com/linux25-mipl > > Diff against latest BK bits can be downloaded from: > http://www.mipl.mediapoli.com/download/linux-2.5+mipv6.diff > > Latest userspace tools are found at: > bk://bk.mipl.mediapoli.com/mipv6-tools > > More information of the project can be found at our website: > http://www.mipl.mediapoli.com/ > > The team continues the development work to have fully RFC compliant > (when the specification moves to RFC) implementation of Mobile IPv6 in > the Linux kernel, as well as work on improving the code. > > On behalf of the MIPL Team, > > Antti Tuominen > > -- 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 yoshfuji@wide.ad.jp Wed Oct 2 02:31:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 02:31:23 -0700 (PDT) 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 g929VKtG017468 for ; Wed, 2 Oct 2002 02:31:21 -0700 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 g929VD1o013573; Wed, 2 Oct 2002 18:31:13 +0900 Date: Wed, 02 Oct 2002 18:31:13 +0900 (JST) Message-Id: <20021002.183113.16291158.yoshfuji@wide.ad.jp> To: pekkas@netcore.fi Cc: ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021002092111.GB17010@morphine.tml.hut.fi> 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-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: 468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev In article (at Wed, 2 Oct 2002 12:25:37 +0300 (EEST)), Pekka Savola says: > I believe MIPL implements an old version of MIPv6 (draft -15 or so). > > Or do you support -18 ? We believe we should do -18, not -15 at all. --yoshfuji From pekkas@netcore.fi Wed Oct 2 02:33:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 02:33:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g929XftG017838 for ; Wed, 2 Oct 2002 02:33:42 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g929XLL27969; Wed, 2 Oct 2002 12:33:21 +0300 Date: Wed, 2 Oct 2002 12:33:21 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: ajtuomin@morphine.tml.hut.fi, , , , , Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) In-Reply-To: <20021002.183113.16291158.yoshfuji@wide.ad.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 469 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 Wed, 2 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Wed, 2 Oct 2002 12:25:37 +0300 (EEST)), Pekka Savola says: > > > I believe MIPL implements an old version of MIPv6 (draft -15 or so). > > > > Or do you support -18 ? > > We believe we should do -18, not -15 at all. Well, www.mipl.mediapoli.com front page at least refers to -15, but you should know better :-) -- 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 yoshfuji@wide.ad.jp Wed Oct 2 02:44:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 02:44:24 -0700 (PDT) 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 g929iLtG019461 for ; Wed, 2 Oct 2002 02:44:22 -0700 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 g929iI1o013674; Wed, 2 Oct 2002 18:44:18 +0900 Date: Wed, 02 Oct 2002 18:44:18 +0900 (JST) Message-Id: <20021002.184418.121132248.yoshfuji@wide.ad.jp> To: pekkas@netcore.fi Cc: ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021002.183113.16291158.yoshfuji@wide.ad.jp> 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-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: 470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev In article (at Wed, 2 Oct 2002 12:33:21 +0300 (EEST)), Pekka Savola says: > On Wed, 2 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > > In article (at Wed, 2 Oct 2002 12:25:37 +0300 (EEST)), Pekka Savola says: > > > > > I believe MIPL implements an old version of MIPv6 (draft -15 or so). > > > > > > Or do you support -18 ? > > > > We believe we should do -18, not -15 at all. > > Well, www.mipl.mediapoli.com front page at least refers to -15, but you > should know better :-) I meant, we should go with -18 (or later). (If the MIPL supports only -15,) -15 is too old. --yoshfuji From yoshfuji@wide.ad.jp Wed Oct 2 02:46:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 02:46:08 -0700 (PDT) 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 g929k5tG020362 for ; Wed, 2 Oct 2002 02:46:06 -0700 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 g929k81o013717; Wed, 2 Oct 2002 18:46:08 +0900 Date: Wed, 02 Oct 2002 18:46:07 +0900 (JST) Message-Id: <20021002.184607.73791540.yoshfuji@wide.ad.jp> To: ajtuomin@morphine.tml.hut.fi Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021002092111.GB17010@morphine.tml.hut.fi> References: <20021002092111.GB17010@morphine.tml.hut.fi> 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-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: 471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev In article <20021002092111.GB17010@morphine.tml.hut.fi> (at Wed, 2 Oct 2002 12:21:11 +0300), Antti Tuominen says: > Diff against latest BK bits can be downloaded from: > http://www.mipl.mediapoli.com/download/linux-2.5+mipv6.diff % wget http://www.mipl.mediapoli.com/download/linux-2.5+mipv6.diff --18:45:25-- http://www.mipl.mediapoli.com/download/linux-2.5+mipv6.diff => `linux-2.5+mipv6.diff' Resolving www.mipl.mediapoli.com... done. Connecting to www.mipl.mediapoli.com[212.68.2.195]:80... connected. HTTP request sent, awaiting response... 403 Forbidden 18:45:25 ERROR 403: Forbidden. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ajtuomin@tml.hut.fi Wed Oct 2 04:04:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 04:04:38 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92B4UtG022382 for ; Wed, 2 Oct 2002 04:04:31 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA22663 for ; Wed, 2 Oct 2002 14:04:29 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma022646; Wed, 2 Oct 02 14:04:24 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g92B4N21005589; Wed, 2 Oct 2002 14:04:23 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g92B4IF5017487; Wed, 2 Oct 2002 14:04:23 +0300 (EEST) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g92B4HFe017486; Wed, 2 Oct 2002 14:04:17 +0300 (EEST) Date: Wed, 2 Oct 2002 14:04:17 +0300 From: Antti Tuominen To: "YOSHIFUJI Hideaki / 吉藤英明" Cc: pekkas@netcore.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) Message-ID: <20021002110416.GC17010@morphine.tml.hut.fi> References: <20021002.183113.16291158.yoshfuji@wide.ad.jp> <20021002.184418.121132248.yoshfuji@wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021002.184418.121132248.yoshfuji@wide.ad.jp> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g92B4UtG022382 X-archive-position: 472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Wed, Oct 02, 2002 at 06:44:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > In article (at Wed, 2 Oct 2002 12:33:21 +0300 (EEST)), Pekka Savola says: > > > On Wed, 2 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > > > In article (at Wed, 2 Oct 2002 12:25:37 +0300 (EEST)), Pekka Savola says: > > > > > > > I believe MIPL implements an old version of MIPv6 (draft -15 or so). > > > > > > > > Or do you support -18 ? > > > > > > We believe we should do -18, not -15 at all. > > > > Well, www.mipl.mediapoli.com front page at least refers to -15, but you > > should know better :-) > > I meant, we should go with -18 (or later). > (If the MIPL supports only -15,) -15 is too old. We do support Draft 18 in our development code (tested last week at ETSI IPv6 Plugtest and mostly working), but since Draft 15 was the last implementable draft (no _draft_ issues, compared to large number of inconcistencies and contradictions in draft 18) and we've had time to test the code properly, we decided to submit working code over latest code. Draft 15 based code is tested and works. To get Mobile IPv6 in the kernel we felt that it is more important to have solid, tested code rather than our latest devel code for the submission. Of course we are committed to providing the latest draft revision compliant code immediately when it's available. But we don't feel draft 18 is the answer since draft 19 will soon be out and should address rest of the 126 issues raised about drafts 16, 17 and 18. If the kernel maintainers feel differently, we are happy to provide you with our latest code implementing most of draft 18. Regards, Antti -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From ajtuomin@tml.hut.fi Wed Oct 2 04:08:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 04:08:43 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92B8ctG022979 for ; Wed, 2 Oct 2002 04:08:39 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA22723 for ; Wed, 2 Oct 2002 14:08:38 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma022711; Wed, 2 Oct 02 14:08:29 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g92B8T21005612; Wed, 2 Oct 2002 14:08:29 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g92B8SF5017511; Wed, 2 Oct 2002 14:08:28 +0300 (EEST) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g92B8S9x017510; Wed, 2 Oct 2002 14:08:28 +0300 (EEST) Date: Wed, 2 Oct 2002 14:08:28 +0300 From: Antti Tuominen To: "YOSHIFUJI Hideaki / 吉藤英明" Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: Re: [PATCH] Mobile IPv6 for 2.5.40 (request for kernel inclusion) Message-ID: <20021002110828.GD17010@morphine.tml.hut.fi> References: <20021002092111.GB17010@morphine.tml.hut.fi> <20021002.184607.73791540.yoshfuji@wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021002.184607.73791540.yoshfuji@wide.ad.jp> User-Agent: Mutt/1.4i X-archive-position: 473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Wed, Oct 02, 2002 at 06:46:07PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > Resolving www.mipl.mediapoli.com... done. > Connecting to www.mipl.mediapoli.com[212.68.2.195]:80... connected. > HTTP request sent, awaiting response... 403 Forbidden > 18:45:25 ERROR 403: Forbidden. Sorry about that. Apache had some strange rule denying download of files with .diff suffix. Now works. Add .gz to the url for gzipped version. Regards, Antti -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From Eric.Lemoine@ens-lyon.fr Wed Oct 2 06:08:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 06:08:07 -0700 (PDT) Received: from mailhost.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92D83tG025714 for ; Wed, 2 Oct 2002 06:08:04 -0700 Received: from [140.77.13.123] (helo=[140.77.13.123]) by mailhost.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 17whRW-0008DZ-00; Wed, 02 Oct 2002 13:13:26 +0200 Received: from eric by (null) with local (MasqMail 0.1.16) id 17whRW-0BG-00; Wed, 02 Oct 2002 13:13:26 +0200 Date: Wed, 2 Oct 2002 13:13:26 +0200 From: Eric Lemoine To: kuznet@ms2.inr.ac.ru Cc: Chris Friesen , hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness Message-ID: <20021002111326.GG357@hookipa> References: <3D99B6C7.3010302@nortelnetworks.com> <200210011531.TAA19943@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210011531.TAA19943@sex.inr.ac.ru> User-Agent: Mutt/1.3.28i X-Warning: return path set from From: address X-archive-position: 474 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 may have to poke around...if nothing else I'll learn more about the > > networking code... > > It is difficult task, if possible at all. > > The main obstacle is that we must not block after select() succeeded, > otherwise applications will lockup. Taking into account nature of datagram > services (and generally of networking services, where routes change et al.) > you do not know at time of select(), where the datagram will go. > So, blocking can be made only based on a criterium not depending on this. > problems with silent losses. People just do not care about this, so > they get the thing which they deserve. Alexey, Would you mind explaining a bit more why apps will lockup if we block after select() succeeded. Or anyone? Thx. Eric. From cfriesen@nortelnetworks.com Wed Oct 2 07:10:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 07:10:46 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92EAftG001462 for ; Wed, 2 Oct 2002 07:10:41 -0700 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g92E9Ne15656; Wed, 2 Oct 2002 10:09:23 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9BXLTQT; Wed, 2 Oct 2002 10:09:25 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK1SR4G; Wed, 2 Oct 2002 10:09:25 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 6A4D12E134; Wed, 2 Oct 2002 10:09:24 -0400 (EDT) Message-ID: <3D9AFE14.4030606@nortelnetworks.com> Date: Wed, 02 Oct 2002 10:09:24 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Eric Lemoine Cc: kuznet@ms2.inr.ac.ru, hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <3D99B6C7.3010302@nortelnetworks.com> <200210011531.TAA19943@sex.inr.ac.ru> <20021002111326.GG357@hookipa> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Eric Lemoine wrote: > Would you mind explaining a bit more why apps will lockup if we block > after select() succeeded. Or anyone? I suspect he means a temporary lockup. There are many apps that use blocking sockets and rely on select() to tell them when they may write out to the socket without blocking. If the write then blocks, the whole app is blocked. Some of them probably wouldn't like this. Was that it Alexey? Or is there something more that I missed? Chris From greearb@candelatech.com Wed Oct 2 08:29:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 08:29:31 -0700 (PDT) Received: from grok.yi.org (IDENT:XvzdN63Fi9D82MGETDFySHeTXsx87E/s@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92FTQtG008373 for ; Wed, 2 Oct 2002 08:29:26 -0700 Received: from candelatech.com (IDENT:GzyoO8qV5hUiED1VCAOVJipCWjwxhl0f@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g92FPbv26485; Wed, 2 Oct 2002 08:25:38 -0700 Message-ID: <3D9B0FF1.1070203@candelatech.com> Date: Wed, 02 Oct 2002 08:25:37 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Lemoine CC: kuznet@ms2.inr.ac.ru, Chris Friesen , hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness References: <3D99B6C7.3010302@nortelnetworks.com> <200210011531.TAA19943@sex.inr.ac.ru> <20021002111326.GG357@hookipa> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 476 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 Eric Lemoine wrote: >>>I may have to poke around...if nothing else I'll learn more about the >>>networking code... >> >>It is difficult task, if possible at all. >> >>The main obstacle is that we must not block after select() succeeded, >>otherwise applications will lockup. Taking into account nature of datagram >>services (and generally of networking services, where routes change et al.) >>you do not know at time of select(), where the datagram will go. >>So, blocking can be made only based on a criterium not depending on this. >>problems with silent losses. People just do not care about this, so >>they get the thing which they deserve. > > > Alexey, > > Would you mind explaining a bit more why apps will lockup if we block > after select() succeeded. Or anyone? Actually, I'm more interested to know why we would **need** to block after select has succeeded. It would seem to me that select is busted in this case. For the case of a very large UDP packet and a small send buffer, select gets confused, but at least when the send buffer is > 128k, it should be right... > > Thx. > > Eric. > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From yoshfuji@linux-ipv6.org Wed Oct 2 09:51:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 09:51:09 -0700 (PDT) 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 g92Gp6tG013806 for ; Wed, 2 Oct 2002 09:51:06 -0700 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 g92GpE1o016333; Thu, 3 Oct 2002 01:51:14 +0900 Date: Thu, 03 Oct 2002 01:50:57 +0900 (JST) Message-Id: <20021003.015057.14743018.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Default Router Selection Round-robin 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-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: 477 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! Linux changes default router even while it is probably reachable. Once it becomes "non-REACHABLE," Linux trys to select one in round-robin fashion, but once it reached end of list, it would be stuck there. Here's the patch against 2.4.19. Thank you in advance. ------------------------------------------------------------------- Patch-Name: Default Router Selection Round-robin Patch-Id: FIX_2_4_19_DEFRTR_SELECT-20020919 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project Reference: RFC2461 ------------------------------------------------------------------- Index: net/ipv6/route.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/route.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.14.1 diff -u -r1.1.1.1 -r1.1.1.1.14.1 --- net/ipv6/route.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/route.c 2002/09/19 16:28:03 1.1.1.1.14.1 @@ -13,6 +13,17 @@ * 2 of the License, or (at your option) any later version. */ +/* Changes: + * + * YOSHIFUJI Hideaki @USAGI + * reworked default router selection. + * - respect outgoing interface + * - select from (probably) reachable routers (i.e. + * routers in REACHABLE, STALE, DELAY or PROBE states). + * - always select the same router if it is (probably) + * reachable. otherwise, round-robin the list. + */ + #include #include #include @@ -168,6 +179,7 @@ static struct rt6_info *rt6_dflt_pointer = NULL; static spinlock_t rt6_dflt_lock = SPIN_LOCK_UNLOCKED; +/* Default Router Selection (RFC 2461 6.3.6) */ static struct rt6_info *rt6_best_dflt(struct rt6_info *rt, int oif) { struct rt6_info *match = NULL; @@ -176,63 +188,117 @@ for (sprt = rt; sprt; sprt = sprt->u.next) { struct neighbour *neigh; + int m = 0; - if ((neigh = sprt->rt6i_nexthop) != NULL) { - int m = -1; + if (!oif || + (sprt->rt6i_dev && + sprt->rt6i_dev->ifindex == oif)) + m += 8; + if (sprt == rt6_dflt_pointer) + m += 4; + + if ((neigh = sprt->rt6i_nexthop) != NULL) { + read_lock_bh(&neigh->lock); switch (neigh->nud_state) { case NUD_REACHABLE: - if (sprt != rt6_dflt_pointer) { - rt = sprt; - goto out; - } - m = 2; + m += 3; break; + case NUD_STALE: case NUD_DELAY: - m = 1; + case NUD_PROBE: + m += 2; break; - case NUD_STALE: - m = 1; + case NUD_NOARP: + case NUD_PERMANENT: + m += 1; break; - }; - if (oif && sprt->rt6i_dev->ifindex == oif) { - m += 2; + case NUD_INCOMPLETE: + default: + read_unlock_bh(&neigh->lock); + continue; } + read_unlock_bh(&neigh->lock); + } else { + continue; + } - if (m >= mpri) { - mpri = m; - match = sprt; + if (m > mpri || m >= 12) { + match = sprt; + mpri = m; + if (m >= 12) { + /* we choose the lastest default router if it + * is in (probably) reachable state. + * If route changed, we should do pmtu + * discovery. --yoshfuji + */ + break; } } } - if (match) { - rt = match; - } else { + spin_lock(&rt6_dflt_lock); + if (!match) { /* * No default routers are known to be reachable. * SHOULD round robin */ - spin_lock(&rt6_dflt_lock); if (rt6_dflt_pointer) { - struct rt6_info *next; - - if ((next = rt6_dflt_pointer->u.next) != NULL && - next->u.dst.obsolete <= 0 && - next->u.dst.error == 0) - rt = next; + for (sprt = rt6_dflt_pointer->u.next; + sprt; sprt = sprt->u.next) { + if (sprt->u.dst.obsolete <= 0 && + sprt->u.dst.error == 0) { + match = sprt; + break; + } + } + for (sprt = rt; + !match && sprt && sprt != rt6_dflt_pointer; + sprt = sprt->u.next) { + if (sprt->u.dst.obsolete <= 0 && + sprt->u.dst.error == 0) { + match = sprt; + break; + } + } } - spin_unlock(&rt6_dflt_lock); } -out: - spin_lock(&rt6_dflt_lock); - rt6_dflt_pointer = rt; + if (match) { + if (rt6_dflt_pointer != match) + RT6_TRACE1(KERN_INFO + "changed default router: %p->%p\n", + rt6_dflt_pointer, match); + rt6_dflt_pointer = match; + } spin_unlock(&rt6_dflt_lock); - return rt; + + if (!match) { + /* + * Last Resort: if no default routers found, + * use addrconf default route. + * We don't record this route. + */ + for (sprt = ip6_routing_table.leaf; + sprt; sprt = sprt->u.next) { + if ((sprt->rt6i_flags & RTF_DEFAULT) && + (!oif || + (sprt->rt6i_dev && + sprt->rt6i_dev->ifindex == oif))) { + match = sprt; + break; + } + } + if (!match) { + /* no default route. give up. */ + match = &ip6_null_entry; + } + } + + return match; } struct rt6_info *rt6_lookup(struct in6_addr *daddr, struct in6_addr *saddr, -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ratz@drugphish.ch Wed Oct 2 10:37:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 10:37:11 -0700 (PDT) Received: from mailphish.drugphish.ch (adsl-196-233.cybernet.ch [212.90.196.233]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92Hb7tG015436 for ; Wed, 2 Oct 2002 10:37:08 -0700 Received: from drugphish.ch (unknown [158.64.76.6]) by mailphish.drugphish.ch (drugphish mail transportation agency) with ESMTP id E2C162EC9; Wed, 2 Oct 2002 17:28:40 +0000 (/etc/localtime) Message-ID: <3D9B2EBC.4010102@drugphish.ch> Date: Wed, 02 Oct 2002 19:37:00 +0200 From: Roberto Nibali User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Davidsen Cc: linux-kernel@vger.kernel.org, netdev Subject: Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ratz@drugphish.ch Precedence: bulk X-list: netdev Hi, >>I will do a new round of testing this weekend for a speech I'll be >>giving. This time I will include ipchains, iptables (of course I am >>willing to apply every interesting patch regarding hash table >>optimisation and whatnot you want me to test), nf-hipac, the OpenBSD pf >>and of course the work done by Jamal. > > Look forward to any info you can provide. Unfortunately (as always) there were tons of delays that didn't allow me to finish the complete test suite as I hoped I could but I sent some information off this list to Jamal and the nf-hipac guys about previous test result. See below. I hope I can do more tests this weekend ... > I particularly like that nf-hipac can be put in and tried in one-to-one > comparison, that leaves an easy route to testing and getting confidence in > the code. Yes and it was very convincing after the first few tests Some prelimiary test with raw TCP throughput have given me following really cool results: TCP RAW throughput 100Mbit/s max MTU: ------------------------------------- ratz@laphish:~/netperf-2.2pl2 > ./netperf -H 192.168.1.141 -p 6666 -l 60 TCP STREAM TEST to 192.168.1.141 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/s 87380 16384 16384 60.01 88.03 <------ ratz@laphish:~/netperf-2.2pl2 > TCP RAW throughput 100Mbit/s max MTU with 10000 non-matching rules + 1 last matching rule at the end of the FORWARD chain [iptables]: ---------------------------------------------------------------------- ratz@laphish:~/netperf-2.2pl2 > ./netperf -H 192.168.1.141 -p 6666 -l 60 TCP STREAM TEST to 192.168.1.141 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 60.12 3.28 <------ ratz@laphish:~/netperf-2.2pl2 > TCP RAW throughput 100Mbit/s max MTU with 10000 non-matching rules + 1 last matching rule at the end of the FORWARD chain [nf-hipac]: ---------------------------------------------------------------------- ratz@laphish:~/netperf-2.2pl2 > ./netperf -H 192.168.1.141 -p 6666 -l 60 TCP STREAM TEST to 192.168.1.141 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 60.03 85.78 <------ ratz@laphish:~/netperf-2.2pl2 > For nf-hipac I also have some statistics: ----------------------------------------- bloodyhell:/var/FWTEST/nf-hipac # cat /proc/net/nf-hipac nf-hipac statistics ------------------- Maximum available memory: 65308672 bytes Currently used memory: 1764160 bytes INPUT: - INPUT chain is empty FORWARD: - Number of rules: 10002 - Total size: 1033010 bytes - Total size (allocated): 1764160 bytes - Termrule size: 80016 bytes - Termrule size (allocated): 320064 bytes - Number of btrees: 30007 * number of u32 btrees: 10003 + distribution of u32 btrees: [ 2, 4]: 10002 [ 16384, 32768]: 1 * number of u16 btrees: 10002 + distribution of u16 btrees: [ 1, 2]: 10002 * number of u8 btrees: 10002 + distribution of u8 btrees: [ 2, 4]: 18 OUTPUT: - OUTPUT chain is empty bloodyhell:/var/FWTEST/nf-hipac # Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc From kuznet@ms2.inr.ac.ru Wed Oct 2 12:24:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 12:24:14 -0700 (PDT) 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 g92JO8tG019032 for ; Wed, 2 Oct 2002 12:24:09 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA26368; Wed, 2 Oct 2002 23:22:41 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210021922.XAA26368@sex.inr.ac.ru> Subject: Re: [PATCH] IPv6: Default Router Selection Round-robin To: yoshfuji@linux-ipv6.ORG (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Wed, 2 Oct 2002 23:22:41 +0400 (MSD) Cc: netdev@oss.sgi.com, davem@redhat.com (Dave Miller) In-Reply-To: <20021003.015057.14743018.yoshfuji@linux-ipv6.org> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at Oct 2, 2 09:15:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 479 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! > Linux changes default router even while it is probably reachable. > Once it becomes "non-REACHABLE," Linux trys to select one in round-robin > fashion, but once it reached end of list, it would be stuck there. The patch looks perfect. Alexey From steve@gw.chygwyn.com Wed Oct 2 14:05:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 14:05:17 -0700 (PDT) Received: from gw.chygwyn.com (IDENT:root@gw.chygwyn.com [62.172.158.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g92L57tG022858 for ; Wed, 2 Oct 2002 14:05:08 -0700 Received: (from steve@localhost) by gw.chygwyn.com (8.9.3/8.9.3) id WAA25884; Wed, 2 Oct 2002 22:08:47 +0100 From: Steven Whitehouse Message-Id: <200210022108.WAA25884@gw.chygwyn.com> Subject: Network stack AIO in 2.5 To: davem@redhat.com, bcrl@redhat.com Date: Wed, 2 Oct 2002 22:08:47 +0100 (BST) Cc: netdev@oss.sgi.com Organization: ChyGywn Limited X-RegisteredOffice: 7, New Yatt Road, Witney, Oxfordshire. OX28 1NU England X-RegisteredNumber: 03887683 Reply-To: Steve Whitehouse X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@gw.chygwyn.com Precedence: bulk X-list: netdev Hi, What is the current status of AIO for the network stack in 2.5 ? Are there patches somewhere (I looked but didn't find any) or is it a matter of porting from the 2.4 AIO or are there still design issues to be resolved ? Steve. From davem@redhat.com Wed Oct 2 17:15:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 17:15:51 -0700 (PDT) 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 g930FntG000749 for ; Wed, 2 Oct 2002 17:15:49 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA26385; Wed, 2 Oct 2002 17:08:32 -0700 Date: Wed, 02 Oct 2002 17:08:31 -0700 (PDT) Message-Id: <20021002.170831.13760613.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Default Router Selection Round-robin From: "David S. Miller" In-Reply-To: <20021003.015057.14743018.yoshfuji@linux-ipv6.org> References: <20021003.015057.14743018.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 481 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 yoshfuji@linux-ipv6.org Wed Oct 2 20:13:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 20:13:52 -0700 (PDT) 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 g933DitG016055 for ; Wed, 2 Oct 2002 20:13:44 -0700 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 g933Do1o019704; Thu, 3 Oct 2002 12:13:50 +0900 Date: Thu, 03 Oct 2002 12:13:50 +0900 (JST) Message-Id: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) 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-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: 482 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! Linux IPv6 stack provides the ability for IPv6 applications to interoperate with IPv4 applications. Port space for TCP (or UDP) is shared by IPv6 and IPv4. This conforms to RFC2553. However, some kind of applications may want to restrict their use of an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is defined for such applications in RFC2553bis, which is successor of RFC2553. This patch allows to bind both IPv6 and IPv4 sockets with the single port number at the same time if IPV6_V6ONLY socket options is set to the IPv6 socket. We also prohibit a completely duplicate set of (local-addr, local-port, remote-addr, remote-port) set even if SO_REUSEADDR is set unless the local address is a multicast address; it is ambiguous and it may steal packets from others; i.e. a kind of DoS. Packet delivery strategy is similar to one before, but we prefer IPv4 a bit. Following patch is against linux-2.4.19. Thank you in advance. ------------------------------------------------------------------- Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) Patch-Id: FIX_2_4_19_DOUBLEBIND-20020909 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project Reference: RFC2553bis ------------------------------------------------------------------- Index: include/linux/in6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- include/linux/in6.h 2002/08/20 09:46:34 1.1.1.1 +++ include/linux/in6.h 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -156,6 +156,7 @@ #define IPV6_MTU_DISCOVER 23 #define IPV6_MTU 24 #define IPV6_RECVERR 25 +#define IPV6_V6ONLY 26 /* IPV6_MTU_DISCOVER values */ #define IPV6_PMTUDISC_DONT 0 @@ -167,4 +168,19 @@ #define IPV6_FLOWINFO_SEND 33 +#ifdef __KERNEL__ +#ifndef IN6_IS_ADDR_UNSPECIFIED +#define IN6_IS_ADDR_UNSPECIFIED(a) \ + ((((a)->s6_addr32[0]) == 0) && \ + (((a)->s6_addr32[1]) == 0) && \ + (((a)->s6_addr32[2]) == 0) && \ + (((a)->s6_addr32[3]) == 0)) +#endif +#ifndef IN6_IS_ADDR_V4MAPPED +#define IN6_IS_ADDR_V4MAPPED(a) \ + ((((a)->s6_addr32[0]) == 0) && \ + (((a)->s6_addr32[1]) == 0) && \ + (((a)->s6_addr32[2]) == __constant_htonl(0x0000ffff))) +#endif +#endif #endif Index: include/linux/sysctl.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- include/linux/sysctl.h 2002/08/20 09:46:34 1.1.1.1 +++ include/linux/sysctl.h 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -369,7 +369,8 @@ 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_BINDV6ONLY=11 }; /* /proc/sys/net//neigh/ */ Index: include/net/if_inet6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/if_inet6.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- include/net/if_inet6.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/if_inet6.h 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -86,6 +86,7 @@ int rtr_solicits; int rtr_solicit_interval; int rtr_solicit_delay; + int bindv6only; void *sysctl; }; Index: include/net/sock.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- include/net/sock.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/sock.h 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -171,7 +171,8 @@ __u8 mc_loop:1, recverr:1, sndflow:1, - pmtudisc:2; + pmtudisc:2, + ipv6only:1; struct ipv6_mc_socklist *ipv6_mc_list; struct ipv6_fl_socklist *ipv6_fl_list; Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_ipv4.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -45,6 +45,14 @@ * Vitaly E. Lavrov : Transparent proxy revived after year coma. * Andi Kleen : Fix new listen. * Andi Kleen : Fix accept error reporting. + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior including: + * - Allow ipv6 and ipv4 bind(2) to the + * same port if IPV6_V6ONLY socket option + * is set. + * - Don't allow binding to the same + * address unless it is one of multi- + * cast address even if SO_REUSEADDR + * is set. */ #include @@ -177,23 +185,92 @@ static inline int tcp_bind_conflict(struct sock *sk, struct tcp_bind_bucket *tb) { struct sock *sk2 = tb->owners; - int sk_reuse = sk->reuse; + int sk_reuse, sk2_reuse; + int addr_type2; + int ret; + + sk_reuse = 0; + if (sk->reuse) + sk_reuse |= 1; for( ; sk2 != NULL; sk2 = sk2->bind_next) { - if (sk != sk2 && - sk2->reuse <= 1 && - sk->bound_dev_if == sk2->bound_dev_if) { - if (!sk_reuse || - !sk2->reuse || - sk2->state == TCP_LISTEN) { - if (!sk2->rcv_saddr || - !sk->rcv_saddr || - (sk2->rcv_saddr == sk->rcv_saddr)) - break; + int both_specified = 0; + + if (sk2 == sk || + (sk2->bound_dev_if && sk->bound_dev_if && + sk2->bound_dev_if != sk->bound_dev_if)) + continue; + +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + if (sk2->family == AF_INET6) { + struct in6_addr *sk2_rcv_saddr6 = sk2->state != TCP_TIME_WAIT ? + &sk2->net_pinfo.af_inet6.rcv_saddr : + &((struct tcp_tw_bucket*)sk2)->v6_rcv_saddr; + if (IN6_IS_ADDR_UNSPECIFIED(sk2_rcv_saddr6)) + addr_type2 = IPV6_ADDR_ANY; + else if (IN6_IS_ADDR_V4MAPPED(sk2_rcv_saddr6)) + addr_type2 = IPV6_ADDR_MAPPED; + else + addr_type2 = IPV6_ADDR_UNICAST; /*XXX*/ + } else + addr_type2 = IPV6_ADDR_MAPPED; +#else + addr_type2 = IPV6_ADDR_MAPPED; +#endif + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && + sk->rcv_saddr) { + if (sk2->rcv_saddr != sk->rcv_saddr) + continue; + both_specified = 1; + } + +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + if (addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only) { + continue; + } +#endif + + sk2_reuse = 0; + if (sk2->reuse) + sk2_reuse |= 1; + + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ + ret = 1; + if (both_specified) { +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + struct in6_addr *sk2_daddr6 = sk2->state != TCP_TIME_WAIT ? + &sk2->net_pinfo.af_inet6.daddr : + &((struct tcp_tw_bucket*)sk2)->v6_daddr; +#endif + int addr_type2d; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + if (sk2->family == AF_INET6) { + if (IN6_IS_ADDR_UNSPECIFIED(sk2_daddr6)) + addr_type2d = IPV6_ADDR_ANY; + else if (IN6_IS_ADDR_V4MAPPED(sk2_daddr6)) + addr_type2d = IPV6_ADDR_MAPPED; + else + addr_type2d = IPV6_ADDR_UNICAST; /*XXX*/ + } else + addr_type2d = IPV6_ADDR_MAPPED; +#else + addr_type2d = IPV6_ADDR_MAPPED; +#endif + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) + continue; + } else { + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || + sk->rcv_saddr) + continue; } } + ret = 1; + goto failed; } - return sk2 != NULL; + /* If we found a conflict, fail. */ + ret = sk2 != NULL; +failed: + return ret; } /* Obtain a reference to a local port for the given sock, @@ -247,10 +324,11 @@ break; } if (tb != NULL && tb->owners != NULL) { - if (sk->reuse > 1) + ret = 1; + if (tb->fastreuse > 0 && + sk->reuse != 0 && + sk->state != TCP_LISTEN) { goto success; - if (tb->fastreuse > 0 && sk->reuse != 0 && sk->state != TCP_LISTEN) { - goto success; } else { ret = 1; if (tcp_bind_conflict(sk, tb)) @@ -418,23 +496,31 @@ struct sock *result = NULL; int score, hiscore; - hiscore=0; + hiscore = -1; for(; sk; sk = sk->next) { if(sk->num == hnum) { __u32 rcv_saddr = sk->rcv_saddr; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + score = 0; + if (sk->family == PF_INET) + score++; + else if (sk->net_pinfo.af_inet6.ipv6only) + continue; +#else score = 1; +#endif if(rcv_saddr) { if (rcv_saddr != daddr) continue; - score++; + score+=2; } if (sk->bound_dev_if) { if (sk->bound_dev_if != dif) continue; - score++; + score+=2; } - if (score == 3) + if (score == 5) return sk; if (score > hiscore) { hiscore = score; @@ -456,6 +542,10 @@ if (sk->num == hnum && sk->next == NULL && (!sk->rcv_saddr || sk->rcv_saddr == daddr) && +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + (sk->family == PF_INET || + (sk->family == PF_INET6 && !sk->net_pinfo.af_inet6.ipv6only)) && +#endif !sk->bound_dev_if) goto sherry_cache; sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); Index: net/ipv4/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv4/udp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/udp.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -61,6 +61,14 @@ * return ENOTCONN for unconnected sockets (POSIX) * Janos Farkas : don't deliver multi/broadcasts to a different * bound-to-device socket + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: + * - Allow ipv6 and ipv4 bind(2) to the + * same port if IPV6_V6ONLY socket opttion is + * is set. + * - Don't allow binding to the same + * address unless it is one of multi- + * cast address even if SO_REUSEADDR + * is set. * * * This program is free software; you can redistribute it and/or @@ -85,6 +93,7 @@ #include #include #include +#include #include #include #include @@ -153,18 +162,88 @@ udp_port_rover = snum = result; } else { struct sock *sk2; + int sk_reuse, sk2_reuse; + int addr_type2; + sk_reuse = 0; + if (sk->reuse) + sk_reuse |= 1; + if (sk_reuse && + MULTICAST(sk->rcv_saddr)) + sk_reuse |= 4; + for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; sk2 != NULL; sk2 = sk2->next) { - if (sk2->num == snum && - sk2 != sk && - sk2->bound_dev_if == sk->bound_dev_if && - (!sk2->rcv_saddr || - !sk->rcv_saddr || - sk2->rcv_saddr == sk->rcv_saddr) && - (!sk2->reuse || !sk->reuse)) - goto fail; + int both_specified = 0; + + if (sk2->num != snum || + sk2 == sk || + (sk2->bound_dev_if && sk->bound_dev_if && + sk2->bound_dev_if != sk->bound_dev_if)) + continue; + +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + if (sk2->family == AF_INET6) { + if (IN6_IS_ADDR_UNSPECIFIED(&sk2->net_pinfo.af_inet6.rcv_saddr)) + addr_type2 = IPV6_ADDR_ANY; + else if (IN6_IS_ADDR_V4MAPPED(&sk2->net_pinfo.af_inet6.rcv_saddr)) + addr_type2 = IPV6_ADDR_MAPPED; + else + addr_type2 = IPV6_ADDR_UNICAST; /*XXX*/ + } else + addr_type2 = IPV6_ADDR_MAPPED; +#else + addr_type2 = IPV6_ADDR_MAPPED; +#endif + + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && + sk->rcv_saddr) { + if (sk2->rcv_saddr != sk->rcv_saddr) + continue; + both_specified = 1; + } + +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + if (addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only) { + continue; + } +#endif + + sk2_reuse = 0; + if (sk2->reuse) + sk2_reuse |= 1; + if (sk2_reuse && + (addr_type2 != IPV6_ADDR_MAPPED ? (addr_type2 & IPV6_ADDR_MULTICAST) : MULTICAST(sk2->rcv_saddr))) + sk2_reuse |= 4; + + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ + if (sk2_reuse & sk_reuse & 4) + continue; + if (both_specified) { + int addr_type2d; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + if (sk2->family == AF_INET6) { + if (IN6_IS_ADDR_UNSPECIFIED(&sk2->net_pinfo.af_inet6.daddr)) + addr_type2d = IPV6_ADDR_ANY; + else if (IN6_IS_ADDR_V4MAPPED(&sk2->net_pinfo.af_inet6.daddr)) + addr_type2d = IPV6_ADDR_MAPPED; + else + addr_type2d = IPV6_ADDR_UNICAST; /*XXX*/ + } else + addr_type2d = IPV6_ADDR_MAPPED; +#else + addr_type2d = IPV6_ADDR_MAPPED; +#endif + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) + continue; + } else { + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || + sk->rcv_saddr) + continue; + } + } + goto fail; } } sk->num = snum; @@ -216,28 +295,37 @@ for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { if(sk->num == hnum) { - int score = 0; + int score; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + score = 0; + if(sk->family == PF_INET) + score++; + else if (sk->net_pinfo.af_inet6.ipv6only) + continue; +#else + score = 1; +#endif if(sk->rcv_saddr) { if(sk->rcv_saddr != daddr) continue; - score++; + score+=2; } if(sk->daddr) { if(sk->daddr != saddr) continue; - score++; + score+=2; } if(sk->dport) { if(sk->dport != sport) continue; - score++; + score+=2; } if(sk->bound_dev_if) { if(sk->bound_dev_if != dif) continue; - score++; + score+=2; } - if(score == 4) { + if(score == 9) { result = sk; break; } else if(score > badness) { @@ -273,6 +361,9 @@ (s->daddr && s->daddr!=rmt_addr) || (s->dport != rmt_port && s->dport != 0) || (s->rcv_saddr && s->rcv_saddr != loc_addr) || +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + (s->family != PF_INET && s->net_pinfo.af_inet6.ipv6only) || +#endif (s->bound_dev_if && s->bound_dev_if != dif)) continue; break; Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -116,6 +116,7 @@ MAX_RTR_SOLICITATIONS, /* router solicits */ RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ + bindv6only: 0, }; static struct ipv6_devconf ipv6_devconf_dflt = @@ -130,6 +131,7 @@ MAX_RTR_SOLICITATIONS, /* router solicits */ RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ + bindv6only: 0, }; int ipv6_addr_type(struct in6_addr *addr) @@ -1879,7 +1881,7 @@ static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table addrconf_vars[11]; + ctl_table addrconf_vars[12]; ctl_table addrconf_dev[2]; ctl_table addrconf_conf_dir[2]; ctl_table addrconf_proto_dir[2]; @@ -1925,6 +1927,10 @@ {NET_IPV6_RTR_SOLICIT_DELAY, "router_solicitation_delay", &ipv6_devconf.rtr_solicit_delay, sizeof(int), 0644, NULL, &proc_dointvec_jiffies}, + + {NET_IPV6_BINDV6ONLY, "bindv6only", + &ipv6_devconf.bindv6only, sizeof(int), 0644, NULL, + &proc_dointvec}, {0}}, Index: net/ipv6/af_inet6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv6/af_inet6.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/af_inet6.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -173,6 +173,8 @@ sk->net_pinfo.af_inet6.mc_loop = 1; sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; + sk->net_pinfo.af_inet6.ipv6only = ipv6_devconf.bindv6only; + /* Init the ipv4 part of the socket since we can have sockets * using v6 API for ipv4. */ @@ -248,6 +250,8 @@ /* Check if the address belongs to the host. */ if (addr_type == IPV6_ADDR_MAPPED) { + if (sk->net_pinfo.af_inet6.ipv6only) + return -EADDRNOTAVAIL; v4addr = addr->sin6_addr.s6_addr32[3]; if (inet_addr_type(v4addr) != RTN_LOCAL) return -EADDRNOTAVAIL; Index: net/ipv6/ipv6_sockglue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv6/ipv6_sockglue.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/ipv6_sockglue.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -380,6 +380,15 @@ retv = ipv6_flowlabel_opt(sk, optval, optlen); break; + case IPV6_V6ONLY: + if (optlen != sizeof(int)) + goto e_inval; + if (sk->userlocks&SOCK_BINDADDR_LOCK) + goto e_inval; + np->ipv6only = valbool; + retv = 0; + break; + #ifdef CONFIG_NETFILTER default: retv = nf_setsockopt(sk, PF_INET6, optname, optval, @@ -520,6 +529,10 @@ case IPV6_FLOWINFO_SEND: val = np->sndflow; + break; + + case IPV6_V6ONLY: + val = np->ipv6only; break; default: Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv6/tcp_ipv6.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/tcp_ipv6.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -14,6 +14,14 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: + * - Allow ipv6 and ipv4 bind(2) to the + * same port if IPV6_V6ONLY socket + * option is set. + * - Don't allow binding to the same + * address unless it is one of multi- + * cast address even if SO_REUSEADDR + * is set. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -137,28 +145,70 @@ goto success; } else { struct sock *sk2 = tb->owners; - int sk_reuse = sk->reuse; - int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr); + int sk_reuse, sk2_reuse; + struct in6_addr *sk_rcv_saddr6 = sk->state != TCP_TIME_WAIT ? + &sk->net_pinfo.af_inet6.rcv_saddr: + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr; + int addr_type = ipv6_addr_type(sk_rcv_saddr6), + addr_type2; + + sk_reuse = 0; + if (sk->reuse) + sk_reuse |= 1; /* We must walk the whole port owner list in this case. -DaveM */ for( ; sk2 != NULL; sk2 = sk2->bind_next) { - if (sk != sk2 && - sk->bound_dev_if == sk2->bound_dev_if) { - if (!sk_reuse || - !sk2->reuse || - sk2->state == TCP_LISTEN) { - /* NOTE: IPv6 tw bucket have different format */ - if (!sk2->rcv_saddr || - addr_type == IPV6_ADDR_ANY || - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, - sk2->state != TCP_TIME_WAIT ? - &sk2->net_pinfo.af_inet6.rcv_saddr : - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && - sk->rcv_saddr==sk2->rcv_saddr)) - break; + int both_specified = 0; + struct in6_addr *sk2_rcv_saddr6; + if (sk2 == sk || + (sk2->bound_dev_if && sk->bound_dev_if && + sk2->bound_dev_if != sk->bound_dev_if)) + continue; + sk2_rcv_saddr6 = sk2->state != TCP_TIME_WAIT ? + &sk2->net_pinfo.af_inet6.rcv_saddr : + &((struct tcp_tw_bucket*)sk2)->v6_rcv_saddr; + + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) { + if (addr_type2 == IPV6_ADDR_MAPPED || addr_type == IPV6_ADDR_MAPPED) { + if (addr_type2 != addr_type || + sk2->rcv_saddr != sk->rcv_saddr) + continue; + } else { + if (ipv6_addr_cmp(sk2_rcv_saddr6, sk_rcv_saddr6)) + continue; } + both_specified = 1; } + + if ((addr_type2 == IPV6_ADDR_MAPPED && + addr_type != IPV6_ADDR_MAPPED && sk->net_pinfo.af_inet6.ipv6only) || + (addr_type == IPV6_ADDR_MAPPED && + addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only)) { + continue; + } + + sk2_reuse = 0; + if (sk2->reuse) + sk2_reuse |= 1; + + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ + ret = 1; + if (both_specified) { + struct in6_addr *sk2_daddr6 = sk2->state != TCP_TIME_WAIT ? + &sk2->net_pinfo.af_inet6.daddr : + &((struct tcp_tw_bucket*)sk2)->v6_daddr; + int addr_type2d = sk2->family == AF_INET6 ? ipv6_addr_type(sk2_daddr6) : IPV6_ADDR_MAPPED; + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) + continue; + } else { + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) + continue; + } + } + ret = 1; + goto fail_unlock; } /* If we found a conflict, fail. */ ret = 1; @@ -601,6 +651,9 @@ struct sockaddr_in sin; SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); + + if (sk->net_pinfo.af_inet6.ipv6only) + return -ENETUNREACH; sin.sin_family = AF_INET; sin.sin_port = usin->sin6_port; Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -u -r1.1.1.1 -r1.1.1.1.8.1 --- net/ipv6/udp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/udp.c 2002/09/11 03:30:27 1.1.1.1.8.1 @@ -11,7 +11,16 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: + * - Allow ipv6 and ipv4 bind(2) to the + * same port if IPV6_V6ONLY socket + * option is set. + * - Don't allow binding to the same + * address unless it is one of multi- + * cast address even if SO_REUSEADDR + * is set. * + * * 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 @@ -98,23 +107,72 @@ udp_port_rover = snum = result; } else { struct sock *sk2; - int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr); + int sk_reuse, sk2_reuse; + int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr), + addr_type2; + + sk_reuse = 0; + if (sk->reuse) + sk_reuse |= 1; + if (sk_reuse && + (addr_type != IPV6_ADDR_MAPPED ? (addr_type & IPV6_ADDR_MULTICAST) : MULTICAST(sk->rcv_saddr))) + sk_reuse |= 4; for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; sk2 != NULL; sk2 = sk2->next) { - if (sk2->num == snum && - sk2 != sk && - sk2->bound_dev_if == sk->bound_dev_if && - (!sk2->rcv_saddr || - addr_type == IPV6_ADDR_ANY || - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, - &sk2->net_pinfo.af_inet6.rcv_saddr) || - (addr_type == IPV6_ADDR_MAPPED && - sk2->family == AF_INET && - sk->rcv_saddr == sk2->rcv_saddr)) && - (!sk2->reuse || !sk->reuse)) - goto fail; + int both_specified = 0; + + if (sk2->num != snum || + sk2 == sk || + (sk2->bound_dev_if && sk->bound_dev_if && + sk2->bound_dev_if != sk->bound_dev_if)) + continue; + + addr_type2 = sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) : IPV6_ADDR_MAPPED; + + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) { + if (addr_type2 == IPV6_ADDR_MAPPED || addr_type == IPV6_ADDR_MAPPED) { + if (addr_type2 != addr_type || + sk2->rcv_saddr != sk->rcv_saddr) + continue; + } else { + if (ipv6_addr_cmp(&sk2->net_pinfo.af_inet6.rcv_saddr, + &sk->net_pinfo.af_inet6.rcv_saddr)) + continue; + } + both_specified = 1; + } + + if ((addr_type2 == IPV6_ADDR_MAPPED && + addr_type != IPV6_ADDR_MAPPED && sk->net_pinfo.af_inet6.ipv6only) || + (addr_type == IPV6_ADDR_MAPPED && + addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only)) { + continue; + } + + sk2_reuse = 0; + if (sk2->reuse) + sk2_reuse |= 1; + if (sk2_reuse && + (addr_type2 != IPV6_ADDR_MAPPED ? (addr_type2 & IPV6_ADDR_MULTICAST) : MULTICAST(sk2->rcv_saddr))) + sk2_reuse |= 4; + + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ + if (sk2_reuse & sk_reuse & 4) + continue; + if (both_specified) { + int addr_type2d = sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.daddr) : IPV6_ADDR_MAPPED; + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) + continue; + } else { + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) + continue; + } + } + goto fail; } } @@ -221,6 +279,8 @@ int err; if (usin->sin6_family == AF_INET) { + if (sk->net_pinfo.af_inet6.ipv6only) + return -EAFNOSUPPORT; err = udp_connect(sk, uaddr, addr_len); goto ipv4_connected; } @@ -256,6 +316,9 @@ if (addr_type == IPV6_ADDR_MAPPED) { struct sockaddr_in sin; + if (sk->net_pinfo.af_inet6.ipv6only) + return -ENETUNREACH; + sin.sin_family = AF_INET; sin.sin_addr.s_addr = daddr->s6_addr32[3]; sin.sin_port = usin->sin6_port; @@ -783,8 +846,11 @@ fl.oif = 0; if (sin6) { - if (sin6->sin6_family == AF_INET) + if (sin6->sin6_family == AF_INET) { + if (sk->net_pinfo.af_inet6.ipv6only) + return -EAFNOSUPPORT; return udp_sendmsg(sk, msg, ulen); + } if (addr_len < SIN6_LEN_RFC2133) return -EINVAL; @@ -830,6 +896,9 @@ if (addr_type == IPV6_ADDR_MAPPED) { struct sockaddr_in sin; + + if (sk->net_pinfo.af_inet6.ipv6only) + return -ENETUNREACH; sin.sin_family = AF_INET; sin.sin_addr.s_addr = daddr->s6_addr32[3]; From jmorris@intercode.com.au Wed Oct 2 20:31:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 20:31:36 -0700 (PDT) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g933VStG016771 for ; Wed, 2 Oct 2002 20:31:29 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id NAA13245; Thu, 3 Oct 2002 13:30:44 +1000 Date: Thu, 3 Oct 2002 13:30:44 +1000 (EST) From: James Morris To: Alan Cox cc: Martin Pool , "David S. Miller" , , , , Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case In-Reply-To: <1033388585.16337.9.camel@irongate.swansea.linux.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 483 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 30 Sep 2002, Alan Cox wrote: > Well if Dave can't test it and isnt doing any 2.2 who wants to be the > 2.2 networking maintainer ? > I'd be willing to give it a go. - James -- James Morris From httpd@dino.conectiva.com.br Wed Oct 2 20:53:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 20:53:24 -0700 (PDT) Received: from dino.conectiva.com.br (dino.conectiva.com.br [200.250.58.152]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g933rLtG017368 for ; Wed, 2 Oct 2002 20:53:22 -0700 Received: (from httpd@localhost) by dino.conectiva.com.br (8.9.3/8.9.3) id AAA16485; Thu, 3 Oct 2002 00:53:15 -0300 To: YOSHIFUJI@conectiva.com.br, UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) Message-ID: <1033617195.3d9bbf2b900e4@webmail.conectiva.com.br> Date: Thu, 03 Oct 2002 00:53:15 -0300 (BRST) From: acme@conectiva.com.br Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-archive-position: 485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Quoting YOSHIFUJI Hideaki / 吉藤英明 : > +#define IN6_IS_ADDR_V4MAPPED(a) \ > + ((((a)->s6_addr32[0]) == 0) && \ > + (((a)->s6_addr32[1]) == 0) && \ > + (((a)->s6_addr32[2]) == __constant_htonl(0x0000ffff))) Please use plain htonl, __constant_htonl is only needed in static initializations, in all other cases with constants as a parameter it generates the same code as htonl, so lets prefer using the shorter, more readable format. - Arnaldo From httpd@dino.conectiva.com.br Wed Oct 2 20:53:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 20:53:19 -0700 (PDT) Received: from dino.conectiva.com.br (dino.conectiva.com.br [200.250.58.152]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g933rBtG017328 for ; Wed, 2 Oct 2002 20:53:12 -0700 Received: (from httpd@localhost) by dino.conectiva.com.br (8.9.3/8.9.3) id AAA16474; Thu, 3 Oct 2002 00:53:01 -0300 To: YOSHIFUJI@conectiva.com.br, UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) Message-ID: <1033617181.3d9bbf1d557a3@webmail.conectiva.com.br> Date: Thu, 03 Oct 2002 00:53:01 -0300 (BRST) From: acme@conectiva.com.br Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> In-Reply-To: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-archive-position: 484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Quoting YOSHIFUJI Hideaki / 吉藤英明 : > +#define IN6_IS_ADDR_V4MAPPED(a) \ > + ((((a)->s6_addr32[0]) == 0) && \ > + (((a)->s6_addr32[1]) == 0) && \ > + (((a)->s6_addr32[2]) == __constant_htonl(0x0000ffff))) Please use plain htonl, __constant_htonl is only needed in static initializations, in all other cases with constants as a parameter it generates the same code as htonl, so lets prefer using the shorter, more readable format. - Arnaldo From acme@conectiva.com.br Wed Oct 2 20:55:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 20:55:29 -0700 (PDT) Received: from dino.conectiva.com.br (dino.conectiva.com.br [200.250.58.152]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g933tQtG018118 for ; Wed, 2 Oct 2002 20:55:27 -0700 Received: (from httpd@localhost) by dino.conectiva.com.br (8.9.3/8.9.3) id AAA16496; Thu, 3 Oct 2002 00:55:19 -0300 From: acme@conectiva.com.br X-Authentication-Warning: dino.conectiva.com.br: httpd set sender to acme@conectiva.com.br using -f To: yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) Message-ID: <1033617319.3d9bbfa7cd15e@webmail.conectiva.com.br> Date: Thu, 03 Oct 2002 00:55:19 -0300 (BRST) Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> In-Reply-To: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-archive-position: 486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Quoting YOSHIFUJI Hideaki / 吉藤英明 : > + (((a)->s6_addr32[2]) == __constant_htonl(0x0000ffff))) Please use plain htonl, __constant_htonl is only needed in static initializations, in all other cases with constants as a parameter it generates the same code as htonl, so lets prefer using the shorter, more readable format. - Arnaldo From andi@averellmail.firstfloor.org Wed Oct 2 20:56:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Oct 2002 20:56:09 -0700 (PDT) Received: from zero.aec.at (nichts@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g933u6tG018380 for ; Wed, 2 Oct 2002 20:56:07 -0700 Received: from averell.firstfloor.org (nichts@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id g933slF02011; Thu, 3 Oct 2002 05:54:50 +0200 Received: by averell.firstfloor.org (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 92BEA6A984; Thu, 3 Oct 2002 05:54:46 +0200 (CEST) Date: Thu, 3 Oct 2002 05:54:46 +0200 From: Andi Kleen To: James Morris Cc: Alan Cox , Martin Pool , "David S. Miller" , kuznet@ms2.inr.ac.ru, ak@muc.de, netdev@oss.sgi.com, Alan.Cox@linux.org Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Message-ID: <20021003035446.GA29860@averell> References: <1033388585.16337.9.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Thu, Oct 03, 2002 at 05:30:44AM +0200, James Morris wrote: > On 30 Sep 2002, Alan Cox wrote: > > > Well if Dave can't test it and isnt doing any 2.2 who wants to be the > > 2.2 networking maintainer ? > > > > I'd be willing to give it a go. 2.2 networking unfortunately has some more SMP bugs (DaveM can tell you details) which are hard to fix. So think twice before you volunteer ;) -Andi From pekkas@netcore.fi Thu Oct 3 00:00:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 00:00:28 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9370ItG021906 for ; Thu, 3 Oct 2002 00:00:19 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g93700S04849; Thu, 3 Oct 2002 10:00:01 +0300 Date: Thu, 3 Oct 2002 10:00:00 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: linux-kernel@vger.kernel.org, , Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) In-Reply-To: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 488 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 Please add a short description of 'bindv6only' in Documentation/networking/ip-sysctl.txt. This toggle seems usable only in interface "all" context. Didn't really look at the rest of the patch. On Thu, 3 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > Hello! > > Linux IPv6 stack provides the ability for IPv6 applications to > interoperate with IPv4 applications. Port space for TCP (or UDP) is > shared by IPv6 and IPv4. This conforms to RFC2553. > However, some kind of applications may want to restrict their use of > an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is > defined for such applications in RFC2553bis, which is successor of RFC2553. > This patch allows to bind both IPv6 and IPv4 sockets with the single > port number at the same time if IPV6_V6ONLY socket options is set to > the IPv6 socket. > > We also prohibit a completely duplicate set of (local-addr, local-port, > remote-addr, remote-port) set even if SO_REUSEADDR is set unless > the local address is a multicast address; it is ambiguous and it may > steal packets from others; i.e. a kind of DoS. > > Packet delivery strategy is similar to one before, but we prefer > IPv4 a bit. > > Following patch is against linux-2.4.19. > > Thank you in advance. > > ------------------------------------------------------------------- > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) > Patch-Id: FIX_2_4_19_DOUBLEBIND-20020909 > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > Credit: YOSHIFUJI Hideaki / USAGI Project > Reference: RFC2553bis > ------------------------------------------------------------------- > Index: include/linux/in6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- include/linux/in6.h 2002/08/20 09:46:34 1.1.1.1 > +++ include/linux/in6.h 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -156,6 +156,7 @@ > #define IPV6_MTU_DISCOVER 23 > #define IPV6_MTU 24 > #define IPV6_RECVERR 25 > +#define IPV6_V6ONLY 26 > > /* IPV6_MTU_DISCOVER values */ > #define IPV6_PMTUDISC_DONT 0 > @@ -167,4 +168,19 @@ > #define IPV6_FLOWINFO_SEND 33 > > > +#ifdef __KERNEL__ > +#ifndef IN6_IS_ADDR_UNSPECIFIED > +#define IN6_IS_ADDR_UNSPECIFIED(a) \ > + ((((a)->s6_addr32[0]) == 0) && \ > + (((a)->s6_addr32[1]) == 0) && \ > + (((a)->s6_addr32[2]) == 0) && \ > + (((a)->s6_addr32[3]) == 0)) > +#endif > +#ifndef IN6_IS_ADDR_V4MAPPED > +#define IN6_IS_ADDR_V4MAPPED(a) \ > + ((((a)->s6_addr32[0]) == 0) && \ > + (((a)->s6_addr32[1]) == 0) && \ > + (((a)->s6_addr32[2]) == __constant_htonl(0x0000ffff))) > +#endif > +#endif > #endif > Index: include/linux/sysctl.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- include/linux/sysctl.h 2002/08/20 09:46:34 1.1.1.1 > +++ include/linux/sysctl.h 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -369,7 +369,8 @@ > 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_BINDV6ONLY=11 > }; > > /* /proc/sys/net//neigh/ */ > Index: include/net/if_inet6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/if_inet6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- include/net/if_inet6.h 2002/08/20 09:46:45 1.1.1.1 > +++ include/net/if_inet6.h 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -86,6 +86,7 @@ > int rtr_solicits; > int rtr_solicit_interval; > int rtr_solicit_delay; > + int bindv6only; > > void *sysctl; > }; > Index: include/net/sock.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- include/net/sock.h 2002/08/20 09:46:45 1.1.1.1 > +++ include/net/sock.h 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -171,7 +171,8 @@ > __u8 mc_loop:1, > recverr:1, > sndflow:1, > - pmtudisc:2; > + pmtudisc:2, > + ipv6only:1; > > struct ipv6_mc_socklist *ipv6_mc_list; > struct ipv6_fl_socklist *ipv6_fl_list; > Index: net/ipv4/tcp_ipv4.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv4/tcp_ipv4.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -45,6 +45,14 @@ > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > * Andi Kleen : Fix new listen. > * Andi Kleen : Fix accept error reporting. > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket option > + * is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > */ > > #include > @@ -177,23 +185,92 @@ > static inline int tcp_bind_conflict(struct sock *sk, struct tcp_bind_bucket *tb) > { > struct sock *sk2 = tb->owners; > - int sk_reuse = sk->reuse; > + int sk_reuse, sk2_reuse; > + int addr_type2; > + int ret; > + > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > - if (sk != sk2 && > - sk2->reuse <= 1 && > - sk->bound_dev_if == sk2->bound_dev_if) { > - if (!sk_reuse || > - !sk2->reuse || > - sk2->state == TCP_LISTEN) { > - if (!sk2->rcv_saddr || > - !sk->rcv_saddr || > - (sk2->rcv_saddr == sk->rcv_saddr)) > - break; > + int both_specified = 0; > + > + if (sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + struct in6_addr *sk2_rcv_saddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk2)->v6_rcv_saddr; > + if (IN6_IS_ADDR_UNSPECIFIED(sk2_rcv_saddr6)) > + addr_type2 = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(sk2_rcv_saddr6)) > + addr_type2 = IPV6_ADDR_MAPPED; > + else > + addr_type2 = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2 = IPV6_ADDR_MAPPED; > +#else > + addr_type2 = IPV6_ADDR_MAPPED; > +#endif > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + sk->rcv_saddr) { > + if (sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + both_specified = 1; > + } > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only) { > + continue; > + } > +#endif > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + ret = 1; > + if (both_specified) { > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + struct in6_addr *sk2_daddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.daddr : > + &((struct tcp_tw_bucket*)sk2)->v6_daddr; > +#endif > + int addr_type2d; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + if (IN6_IS_ADDR_UNSPECIFIED(sk2_daddr6)) > + addr_type2d = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(sk2_daddr6)) > + addr_type2d = IPV6_ADDR_MAPPED; > + else > + addr_type2d = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2d = IPV6_ADDR_MAPPED; > +#else > + addr_type2d = IPV6_ADDR_MAPPED; > +#endif > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + sk->rcv_saddr) > + continue; > } > } > + ret = 1; > + goto failed; > } > - return sk2 != NULL; > + /* If we found a conflict, fail. */ > + ret = sk2 != NULL; > +failed: > + return ret; > } > > /* Obtain a reference to a local port for the given sock, > @@ -247,10 +324,11 @@ > break; > } > if (tb != NULL && tb->owners != NULL) { > - if (sk->reuse > 1) > + ret = 1; > + if (tb->fastreuse > 0 && > + sk->reuse != 0 && > + sk->state != TCP_LISTEN) { > goto success; > - if (tb->fastreuse > 0 && sk->reuse != 0 && sk->state != TCP_LISTEN) { > - goto success; > } else { > ret = 1; > if (tcp_bind_conflict(sk, tb)) > @@ -418,23 +496,31 @@ > struct sock *result = NULL; > int score, hiscore; > > - hiscore=0; > + hiscore = -1; > for(; sk; sk = sk->next) { > if(sk->num == hnum) { > __u32 rcv_saddr = sk->rcv_saddr; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = 0; > + if (sk->family == PF_INET) > + score++; > + else if (sk->net_pinfo.af_inet6.ipv6only) > + continue; > +#else > score = 1; > +#endif > if(rcv_saddr) { > if (rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if (sk->bound_dev_if) { > if (sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if (score == 3) > + if (score == 5) > return sk; > if (score > hiscore) { > hiscore = score; > @@ -456,6 +542,10 @@ > if (sk->num == hnum && > sk->next == NULL && > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + (sk->family == PF_INET || > + (sk->family == PF_INET6 && !sk->net_pinfo.af_inet6.ipv6only)) && > +#endif > !sk->bound_dev_if) > goto sherry_cache; > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > Index: net/ipv4/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv4/udp.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv4/udp.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -61,6 +61,14 @@ > * return ENOTCONN for unconnected sockets (POSIX) > * Janos Farkas : don't deliver multi/broadcasts to a different > * bound-to-device socket > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket opttion is > + * is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > * > * > * This program is free software; you can redistribute it and/or > @@ -85,6 +93,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -153,18 +162,88 @@ > udp_port_rover = snum = result; > } else { > struct sock *sk2; > + int sk_reuse, sk2_reuse; > + int addr_type2; > > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > + if (sk_reuse && > + MULTICAST(sk->rcv_saddr)) > + sk_reuse |= 4; > + > for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; > sk2 != NULL; > sk2 = sk2->next) { > - if (sk2->num == snum && > - sk2 != sk && > - sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - !sk->rcv_saddr || > - sk2->rcv_saddr == sk->rcv_saddr) && > - (!sk2->reuse || !sk->reuse)) > - goto fail; > + int both_specified = 0; > + > + if (sk2->num != snum || > + sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + if (IN6_IS_ADDR_UNSPECIFIED(&sk2->net_pinfo.af_inet6.rcv_saddr)) > + addr_type2 = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(&sk2->net_pinfo.af_inet6.rcv_saddr)) > + addr_type2 = IPV6_ADDR_MAPPED; > + else > + addr_type2 = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2 = IPV6_ADDR_MAPPED; > +#else > + addr_type2 = IPV6_ADDR_MAPPED; > +#endif > + > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + sk->rcv_saddr) { > + if (sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + both_specified = 1; > + } > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only) { > + continue; > + } > +#endif > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + if (sk2_reuse && > + (addr_type2 != IPV6_ADDR_MAPPED ? (addr_type2 & IPV6_ADDR_MULTICAST) : MULTICAST(sk2->rcv_saddr))) > + sk2_reuse |= 4; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + if (sk2_reuse & sk_reuse & 4) > + continue; > + if (both_specified) { > + int addr_type2d; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + if (IN6_IS_ADDR_UNSPECIFIED(&sk2->net_pinfo.af_inet6.daddr)) > + addr_type2d = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(&sk2->net_pinfo.af_inet6.daddr)) > + addr_type2d = IPV6_ADDR_MAPPED; > + else > + addr_type2d = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2d = IPV6_ADDR_MAPPED; > +#else > + addr_type2d = IPV6_ADDR_MAPPED; > +#endif > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + sk->rcv_saddr) > + continue; > + } > + } > + goto fail; > } > } > sk->num = snum; > @@ -216,28 +295,37 @@ > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { > if(sk->num == hnum) { > - int score = 0; > + int score; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = 0; > + if(sk->family == PF_INET) > + score++; > + else if (sk->net_pinfo.af_inet6.ipv6only) > + continue; > +#else > + score = 1; > +#endif > if(sk->rcv_saddr) { > if(sk->rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if(sk->daddr) { > if(sk->daddr != saddr) > continue; > - score++; > + score+=2; > } > if(sk->dport) { > if(sk->dport != sport) > continue; > - score++; > + score+=2; > } > if(sk->bound_dev_if) { > if(sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if(score == 4) { > + if(score == 9) { > result = sk; > break; > } else if(score > badness) { > @@ -273,6 +361,9 @@ > (s->daddr && s->daddr!=rmt_addr) || > (s->dport != rmt_port && s->dport != 0) || > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + (s->family != PF_INET && s->net_pinfo.af_inet6.ipv6only) || > +#endif > (s->bound_dev_if && s->bound_dev_if != dif)) > continue; > break; > Index: net/ipv6/addrconf.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/addrconf.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -116,6 +116,7 @@ > MAX_RTR_SOLICITATIONS, /* router solicits */ > RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ > MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ > + bindv6only: 0, > }; > > static struct ipv6_devconf ipv6_devconf_dflt = > @@ -130,6 +131,7 @@ > MAX_RTR_SOLICITATIONS, /* router solicits */ > RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ > MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ > + bindv6only: 0, > }; > > int ipv6_addr_type(struct in6_addr *addr) > @@ -1879,7 +1881,7 @@ > static struct addrconf_sysctl_table > { > struct ctl_table_header *sysctl_header; > - ctl_table addrconf_vars[11]; > + ctl_table addrconf_vars[12]; > ctl_table addrconf_dev[2]; > ctl_table addrconf_conf_dir[2]; > ctl_table addrconf_proto_dir[2]; > @@ -1925,6 +1927,10 @@ > {NET_IPV6_RTR_SOLICIT_DELAY, "router_solicitation_delay", > &ipv6_devconf.rtr_solicit_delay, sizeof(int), 0644, NULL, > &proc_dointvec_jiffies}, > + > + {NET_IPV6_BINDV6ONLY, "bindv6only", > + &ipv6_devconf.bindv6only, sizeof(int), 0644, NULL, > + &proc_dointvec}, > > {0}}, > > Index: net/ipv6/af_inet6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/af_inet6.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/af_inet6.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -173,6 +173,8 @@ > sk->net_pinfo.af_inet6.mc_loop = 1; > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > + sk->net_pinfo.af_inet6.ipv6only = ipv6_devconf.bindv6only; > + > /* Init the ipv4 part of the socket since we can have sockets > * using v6 API for ipv4. > */ > @@ -248,6 +250,8 @@ > > /* Check if the address belongs to the host. */ > if (addr_type == IPV6_ADDR_MAPPED) { > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -EADDRNOTAVAIL; > v4addr = addr->sin6_addr.s6_addr32[3]; > if (inet_addr_type(v4addr) != RTN_LOCAL) > return -EADDRNOTAVAIL; > Index: net/ipv6/ipv6_sockglue.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/ipv6_sockglue.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/ipv6_sockglue.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -380,6 +380,15 @@ > retv = ipv6_flowlabel_opt(sk, optval, optlen); > break; > > + case IPV6_V6ONLY: > + if (optlen != sizeof(int)) > + goto e_inval; > + if (sk->userlocks&SOCK_BINDADDR_LOCK) > + goto e_inval; > + np->ipv6only = valbool; > + retv = 0; > + break; > + > #ifdef CONFIG_NETFILTER > default: > retv = nf_setsockopt(sk, PF_INET6, optname, optval, > @@ -520,6 +529,10 @@ > > case IPV6_FLOWINFO_SEND: > val = np->sndflow; > + break; > + > + case IPV6_V6ONLY: > + val = np->ipv6only; > break; > > default: > Index: net/ipv6/tcp_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/tcp_ipv6.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/tcp_ipv6.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -14,6 +14,14 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket > + * option is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -137,28 +145,70 @@ > goto success; > } else { > struct sock *sk2 = tb->owners; > - int sk_reuse = sk->reuse; > - int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr); > + int sk_reuse, sk2_reuse; > + struct in6_addr *sk_rcv_saddr6 = sk->state != TCP_TIME_WAIT ? > + &sk->net_pinfo.af_inet6.rcv_saddr: > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr; > + int addr_type = ipv6_addr_type(sk_rcv_saddr6), > + addr_type2; > + > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > > /* We must walk the whole port owner list in this case. -DaveM */ > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > - if (sk != sk2 && > - sk->bound_dev_if == sk2->bound_dev_if) { > - if (!sk_reuse || > - !sk2->reuse || > - sk2->state == TCP_LISTEN) { > - /* NOTE: IPv6 tw bucket have different format */ > - if (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - sk2->state != TCP_TIME_WAIT ? > - &sk2->net_pinfo.af_inet6.rcv_saddr : > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > - sk->rcv_saddr==sk2->rcv_saddr)) > - break; > + int both_specified = 0; > + struct in6_addr *sk2_rcv_saddr6; > + if (sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + sk2_rcv_saddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk2)->v6_rcv_saddr; > + > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) { > + if (addr_type2 == IPV6_ADDR_MAPPED || addr_type == IPV6_ADDR_MAPPED) { > + if (addr_type2 != addr_type || > + sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + } else { > + if (ipv6_addr_cmp(sk2_rcv_saddr6, sk_rcv_saddr6)) > + continue; > } > + both_specified = 1; > } > + > + if ((addr_type2 == IPV6_ADDR_MAPPED && > + addr_type != IPV6_ADDR_MAPPED && sk->net_pinfo.af_inet6.ipv6only) || > + (addr_type == IPV6_ADDR_MAPPED && > + addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only)) { > + continue; > + } > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + ret = 1; > + if (both_specified) { > + struct in6_addr *sk2_daddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.daddr : > + &((struct tcp_tw_bucket*)sk2)->v6_daddr; > + int addr_type2d = sk2->family == AF_INET6 ? ipv6_addr_type(sk2_daddr6) : IPV6_ADDR_MAPPED; > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) > + continue; > + } > + } > + ret = 1; > + goto fail_unlock; > } > /* If we found a conflict, fail. */ > ret = 1; > @@ -601,6 +651,9 @@ > struct sockaddr_in sin; > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > + > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_port = usin->sin6_port; > Index: net/ipv6/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/udp.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/udp.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -11,7 +11,16 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket > + * option is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > * > + * > * 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 > @@ -98,23 +107,72 @@ > udp_port_rover = snum = result; > } else { > struct sock *sk2; > - int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr); > + int sk_reuse, sk2_reuse; > + int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr), > + addr_type2; > + > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > + if (sk_reuse && > + (addr_type != IPV6_ADDR_MAPPED ? (addr_type & IPV6_ADDR_MULTICAST) : MULTICAST(sk->rcv_saddr))) > + sk_reuse |= 4; > > for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; > sk2 != NULL; > sk2 = sk2->next) { > - if (sk2->num == snum && > - sk2 != sk && > - sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > - (addr_type == IPV6_ADDR_MAPPED && > - sk2->family == AF_INET && > - sk->rcv_saddr == sk2->rcv_saddr)) && > - (!sk2->reuse || !sk->reuse)) > - goto fail; > + int both_specified = 0; > + > + if (sk2->num != snum || > + sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + > + addr_type2 = sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) : IPV6_ADDR_MAPPED; > + > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) { > + if (addr_type2 == IPV6_ADDR_MAPPED || addr_type == IPV6_ADDR_MAPPED) { > + if (addr_type2 != addr_type || > + sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + } else { > + if (ipv6_addr_cmp(&sk2->net_pinfo.af_inet6.rcv_saddr, > + &sk->net_pinfo.af_inet6.rcv_saddr)) > + continue; > + } > + both_specified = 1; > + } > + > + if ((addr_type2 == IPV6_ADDR_MAPPED && > + addr_type != IPV6_ADDR_MAPPED && sk->net_pinfo.af_inet6.ipv6only) || > + (addr_type == IPV6_ADDR_MAPPED && > + addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only)) { > + continue; > + } > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + if (sk2_reuse && > + (addr_type2 != IPV6_ADDR_MAPPED ? (addr_type2 & IPV6_ADDR_MULTICAST) : MULTICAST(sk2->rcv_saddr))) > + sk2_reuse |= 4; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + if (sk2_reuse & sk_reuse & 4) > + continue; > + if (both_specified) { > + int addr_type2d = sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.daddr) : IPV6_ADDR_MAPPED; > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) > + continue; > + } > + } > + goto fail; > } > } > > @@ -221,6 +279,8 @@ > int err; > > if (usin->sin6_family == AF_INET) { > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -EAFNOSUPPORT; > err = udp_connect(sk, uaddr, addr_len); > goto ipv4_connected; > } > @@ -256,6 +316,9 @@ > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -ENETUNREACH; > + > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > sin.sin_port = usin->sin6_port; > @@ -783,8 +846,11 @@ > fl.oif = 0; > > if (sin6) { > - if (sin6->sin6_family == AF_INET) > + if (sin6->sin6_family == AF_INET) { > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -EAFNOSUPPORT; > return udp_sendmsg(sk, msg, ulen); > + } > > if (addr_len < SIN6_LEN_RFC2133) > return -EINVAL; > @@ -830,6 +896,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > + > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From davem@redhat.com Thu Oct 3 01:05:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 01:05:08 -0700 (PDT) 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 g93850tG005128 for ; Thu, 3 Oct 2002 01:05:01 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA28473; Thu, 3 Oct 2002 00:56:56 -0700 Date: Thu, 03 Oct 2002 00:56:56 -0700 (PDT) Message-Id: <20021003.005656.102625653.davem@redhat.com> To: jmorris@intercode.com.au Cc: alan@lxorguk.ukuu.org.uk, mbp@samba.org, kuznet@ms2.inr.ac.ru, ak@muc.de, netdev@oss.sgi.com, Alan.Cox@linux.org Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case From: "David S. Miller" In-Reply-To: References: <1033388585.16337.9.camel@irongate.swansea.linux.org.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: 489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: James Morris Date: Thu, 3 Oct 2002 13:30:44 +1000 (EST) On 30 Sep 2002, Alan Cox wrote: > Well if Dave can't test it and isnt doing any 2.2 who wants to be the > 2.2 networking maintainer ? I'd be willing to give it a go. So be it. From davem@redhat.com Thu Oct 3 01:07:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 01:07:08 -0700 (PDT) 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 g93874tG005445 for ; Thu, 3 Oct 2002 01:07:04 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA28486; Thu, 3 Oct 2002 00:59:08 -0700 Date: Thu, 03 Oct 2002 00:59:07 -0700 (PDT) Message-Id: <20021003.005907.62651859.davem@redhat.com> To: ak@muc.de Cc: jmorris@intercode.com.au, alan@lxorguk.ukuu.org.uk, mbp@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Alan.Cox@linux.org Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case From: "David S. Miller" In-Reply-To: <20021003035446.GA29860@averell> References: <1033388585.16337.9.camel@irongate.swansea.linux.org.uk> <20021003035446.GA29860@averell> 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: 490 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: Andi Kleen Date: Thu, 3 Oct 2002 05:54:46 +0200 On Thu, Oct 03, 2002 at 05:30:44AM +0200, James Morris wrote: > On 30 Sep 2002, Alan Cox wrote: > > > Well if Dave can't test it and isnt doing any 2.2 who wants to be the > > 2.2 networking maintainer ? > > > > I'd be willing to give it a go. 2.2 networking unfortunately has some more SMP bugs (DaveM can tell you details) which are hard to fix. So think twice before you volunteer ;) These don't matter as much as you may think. The real show stoppers are the ones like this FIN_WAIT1 cork bug. These are the only ones we can come up with safe fixes (in terms of what this means for 2.2.x) for anyways. Franks a lot, David S. Miller davem@redhat.com From davem@redhat.com Thu Oct 3 01:36:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 01:36:24 -0700 (PDT) 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 g938aKtG006014 for ; Thu, 3 Oct 2002 01:36:20 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id BAA28665; Thu, 3 Oct 2002 01:29:05 -0700 Date: Thu, 03 Oct 2002 01:29:04 -0700 (PDT) Message-Id: <20021003.012904.75241727.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) From: "David S. Miller" In-Reply-To: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> References: <20021003.121350.119660876.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: 491 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 / 吉藤英明 Date: Thu, 03 Oct 2002 12:13:50 +0900 (JST) Linux IPv6 stack provides the ability for IPv6 applications to interoperate with IPv4 applications. Port space for TCP (or UDP) is shared by IPv6 and IPv4. This conforms to RFC2553. However, some kind of applications may want to restrict their use of an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is defined for such applications in RFC2553bis, which is successor of RFC2553. I really wish BSD socket features did not get standardized in RFC's, we must live with their mistakes. For example, this IPV6_V6ONLY socket option is flawed. What we really need is a generic socket option which says "my family only" There is nothing ipv6 specific about such a socket attribute. So please, create instead "SO_ONEFAMILY" or similar generic socket option. I still need to review the rest of the patch for functional correctness. This is probably the most complex area of the socket identity code in TCP/UDP :-) From bhards@bigpond.net.au Thu Oct 3 02:02:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 02:02:31 -0700 (PDT) Received: from mta06bw.bigpond.com (mta06bw.bigpond.com [139.134.6.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9392StG006522 for ; Thu, 3 Oct 2002 02:02:28 -0700 Received: from 192.168.1.246 ([144.135.24.81]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15 mta06bw Jul 16 2002 22:47:55) with SMTP id H3EEFW00.CZD; Thu, 3 Oct 2002 19:02:20 +1000 Received: from CPE-203-51-35-141.nsw.bigpond.net.au ([203.51.35.141]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0n 44/2343467); 03 Oct 2002 19:02:20 From: Brad Hards To: "David S. Miller" , yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) Date: Thu, 3 Oct 2002 18:55:11 +1000 User-Agent: KMail/1.4.5 Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> <20021003.012904.75241727.davem@redhat.com> In-Reply-To: <20021003.012904.75241727.davem@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200210031855.12148.bhards@bigpond.net.au> X-archive-position: 492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhards@bigpond.net.au Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 3 Oct 2002 18:29, David S. Miller wrote: > For example, this IPV6_V6ONLY socket option is flawed. What we > really need is a generic socket option which says "my family only" > > There is nothing ipv6 specific about such a socket attribute. > > So please, create instead "SO_ONEFAMILY" or similar generic > socket option. > > I still need to review the rest of the patch for functional > correctness. This is probably the most complex area of the > socket identity code in TCP/UDP :-) While you are grotting aroung in this area - a thought / request. When we get IPv4 link-local autoconf addressing in widespread use, there is a problem on multi-homed machines. Assume B has two network interfaces (B1 and B2) on seperate IPv4 links (net1 and net2). Host A is on net1 and Host C is on net2. Assume that both Host A and Host C have the same autoconf address. So IP address is not enough information for Host B to use to determine which interface to use in order to contact Host A (instead of Host C). If host B has socket binding on IP+port+local interface, it all works out. Is this going to work? Brad - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9nAXwW6pHgIdAuOMRAscOAKC/TyYdV1IOjDMlYZghhLf1mYtrKgCfbDEh VJAdPL1Rc1Z2uM6RCIgSYOE= =JZGw -----END PGP SIGNATURE----- From davem@redhat.com Thu Oct 3 02:06:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 02:06:34 -0700 (PDT) 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 g9396XtG006937 for ; Thu, 3 Oct 2002 02:06:33 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id BAA28848; Thu, 3 Oct 2002 01:58:42 -0700 Date: Thu, 03 Oct 2002 01:58:42 -0700 (PDT) Message-Id: <20021003.015842.56966498.davem@redhat.com> To: bhards@bigpond.net.au Cc: yoshfuji@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) From: "David S. Miller" In-Reply-To: <200210031855.12148.bhards@bigpond.net.au> References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> <20021003.012904.75241727.davem@redhat.com> <200210031855.12148.bhards@bigpond.net.au> 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: 493 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: Brad Hards Date: Thu, 3 Oct 2002 18:55:11 +1000 Assume B has two network interfaces (B1 and B2) on seperate IPv4 links (net1 and net2). Host A is on net1 and Host C is on net2. Assume that both Host A and Host C have the same autoconf address. So IP address is not enough information for Host B to use to determine which interface to use in order to contact Host A (instead of Host C). If host B has socket binding on IP+port+local interface, it all works out. You want SO_BINDTODEVICE, which we have. From steve@gw.chygwyn.com Thu Oct 3 03:27:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 03:27:28 -0700 (PDT) Received: from gw.chygwyn.com (IDENT:root@gw.chygwyn.com [62.172.158.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93ARKtG016467 for ; Thu, 3 Oct 2002 03:27:21 -0700 Received: (from steve@localhost) by gw.chygwyn.com (8.9.3/8.9.3) id LAA29397; Thu, 3 Oct 2002 11:31:01 +0100 From: Steven Whitehouse Message-Id: <200210031031.LAA29397@gw.chygwyn.com> Subject: DECnet patch for 2.5 To: davej@suse.de, davem@redhat.com Date: Thu, 3 Oct 2002 11:31:01 +0100 (BST) Cc: netdev@oss.sgi.com Organization: ChyGywn Limited X-RegisteredOffice: 7, New Yatt Road, Witney, Oxfordshire. OX28 1NU England X-RegisteredNumber: 03887683 Reply-To: Steve Whitehouse X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@gw.chygwyn.com Precedence: bulk X-list: netdev Hi, Here is the URL for my latest DECnet patch (for 2.5 kernels only): http://www.chygwyn.com/~steve/kpatch/decnet/decnet-2.5.40-autoconfig.diff It changes the way that DECnet gets autoconfigured in order to make the simple case of setting up an endnode easier. It also fixes several bugs which I found along the way and does a bit of C99 cleanup in the sysctl code. I'm not ready for this to go to Linus yet, but I'd like the maximum number of people possible to try it and send me feedback on any problems that are seen. I've updated the docs to explain the new configuration procedure. Other features are: o Outgoing packets set with correct source address when device MAC address isn't the same as the DECnet address o Updated TODO list o Updated socket allocation in the light of the socket layer changes in 2.5 o Fixed a race in bind() system call o Fixed a bug in autobind where we were not checking a return value o Fixed locking on the default_device o Routing changes for loopback routes in order to allow the new autoconfiguration changes to work as intended. o "hello" messages now sent for each address on an interface o Using multicast address filters to listen to extra unicast MAC addresses when they are not equal to the MAC address of the device (allows DECnet without setting MAC address to a DECnet compatible address and multiple DECnet addresses per interface) o Unregisters the "all endnodes" or "all routers" multicast addresses when the device goes down (previously we forgot, causing an address leak). o Updated version string I'll back port the bug fix parts to 2.4 in chunks once this has had a bit of testing, Steve. From webmaster@coeursolitaire.com Thu Oct 3 05:02:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 05:03:02 -0700 (PDT) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93C2stG019402 for ; Thu, 3 Oct 2002 05:02:55 -0700 Received: from Poste07 (213.19.0.21) by mail.libertysurf.net (6.5.026) id 3D902B020011E682; Thu, 3 Oct 2002 13:49:38 +0200 Message-ID: <41199-220021043114942722@Poste07> To: "jen08" From: "webmaster" Subject: Le 1er site de rencontres Date: Thu, 3 Oct 2002 13:49:42 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 841 X-archive-position: 495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@coeursolitaire.com Precedence: bulk X-list: netdev =20=20=20=20=20=20=20=20=20 =20=20=20 =20=20=20=20 http://www.hollygood.net=20 =20=20=20 =20=20=20=20=20 =20=20=20 =20=20 Faites des rencontres sans tabous =20=20=20=20=20 Vous cherchez l'=E2me soeur ? une seule solution pour cela ... http://www.= hollygood.net=20=20=20=20 =20=20 Sur Hollygood.net pas de tabous, c'est vous qui d=E9cidez qui vous voulez r= encontrer, 35 000 Membres actifs Recherchent activement l'amour et les renc= ontres :=20 HOMMES / FEMMES ET COUPLES Lachez vous ...=20 Ce mail vous est envoy=E9 car vous =EAtes inscrit ou une personne vous =E0 = inscrit =E0 notre base de donn=E9es, si vous ne souhaitez plus recevoir ce = genre d'informations envoyez un mail vide =E0 :webmaster@coeursolitaire.com= et vous serez automatiquement supprim=E9=20 =20=20=20 =20=20=20 [[HTML alternate version deleted]] From jaganbabu_ipv6@yahoo.co.in Thu Oct 3 05:24:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 05:24:54 -0700 (PDT) Received: from web40603.mail.yahoo.com (web40603.mail.yahoo.com [66.218.78.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93COotG019871 for ; Thu, 3 Oct 2002 05:24:50 -0700 Message-ID: <20021003122445.37447.qmail@web40603.mail.yahoo.com> Received: from [12.27.183.253] by web40603.mail.yahoo.com via HTTP; Thu, 03 Oct 2002 13:24:45 BST Date: Thu, 3 Oct 2002 13:24:45 +0100 (BST) From: =?iso-8859-1?q?jaganbabu=20rajamanickam?= Subject: problem in binding with ipv6 socket.. please help me To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaganbabu_ipv6@yahoo.co.in Precedence: bulk X-list: netdev hi, Iam working on "Red Hat Linux release 7.2", I have an interface configured with ipv6 address "fe80::203:baff:fe14:4747/10". Iam trying to open a TCP socket on that interface and bind with it, but bind() call is failing, if iam using getsockopt( SO_ERROR), iam getting error as "0". What could be the problem, Is there any configuration need to be done. Note: by the way, same programm is running fine for loopback address (::1) and in_addr_any (::). can any one please help me in sorting out this problem. Iam pasting my test code below.. Thanx, Jags int ipv6_sock_test(void) { struct sockaddr_in6 laddr, faddr; int sock, new_sock, sock_opt; int faddrlen; char addrbuf[INET6_ADDRSTRLEN]; int port = 3000; /* * Set up a socket to listen on for connections. * Make sure all sockaddr_in6 fields are zero. */ bzero(&laddr, sizeof (laddr)); laddr.sin6_family = AF_INET6; laddr.sin6_port = htons(port); /*laddr.sin6_addr = in6addr_any; structure assignment */ laddr.sin6_addr.s6_addr[0] = 0xfe; laddr.sin6_addr.s6_addr[1] = 0x80; laddr.sin6_addr.s6_addr[2] = 0x0; laddr.sin6_addr.s6_addr[3] = 0x0; laddr.sin6_addr.s6_addr[4] = 0x0; laddr.sin6_addr.s6_addr[5] = 0x0; laddr.sin6_addr.s6_addr[6] = 0x0; laddr.sin6_addr.s6_addr[7] = 0x0; laddr.sin6_addr.s6_addr[8] = 0x2; laddr.sin6_addr.s6_addr[9] = 0x3; laddr.sin6_addr.s6_addr[10] = 0xba; laddr.sin6_addr.s6_addr[11] = 0xff; laddr.sin6_addr.s6_addr[12] = 0xfe; laddr.sin6_addr.s6_addr[13] = 0x14; laddr.sin6_addr.s6_addr[14] = 0x47; laddr.sin6_addr.s6_addr[15] = 0x47; sock = socket(AF_INET6, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return (-1); } /* Tell the system to allow local addresses to be reused. */ sock_opt = 1; if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (void *)&sock_opt, sizeof (sock_opt)) == -1) { perror("setsockopt(SO_REUSEADDR)"); (void) close(sock); return (-1); } if (bind(sock, (struct sockaddr *)&laddr, sizeof (laddr)) == -1) { perror("bind"); (void) close(sock); return (-1); } return 0; } ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From kuznet@ms2.inr.ac.ru Thu Oct 3 06:08:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 06:08:23 -0700 (PDT) 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 g93D8HtG025256 for ; Thu, 3 Oct 2002 06:08:18 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id RAA29293; Thu, 3 Oct 2002 17:06:48 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210031306.RAA29293@sex.inr.ac.ru> Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same To: davem@redhat.COM (David S. Miller) Date: Thu, 3 Oct 2002 17:06:48 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <20021003.012904.75241727.davem@redhat.com> from "David S. Miller" at Oct 3, 2 12:45:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 497 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! > For example, this IPV6_V6ONLY socket option is flawed. What we > really need is a generic socket option which says "my family only" > > There is nothing ipv6 specific about such a socket attribute. > > So please, create instead "SO_ONEFAMILY" or similar generic > socket option. No, really! __Sharing__ of port space between IPv4 and IPv6 was mad idea. It cannot generalized to other protocol families. So, IPV6_V6ONLY is really unique for IPv6. Well, actually, it could be negated: be default and the option would be called IPV6_SHARE_THIS_PORT_TO_IPV4. Alexey From davem@redhat.com Thu Oct 3 06:10:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 06:10:41 -0700 (PDT) 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 g93DAdtG025735 for ; Thu, 3 Oct 2002 06:10:39 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id GAA31391; Thu, 3 Oct 2002 06:02:55 -0700 Date: Thu, 03 Oct 2002 06:02:54 -0700 (PDT) Message-Id: <20021003.060254.26942488.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same From: "David S. Miller" In-Reply-To: <200210031306.RAA29293@sex.inr.ac.ru> References: <20021003.012904.75241727.davem@redhat.com> <200210031306.RAA29293@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: 498 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: Thu, 3 Oct 2002 17:06:48 +0400 (MSD) No, really! __Sharing__ of port space between IPv4 and IPv6 was mad idea. It cannot generalized to other protocol families. So, IPV6_V6ONLY is really unique for IPv6. Well, actually, it could be negated: be default and the option would be called IPV6_SHARE_THIS_PORT_TO_IPV4. I think what I want to really say is that I want to provide way for ipv4 application to say "no ipv6 connections on this listening socket please". So does it make no sense at all to have IP_V4ONLY? From pekkas@netcore.fi Thu Oct 3 06:19:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 06:19:11 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93DJ8tG026473 for ; Thu, 3 Oct 2002 06:19:09 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g93DIsf08541; Thu, 3 Oct 2002 16:18:54 +0300 Date: Thu, 3 Oct 2002 16:18:53 +0300 (EEST) From: Pekka Savola To: "David S. Miller" cc: kuznet@ms2.inr.ac.ru, Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same In-Reply-To: <20021003.060254.26942488.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 499 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, 3 Oct 2002, David S. Miller wrote: > From: kuznet@ms2.inr.ac.ru > Date: Thu, 3 Oct 2002 17:06:48 +0400 (MSD) > > No, really! __Sharing__ of port space between IPv4 and IPv6 was mad > idea. It cannot generalized to other protocol families. > > So, IPV6_V6ONLY is really unique for IPv6. Well, actually, it could > be negated: be default and the option would be called > IPV6_SHARE_THIS_PORT_TO_IPV4. > > I think what I want to really say is that I want to provide > way for ipv4 application to say "no ipv6 connections on this > listening socket please". > > So does it make no sense at all to have IP_V4ONLY? Umm, I think an app guy can do that with creating an AF_INET socket; there will not be IPv6 there. Folks Who Think They Know Best decided that dual use for AF_INET6 would be best, and IPV6_V6ONLY was invented (note: it'd already implemented by some others) to repair that. -- 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 Thu Oct 3 06:21:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 06:21:30 -0700 (PDT) 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 g93DLStG028294 for ; Thu, 3 Oct 2002 06:21:28 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id GAA31636; Thu, 3 Oct 2002 06:13:41 -0700 Date: Thu, 03 Oct 2002 06:13:40 -0700 (PDT) Message-Id: <20021003.061340.91772406.davem@redhat.com> To: pekkas@netcore.fi Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same From: "David S. Miller" In-Reply-To: References: <20021003.060254.26942488.davem@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 500 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: Pekka Savola Date: Thu, 3 Oct 2002 16:18:53 +0300 (EEST) On Thu, 3 Oct 2002, David S. Miller wrote: > So does it make no sense at all to have IP_V4ONLY? Umm, I think an app guy can do that with creating an AF_INET socket; there will not be IPv6 there. Folks Who Think They Know Best decided that dual use for AF_INET6 would be best, and IPV6_V6ONLY was invented (note: it'd already implemented by some others) to repair that. Ok, ignore my silly idea then. Let us continue with verifying correctness of the USAGI patch. From kuznet@ms2.inr.ac.ru Thu Oct 3 06:21:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 06:21:58 -0700 (PDT) Received: from netserv1.free.net (netserv1.free.net [147.45.15.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93DLqtG029833 for ; Thu, 3 Oct 2002 06:21:53 -0700 Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by netserv1.free.net (8.9.3/EM.SRV.11.2) with SMTP id RAA31420 for ; Thu, 3 Oct 2002 17:20:46 +0400 From: kuznet@ms2.inr.ac.ru Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id RAA29267; Thu, 3 Oct 2002 17:01:11 +0400 Message-Id: <200210031301.RAA29267@sex.inr.ac.ru> Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port To: yoshfuji@linux-ipv6.ORG (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Thu, 3 Oct 2002 17:01:11 +0400 (MSD) Cc: netdev@oss.sgi.com, davem@redhat.com (Dave Miller) In-Reply-To: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at Oct 3, 2 07:45:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 501 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! > We also prohibit a completely duplicate set of (local-addr, local-port, > remote-addr, remote-port) set even if SO_REUSEADDR is set unless > the local address is a multicast address; it is ambiguous and it may > steal packets from others; i.e. a kind of DoS. This part of the patch is noop. While doing *_get_port() daddr/dport are _unknown_ and always zero, so it never works. Please, remove these bits, the patch will become simpler. What's about the problem, it cannot be a problem for TCP, connection uniqueness is verified by tcp_*_check_established() not depending on value of SO_REUSEADDR. What's about UDP, the problem really might be a real problem, let's defer the issue, it looks absoluteky unrelated. BTW the question: why is bindv6only in device configuration directory? Alexey > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/if_inet6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- include/net/if_inet6.h 2002/08/20 09:46:45 1.1.1.1 > +++ include/net/if_inet6.h 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -86,6 +86,7 @@ > int rtr_solicits; > int rtr_solicit_interval; > int rtr_solicit_delay; > + int bindv6only; > > void *sysctl; > }; > Index: include/net/sock.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- include/net/sock.h 2002/08/20 09:46:45 1.1.1.1 > +++ include/net/sock.h 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -171,7 +171,8 @@ > __u8 mc_loop:1, > recverr:1, > sndflow:1, > - pmtudisc:2; > + pmtudisc:2, > + ipv6only:1; > > struct ipv6_mc_socklist *ipv6_mc_list; > struct ipv6_fl_socklist *ipv6_fl_list; > Index: net/ipv4/tcp_ipv4.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv4/tcp_ipv4.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -45,6 +45,14 @@ > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > * Andi Kleen : Fix new listen. > * Andi Kleen : Fix accept error reporting. > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket option > + * is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > */ > > #include > @@ -177,23 +185,92 @@ > static inline int tcp_bind_conflict(struct sock *sk, struct tcp_bind_bucket *tb) > { > struct sock *sk2 = tb->owners; > - int sk_reuse = sk->reuse; > + int sk_reuse, sk2_reuse; > + int addr_type2; > + int ret; > + > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > - if (sk != sk2 && > - sk2->reuse <= 1 && > - sk->bound_dev_if == sk2->bound_dev_if) { > - if (!sk_reuse || > - !sk2->reuse || > - sk2->state == TCP_LISTEN) { > - if (!sk2->rcv_saddr || > - !sk->rcv_saddr || > - (sk2->rcv_saddr == sk->rcv_saddr)) > - break; > + int both_specified = 0; > + > + if (sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + struct in6_addr *sk2_rcv_saddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk2)->v6_rcv_saddr; > + if (IN6_IS_ADDR_UNSPECIFIED(sk2_rcv_saddr6)) > + addr_type2 = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(sk2_rcv_saddr6)) > + addr_type2 = IPV6_ADDR_MAPPED; > + else > + addr_type2 = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2 = IPV6_ADDR_MAPPED; > +#else > + addr_type2 = IPV6_ADDR_MAPPED; > +#endif > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + sk->rcv_saddr) { > + if (sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + both_specified = 1; > + } > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only) { > + continue; > + } > +#endif > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + ret = 1; > + if (both_specified) { > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + struct in6_addr *sk2_daddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.daddr : > + &((struct tcp_tw_bucket*)sk2)->v6_daddr; > +#endif > + int addr_type2d; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + if (IN6_IS_ADDR_UNSPECIFIED(sk2_daddr6)) > + addr_type2d = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(sk2_daddr6)) > + addr_type2d = IPV6_ADDR_MAPPED; > + else > + addr_type2d = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2d = IPV6_ADDR_MAPPED; > +#else > + addr_type2d = IPV6_ADDR_MAPPED; > +#endif > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + sk->rcv_saddr) > + continue; > } > } > + ret = 1; > + goto failed; > } > - return sk2 != NULL; > + /* If we found a conflict, fail. */ > + ret = sk2 != NULL; > +failed: > + return ret; > } > > /* Obtain a reference to a local port for the given sock, > @@ -247,10 +324,11 @@ > break; > } > if (tb != NULL && tb->owners != NULL) { > - if (sk->reuse > 1) > + ret = 1; > + if (tb->fastreuse > 0 && > + sk->reuse != 0 && > + sk->state != TCP_LISTEN) { > goto success; > - if (tb->fastreuse > 0 && sk->reuse != 0 && sk->state != TCP_LISTEN) { > - goto success; > } else { > ret = 1; > if (tcp_bind_conflict(sk, tb)) > @@ -418,23 +496,31 @@ > struct sock *result = NULL; > int score, hiscore; > > - hiscore=0; > + hiscore = -1; > for(; sk; sk = sk->next) { > if(sk->num == hnum) { > __u32 rcv_saddr = sk->rcv_saddr; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = 0; > + if (sk->family == PF_INET) > + score++; > + else if (sk->net_pinfo.af_inet6.ipv6only) > + continue; > +#else > score = 1; > +#endif > if(rcv_saddr) { > if (rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if (sk->bound_dev_if) { > if (sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if (score == 3) > + if (score == 5) > return sk; > if (score > hiscore) { > hiscore = score; > @@ -456,6 +542,10 @@ > if (sk->num == hnum && > sk->next == NULL && > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + (sk->family == PF_INET || > + (sk->family == PF_INET6 && !sk->net_pinfo.af_inet6.ipv6only)) && > +#endif > !sk->bound_dev_if) > goto sherry_cache; > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > Index: net/ipv4/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv4/udp.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv4/udp.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -61,6 +61,14 @@ > * return ENOTCONN for unconnected sockets (POSIX) > * Janos Farkas : don't deliver multi/broadcasts to a different > * bound-to-device socket > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket opttion is > + * is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > * > * > * This program is free software; you can redistribute it and/or > @@ -85,6 +93,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -153,18 +162,88 @@ > udp_port_rover = snum = result; > } else { > struct sock *sk2; > + int sk_reuse, sk2_reuse; > + int addr_type2; > > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > + if (sk_reuse && > + MULTICAST(sk->rcv_saddr)) > + sk_reuse |= 4; > + > for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; > sk2 != NULL; > sk2 = sk2->next) { > - if (sk2->num == snum && > - sk2 != sk && > - sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - !sk->rcv_saddr || > - sk2->rcv_saddr == sk->rcv_saddr) && > - (!sk2->reuse || !sk->reuse)) > - goto fail; > + int both_specified = 0; > + > + if (sk2->num != snum || > + sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + if (IN6_IS_ADDR_UNSPECIFIED(&sk2->net_pinfo.af_inet6.rcv_saddr)) > + addr_type2 = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(&sk2->net_pinfo.af_inet6.rcv_saddr)) > + addr_type2 = IPV6_ADDR_MAPPED; > + else > + addr_type2 = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2 = IPV6_ADDR_MAPPED; > +#else > + addr_type2 = IPV6_ADDR_MAPPED; > +#endif > + > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + sk->rcv_saddr) { > + if (sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + both_specified = 1; > + } > + > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only) { > + continue; > + } > +#endif > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + if (sk2_reuse && > + (addr_type2 != IPV6_ADDR_MAPPED ? (addr_type2 & IPV6_ADDR_MULTICAST) : MULTICAST(sk2->rcv_saddr))) > + sk2_reuse |= 4; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + if (sk2_reuse & sk_reuse & 4) > + continue; > + if (both_specified) { > + int addr_type2d; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + if (sk2->family == AF_INET6) { > + if (IN6_IS_ADDR_UNSPECIFIED(&sk2->net_pinfo.af_inet6.daddr)) > + addr_type2d = IPV6_ADDR_ANY; > + else if (IN6_IS_ADDR_V4MAPPED(&sk2->net_pinfo.af_inet6.daddr)) > + addr_type2d = IPV6_ADDR_MAPPED; > + else > + addr_type2d = IPV6_ADDR_UNICAST; /*XXX*/ > + } else > + addr_type2d = IPV6_ADDR_MAPPED; > +#else > + addr_type2d = IPV6_ADDR_MAPPED; > +#endif > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + sk->rcv_saddr) > + continue; > + } > + } > + goto fail; > } > } > sk->num = snum; > @@ -216,28 +295,37 @@ > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { > if(sk->num == hnum) { > - int score = 0; > + int score; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = 0; > + if(sk->family == PF_INET) > + score++; > + else if (sk->net_pinfo.af_inet6.ipv6only) > + continue; > +#else > + score = 1; > +#endif > if(sk->rcv_saddr) { > if(sk->rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if(sk->daddr) { > if(sk->daddr != saddr) > continue; > - score++; > + score+=2; > } > if(sk->dport) { > if(sk->dport != sport) > continue; > - score++; > + score+=2; > } > if(sk->bound_dev_if) { > if(sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if(score == 4) { > + if(score == 9) { > result = sk; > break; > } else if(score > badness) { > @@ -273,6 +361,9 @@ > (s->daddr && s->daddr!=rmt_addr) || > (s->dport != rmt_port && s->dport != 0) || > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + (s->family != PF_INET && s->net_pinfo.af_inet6.ipv6only) || > +#endif > (s->bound_dev_if && s->bound_dev_if != dif)) > continue; > break; > Index: net/ipv6/addrconf.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/addrconf.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -116,6 +116,7 @@ > MAX_RTR_SOLICITATIONS, /* router solicits */ > RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ > MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ > + bindv6only: 0, > }; > > static struct ipv6_devconf ipv6_devconf_dflt = > @@ -130,6 +131,7 @@ > MAX_RTR_SOLICITATIONS, /* router solicits */ > RTR_SOLICITATION_INTERVAL, /* rtr solicit interval */ > MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ > + bindv6only: 0, > }; > > int ipv6_addr_type(struct in6_addr *addr) > @@ -1879,7 +1881,7 @@ > static struct addrconf_sysctl_table > { > struct ctl_table_header *sysctl_header; > - ctl_table addrconf_vars[11]; > + ctl_table addrconf_vars[12]; > ctl_table addrconf_dev[2]; > ctl_table addrconf_conf_dir[2]; > ctl_table addrconf_proto_dir[2]; > @@ -1925,6 +1927,10 @@ > {NET_IPV6_RTR_SOLICIT_DELAY, "router_solicitation_delay", > &ipv6_devconf.rtr_solicit_delay, sizeof(int), 0644, NULL, > &proc_dointvec_jiffies}, > + > + {NET_IPV6_BINDV6ONLY, "bindv6only", > + &ipv6_devconf.bindv6only, sizeof(int), 0644, NULL, > + &proc_dointvec}, > > {0}}, > > Index: net/ipv6/af_inet6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/af_inet6.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/af_inet6.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -173,6 +173,8 @@ > sk->net_pinfo.af_inet6.mc_loop = 1; > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > + sk->net_pinfo.af_inet6.ipv6only = ipv6_devconf.bindv6only; > + > /* Init the ipv4 part of the socket since we can have sockets > * using v6 API for ipv4. > */ > @@ -248,6 +250,8 @@ > > /* Check if the address belongs to the host. */ > if (addr_type == IPV6_ADDR_MAPPED) { > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -EADDRNOTAVAIL; > v4addr = addr->sin6_addr.s6_addr32[3]; > if (inet_addr_type(v4addr) != RTN_LOCAL) > return -EADDRNOTAVAIL; > Index: net/ipv6/ipv6_sockglue.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/ipv6_sockglue.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/ipv6_sockglue.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -380,6 +380,15 @@ > retv = ipv6_flowlabel_opt(sk, optval, optlen); > break; > > + case IPV6_V6ONLY: > + if (optlen != sizeof(int)) > + goto e_inval; > + if (sk->userlocks&SOCK_BINDADDR_LOCK) > + goto e_inval; > + np->ipv6only = valbool; > + retv = 0; > + break; > + > #ifdef CONFIG_NETFILTER > default: > retv = nf_setsockopt(sk, PF_INET6, optname, optval, > @@ -520,6 +529,10 @@ > > case IPV6_FLOWINFO_SEND: > val = np->sndflow; > + break; > + > + case IPV6_V6ONLY: > + val = np->ipv6only; > break; > > default: > Index: net/ipv6/tcp_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/tcp_ipv6.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/tcp_ipv6.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -14,6 +14,14 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket > + * option is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -137,28 +145,70 @@ > goto success; > } else { > struct sock *sk2 = tb->owners; > - int sk_reuse = sk->reuse; > - int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr); > + int sk_reuse, sk2_reuse; > + struct in6_addr *sk_rcv_saddr6 = sk->state != TCP_TIME_WAIT ? > + &sk->net_pinfo.af_inet6.rcv_saddr: > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr; > + int addr_type = ipv6_addr_type(sk_rcv_saddr6), > + addr_type2; > + > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > > /* We must walk the whole port owner list in this case. -DaveM */ > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > - if (sk != sk2 && > - sk->bound_dev_if == sk2->bound_dev_if) { > - if (!sk_reuse || > - !sk2->reuse || > - sk2->state == TCP_LISTEN) { > - /* NOTE: IPv6 tw bucket have different format */ > - if (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - sk2->state != TCP_TIME_WAIT ? > - &sk2->net_pinfo.af_inet6.rcv_saddr : > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > - sk->rcv_saddr==sk2->rcv_saddr)) > - break; > + int both_specified = 0; > + struct in6_addr *sk2_rcv_saddr6; > + if (sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + sk2_rcv_saddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk2)->v6_rcv_saddr; > + > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) { > + if (addr_type2 == IPV6_ADDR_MAPPED || addr_type == IPV6_ADDR_MAPPED) { > + if (addr_type2 != addr_type || > + sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + } else { > + if (ipv6_addr_cmp(sk2_rcv_saddr6, sk_rcv_saddr6)) > + continue; > } > + both_specified = 1; > } > + > + if ((addr_type2 == IPV6_ADDR_MAPPED && > + addr_type != IPV6_ADDR_MAPPED && sk->net_pinfo.af_inet6.ipv6only) || > + (addr_type == IPV6_ADDR_MAPPED && > + addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only)) { > + continue; > + } > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + ret = 1; > + if (both_specified) { > + struct in6_addr *sk2_daddr6 = sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.daddr : > + &((struct tcp_tw_bucket*)sk2)->v6_daddr; > + int addr_type2d = sk2->family == AF_INET6 ? ipv6_addr_type(sk2_daddr6) : IPV6_ADDR_MAPPED; > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) > + continue; > + } > + } > + ret = 1; > + goto fail_unlock; > } > /* If we found a conflict, fail. */ > ret = 1; > @@ -601,6 +651,9 @@ > struct sockaddr_in sin; > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > + > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_port = usin->sin6_port; > Index: net/ipv6/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.8.1 > diff -u -r1.1.1.1 -r1.1.1.1.8.1 > --- net/ipv6/udp.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/udp.c 2002/09/11 03:30:27 1.1.1.1.8.1 > @@ -11,7 +11,16 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Reworked bind(2) behavior, including: > + * - Allow ipv6 and ipv4 bind(2) to the > + * same port if IPV6_V6ONLY socket > + * option is set. > + * - Don't allow binding to the same > + * address unless it is one of multi- > + * cast address even if SO_REUSEADDR > + * is set. > * > + * > * 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 > @@ -98,23 +107,72 @@ > udp_port_rover = snum = result; > } else { > struct sock *sk2; > - int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr); > + int sk_reuse, sk2_reuse; > + int addr_type = ipv6_addr_type(&sk->net_pinfo.af_inet6.rcv_saddr), > + addr_type2; > + > + sk_reuse = 0; > + if (sk->reuse) > + sk_reuse |= 1; > + if (sk_reuse && > + (addr_type != IPV6_ADDR_MAPPED ? (addr_type & IPV6_ADDR_MULTICAST) : MULTICAST(sk->rcv_saddr))) > + sk_reuse |= 4; > > for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)]; > sk2 != NULL; > sk2 = sk2->next) { > - if (sk2->num == snum && > - sk2 != sk && > - sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > - (addr_type == IPV6_ADDR_MAPPED && > - sk2->family == AF_INET && > - sk->rcv_saddr == sk2->rcv_saddr)) && > - (!sk2->reuse || !sk->reuse)) > - goto fail; > + int both_specified = 0; > + > + if (sk2->num != snum || > + sk2 == sk || > + (sk2->bound_dev_if && sk->bound_dev_if && > + sk2->bound_dev_if != sk->bound_dev_if)) > + continue; > + > + addr_type2 = sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) : IPV6_ADDR_MAPPED; > + > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) && > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) { > + if (addr_type2 == IPV6_ADDR_MAPPED || addr_type == IPV6_ADDR_MAPPED) { > + if (addr_type2 != addr_type || > + sk2->rcv_saddr != sk->rcv_saddr) > + continue; > + } else { > + if (ipv6_addr_cmp(&sk2->net_pinfo.af_inet6.rcv_saddr, > + &sk->net_pinfo.af_inet6.rcv_saddr)) > + continue; > + } > + both_specified = 1; > + } > + > + if ((addr_type2 == IPV6_ADDR_MAPPED && > + addr_type != IPV6_ADDR_MAPPED && sk->net_pinfo.af_inet6.ipv6only) || > + (addr_type == IPV6_ADDR_MAPPED && > + addr_type2 != IPV6_ADDR_MAPPED && sk2->net_pinfo.af_inet6.ipv6only)) { > + continue; > + } > + > + sk2_reuse = 0; > + if (sk2->reuse) > + sk2_reuse |= 1; > + if (sk2_reuse && > + (addr_type2 != IPV6_ADDR_MAPPED ? (addr_type2 & IPV6_ADDR_MULTICAST) : MULTICAST(sk2->rcv_saddr))) > + sk2_reuse |= 4; > + > + if (sk2_reuse & sk_reuse & 3) { /* NOT && */ > + if (sk2_reuse & sk_reuse & 4) > + continue; > + if (both_specified) { > + int addr_type2d = sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.daddr) : IPV6_ADDR_MAPPED; > + if (addr_type2d != IPV6_ADDR_MAPPED ? addr_type2d != IPV6_ADDR_ANY : sk2->daddr) > + continue; > + } else { > + if ((addr_type2 != IPV6_ADDR_MAPPED ? addr_type2 != IPV6_ADDR_ANY : sk2->rcv_saddr) || > + (addr_type != IPV6_ADDR_MAPPED ? addr_type != IPV6_ADDR_ANY : sk->rcv_saddr)) > + continue; > + } > + } > + goto fail; > } > } > > @@ -221,6 +279,8 @@ > int err; > > if (usin->sin6_family == AF_INET) { > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -EAFNOSUPPORT; > err = udp_connect(sk, uaddr, addr_len); > goto ipv4_connected; > } > @@ -256,6 +316,9 @@ > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -ENETUNREACH; > + > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > sin.sin_port = usin->sin6_port; > @@ -783,8 +846,11 @@ > fl.oif = 0; > > if (sin6) { > - if (sin6->sin6_family == AF_INET) > + if (sin6->sin6_family == AF_INET) { > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -EAFNOSUPPORT; > return udp_sendmsg(sk, msg, ulen); > + } > > if (addr_len < SIN6_LEN_RFC2133) > return -EINVAL; > @@ -830,6 +896,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > + > + if (sk->net_pinfo.af_inet6.ipv6only) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > > From yoshfuji@linux-ipv6.org Thu Oct 3 07:15:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 07:15:37 -0700 (PDT) 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 g93EFTtG000322 for ; Thu, 3 Oct 2002 07:15:30 -0700 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 g93EFY1o023765; Thu, 3 Oct 2002 23:15:34 +0900 Date: Thu, 03 Oct 2002 23:15:34 +0900 (JST) Message-Id: <20021003.231534.83777766.yoshfuji@linux-ipv6.org> To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, davem@redhat.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200210031301.RAA29267@sex.inr.ac.ru> References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> <200210031301.RAA29267@sex.inr.ac.ru> 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-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: 502 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 <200210031301.RAA29267@sex.inr.ac.ru> (at Thu, 3 Oct 2002 17:01:11 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > While doing *_get_port() daddr/dport are _unknown_ and always zero, > so it never works. > > Please, remove these bits, the patch will become simpler. Ok, I'll do that. > What's about the problem, it cannot be a problem for TCP, connection > uniqueness is verified by tcp_*_check_established() not depending > on value of SO_REUSEADDR. What's about UDP, the problem really might > be a real problem, let's defer the issue, it looks absoluteky unrelated. Hmm, but I'm afraid that different behavior between TCP and UDP would confuse users. > BTW the question: why is bindv6only in device configuration directory? Because I thought that net.ipv6.conf is the place for all configuration... Do you propose to move it to parent directory (net.ipv6.bindv6only), and put other general settings there? --yoshfuji From davem@redhat.com Thu Oct 3 07:18:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 07:18:53 -0700 (PDT) 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 g93EIntG000692 for ; Thu, 3 Oct 2002 07:18:49 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id HAA32140; Thu, 3 Oct 2002 07:10:59 -0700 Date: Thu, 03 Oct 2002 07:10:58 -0700 (PDT) Message-Id: <20021003.071058.89246593.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port From: "David S. Miller" In-Reply-To: <20021003.231534.83777766.yoshfuji@linux-ipv6.org> References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> <200210031301.RAA29267@sex.inr.ac.ru> <20021003.231534.83777766.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: 503 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 / 吉藤英明 Date: Thu, 03 Oct 2002 23:15:34 +0900 (JST) In article <200210031301.RAA29267@sex.inr.ac.ru> (at Thu, 3 Oct 2002 17:01:11 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > What's about the problem, it cannot be a problem for TCP, connection > uniqueness is verified by tcp_*_check_established() not depending > on value of SO_REUSEADDR. What's about UDP, the problem really might > be a real problem, let's defer the issue, it looks absoluteky unrelated. Hmm, but I'm afraid that different behavior between TCP and UDP would confuse users. He is saying we should do the TCP part first to make the patch simpler and easier to verify. Then we can investigate the UDP side seperately. > BTW the question: why is bindv6only in device configuration directory? Because I thought that net.ipv6.conf is the place for all configuration... It is for interface level configuration. Do you propose to move it to parent directory (net.ipv6.bindv6only), and put other general settings there? Yes. From yoshfuji@linux-ipv6.org Thu Oct 3 08:06:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 08:06:28 -0700 (PDT) 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 g93F6PtG001966 for ; Thu, 3 Oct 2002 08:06:26 -0700 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 g93F6V1o024082; Fri, 4 Oct 2002 00:06:31 +0900 Date: Fri, 04 Oct 2002 00:06:31 +0900 (JST) Message-Id: <20021004.000631.28088811.yoshfuji@linux-ipv6.org> To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, davem@redhat.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021003.231534.83777766.yoshfuji@linux-ipv6.org> References: <20021003.121350.119660876.yoshfuji@linux-ipv6.org> <200210031301.RAA29267@sex.inr.ac.ru> <20021003.231534.83777766.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-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: 504 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 <20021003.231534.83777766.yoshfuji@linux-ipv6.org> (at Thu, 03 Oct 2002 23:15:34 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > In article <200210031301.RAA29267@sex.inr.ac.ru> (at Thu, 3 Oct 2002 17:01:11 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > While doing *_get_port() daddr/dport are _unknown_ and always zero, > > so it never works. > > > > Please, remove these bits, the patch will become simpler. > > Ok, I'll do that. I remember that test for daddr is for existing sockets, not for socket doing XXX_get_port(). So, I think I don't need to remove that. --yoshfuji From davem@redhat.com Thu Oct 3 08:11:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 08:11:58 -0700 (PDT) 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 g93FButG002427 for ; Thu, 3 Oct 2002 08:11:56 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id IAA32662; Thu, 3 Oct 2002 08:04:09 -0700 Date: Thu, 03 Oct 2002 08:04:08 -0700 (PDT) Message-Id: <20021003.080408.78030688.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port From: "David S. Miller" In-Reply-To: <20021004.000631.28088811.yoshfuji@linux-ipv6.org> References: <200210031301.RAA29267@sex.inr.ac.ru> <20021003.231534.83777766.yoshfuji@linux-ipv6.org> <20021004.000631.28088811.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: 505 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 / 吉藤英明 Date: Fri, 04 Oct 2002 00:06:31 +0900 (JST) In article <20021003.231534.83777766.yoshfuji@linux-ipv6.org> (at Thu, 03 Oct 2002 23:15:34 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > In article <200210031301.RAA29267@sex.inr.ac.ru> (at Thu, 3 Oct 2002 17:01:11 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > While doing *_get_port() daddr/dport are _unknown_ and always zero, > > so it never works. > > > > Please, remove these bits, the patch will become simpler. > > Ok, I'll do that. I remember that test for daddr is for existing sockets, not for socket doing XXX_get_port(). So, I think I don't need to remove that. Where can daddr/dport be non-zero during get_port()? From yoshfuji@linux-ipv6.org Thu Oct 3 08:19:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 08:19:30 -0700 (PDT) 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 g93FJOtG002853 for ; Thu, 3 Oct 2002 08:19:25 -0700 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 g93FJT1o024223; Fri, 4 Oct 2002 00:19:30 +0900 Date: Fri, 04 Oct 2002 00:19:29 +0900 (JST) Message-Id: <20021004.001929.03389091.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021003.080408.78030688.davem@redhat.com> References: <20021003.231534.83777766.yoshfuji@linux-ipv6.org> <20021004.000631.28088811.yoshfuji@linux-ipv6.org> <20021003.080408.78030688.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-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: 506 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 <20021003.080408.78030688.davem@redhat.com> (at Thu, 03 Oct 2002 08:04:08 -0700 (PDT)), "David S. Miller" says: > I remember that test for daddr is for existing sockets, > not for socket doing XXX_get_port(). > So, I think I don't need to remove that. > > Where can daddr/dport be non-zero during get_port()? test for daddr if for sk2. sk2 is iterator for existing sockets, which can be "connected." daddr can be non-zero, can't it? Am I wrong??? --yoshfuji From kuznet@ms2.inr.ac.ru Thu Oct 3 08:54:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 08:54:22 -0700 (PDT) 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 g93FsGtG009489 for ; Thu, 3 Oct 2002 08:54:17 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id TAA29921; Thu, 3 Oct 2002 19:52:40 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210031552.TAA29921@sex.inr.ac.ru> Subject: Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Thu, 3 Oct 2002 19:52:40 +0400 (MSD) Cc: davem@redhat.com, netdev@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: <20021004.001929.03389091.yoshfuji@linux-ipv6.org> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at Oct 4, 2 00:19:29 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 507 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! > test for daddr if for sk2. > sk2 is iterator for existing sockets, which can be "connected." > daddr can be non-zero, can't it? > Am I wrong??? You are absolutely right. But then I am put to coma. Now I do not understand the goal of the check. Can you give a simple example showing what illegal case this check is supposed to eliminate? Actually, it would be great if you said what is wrong in that my patch? It looks so simple that I am not ready to agree that real one should be so complicated. :-) Alexey From Eric.Lemoine@sun.com Thu Oct 3 08:59:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 08:59:40 -0700 (PDT) Received: from s1.smtp.oleane.net (s1.smtp.oleane.net [195.25.12.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g93FxbtG009860 for ; Thu, 3 Oct 2002 08:59:38 -0700 Received: from gbl-dhcp-198-204.europe.research.sun.com ([194.2.198.204]) by s1.smtp.oleane.net with ESMTP id g93FwgoR014297; Thu, 3 Oct 2002 17:58:46 +0200 Received: from eric by (null) with local (MasqMail 0.1.16) id 17x8N7-0ID-00; Thu, 03 Oct 2002 17:58:41 +0200 Date: Thu, 3 Oct 2002 17:58:41 +0200 From: Eric Lemoine To: Ben Greear Cc: Eric Lemoine , kuznet@ms2.inr.ac.ru, Chris Friesen , hadi@cyberus.CA, netdev@oss.sgi.com Subject: Re: PATCH Re: udp weirdness Message-ID: <20021003155841.GF601@hookipa> References: <3D99B6C7.3010302@nortelnetworks.com> <200210011531.TAA19943@sex.inr.ac.ru> <20021002111326.GG357@hookipa> <3D9B0FF1.1070203@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D9B0FF1.1070203@candelatech.com> User-Agent: Mutt/1.3.28i X-Warning: return path set from From: address X-archive-position: 508 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 > > >It is difficult task, if possible at all. > > > > > >The main obstacle is that we must not block after select() succeeded, > > >otherwise applications will lockup. Taking into account nature of datagram > > >services (and generally of networking services, where routes change et > > >al.) > > >you do not know at time of select(), where the datagram will go. > > >So, blocking can be made only based on a criterium not depending on this. > > >problems with silent losses. People just do not care about this, so > > >they get the thing which they deserve. > > > >Alexey, > > > >Would you mind explaining a bit more why apps will lockup if we block > >after select() succeeded. Or anyone? > > Actually, I'm more interested to know why we would **need** to block after > select has succeeded. It would seem to me that select is busted in this > case. For the case of a very large UDP packet and a small send buffer, > select gets confused, but at least when the send buffer is > 128k, it should > be right... With the current impl. process calling sendto() doesn't go to sleep after select() has succeeded. My question applied in the context where process goes to sleep when the qdisc queue is overflowed. -- Eric From yoshfuji@linux-ipv6.org Thu Oct 3 09:13:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 09:13:26 -0700 (PDT) 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 g93GDItG010360 for ; Thu, 3 Oct 2002 09:13:21 -0700 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 g93GDF1o028041; Fri, 4 Oct 2002 01:13:15 +0900 Date: Fri, 04 Oct 2002 01:13:15 +0900 (JST) Message-Id: <20021004.011315.05129566.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Miscellaneous clean-ups 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-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: 509 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, 1. use s6_addrXX instead of in6_u.s6_addrXX. 2. avoid using magic number. 3. use 32bit constants. Following patch in against linux-2.4.19. Thanks in advance. ------------------------------------------------------------------- Patch-Name: Miscellaneous clean-ups Patch-Id: FIX_2_4_19_ADDRCONF_TIMER-20020905 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project Reference: RFC2553 ------------------------------------------------------------------- Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/09/12 09:41:58 1.1.1.1.12.1 @@ -172,7 +172,7 @@ if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { - if (addr->in6_u.u6_addr32[3] == 0) + if (addr->s6_addr32[3] == 0) return IPV6_ADDR_ANY; if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) @@ -1187,7 +1187,7 @@ ASSERT_RTNL(); memset(&addr, 0, sizeof(struct in6_addr)); - addr.s6_addr[15] = 1; + addr.s6_addr32[3] = __constant_htonl(0x00000001); if ((idev = ipv6_find_idev(dev)) == NULL) { printk(KERN_DEBUG "init loopback: add_dev failed\n"); @@ -1234,9 +1234,7 @@ return; memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; + addr.s6_addr32[0] = __contant_htonl(0xFE800000); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/icmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/icmp.c 2002/09/12 09:41:58 1.1.1.1.12.1 @@ -198,7 +198,7 @@ u8 type; if (skb_copy_bits(skb, ptr+offsetof(struct icmp6hdr, icmp6_type), &type, 1) - || !(type & 0x80)) + || !(type & ICMPV6_INFOMSG_MASK)) return 1; } return 0; @@ -216,7 +216,7 @@ int res = 0; /* Informational messages are not limited. */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) return 1; /* Do not limit pmtu discovery, it would break it. */ @@ -519,22 +519,22 @@ skb_checksum(skb, 0, skb->len, 0))) { if (net_ratelimit()) printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - ntohs(saddr->in6_u.u6_addr16[0]), - ntohs(saddr->in6_u.u6_addr16[1]), - ntohs(saddr->in6_u.u6_addr16[2]), - ntohs(saddr->in6_u.u6_addr16[3]), - ntohs(saddr->in6_u.u6_addr16[4]), - ntohs(saddr->in6_u.u6_addr16[5]), - ntohs(saddr->in6_u.u6_addr16[6]), - ntohs(saddr->in6_u.u6_addr16[7]), - ntohs(daddr->in6_u.u6_addr16[0]), - ntohs(daddr->in6_u.u6_addr16[1]), - ntohs(daddr->in6_u.u6_addr16[2]), - ntohs(daddr->in6_u.u6_addr16[3]), - ntohs(daddr->in6_u.u6_addr16[4]), - ntohs(daddr->in6_u.u6_addr16[5]), - ntohs(daddr->in6_u.u6_addr16[6]), - ntohs(daddr->in6_u.u6_addr16[7])); + ntohs(saddr->s6_addr16[0]), + ntohs(saddr->s6_addr16[1]), + ntohs(saddr->s6_addr16[2]), + ntohs(saddr->s6_addr16[3]), + ntohs(saddr->s6_addr16[4]), + ntohs(saddr->s6_addr16[5]), + ntohs(saddr->s6_addr16[6]), + ntohs(saddr->s6_addr16[7]), + ntohs(daddr->s6_addr16[0]), + ntohs(daddr->s6_addr16[1]), + ntohs(daddr->s6_addr16[2]), + ntohs(daddr->s6_addr16[3]), + ntohs(daddr->s6_addr16[4]), + ntohs(daddr->s6_addr16[5]), + ntohs(daddr->s6_addr16[6]), + ntohs(daddr->s6_addr16[7])); goto discard_it; } } @@ -613,7 +613,7 @@ printk(KERN_DEBUG "icmpv6: msg of unkown type\n"); /* informational */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) break; /* Index: net/ipv6/netfilter/ip6_queue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6_queue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.2 diff -u -r1.1.1.1 -r1.1.1.1.12.2 --- net/ipv6/netfilter/ip6_queue.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6_queue.c 2002/09/19 03:57:51 1.1.1.1.12.2 @@ -306,14 +306,8 @@ */ if (e->info->hook == NF_IP_LOCAL_OUT) { struct ipv6hdr *iph = e->skb->nh.ipv6h; - if (!( iph->daddr.in6_u.u6_addr32[0] == e->rt_info.daddr.in6_u.u6_addr32[0] - && iph->daddr.in6_u.u6_addr32[1] == e->rt_info.daddr.in6_u.u6_addr32[1] - && iph->daddr.in6_u.u6_addr32[2] == e->rt_info.daddr.in6_u.u6_addr32[2] - && iph->daddr.in6_u.u6_addr32[3] == e->rt_info.daddr.in6_u.u6_addr32[3] - && iph->saddr.in6_u.u6_addr32[0] == e->rt_info.saddr.in6_u.u6_addr32[0] - && iph->saddr.in6_u.u6_addr32[1] == e->rt_info.saddr.in6_u.u6_addr32[1] - && iph->saddr.in6_u.u6_addr32[2] == e->rt_info.saddr.in6_u.u6_addr32[2] - && iph->saddr.in6_u.u6_addr32[3] == e->rt_info.saddr.in6_u.u6_addr32[3])) + 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 0; From kuznet@ms2.inr.ac.ru Thu Oct 3 09:31:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 09:32:02 -0700 (PDT) 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 g93GVutG010843 for ; Thu, 3 Oct 2002 09:31:56 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id UAA30047; Thu, 3 Oct 2002 20:29:59 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210031629.UAA30047@sex.inr.ac.ru> Subject: Re: PATCH Re: udp weirdness To: Eric.Lemoine@ens-lyon.fr (Eric Lemoine) Date: Thu, 3 Oct 2002 20:29:59 +0400 (MSD) Cc: greearb@candelatech.com, Eric.Lemoine@ens-lyon.fr, cfriesen@nortelnetworks.com, hadi@cyberus.CA, netdev@oss.sgi.com In-Reply-To: <20021003155841.GF601@hookipa> from "Eric Lemoine" at Oct 3, 2 05:58:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 510 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! > > >Would you mind explaining a bit more why apps will lockup if we block > > >after select() succeeded. Or anyone? Because queue overflow is persistant condition. Do you want your routing daemon went to coma when sending an update to dead ppp link? But, actually, it is simply required by standards. No blocking after select success is definition of select, in fact. Alexey From yoshfuji@linux-ipv6.org Thu Oct 3 09:50:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 09:50:39 -0700 (PDT) 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 g93GoZtG011878 for ; Thu, 3 Oct 2002 09:50:36 -0700 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 g93Goj1o028339; Fri, 4 Oct 2002 01:50:45 +0900 Date: Fri, 04 Oct 2002 01:50:45 +0900 (JST) Message-Id: <20021004.015045.96199793.yoshfuji@linux-ipv6.org> To: netdev@oss.sgi.com Cc: usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Improvement of Source Address Selection From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20020928.001742.125874265.yoshfuji@linux-ipv6.org> References: <20020928.001742.125874265.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-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: 511 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 <20020928.001742.125874265.yoshfuji@linux-ipv6.org> (at Sat, 28 Sep 2002 00:17:42 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > This patch supports standard default source address selection > algorithm. It takes status, address/prefix itself (prefer same address, > prefer longest matching prefix) into consideration. > Note: Even though matching label is not implemented yet, > this is better than current one. > > Following patch is against linux-2.4.19. This patch is revised version. I think we have more things to be done, but anyways, - save memory (comment from devem) - introduced (static) policy label (comment from pekkas) Thanks in advance. ------ Index: include/net/addrconf.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/addrconf.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.6.1 diff -u -r1.1.1.1 -r1.1.1.1.6.1 --- include/net/addrconf.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/addrconf.h 2002/09/26 19:15:15 1.1.1.1.6.1 @@ -55,6 +55,9 @@ struct net_device *dev); extern struct inet6_ifaddr * ipv6_get_ifaddr(struct in6_addr *addr, struct net_device *dev); +extern int ipv6_dev_get_saddr(struct net_device *ddev, + struct in6_addr *daddr, + struct in6_addr *saddr); extern int ipv6_get_saddr(struct dst_entry *dst, struct in6_addr *daddr, struct in6_addr *saddr); Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.6.6 diff -u -r1.1.1.1 -r1.1.1.1.6.6 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/10/03 03:28:33 1.1.1.1.6.6 @@ -26,6 +26,10 @@ * packets. * yoshfuji@USAGI : Fixed interval between DAD * packets. + * YOSHIFUJI Hideaki @USAGI : improved source address + * selection; consider scope, + * status etc. + * */ #include @@ -104,6 +108,8 @@ static struct notifier_block *inet6addr_chain; +static u32 ipv6_addrselect_label_lookup(const struct in6_addr *addr, int ifindex); + struct ipv6_devconf ipv6_devconf = { 0, /* forwarding */ @@ -188,6 +194,99 @@ return IPV6_ADDR_RESERVED; } +#ifndef IPV6_ADDR_MC_SCOPE +#define IPV6_ADDR_MC_SCOPE(a) \ + ((a)->s6_addr[1] & 0x0f) /* XXX nonstandard */ +#define __IPV6_ADDR_SCOPE_RESERVED -2 +#define __IPV6_ADDR_SCOPE_ANY -1 +#define IPV6_ADDR_SCOPE_NODELOCAL 0x01 +#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 +#define IPV6_ADDR_SCOPE_SITELOCAL 0x05 +#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 +#define IPV6_ADDR_SCOPE_GLOBAL 0x0e +#endif + +int ipv6_addrselect_scope(const struct in6_addr *addr) +{ + u32 st; + + st = addr->s6_addr32[0]; + + if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && + (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) + return IPV6_ADDR_SCOPE_GLOBAL; + + if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) + return IPV6_ADDR_MC_SCOPE(addr); + + if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) + return IPV6_ADDR_SCOPE_LINKLOCAL; + + if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) + return IPV6_ADDR_SCOPE_SITELOCAL; + + if ((st | addr->s6_addr32[1]) == 0) { + if (addr->s6_addr32[2] == 0) { + if (addr->s6_addr32[3] == 0) + return __IPV6_ADDR_SCOPE_ANY; + + if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.4 */ + + return IPV6_ADDR_SCOPE_GLOBAL; /* section 2.3 */ + } + + if (addr->s6_addr32[2] == __constant_htonl(0x0000FFFF)) { + if (addr->s6_addr32[3] == __constant_htonl(0xA9FF0000)) + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */ + if (addr->s6_addr32[3] == __constant_htonl(0xAC000000)) { + if (addr->s6_addr32[3] == __constant_htonl(0xAC100000)) + return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */ + + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */ + } + if (addr->s6_addr32[3] == __constant_htonl(0x0A000000)) + return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */ + if (addr->s6_addr32[3] == __constant_htonl(0xC0A80000)) + return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */ + + return IPV6_ADDR_SCOPE_GLOBAL; /* section 2.2 */ + } + } + + return __IPV6_ADDR_SCOPE_RESERVED; +} + +/* find 1st bit in difference between the 2 addrs */ +static inline int addr_diff(const void *__a1, const void *__a2, int addrlen) +{ + /* find 1st bit in difference between the 2 addrs. + * bit may be an invalid value, + * but if it is >= plen, the value is ignored in any case. + */ + const u32 *a1 = __a1; + const u32 *a2 = __a2; + int i; + + addrlen >>= 2; + for (i = 0; i < addrlen; i++) { + u32 xb = a1[i] ^ a2[i]; + if (xb) { + int j = 31; + xb = ntohl(xb); + while ((xb & (1 << j)) == 0) + j--; + return (i * 32 + 31 - j); + } + } + return addrlen<<5; +} + +static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_addr *a2) +{ + return addr_diff(a1->s6_addr, a2->s6_addr, sizeof(struct in6_addr)); +} + static void addrconf_del_timer(struct inet6_ifaddr *ifp) { if (del_timer(&ifp->timer)) @@ -449,122 +548,160 @@ /* * Choose an apropriate source address - * should do: - * i) get an address with an apropriate scope - * ii) see if there is a specific route for the destination and use - * an address of the attached interface - * iii) don't use deprecated addresses + * draft-ietf-ipngwg-default-addr-select-09.txt */ -int ipv6_get_saddr(struct dst_entry *dst, - struct in6_addr *daddr, struct in6_addr *saddr) +#define IPV6_SADDRSELECT_SELF 0x01 +#define IPV6_SADDRSELECT_PREFERRED 0x02 +#define IPV6_SADDRSELECT_HOME 0x04 +#define IPV6_SADDRSELECT_PUBLIC 0x08 +#define IPV6_SADDRSELECT_INTERFACE 0x10 +#define IPV6_SADDRSELECT_LABEL 0x20 + +struct addrselect_attrs { + struct inet6_ifaddr *ifp; + u16 flags; + s16 matchlen; + u8 scope; +}; + +int ipv6_dev_get_saddr(struct net_device *daddr_dev, + struct in6_addr *daddr, struct in6_addr *saddr) { - int scope; - struct inet6_ifaddr *ifp = NULL; - struct inet6_ifaddr *match = NULL; - struct net_device *dev = NULL; + int daddr_scope; + u32 daddr_label; + struct inet6_ifaddr *ifp0, *ifp = NULL; + struct net_device *dev; struct inet6_dev *idev; - struct rt6_info *rt; - int err; - rt = (struct rt6_info *) dst; - if (rt) - dev = rt->rt6i_dev; - - scope = ipv6_addr_scope(daddr); - if (rt && (rt->rt6i_flags & RTF_ALLONLINK)) { - /* - * route for the "all destinations on link" rule - * when no routers are present - */ - scope = IFA_LINK; - } - - /* - * known dev - * search dev and walk through dev addresses - */ + int err; + int update; + struct addrselect_attrs candidate = {NULL,0,0}; - if (dev) { - if (dev->flags & IFF_LOOPBACK) - scope = IFA_HOST; + daddr_scope = ipv6_addrselect_scope(daddr); + daddr_label = ipv6_addrselect_label_lookup(daddr, + daddr_dev?daddr_dev->ifindex:0); - read_lock(&addrconf_lock); + read_lock(&dev_base_lock); + read_lock(&addrconf_lock); + for (dev = dev_base; dev; dev=dev->next) { idev = __in6_dev_get(dev); - if (idev) { - 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); - read_unlock_bh(&idev->lock); - read_unlock(&addrconf_lock); - goto out; - } - - if (!match && !(ifp->flags & IFA_F_TENTATIVE)) { - match = ifp; - in6_ifa_hold(ifp); - } + + if (!idev) + continue; + + read_lock_bh(&idev->lock); + ifp0 = idev->addr_list; + for (ifp=ifp0; ifp; ifp=ifp->if_next) { + struct addrselect_attrs temp = {NULL,0,0}; + update = 0; + + /* Rule 1: Prefer same address */ + if (ipv6_addr_cmp(&ifp->addr, daddr) == 0) + temp.flags |= IPV6_SADDRSELECT_SELF; + else + temp.flags &= ~IPV6_SADDRSELECT_SELF; + update = (temp.flags&IPV6_SADDRSELECT_SELF) - + (candidate.flags&IPV6_SADDRSELECT_SELF); + if (update < 0) { + continue; + } + + /* Rule 2: Prefer appropriate scope */ + temp.scope = ipv6_addrselect_scope(&ifp->addr); + if (!update) { + update = temp.scope - candidate.scope; + if (update > 0) { + update = candidate.scope < daddr_scope ? 1 : -1; + } else if (update < 0) { + update = temp.scope < daddr_scope ? -1 : 1; } } - read_unlock_bh(&idev->lock); - } - read_unlock(&addrconf_lock); - } + if (update < 0) { + continue; + } - if (scope == IFA_LINK) - goto out; + /* Rule 3: Avoid deprecated address */ + if (!(ifp->flags & IFA_F_DEPRECATED)) + temp.flags |= IPV6_SADDRSELECT_PREFERRED; + else + temp.flags &= ~IPV6_SADDRSELECT_PREFERRED; + if (!update) + update = (temp.flags&IPV6_SADDRSELECT_PREFERRED) - + (candidate.flags&IPV6_SADDRSELECT_PREFERRED); + if (update < 0) { + continue; + } - /* - * dev == NULL or search failed for specified dev - */ + /* XXX: Rule 4: Prefer home address */ - read_lock(&dev_base_lock); - read_lock(&addrconf_lock); - for (dev = dev_base; dev; dev=dev->next) { - idev = __in6_dev_get(dev); - if (idev) { - 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); - read_unlock_bh(&idev->lock); - goto out_unlock_base; - } - - if (!match && !(ifp->flags&IFA_F_TENTATIVE)) { - match = ifp; - in6_ifa_hold(ifp); - } - } + /* Rule 5: Prefer outgoing interface */ + if (daddr_dev == NULL || ifp->idev == NULL || + daddr_dev == ifp->idev->dev) + temp.flags |= IPV6_SADDRSELECT_INTERFACE; + else + temp.flags &= ~IPV6_SADDRSELECT_INTERFACE; + if (!update) + update = (temp.flags&IPV6_SADDRSELECT_INTERFACE) - + (candidate.flags&IPV6_SADDRSELECT_INTERFACE); + if (update < 0) { + continue; } - read_unlock_bh(&idev->lock); + + /* XXX: Rule 6: Prefer matching label */ + if (ipv6_addrselect_label_lookup(&ifp->addr, dev->ifindex) == daddr_label) + temp.flags |= IPV6_SADDRSELECT_LABEL; + else + temp.flags &= ~IPV6_SADDRSELECT_LABEL; + if (!update) + update = (temp.flags&IPV6_SADDRSELECT_LABEL) - + (candidate.flags&IPV6_SADDRSELECT_LABEL); + if (update < 0) { + continue; + } + + /* XXX: Rule 7: Prefer public address */ + + /* Rule 8: Use longest matching prefix */ + temp.matchlen = ipv6_addr_diff(&ifp->addr, daddr); + if (!update) + update = temp.matchlen - candidate.matchlen; + if (update < 0) { + continue; + } + + /* Final Rule */ + if (update <= 0) + continue; + + /* update candidate */ + temp.ifp = ifp; + in6_ifa_hold(ifp); + if (candidate.ifp) + in6_ifa_put(candidate.ifp); + candidate = temp; } + read_unlock_bh(&idev->lock); } - -out_unlock_base: read_unlock(&addrconf_lock); read_unlock(&dev_base_lock); - -out: - if (ifp == NULL) { - ifp = match; - match = NULL; - } - err = -EADDRNOTAVAIL; - if (ifp) { - ipv6_addr_copy(saddr, &ifp->addr); + if (candidate.ifp) { + ipv6_addr_copy(saddr, &candidate.ifp->addr); + in6_ifa_put(candidate.ifp); err = 0; - in6_ifa_put(ifp); + } else { + err = -EADDRNOTAVAIL; } - if (match) - in6_ifa_put(match); - return err; } +int ipv6_get_saddr(struct dst_entry *dst, + struct in6_addr *daddr, struct in6_addr *saddr) +{ + return ipv6_dev_get_saddr(dst ? ((struct rt6_info *)dst)->rt6i_dev : NULL, + daddr, saddr); +} + int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr) { struct inet6_dev *idev; @@ -636,6 +773,69 @@ read_unlock_bh(&addrconf_hash_lock); return ifp; +} + +/* address selection: default policy label */ +/* XXX: user level configuration */ +static struct ipv6_addrselect_label { + struct in6_addr addr; + u16 plen; + u32 ifindex; + u32 label; +} ipv6_addrselect_label_table[] = { + /* ::1/128, label = 0 */ + { + .addr = {{{ [15] = 1 }}}, + .plen = 128, + .label = 0, + }, + /* ::/0, label = 1 */ + { + .plen = 0, + .label = 1, + }, + /* 2002::/16, label = 2 */ + { + .addr = {{{ 0x20, 0x02 }}}, + .plen = 16, + .label = 2, + }, + /* ::/96, label = 3 */ + { + .plen = 96, + .label = 3, + }, + /* ::ffff:0:0/96, label = 4 */ + { + .addr = {{{ [10] = 0xff, [11] = 0xff }}}, + .plen = 96, + .label = 4, + }, + /* sentinel */ + { + .label = 0xffffffff, + } +}; + +static u32 ipv6_addrselect_label_lookup(const struct in6_addr *addr, + int ifindex) +{ + struct ipv6_addrselect_label *p; + int plen, matchlen = -1; + u32 label = 0xffffffff; + + for (p = ipv6_addrselect_label_table; + p->label != 0xffffffff; + p++) { + if (ifindex && p->ifindex && ifindex != p->ifindex) + continue; + plen = ipv6_addr_diff(addr, &p->addr); + if (plen < p->plen || plen < matchlen) + continue; + matchlen = plen; + label = p->label; + } + return label; } /* Gets referenced address, destroys ifaddr */ From davem@redhat.com Thu Oct 3 10:43:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 10:43:37 -0700 (PDT) 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 g93HhZtG016213 for ; Thu, 3 Oct 2002 10:43:35 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA01693; Thu, 3 Oct 2002 10:36:17 -0700 Date: Thu, 03 Oct 2002 10:36:17 -0700 (PDT) Message-Id: <20021003.103617.04446177.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups From: "David S. Miller" In-Reply-To: <20021004.011315.05129566.yoshfuji@linux-ipv6.org> References: <20021004.011315.05129566.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: 512 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 / 吉藤英明 Date: Fri, 04 Oct 2002 01:13:15 +0900 (JST) @@ -1187,7 +1187,7 @@ ASSERT_RTNL(); memset(&addr, 0, sizeof(struct in6_addr)); - addr.s6_addr[15] = 1; + addr.s6_addr32[3] = __constant_htonl(0x00000001); Do not use __constant_htonl() in runtime code, use htonl(). Arnaldo de Melo told you this the other day for another one of your patches, so you must fix this kind of stuff up before I'll apply any of your patches which have this problem. Only use __constant_htonl() for compile time initialization of data built into the kernel. Otherwise I like you patch, please fix it up so I may apply it. From yoshfuji@linux-ipv6.org Thu Oct 3 15:39:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 15:39:27 -0700 (PDT) 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 g93MdJtG025889 for ; Thu, 3 Oct 2002 15:39:20 -0700 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 g93MdQ1o030139; Fri, 4 Oct 2002 07:39:26 +0900 Date: Fri, 04 Oct 2002 07:39:25 +0900 (JST) Message-Id: <20021004.073925.101556969.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021004.073642.125593159.yoshfuji@linux-ipv6.org> References: <20021004.011315.05129566.yoshfuji@linux-ipv6.org> <20021003.103617.04446177.davem@redhat.com> <20021004.073642.125593159.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-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: 513 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 <20021004.073642.125593159.yoshfuji@linux-ipv6.org> (at Fri, 04 Oct 2002 07:36:42 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > I saw many __constant_{hton,ntoh}{s,l}()s, so fixed. > > 1. use s6_addrXX instead of in6_u.s6_addrXX. > 2. avoid using magic number. > 3. use 32bit constants. > --> 4. avoid __constant_{hton,ntoh}{l,s}() in runtime code. oops, sorry, not fixed in my fix... :-p just a moment, please... --yoshfuji From yoshfuji@linux-ipv6.org Thu Oct 3 16:32:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 16:32:23 -0700 (PDT) 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 g93NW4tK028181 for ; Thu, 3 Oct 2002 16:32:10 -0700 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 g93MsG1o030234; Fri, 4 Oct 2002 07:54:16 +0900 Date: Fri, 04 Oct 2002 07:54:16 +0900 (JST) Message-Id: <20021004.075416.20775355.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021004.073925.101556969.yoshfuji@linux-ipv6.org> References: <20021003.103617.04446177.davem@redhat.com> <20021004.073642.125593159.yoshfuji@linux-ipv6.org> <20021004.073925.101556969.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-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: 515 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 <20021004.073925.101556969.yoshfuji@linux-ipv6.org> (at Fri, 04 Oct 2002 07:39:25 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > In article <20021004.073642.125593159.yoshfuji@linux-ipv6.org> (at Fri, 04 Oct 2002 07:36:42 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > > > I saw many __constant_{hton,ntoh}{s,l}()s, so fixed. > > > > 1. use s6_addrXX instead of in6_u.s6_addrXX. > > 2. avoid using magic number. > > 3. use 32bit constants. > > --> 4. avoid __constant_{hton,ntoh}{l,s}() in runtime code. > > oops, sorry, not fixed in my fix... :-p I forgot to commit __constant_XXX() under net/ipv6 in my tree... anyway, resend with the fix for ipv6. Index: net/ipv4/arp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/arp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/arp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/arp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -513,7 +513,7 @@ skb->nh.raw = skb->data; arp = (struct arphdr *) skb_put(skb,sizeof(struct arphdr) + 2*(dev->addr_len+4)); skb->dev = dev; - skb->protocol = __constant_htons (ETH_P_ARP); + skb->protocol = htons (ETH_P_ARP); if (src_hw == NULL) src_hw = dev->dev_addr; if (dest_hw == NULL) @@ -539,33 +539,33 @@ switch (dev->type) { default: arp->ar_hrd = htons(dev->type); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_pro = htons(ETH_P_IP); break; #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - arp->ar_hrd = __constant_htons(ARPHRD_AX25); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_AX25); + arp->ar_pro = htons(AX25_P_IP); break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - arp->ar_hrd = __constant_htons(ARPHRD_NETROM); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_NETROM); + arp->ar_pro = htons(AX25_P_IP); break; #endif #endif #ifdef CONFIG_FDDI case ARPHRD_FDDI: - arp->ar_hrd = __constant_htons(ARPHRD_ETHER); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_ETHER); + arp->ar_pro = htons(ETH_P_IP); break; #endif #ifdef CONFIG_TR case ARPHRD_IEEE802_TR: - arp->ar_hrd = __constant_htons(ARPHRD_IEEE802); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_IEEE802); + arp->ar_pro = htons(ETH_P_IP); break; #endif } @@ -629,7 +629,7 @@ switch (dev_type) { default: - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; if (htons(dev_type) != arp->ar_hrd) goto out; @@ -640,10 +640,10 @@ * ETHERNET devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -653,10 +653,10 @@ * Token ring devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -667,10 +667,10 @@ * of 1 (Ethernet). However, to be more robust, we'll accept hardware * types of either 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -681,25 +681,25 @@ * 802 devices) should accept ARP hardware types of 6 (IEEE 802) * and 1 (Ethernet). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_AX25)) + if (arp->ar_hrd != htons(ARPHRD_AX25)) goto out; break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_NETROM)) + if (arp->ar_hrd != htons(ARPHRD_NETROM)) goto out; break; #endif @@ -708,8 +708,8 @@ /* Understand only these message types */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) && - arp->ar_op != __constant_htons(ARPOP_REQUEST)) + if (arp->ar_op != htons(ARPOP_REPLY) && + arp->ar_op != htons(ARPOP_REQUEST)) goto out; /* @@ -754,13 +754,13 @@ /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && inet_addr_type(tip) == RTN_LOCAL) arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); goto out; } - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && ip_route_input(skb, tip, sip, 0, dev) == 0) { rt = (struct rtable*)skb->dst; @@ -810,7 +810,7 @@ devices (strip is candidate) */ if (n == NULL && - arp->ar_op == __constant_htons(ARPOP_REPLY) && + arp->ar_op == htons(ARPOP_REPLY) && inet_addr_type(sip) == RTN_UNICAST) n = __neigh_lookup(&arp_tbl, &sip, dev, -1); #endif @@ -830,7 +830,7 @@ /* Broadcast replies and request packets do not assert neighbour reachability. */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) || + if (arp->ar_op != htons(ARPOP_REPLY) || skb->pkt_type != PACKET_HOST) state = NUD_STALE; neigh_update(n, sha, state, override, 1); @@ -1050,7 +1050,7 @@ (r.arp_flags & (ATF_NETMASK|ATF_DONTPUB))) return -EINVAL; if (!(r.arp_flags & ATF_NETMASK)) - ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=__constant_htonl(0xFFFFFFFFUL); + ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=htonl(0xFFFFFFFFUL); rtnl_lock(); if (r.arp_dev[0]) { Index: net/ipv4/igmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/igmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/igmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/igmp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -229,7 +229,7 @@ iph->version = 4; iph->ihl = (sizeof(struct iphdr)+4)>>2; iph->tos = 0; - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); iph->ttl = 1; iph->daddr = dst; iph->saddr = rt->rt_src; Index: net/ipv4/ip_gre.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_gre.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_gre.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_gre.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -412,7 +412,7 @@ struct sk_buff *skb2; struct rtable *rt; - if (p[1] != __constant_htons(ETH_P_IP)) + if (p[1] != htons(ETH_P_IP)) return; flags = p[0]; @@ -535,10 +535,10 @@ static inline void ipgre_ecn_decapsulate(struct iphdr *iph, struct sk_buff *skb) { if (INET_ECN_is_ce(iph->tos)) { - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (INET_ECN_is_not_ce(skb->nh.iph->tos)) IP_ECN_set_ce(skb->nh.iph); - } else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + } else if (skb->protocol == htons(ETH_P_IPV6)) { if (INET_ECN_is_not_ce(ip6_get_dsfield(skb->nh.ipv6h))) IP6_ECN_set_ce(skb->nh.ipv6h); } @@ -549,9 +549,9 @@ ipgre_ecn_encapsulate(u8 tos, struct iphdr *old_iph, struct sk_buff *skb) { u8 inner = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) inner = old_iph->tos; - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) inner = ip6_get_dsfield((struct ipv6hdr*)old_iph); return INET_ECN_encapsulate(tos, inner); } @@ -708,13 +708,13 @@ goto tx_error; } - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { rt = (struct rtable*)skb->dst; if ((dst = rt->rt_gateway) == 0) goto tx_error_icmp; } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct in6_addr *addr6; int addr_type; struct neighbour *neigh = skb->dst->neighbour; @@ -742,7 +742,7 @@ tos = tiph->tos; if (tos&1) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) tos = old_iph->tos; tos &= ~1; } @@ -765,13 +765,13 @@ else mtu = skb->dst ? skb->dst->pmtu : dev->mtu; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (skb->dst && mtu < skb->dst->pmtu && mtu >= 68) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); @@ -779,7 +779,7 @@ } } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct rt6_info *rt6 = (struct rt6_info*)skb->dst; if (rt6 && mtu < rt6->u.dst.pmtu && mtu >= IPV6_MIN_MTU) { @@ -845,10 +845,10 @@ iph->saddr = rt->rt_src; if ((iph->ttl = tiph->ttl) == 0) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) iph->ttl = old_iph->ttl; #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) iph->ttl = ((struct ipv6hdr*)old_iph)->hop_limit; #endif else @@ -936,11 +936,11 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_GRE || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF)) || + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF)) || ((p.i_flags|p.o_flags)&(GRE_VERSION|GRE_ROUTING))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); if (!(p.i_flags&GRE_KEY)) p.i_key = 0; Index: net/ipv4/ip_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_output.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -186,7 +186,7 @@ struct net_device *dev = skb->dst->dev; skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev, ip_finish_output2); @@ -208,7 +208,7 @@ #endif skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); /* * Multicasts are looped back for other local users @@ -382,7 +382,7 @@ *((__u16 *)iph) = htons((4 << 12) | (5 << 8) | (sk->protinfo.af_inet.tos & 0xff)); iph->tot_len = htons(skb->len); if (ip_dont_fragment(sk, &rt->u.dst)) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; iph->ttl = sk->protinfo.af_inet.ttl; Index: net/ipv4/ipconfig.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipconfig.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipconfig.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipconfig.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -356,11 +356,11 @@ if (ic_netmask == INADDR_NONE) { if (IN_CLASSA(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSA_NET); + ic_netmask = htonl(IN_CLASSA_NET); else if (IN_CLASSB(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSB_NET); + ic_netmask = htonl(IN_CLASSB_NET); else if (IN_CLASSC(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSC_NET); + ic_netmask = htonl(IN_CLASSC_NET); else { printk(KERN_ERR "IP-Config: Unable to guess netmask for address %u.%u.%u.%u\n", NIPQUAD(ic_myaddr)); @@ -426,11 +426,11 @@ goto drop; /* If it's not a RARP reply, delete it. */ - if (rarp->ar_op != __constant_htons(ARPOP_RREPLY)) + if (rarp->ar_op != htons(ARPOP_RREPLY)) goto drop; /* If it's not Ethernet, delete it. */ - if (rarp->ar_pro != __constant_htons(ETH_P_IP)) + if (rarp->ar_pro != htons(ETH_P_IP)) goto drop; /* Extract variable-width fields */ @@ -661,15 +661,15 @@ h->version = 4; h->ihl = 5; h->tot_len = htons(sizeof(struct bootp_pkt)); - h->frag_off = __constant_htons(IP_DF); + h->frag_off = htons(IP_DF); h->ttl = 64; h->protocol = IPPROTO_UDP; h->daddr = INADDR_BROADCAST; h->check = ip_fast_csum((unsigned char *) h, h->ihl); /* Construct UDP header */ - b->udph.source = __constant_htons(68); - b->udph.dest = __constant_htons(67); + b->udph.source = htons(68); + b->udph.dest = htons(67); b->udph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr)); /* UDP checksum not calculated -- explicitly allowed in BOOTP RFC */ @@ -700,7 +700,7 @@ /* Chain packet down the line... */ skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); if ((dev->hard_header && dev->hard_header(skb, dev, ntohs(skb->protocol), dev->broadcast, dev->dev_addr, skb->len) < 0) || dev_queue_xmit(skb) < 0) @@ -800,13 +800,13 @@ ip_fast_csum((char *) h, h->ihl) != 0 || skb->len < ntohs(h->tot_len) || h->protocol != IPPROTO_UDP || - b->udph.source != __constant_htons(67) || - b->udph.dest != __constant_htons(68) || + b->udph.source != htons(67) || + b->udph.dest != htons(68) || ntohs(h->tot_len) < ntohs(b->udph.len) + sizeof(struct iphdr)) goto drop; /* Fragments are not supported */ - if (h->frag_off & __constant_htons(IP_OFFSET | IP_MF)) { + if (h->frag_off & htons(IP_OFFSET | IP_MF)) { printk(KERN_ERR "DHCP/BOOTP: Ignoring fragmented reply.\n"); goto drop; } Index: net/ipv4/ipip.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipip.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipip.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipip.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -483,7 +483,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->pkt_type = PACKET_HOST; read_lock(&ipip_lock); @@ -544,7 +544,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto tx_error; if (tos&1) @@ -585,9 +585,9 @@ if (skb->dst && mtu < skb->dst->pmtu) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); goto tx_error; @@ -703,10 +703,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPIP || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv4/ipmr.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipmr.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipmr.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipmr.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1434,7 +1434,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); @@ -1501,7 +1501,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); Index: net/ipv4/route.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/route.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/route.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/route.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1246,7 +1246,7 @@ return -EINVAL; if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) || - skb->protocol != __constant_htons(ETH_P_IP)) + skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) { @@ -1457,7 +1457,7 @@ inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) flags |= RTCF_DOREDIRECT; - if (skb->protocol != __constant_htons(ETH_P_IP)) { + if (skb->protocol != htons(ETH_P_IP)) { /* Not IP (i.e. ARP). Do not create route, if it is * invalid for proxy arp. DNAT routes are always valid. */ @@ -1522,7 +1522,7 @@ out: return err; brd_input: - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) @@ -2156,7 +2156,7 @@ err = -ENODEV; if (!dev) goto out; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->dev = dev; local_bh_disable(); err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev); Index: net/ipv4/tcp_diag.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_diag.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_diag.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_diag.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -346,7 +346,7 @@ break; if (sk->family == AF_INET6 && cond->family == AF_INET) { if (addr[0] == 0 && addr[1] == 0 && - addr[2] == __constant_htonl(0xffff) && + addr[2] == htonl(0xffff) && bitstring_match(addr+3, cond->addr, cond->prefix_len)) break; } Index: net/ipv4/tcp_input.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_input.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_input.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_input.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -2083,8 +2083,8 @@ } else if (tp->tstamp_ok && th->doff == (sizeof(struct tcphdr)>>2)+(TCPOLEN_TSTAMP_ALIGNED>>2)) { __u32 *ptr = (__u32 *)(th + 1); - if (*ptr == __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { + if (*ptr == ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { tp->saw_tstamp = 1; ++ptr; tp->rcv_tsval = ntohl(*ptr); @@ -3252,8 +3252,8 @@ __u32 *ptr = (__u32 *)(th + 1); /* No? Slow path! */ - if (*ptr != __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) + if (*ptr != ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) goto slow_path; tp->saw_tstamp = 1; Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_ipv4.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1210,10 +1210,10 @@ arg.iov[0].iov_len = sizeof(rep.th); arg.n_iov = 1; if (ts) { - rep.tsopt[0] = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + rep.tsopt[0] = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); rep.tsopt[1] = htonl(tcp_time_stamp); rep.tsopt[2] = htonl(ts); arg.iov[0].iov_len = sizeof(rep); Index: net/ipv4/netfilter/ip_nat_core.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_core.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_core.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_core.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -775,7 +775,7 @@ if (helper) { /* Always defragged for helpers */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); return helper->help(ct, info, ctinfo, hooknum, pskb); } else return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_snmp_basic.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_snmp_basic.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -1259,9 +1259,9 @@ * on post routing (SNAT). */ if (!((dir == IP_CT_DIR_REPLY && hooknum == NF_IP_PRE_ROUTING && - udph->source == __constant_ntohs(SNMP_PORT)) || + udph->source == ntohs(SNMP_PORT)) || (dir == IP_CT_DIR_ORIGINAL && hooknum == NF_IP_POST_ROUTING && - udph->dest == __constant_ntohs(SNMP_TRAP_PORT)))) { + udph->dest == ntohs(SNMP_TRAP_PORT)))) { spin_unlock_bh(&snmp_lock); return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_standalone.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_standalone.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_standalone.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_standalone.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -60,7 +60,7 @@ /* We never see fragments: conntrack defrags on pre-routing and local-out, and ip_nat_out protects post-routing. */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); (*pskb)->nfcache |= NFC_UNKNOWN; @@ -163,7 +163,7 @@ I'm starting to have nightmares about fragments. */ - if ((*pskb)->nh.iph->frag_off & __constant_htons(IP_MF|IP_OFFSET)) { + if ((*pskb)->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { *pskb = ip_ct_gather_frags(*pskb); if (!*pskb) Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.2 diff -u -r1.1.1.1 -r1.1.1.1.12.2 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/10/03 22:41:07 1.1.1.1.12.2 @@ -141,14 +141,14 @@ /* Consider all addresses with the first three bits different of 000 and 111 as unicasts. */ - if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && - (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) + if ((st & htonl(0xE0000000)) != htonl(0x00000000) && + (st & htonl(0xE0000000)) != htonl(0xE0000000)) return IPV6_ADDR_UNICAST; - if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) { + if ((st & htonl(0xFF000000)) == htonl(0xFF000000)) { int type = IPV6_ADDR_MULTICAST; - switch((st & __constant_htonl(0x00FF0000))) { + switch((st & htonl(0x00FF0000))) { case __constant_htonl(0x00010000): type |= IPV6_ADDR_LOOPBACK; break; @@ -164,24 +164,24 @@ return type; } - if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) + if ((st & htonl(0xFFC00000)) == htonl(0xFE800000)) return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST); - if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) + if ((st & htonl(0xFFC00000)) == htonl(0xFEC00000)) return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST); if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { - if (addr->in6_u.u6_addr32[3] == 0) + if (addr->s6_addr32[3] == 0) return IPV6_ADDR_ANY; - if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) + if (addr->s6_addr32[3] == htonl(0x00000001)) return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST); return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST); } - if (addr->s6_addr32[2] == __constant_htonl(0x0000ffff)) + if (addr->s6_addr32[2] == htonl(0x0000ffff)) return IPV6_ADDR_MAPPED; } @@ -752,7 +752,7 @@ memset(&rtmsg, 0, sizeof(rtmsg)); ipv6_addr_set(&rtmsg.rtmsg_dst, - __constant_htonl(0xFF000000), 0, 0, 0); + htonl(0xFF000000), 0, 0, 0); rtmsg.rtmsg_dst_len = 8; rtmsg.rtmsg_metric = IP6_RT_PRIO_ADDRCONF; rtmsg.rtmsg_ifindex = dev->ifindex; @@ -782,7 +782,7 @@ { struct in6_addr addr; - ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0); + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0); addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF); } @@ -1120,7 +1120,7 @@ memcpy(&addr.s6_addr32[3], idev->dev->dev_addr, 4); if (idev->dev->flags&IFF_POINTOPOINT) { - addr.s6_addr32[0] = __constant_htonl(0xfe800000); + addr.s6_addr32[0] = htonl(0xfe800000); scope = IFA_LINK; } else { scope = IPV6_ADDR_COMPATv4; @@ -1187,7 +1187,7 @@ ASSERT_RTNL(); memset(&addr, 0, sizeof(struct in6_addr)); - addr.s6_addr[15] = 1; + addr.s6_addr32[3] = htonl(0x00000001); if ((idev = ipv6_find_idev(dev)) == NULL) { printk(KERN_DEBUG "init loopback: add_dev failed\n"); @@ -1234,9 +1234,7 @@ return; memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; + addr.s6_addr32[0] = __contant_htonl(0xFE800000); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); Index: net/ipv6/datagram.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/datagram.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/datagram.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/datagram.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -147,7 +147,7 @@ } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, - __constant_htonl(0xffff), + htonl(0xffff), *(u32*)(skb->nh.raw + serr->addr_offset)); } } @@ -168,7 +168,7 @@ } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, - __constant_htonl(0xffff), + htonl(0xffff), skb->nh.iph->saddr); if (sk->protinfo.af_inet.cmsg_flags) ip_cmsg_recv(msg, skb); Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/icmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/icmp.c 2002/09/12 09:41:58 1.1.1.1.12.1 @@ -198,7 +198,7 @@ u8 type; if (skb_copy_bits(skb, ptr+offsetof(struct icmp6hdr, icmp6_type), &type, 1) - || !(type & 0x80)) + || !(type & ICMPV6_INFOMSG_MASK)) return 1; } return 0; @@ -216,7 +216,7 @@ int res = 0; /* Informational messages are not limited. */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) return 1; /* Do not limit pmtu discovery, it would break it. */ @@ -519,22 +519,22 @@ skb_checksum(skb, 0, skb->len, 0))) { if (net_ratelimit()) printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - ntohs(saddr->in6_u.u6_addr16[0]), - ntohs(saddr->in6_u.u6_addr16[1]), - ntohs(saddr->in6_u.u6_addr16[2]), - ntohs(saddr->in6_u.u6_addr16[3]), - ntohs(saddr->in6_u.u6_addr16[4]), - ntohs(saddr->in6_u.u6_addr16[5]), - ntohs(saddr->in6_u.u6_addr16[6]), - ntohs(saddr->in6_u.u6_addr16[7]), - ntohs(daddr->in6_u.u6_addr16[0]), - ntohs(daddr->in6_u.u6_addr16[1]), - ntohs(daddr->in6_u.u6_addr16[2]), - ntohs(daddr->in6_u.u6_addr16[3]), - ntohs(daddr->in6_u.u6_addr16[4]), - ntohs(daddr->in6_u.u6_addr16[5]), - ntohs(daddr->in6_u.u6_addr16[6]), - ntohs(daddr->in6_u.u6_addr16[7])); + ntohs(saddr->s6_addr16[0]), + ntohs(saddr->s6_addr16[1]), + ntohs(saddr->s6_addr16[2]), + ntohs(saddr->s6_addr16[3]), + ntohs(saddr->s6_addr16[4]), + ntohs(saddr->s6_addr16[5]), + ntohs(saddr->s6_addr16[6]), + ntohs(saddr->s6_addr16[7]), + ntohs(daddr->s6_addr16[0]), + ntohs(daddr->s6_addr16[1]), + ntohs(daddr->s6_addr16[2]), + ntohs(daddr->s6_addr16[3]), + ntohs(daddr->s6_addr16[4]), + ntohs(daddr->s6_addr16[5]), + ntohs(daddr->s6_addr16[6]), + ntohs(daddr->s6_addr16[7])); goto discard_it; } } @@ -613,7 +613,7 @@ printk(KERN_DEBUG "icmpv6: msg of unkown type\n"); /* informational */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) break; /* Index: net/ipv6/ip6_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ip6_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/ip6_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/ip6_output.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -101,7 +101,7 @@ struct dst_entry *dst = skb->dst; struct net_device *dev = dst->dev; - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr)) { @@ -221,7 +221,7 @@ * Fill in the IPv6 header */ - *(u32*)hdr = __constant_htonl(0x60000000) | fl->fl6_flowlabel; + *(u32*)hdr = htonl(0x60000000) | fl->fl6_flowlabel; hlimit = -1; if (np) hlimit = np->hop_limit; @@ -262,7 +262,7 @@ struct ipv6hdr *hdr; int totlen; - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; totlen = len + sizeof(struct ipv6hdr); Index: net/ipv6/reassembly.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/reassembly.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/reassembly.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/reassembly.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -372,7 +372,7 @@ csum_partial(skb->nh.raw, (u8*)(fhdr+1)-skb->nh.raw, 0)); /* Is this the final fragment? */ - if (!(fhdr->frag_off & __constant_htons(0x0001))) { + if (!(fhdr->frag_off & htons(0x0001))) { /* If we already have some bits beyond end * or have different end, the segment is corrupted. */ @@ -648,7 +648,7 @@ hdr = skb->nh.ipv6h; fhdr = (struct frag_hdr *)skb->h.raw; - if (!(fhdr->frag_off & __constant_htons(0xFFF9))) { + if (!(fhdr->frag_off & htons(0xFFF9))) { /* It is not a fragmented frame */ skb->h.raw += sizeof(struct frag_hdr); IP6_INC_STATS_BH(Ip6ReasmOKs); Index: net/ipv6/sit.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sit.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/sit.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/sit.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -396,7 +396,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->pkt_type = PACKET_HOST; tunnel->stat.rx_packets++; tunnel->stat.rx_bytes += skb->len; @@ -470,7 +470,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IPV6)) + if (skb->protocol != htons(ETH_P_IPV6)) goto tx_error; if (!dst) @@ -588,7 +588,7 @@ iph->version = 4; iph->ihl = sizeof(struct iphdr)>>2; if (mtu > IPV6_MIN_MTU) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; @@ -659,10 +659,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPV6 || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip6_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/tcp_ipv6.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/tcp_ipv6.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -402,7 +402,7 @@ static __u32 tcp_v6_init_sequence(struct sock *sk, struct sk_buff *skb) { - if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + if (skb->protocol == htons(ETH_P_IPV6)) { return secure_tcpv6_sequence_number(skb->nh.ipv6h->daddr.s6_addr32, skb->nh.ipv6h->saddr.s6_addr32, skb->h.th->dest, @@ -617,9 +617,9 @@ sk->backlog_rcv = tcp_v6_do_rcv; goto failure; } else { - ipv6_addr_set(&np->saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->saddr, 0, 0, htonl(0x0000FFFF), sk->saddr); - ipv6_addr_set(&np->rcv_saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->rcv_saddr, 0, 0, htonl(0x0000FFFF), sk->rcv_saddr); } @@ -1031,10 +1031,10 @@ if (ts) { u32 *ptr = (u32*)(t1 + 1); - *ptr++ = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + *ptr++ = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); *ptr++ = htonl(tcp_time_stamp); *ptr = htonl(ts); } @@ -1145,7 +1145,7 @@ struct open_request *req = NULL; __u32 isn = TCP_SKB_CB(skb)->when; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_conn_request(sk, skb); /* FIXME: do the same check for anycast */ @@ -1224,7 +1224,7 @@ struct sock *newsk; struct ipv6_txoptions *opt; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { /* * v6 mapped */ @@ -1236,10 +1236,10 @@ np = &newsk->net_pinfo.af_inet6; - ipv6_addr_set(&np->daddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->daddr, 0, 0, htonl(0x0000FFFF), newsk->daddr); - ipv6_addr_set(&np->saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->saddr, 0, 0, htonl(0x0000FFFF), newsk->saddr); ipv6_addr_copy(&np->rcv_saddr, &np->saddr); @@ -1425,7 +1425,7 @@ tcp_v6_hnd_req and tcp_v6_send_reset(). --ANK */ - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_do_rcv(sk, skb); #ifdef CONFIG_FILTER Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/udp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/udp.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -267,18 +267,18 @@ return err; ipv6_addr_set(&np->daddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->daddr); if(ipv6_addr_any(&np->saddr)) { ipv6_addr_set(&np->saddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->saddr); } if(ipv6_addr_any(&np->rcv_saddr)) { ipv6_addr_set(&np->rcv_saddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->rcv_saddr); } return 0; @@ -420,9 +420,9 @@ sin6->sin6_flowinfo = 0; sin6->sin6_scope_id = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { ipv6_addr_set(&sin6->sin6_addr, 0, 0, - __constant_htonl(0xffff), skb->nh.iph->saddr); + htonl(0xffff), skb->nh.iph->saddr); if (sk->protinfo.af_inet.cmsg_flags) ip_cmsg_recv(msg, skb); } else { Index: net/ipv6/netfilter/ip6_queue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6_queue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.2 diff -u -r1.1.1.1 -r1.1.1.1.12.2 --- net/ipv6/netfilter/ip6_queue.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6_queue.c 2002/09/19 03:57:51 1.1.1.1.12.2 @@ -306,14 +306,8 @@ */ if (e->info->hook == NF_IP_LOCAL_OUT) { struct ipv6hdr *iph = e->skb->nh.ipv6h; - if (!( iph->daddr.in6_u.u6_addr32[0] == e->rt_info.daddr.in6_u.u6_addr32[0] - && iph->daddr.in6_u.u6_addr32[1] == e->rt_info.daddr.in6_u.u6_addr32[1] - && iph->daddr.in6_u.u6_addr32[2] == e->rt_info.daddr.in6_u.u6_addr32[2] - && iph->daddr.in6_u.u6_addr32[3] == e->rt_info.daddr.in6_u.u6_addr32[3] - && iph->saddr.in6_u.u6_addr32[0] == e->rt_info.saddr.in6_u.u6_addr32[0] - && iph->saddr.in6_u.u6_addr32[1] == e->rt_info.saddr.in6_u.u6_addr32[1] - && iph->saddr.in6_u.u6_addr32[2] == e->rt_info.saddr.in6_u.u6_addr32[2] - && iph->saddr.in6_u.u6_addr32[3] == e->rt_info.saddr.in6_u.u6_addr32[3])) + 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 0; Index: net/ipv6/netfilter/ip6t_LOG.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6t_LOG.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/netfilter/ip6t_LOG.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6t_LOG.c 2002/10/03 22:07:26 1.1.1.1.12.1 @@ -112,7 +112,7 @@ printk("FRAG:%u ", ntohs(fhdr->frag_off) & 0xFFF8); /* Max length: 11 "INCOMPLETE " */ - if (fhdr->frag_off & __constant_htons(0x0001)) + if (fhdr->frag_off & htons(0x0001)) printk("INCOMPLETE "); printk("ID:%08x ", fhdr->identification); Index: net/ipv4/arp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/arp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/arp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/arp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -513,7 +513,7 @@ skb->nh.raw = skb->data; arp = (struct arphdr *) skb_put(skb,sizeof(struct arphdr) + 2*(dev->addr_len+4)); skb->dev = dev; - skb->protocol = __constant_htons (ETH_P_ARP); + skb->protocol = htons (ETH_P_ARP); if (src_hw == NULL) src_hw = dev->dev_addr; if (dest_hw == NULL) @@ -539,33 +539,33 @@ switch (dev->type) { default: arp->ar_hrd = htons(dev->type); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_pro = htons(ETH_P_IP); break; #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - arp->ar_hrd = __constant_htons(ARPHRD_AX25); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_AX25); + arp->ar_pro = htons(AX25_P_IP); break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - arp->ar_hrd = __constant_htons(ARPHRD_NETROM); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_NETROM); + arp->ar_pro = htons(AX25_P_IP); break; #endif #endif #ifdef CONFIG_FDDI case ARPHRD_FDDI: - arp->ar_hrd = __constant_htons(ARPHRD_ETHER); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_ETHER); + arp->ar_pro = htons(ETH_P_IP); break; #endif #ifdef CONFIG_TR case ARPHRD_IEEE802_TR: - arp->ar_hrd = __constant_htons(ARPHRD_IEEE802); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_IEEE802); + arp->ar_pro = htons(ETH_P_IP); break; #endif } @@ -629,7 +629,7 @@ switch (dev_type) { default: - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; if (htons(dev_type) != arp->ar_hrd) goto out; @@ -640,10 +640,10 @@ * ETHERNET devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -653,10 +653,10 @@ * Token ring devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -667,10 +667,10 @@ * of 1 (Ethernet). However, to be more robust, we'll accept hardware * types of either 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -681,25 +681,25 @@ * 802 devices) should accept ARP hardware types of 6 (IEEE 802) * and 1 (Ethernet). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_AX25)) + if (arp->ar_hrd != htons(ARPHRD_AX25)) goto out; break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_NETROM)) + if (arp->ar_hrd != htons(ARPHRD_NETROM)) goto out; break; #endif @@ -708,8 +708,8 @@ /* Understand only these message types */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) && - arp->ar_op != __constant_htons(ARPOP_REQUEST)) + if (arp->ar_op != htons(ARPOP_REPLY) && + arp->ar_op != htons(ARPOP_REQUEST)) goto out; /* @@ -754,13 +754,13 @@ /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && inet_addr_type(tip) == RTN_LOCAL) arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); goto out; } - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && ip_route_input(skb, tip, sip, 0, dev) == 0) { rt = (struct rtable*)skb->dst; @@ -810,7 +810,7 @@ devices (strip is candidate) */ if (n == NULL && - arp->ar_op == __constant_htons(ARPOP_REPLY) && + arp->ar_op == htons(ARPOP_REPLY) && inet_addr_type(sip) == RTN_UNICAST) n = __neigh_lookup(&arp_tbl, &sip, dev, -1); #endif @@ -830,7 +830,7 @@ /* Broadcast replies and request packets do not assert neighbour reachability. */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) || + if (arp->ar_op != htons(ARPOP_REPLY) || skb->pkt_type != PACKET_HOST) state = NUD_STALE; neigh_update(n, sha, state, override, 1); @@ -1050,7 +1050,7 @@ (r.arp_flags & (ATF_NETMASK|ATF_DONTPUB))) return -EINVAL; if (!(r.arp_flags & ATF_NETMASK)) - ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=__constant_htonl(0xFFFFFFFFUL); + ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=htonl(0xFFFFFFFFUL); rtnl_lock(); if (r.arp_dev[0]) { Index: net/ipv4/igmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/igmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/igmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/igmp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -229,7 +229,7 @@ iph->version = 4; iph->ihl = (sizeof(struct iphdr)+4)>>2; iph->tos = 0; - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); iph->ttl = 1; iph->daddr = dst; iph->saddr = rt->rt_src; Index: net/ipv4/ip_gre.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_gre.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_gre.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_gre.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -412,7 +412,7 @@ struct sk_buff *skb2; struct rtable *rt; - if (p[1] != __constant_htons(ETH_P_IP)) + if (p[1] != htons(ETH_P_IP)) return; flags = p[0]; @@ -535,10 +535,10 @@ static inline void ipgre_ecn_decapsulate(struct iphdr *iph, struct sk_buff *skb) { if (INET_ECN_is_ce(iph->tos)) { - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (INET_ECN_is_not_ce(skb->nh.iph->tos)) IP_ECN_set_ce(skb->nh.iph); - } else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + } else if (skb->protocol == htons(ETH_P_IPV6)) { if (INET_ECN_is_not_ce(ip6_get_dsfield(skb->nh.ipv6h))) IP6_ECN_set_ce(skb->nh.ipv6h); } @@ -549,9 +549,9 @@ ipgre_ecn_encapsulate(u8 tos, struct iphdr *old_iph, struct sk_buff *skb) { u8 inner = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) inner = old_iph->tos; - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) inner = ip6_get_dsfield((struct ipv6hdr*)old_iph); return INET_ECN_encapsulate(tos, inner); } @@ -708,13 +708,13 @@ goto tx_error; } - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { rt = (struct rtable*)skb->dst; if ((dst = rt->rt_gateway) == 0) goto tx_error_icmp; } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct in6_addr *addr6; int addr_type; struct neighbour *neigh = skb->dst->neighbour; @@ -742,7 +742,7 @@ tos = tiph->tos; if (tos&1) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) tos = old_iph->tos; tos &= ~1; } @@ -765,13 +765,13 @@ else mtu = skb->dst ? skb->dst->pmtu : dev->mtu; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (skb->dst && mtu < skb->dst->pmtu && mtu >= 68) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); @@ -779,7 +779,7 @@ } } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct rt6_info *rt6 = (struct rt6_info*)skb->dst; if (rt6 && mtu < rt6->u.dst.pmtu && mtu >= IPV6_MIN_MTU) { @@ -845,10 +845,10 @@ iph->saddr = rt->rt_src; if ((iph->ttl = tiph->ttl) == 0) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) iph->ttl = old_iph->ttl; #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) iph->ttl = ((struct ipv6hdr*)old_iph)->hop_limit; #endif else @@ -936,11 +936,11 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_GRE || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF)) || + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF)) || ((p.i_flags|p.o_flags)&(GRE_VERSION|GRE_ROUTING))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); if (!(p.i_flags&GRE_KEY)) p.i_key = 0; Index: net/ipv4/ip_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_output.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -186,7 +186,7 @@ struct net_device *dev = skb->dst->dev; skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev, ip_finish_output2); @@ -208,7 +208,7 @@ #endif skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); /* * Multicasts are looped back for other local users @@ -382,7 +382,7 @@ *((__u16 *)iph) = htons((4 << 12) | (5 << 8) | (sk->protinfo.af_inet.tos & 0xff)); iph->tot_len = htons(skb->len); if (ip_dont_fragment(sk, &rt->u.dst)) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; iph->ttl = sk->protinfo.af_inet.ttl; Index: net/ipv4/ipconfig.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipconfig.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipconfig.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipconfig.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -356,11 +356,11 @@ if (ic_netmask == INADDR_NONE) { if (IN_CLASSA(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSA_NET); + ic_netmask = htonl(IN_CLASSA_NET); else if (IN_CLASSB(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSB_NET); + ic_netmask = htonl(IN_CLASSB_NET); else if (IN_CLASSC(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSC_NET); + ic_netmask = htonl(IN_CLASSC_NET); else { printk(KERN_ERR "IP-Config: Unable to guess netmask for address %u.%u.%u.%u\n", NIPQUAD(ic_myaddr)); @@ -426,11 +426,11 @@ goto drop; /* If it's not a RARP reply, delete it. */ - if (rarp->ar_op != __constant_htons(ARPOP_RREPLY)) + if (rarp->ar_op != htons(ARPOP_RREPLY)) goto drop; /* If it's not Ethernet, delete it. */ - if (rarp->ar_pro != __constant_htons(ETH_P_IP)) + if (rarp->ar_pro != htons(ETH_P_IP)) goto drop; /* Extract variable-width fields */ @@ -661,15 +661,15 @@ h->version = 4; h->ihl = 5; h->tot_len = htons(sizeof(struct bootp_pkt)); - h->frag_off = __constant_htons(IP_DF); + h->frag_off = htons(IP_DF); h->ttl = 64; h->protocol = IPPROTO_UDP; h->daddr = INADDR_BROADCAST; h->check = ip_fast_csum((unsigned char *) h, h->ihl); /* Construct UDP header */ - b->udph.source = __constant_htons(68); - b->udph.dest = __constant_htons(67); + b->udph.source = htons(68); + b->udph.dest = htons(67); b->udph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr)); /* UDP checksum not calculated -- explicitly allowed in BOOTP RFC */ @@ -700,7 +700,7 @@ /* Chain packet down the line... */ skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); if ((dev->hard_header && dev->hard_header(skb, dev, ntohs(skb->protocol), dev->broadcast, dev->dev_addr, skb->len) < 0) || dev_queue_xmit(skb) < 0) @@ -800,13 +800,13 @@ ip_fast_csum((char *) h, h->ihl) != 0 || skb->len < ntohs(h->tot_len) || h->protocol != IPPROTO_UDP || - b->udph.source != __constant_htons(67) || - b->udph.dest != __constant_htons(68) || + b->udph.source != htons(67) || + b->udph.dest != htons(68) || ntohs(h->tot_len) < ntohs(b->udph.len) + sizeof(struct iphdr)) goto drop; /* Fragments are not supported */ - if (h->frag_off & __constant_htons(IP_OFFSET | IP_MF)) { + if (h->frag_off & htons(IP_OFFSET | IP_MF)) { printk(KERN_ERR "DHCP/BOOTP: Ignoring fragmented reply.\n"); goto drop; } Index: net/ipv4/ipip.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipip.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipip.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipip.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -483,7 +483,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->pkt_type = PACKET_HOST; read_lock(&ipip_lock); @@ -544,7 +544,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto tx_error; if (tos&1) @@ -585,9 +585,9 @@ if (skb->dst && mtu < skb->dst->pmtu) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); goto tx_error; @@ -703,10 +703,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPIP || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv4/ipmr.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipmr.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipmr.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipmr.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1434,7 +1434,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); @@ -1501,7 +1501,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); Index: net/ipv4/route.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/route.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/route.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/route.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1246,7 +1246,7 @@ return -EINVAL; if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) || - skb->protocol != __constant_htons(ETH_P_IP)) + skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) { @@ -1457,7 +1457,7 @@ inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) flags |= RTCF_DOREDIRECT; - if (skb->protocol != __constant_htons(ETH_P_IP)) { + if (skb->protocol != htons(ETH_P_IP)) { /* Not IP (i.e. ARP). Do not create route, if it is * invalid for proxy arp. DNAT routes are always valid. */ @@ -1522,7 +1522,7 @@ out: return err; brd_input: - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) @@ -2156,7 +2156,7 @@ err = -ENODEV; if (!dev) goto out; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->dev = dev; local_bh_disable(); err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev); Index: net/ipv4/tcp_diag.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_diag.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_diag.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_diag.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -346,7 +346,7 @@ break; if (sk->family == AF_INET6 && cond->family == AF_INET) { if (addr[0] == 0 && addr[1] == 0 && - addr[2] == __constant_htonl(0xffff) && + addr[2] == htonl(0xffff) && bitstring_match(addr+3, cond->addr, cond->prefix_len)) break; } Index: net/ipv4/tcp_input.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_input.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_input.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_input.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -2083,8 +2083,8 @@ } else if (tp->tstamp_ok && th->doff == (sizeof(struct tcphdr)>>2)+(TCPOLEN_TSTAMP_ALIGNED>>2)) { __u32 *ptr = (__u32 *)(th + 1); - if (*ptr == __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { + if (*ptr == ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { tp->saw_tstamp = 1; ++ptr; tp->rcv_tsval = ntohl(*ptr); @@ -3252,8 +3252,8 @@ __u32 *ptr = (__u32 *)(th + 1); /* No? Slow path! */ - if (*ptr != __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) + if (*ptr != ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) goto slow_path; tp->saw_tstamp = 1; Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_ipv4.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1210,10 +1210,10 @@ arg.iov[0].iov_len = sizeof(rep.th); arg.n_iov = 1; if (ts) { - rep.tsopt[0] = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + rep.tsopt[0] = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); rep.tsopt[1] = htonl(tcp_time_stamp); rep.tsopt[2] = htonl(ts); arg.iov[0].iov_len = sizeof(rep); Index: net/ipv4/netfilter/ip_nat_core.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_core.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_core.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_core.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -775,7 +775,7 @@ if (helper) { /* Always defragged for helpers */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); return helper->help(ct, info, ctinfo, hooknum, pskb); } else return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_snmp_basic.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_snmp_basic.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -1259,9 +1259,9 @@ * on post routing (SNAT). */ if (!((dir == IP_CT_DIR_REPLY && hooknum == NF_IP_PRE_ROUTING && - udph->source == __constant_ntohs(SNMP_PORT)) || + udph->source == ntohs(SNMP_PORT)) || (dir == IP_CT_DIR_ORIGINAL && hooknum == NF_IP_POST_ROUTING && - udph->dest == __constant_ntohs(SNMP_TRAP_PORT)))) { + udph->dest == ntohs(SNMP_TRAP_PORT)))) { spin_unlock_bh(&snmp_lock); return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_standalone.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_standalone.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_standalone.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_standalone.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -60,7 +60,7 @@ /* We never see fragments: conntrack defrags on pre-routing and local-out, and ip_nat_out protects post-routing. */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); (*pskb)->nfcache |= NFC_UNKNOWN; @@ -163,7 +163,7 @@ I'm starting to have nightmares about fragments. */ - if ((*pskb)->nh.iph->frag_off & __constant_htons(IP_MF|IP_OFFSET)) { + if ((*pskb)->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { *pskb = ip_ct_gather_frags(*pskb); if (!*pskb) Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.3 diff -u -r1.1.1.1 -r1.1.1.1.12.3 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/10/03 22:48:03 1.1.1.1.12.3 @@ -141,14 +141,14 @@ /* Consider all addresses with the first three bits different of 000 and 111 as unicasts. */ - if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && - (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) + if ((st & htonl(0xE0000000)) != htonl(0x00000000) && + (st & htonl(0xE0000000)) != htonl(0xE0000000)) return IPV6_ADDR_UNICAST; - if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) { + if ((st & htonl(0xFF000000)) == htonl(0xFF000000)) { int type = IPV6_ADDR_MULTICAST; - switch((st & __constant_htonl(0x00FF0000))) { + switch((st & htonl(0x00FF0000))) { case __constant_htonl(0x00010000): type |= IPV6_ADDR_LOOPBACK; break; @@ -164,24 +164,24 @@ return type; } - if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) + if ((st & htonl(0xFFC00000)) == htonl(0xFE800000)) return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST); - if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) + if ((st & htonl(0xFFC00000)) == htonl(0xFEC00000)) return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST); if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { - if (addr->in6_u.u6_addr32[3] == 0) + if (addr->s6_addr32[3] == 0) return IPV6_ADDR_ANY; - if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) + if (addr->s6_addr32[3] == htonl(0x00000001)) return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST); return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST); } - if (addr->s6_addr32[2] == __constant_htonl(0x0000ffff)) + if (addr->s6_addr32[2] == htonl(0x0000ffff)) return IPV6_ADDR_MAPPED; } @@ -752,7 +752,7 @@ memset(&rtmsg, 0, sizeof(rtmsg)); ipv6_addr_set(&rtmsg.rtmsg_dst, - __constant_htonl(0xFF000000), 0, 0, 0); + htonl(0xFF000000), 0, 0, 0); rtmsg.rtmsg_dst_len = 8; rtmsg.rtmsg_metric = IP6_RT_PRIO_ADDRCONF; rtmsg.rtmsg_ifindex = dev->ifindex; @@ -782,7 +782,7 @@ { struct in6_addr addr; - ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0); + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0); addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF); } @@ -1120,7 +1120,7 @@ memcpy(&addr.s6_addr32[3], idev->dev->dev_addr, 4); if (idev->dev->flags&IFF_POINTOPOINT) { - addr.s6_addr32[0] = __constant_htonl(0xfe800000); + addr.s6_addr32[0] = htonl(0xfe800000); scope = IFA_LINK; } else { scope = IPV6_ADDR_COMPATv4; @@ -1187,7 +1187,7 @@ ASSERT_RTNL(); memset(&addr, 0, sizeof(struct in6_addr)); - addr.s6_addr[15] = 1; + addr.s6_addr32[3] = htonl(0x00000001); if ((idev = ipv6_find_idev(dev)) == NULL) { printk(KERN_DEBUG "init loopback: add_dev failed\n"); @@ -1234,9 +1234,7 @@ return; memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; + addr.s6_addr32[0] = htonl(0xFE800000); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); Index: net/ipv6/datagram.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/datagram.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/datagram.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/datagram.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -147,7 +147,7 @@ } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, - __constant_htonl(0xffff), + htonl(0xffff), *(u32*)(skb->nh.raw + serr->addr_offset)); } } @@ -168,7 +168,7 @@ } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, - __constant_htonl(0xffff), + htonl(0xffff), skb->nh.iph->saddr); if (sk->protinfo.af_inet.cmsg_flags) ip_cmsg_recv(msg, skb); Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/icmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/icmp.c 2002/09/12 09:41:58 1.1.1.1.12.1 @@ -198,7 +198,7 @@ u8 type; if (skb_copy_bits(skb, ptr+offsetof(struct icmp6hdr, icmp6_type), &type, 1) - || !(type & 0x80)) + || !(type & ICMPV6_INFOMSG_MASK)) return 1; } return 0; @@ -216,7 +216,7 @@ int res = 0; /* Informational messages are not limited. */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) return 1; /* Do not limit pmtu discovery, it would break it. */ @@ -519,22 +519,22 @@ skb_checksum(skb, 0, skb->len, 0))) { if (net_ratelimit()) printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - ntohs(saddr->in6_u.u6_addr16[0]), - ntohs(saddr->in6_u.u6_addr16[1]), - ntohs(saddr->in6_u.u6_addr16[2]), - ntohs(saddr->in6_u.u6_addr16[3]), - ntohs(saddr->in6_u.u6_addr16[4]), - ntohs(saddr->in6_u.u6_addr16[5]), - ntohs(saddr->in6_u.u6_addr16[6]), - ntohs(saddr->in6_u.u6_addr16[7]), - ntohs(daddr->in6_u.u6_addr16[0]), - ntohs(daddr->in6_u.u6_addr16[1]), - ntohs(daddr->in6_u.u6_addr16[2]), - ntohs(daddr->in6_u.u6_addr16[3]), - ntohs(daddr->in6_u.u6_addr16[4]), - ntohs(daddr->in6_u.u6_addr16[5]), - ntohs(daddr->in6_u.u6_addr16[6]), - ntohs(daddr->in6_u.u6_addr16[7])); + ntohs(saddr->s6_addr16[0]), + ntohs(saddr->s6_addr16[1]), + ntohs(saddr->s6_addr16[2]), + ntohs(saddr->s6_addr16[3]), + ntohs(saddr->s6_addr16[4]), + ntohs(saddr->s6_addr16[5]), + ntohs(saddr->s6_addr16[6]), + ntohs(saddr->s6_addr16[7]), + ntohs(daddr->s6_addr16[0]), + ntohs(daddr->s6_addr16[1]), + ntohs(daddr->s6_addr16[2]), + ntohs(daddr->s6_addr16[3]), + ntohs(daddr->s6_addr16[4]), + ntohs(daddr->s6_addr16[5]), + ntohs(daddr->s6_addr16[6]), + ntohs(daddr->s6_addr16[7])); goto discard_it; } } @@ -613,7 +613,7 @@ printk(KERN_DEBUG "icmpv6: msg of unkown type\n"); /* informational */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) break; /* Index: net/ipv6/ip6_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ip6_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/ip6_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/ip6_output.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -101,7 +101,7 @@ struct dst_entry *dst = skb->dst; struct net_device *dev = dst->dev; - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr)) { @@ -221,7 +221,7 @@ * Fill in the IPv6 header */ - *(u32*)hdr = __constant_htonl(0x60000000) | fl->fl6_flowlabel; + *(u32*)hdr = htonl(0x60000000) | fl->fl6_flowlabel; hlimit = -1; if (np) hlimit = np->hop_limit; @@ -262,7 +262,7 @@ struct ipv6hdr *hdr; int totlen; - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; totlen = len + sizeof(struct ipv6hdr); Index: net/ipv6/reassembly.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/reassembly.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/reassembly.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/reassembly.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -372,7 +372,7 @@ csum_partial(skb->nh.raw, (u8*)(fhdr+1)-skb->nh.raw, 0)); /* Is this the final fragment? */ - if (!(fhdr->frag_off & __constant_htons(0x0001))) { + if (!(fhdr->frag_off & htons(0x0001))) { /* If we already have some bits beyond end * or have different end, the segment is corrupted. */ @@ -648,7 +648,7 @@ hdr = skb->nh.ipv6h; fhdr = (struct frag_hdr *)skb->h.raw; - if (!(fhdr->frag_off & __constant_htons(0xFFF9))) { + if (!(fhdr->frag_off & htons(0xFFF9))) { /* It is not a fragmented frame */ skb->h.raw += sizeof(struct frag_hdr); IP6_INC_STATS_BH(Ip6ReasmOKs); Index: net/ipv6/sit.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sit.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/sit.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/sit.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -396,7 +396,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->pkt_type = PACKET_HOST; tunnel->stat.rx_packets++; tunnel->stat.rx_bytes += skb->len; @@ -470,7 +470,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IPV6)) + if (skb->protocol != htons(ETH_P_IPV6)) goto tx_error; if (!dst) @@ -588,7 +588,7 @@ iph->version = 4; iph->ihl = sizeof(struct iphdr)>>2; if (mtu > IPV6_MIN_MTU) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; @@ -659,10 +659,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPV6 || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip6_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/tcp_ipv6.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/tcp_ipv6.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -402,7 +402,7 @@ static __u32 tcp_v6_init_sequence(struct sock *sk, struct sk_buff *skb) { - if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + if (skb->protocol == htons(ETH_P_IPV6)) { return secure_tcpv6_sequence_number(skb->nh.ipv6h->daddr.s6_addr32, skb->nh.ipv6h->saddr.s6_addr32, skb->h.th->dest, @@ -617,9 +617,9 @@ sk->backlog_rcv = tcp_v6_do_rcv; goto failure; } else { - ipv6_addr_set(&np->saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->saddr, 0, 0, htonl(0x0000FFFF), sk->saddr); - ipv6_addr_set(&np->rcv_saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->rcv_saddr, 0, 0, htonl(0x0000FFFF), sk->rcv_saddr); } @@ -1031,10 +1031,10 @@ if (ts) { u32 *ptr = (u32*)(t1 + 1); - *ptr++ = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + *ptr++ = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); *ptr++ = htonl(tcp_time_stamp); *ptr = htonl(ts); } @@ -1145,7 +1145,7 @@ struct open_request *req = NULL; __u32 isn = TCP_SKB_CB(skb)->when; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_conn_request(sk, skb); /* FIXME: do the same check for anycast */ @@ -1224,7 +1224,7 @@ struct sock *newsk; struct ipv6_txoptions *opt; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { /* * v6 mapped */ @@ -1236,10 +1236,10 @@ np = &newsk->net_pinfo.af_inet6; - ipv6_addr_set(&np->daddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->daddr, 0, 0, htonl(0x0000FFFF), newsk->daddr); - ipv6_addr_set(&np->saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->saddr, 0, 0, htonl(0x0000FFFF), newsk->saddr); ipv6_addr_copy(&np->rcv_saddr, &np->saddr); @@ -1425,7 +1425,7 @@ tcp_v6_hnd_req and tcp_v6_send_reset(). --ANK */ - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_do_rcv(sk, skb); #ifdef CONFIG_FILTER Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/udp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/udp.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -267,18 +267,18 @@ return err; ipv6_addr_set(&np->daddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->daddr); if(ipv6_addr_any(&np->saddr)) { ipv6_addr_set(&np->saddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->saddr); } if(ipv6_addr_any(&np->rcv_saddr)) { ipv6_addr_set(&np->rcv_saddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->rcv_saddr); } return 0; @@ -420,9 +420,9 @@ sin6->sin6_flowinfo = 0; sin6->sin6_scope_id = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { ipv6_addr_set(&sin6->sin6_addr, 0, 0, - __constant_htonl(0xffff), skb->nh.iph->saddr); + htonl(0xffff), skb->nh.iph->saddr); if (sk->protinfo.af_inet.cmsg_flags) ip_cmsg_recv(msg, skb); } else { Index: net/ipv6/netfilter/ip6_queue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6_queue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.2 diff -u -r1.1.1.1 -r1.1.1.1.12.2 --- net/ipv6/netfilter/ip6_queue.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6_queue.c 2002/09/19 03:57:51 1.1.1.1.12.2 @@ -306,14 +306,8 @@ */ if (e->info->hook == NF_IP_LOCAL_OUT) { struct ipv6hdr *iph = e->skb->nh.ipv6h; - if (!( iph->daddr.in6_u.u6_addr32[0] == e->rt_info.daddr.in6_u.u6_addr32[0] - && iph->daddr.in6_u.u6_addr32[1] == e->rt_info.daddr.in6_u.u6_addr32[1] - && iph->daddr.in6_u.u6_addr32[2] == e->rt_info.daddr.in6_u.u6_addr32[2] - && iph->daddr.in6_u.u6_addr32[3] == e->rt_info.daddr.in6_u.u6_addr32[3] - && iph->saddr.in6_u.u6_addr32[0] == e->rt_info.saddr.in6_u.u6_addr32[0] - && iph->saddr.in6_u.u6_addr32[1] == e->rt_info.saddr.in6_u.u6_addr32[1] - && iph->saddr.in6_u.u6_addr32[2] == e->rt_info.saddr.in6_u.u6_addr32[2] - && iph->saddr.in6_u.u6_addr32[3] == e->rt_info.saddr.in6_u.u6_addr32[3])) + 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 0; Index: net/ipv6/netfilter/ip6t_LOG.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6t_LOG.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/netfilter/ip6t_LOG.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6t_LOG.c 2002/10/03 22:07:26 1.1.1.1.12.1 @@ -112,7 +112,7 @@ printk("FRAG:%u ", ntohs(fhdr->frag_off) & 0xFFF8); /* Max length: 11 "INCOMPLETE " */ - if (fhdr->frag_off & __constant_htons(0x0001)) + if (fhdr->frag_off & htons(0x0001)) printk("INCOMPLETE "); printk("ID:%08x ", fhdr->identification); --yoshfuji From yoshfuji@linux-ipv6.org Thu Oct 3 16:32:08 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 16:32:16 -0700 (PDT) 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 g93NW4tG028181 for ; Thu, 3 Oct 2002 16:32:05 -0700 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 g93NFP1o030342; Fri, 4 Oct 2002 08:15:25 +0900 Date: Fri, 04 Oct 2002 08:15:25 +0900 (JST) Message-Id: <20021004.081525.51826759.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021004.075416.20775355.yoshfuji@linux-ipv6.org> References: <20021004.073642.125593159.yoshfuji@linux-ipv6.org> <20021004.073925.101556969.yoshfuji@linux-ipv6.org> <20021004.075416.20775355.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-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: 514 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 <20021004.075416.20775355.yoshfuji@linux-ipv6.org> (at Fri, 04 Oct 2002 07:54:16 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > In article <20021004.073925.101556969.yoshfuji@linux-ipv6.org> (at Fri, 04 Oct 2002 07:39:25 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > > > In article <20021004.073642.125593159.yoshfuji@linux-ipv6.org> (at Fri, 04 Oct 2002 07:36:42 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > > > > > I saw many __constant_{hton,ntoh}{s,l}()s, so fixed. > > > > > > 1. use s6_addrXX instead of in6_u.s6_addrXX. > > > 2. avoid using magic number. > > > 3. use 32bit constants. > > > --> 4. avoid __constant_{hton,ntoh}{l,s}() in runtime code. > > > > oops, sorry, not fixed in my fix... :-p > > I forgot to commit __constant_XXX() under net/ipv6 in my tree... > anyway, resend with the fix for ipv6. so sorry... it must be a bad day for me today and i should not do anything today... removed duplicate chunks. confirmed to be applied with linux-2.4.19. Index: net/ipv4/arp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/arp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/arp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/arp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -513,7 +513,7 @@ skb->nh.raw = skb->data; arp = (struct arphdr *) skb_put(skb,sizeof(struct arphdr) + 2*(dev->addr_len+4)); skb->dev = dev; - skb->protocol = __constant_htons (ETH_P_ARP); + skb->protocol = htons (ETH_P_ARP); if (src_hw == NULL) src_hw = dev->dev_addr; if (dest_hw == NULL) @@ -539,33 +539,33 @@ switch (dev->type) { default: arp->ar_hrd = htons(dev->type); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_pro = htons(ETH_P_IP); break; #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - arp->ar_hrd = __constant_htons(ARPHRD_AX25); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_AX25); + arp->ar_pro = htons(AX25_P_IP); break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - arp->ar_hrd = __constant_htons(ARPHRD_NETROM); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_NETROM); + arp->ar_pro = htons(AX25_P_IP); break; #endif #endif #ifdef CONFIG_FDDI case ARPHRD_FDDI: - arp->ar_hrd = __constant_htons(ARPHRD_ETHER); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_ETHER); + arp->ar_pro = htons(ETH_P_IP); break; #endif #ifdef CONFIG_TR case ARPHRD_IEEE802_TR: - arp->ar_hrd = __constant_htons(ARPHRD_IEEE802); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_IEEE802); + arp->ar_pro = htons(ETH_P_IP); break; #endif } @@ -629,7 +629,7 @@ switch (dev_type) { default: - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; if (htons(dev_type) != arp->ar_hrd) goto out; @@ -640,10 +640,10 @@ * ETHERNET devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -653,10 +653,10 @@ * Token ring devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -667,10 +667,10 @@ * of 1 (Ethernet). However, to be more robust, we'll accept hardware * types of either 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -681,25 +681,25 @@ * 802 devices) should accept ARP hardware types of 6 (IEEE 802) * and 1 (Ethernet). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_AX25)) + if (arp->ar_hrd != htons(ARPHRD_AX25)) goto out; break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_NETROM)) + if (arp->ar_hrd != htons(ARPHRD_NETROM)) goto out; break; #endif @@ -708,8 +708,8 @@ /* Understand only these message types */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) && - arp->ar_op != __constant_htons(ARPOP_REQUEST)) + if (arp->ar_op != htons(ARPOP_REPLY) && + arp->ar_op != htons(ARPOP_REQUEST)) goto out; /* @@ -754,13 +754,13 @@ /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && inet_addr_type(tip) == RTN_LOCAL) arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); goto out; } - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && ip_route_input(skb, tip, sip, 0, dev) == 0) { rt = (struct rtable*)skb->dst; @@ -810,7 +810,7 @@ devices (strip is candidate) */ if (n == NULL && - arp->ar_op == __constant_htons(ARPOP_REPLY) && + arp->ar_op == htons(ARPOP_REPLY) && inet_addr_type(sip) == RTN_UNICAST) n = __neigh_lookup(&arp_tbl, &sip, dev, -1); #endif @@ -830,7 +830,7 @@ /* Broadcast replies and request packets do not assert neighbour reachability. */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) || + if (arp->ar_op != htons(ARPOP_REPLY) || skb->pkt_type != PACKET_HOST) state = NUD_STALE; neigh_update(n, sha, state, override, 1); @@ -1050,7 +1050,7 @@ (r.arp_flags & (ATF_NETMASK|ATF_DONTPUB))) return -EINVAL; if (!(r.arp_flags & ATF_NETMASK)) - ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=__constant_htonl(0xFFFFFFFFUL); + ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=htonl(0xFFFFFFFFUL); rtnl_lock(); if (r.arp_dev[0]) { Index: net/ipv4/igmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/igmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/igmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/igmp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -229,7 +229,7 @@ iph->version = 4; iph->ihl = (sizeof(struct iphdr)+4)>>2; iph->tos = 0; - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); iph->ttl = 1; iph->daddr = dst; iph->saddr = rt->rt_src; Index: net/ipv4/ip_gre.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_gre.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_gre.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_gre.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -412,7 +412,7 @@ struct sk_buff *skb2; struct rtable *rt; - if (p[1] != __constant_htons(ETH_P_IP)) + if (p[1] != htons(ETH_P_IP)) return; flags = p[0]; @@ -535,10 +535,10 @@ static inline void ipgre_ecn_decapsulate(struct iphdr *iph, struct sk_buff *skb) { if (INET_ECN_is_ce(iph->tos)) { - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (INET_ECN_is_not_ce(skb->nh.iph->tos)) IP_ECN_set_ce(skb->nh.iph); - } else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + } else if (skb->protocol == htons(ETH_P_IPV6)) { if (INET_ECN_is_not_ce(ip6_get_dsfield(skb->nh.ipv6h))) IP6_ECN_set_ce(skb->nh.ipv6h); } @@ -549,9 +549,9 @@ ipgre_ecn_encapsulate(u8 tos, struct iphdr *old_iph, struct sk_buff *skb) { u8 inner = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) inner = old_iph->tos; - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) inner = ip6_get_dsfield((struct ipv6hdr*)old_iph); return INET_ECN_encapsulate(tos, inner); } @@ -708,13 +708,13 @@ goto tx_error; } - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { rt = (struct rtable*)skb->dst; if ((dst = rt->rt_gateway) == 0) goto tx_error_icmp; } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct in6_addr *addr6; int addr_type; struct neighbour *neigh = skb->dst->neighbour; @@ -742,7 +742,7 @@ tos = tiph->tos; if (tos&1) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) tos = old_iph->tos; tos &= ~1; } @@ -765,13 +765,13 @@ else mtu = skb->dst ? skb->dst->pmtu : dev->mtu; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (skb->dst && mtu < skb->dst->pmtu && mtu >= 68) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); @@ -779,7 +779,7 @@ } } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct rt6_info *rt6 = (struct rt6_info*)skb->dst; if (rt6 && mtu < rt6->u.dst.pmtu && mtu >= IPV6_MIN_MTU) { @@ -845,10 +845,10 @@ iph->saddr = rt->rt_src; if ((iph->ttl = tiph->ttl) == 0) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) iph->ttl = old_iph->ttl; #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) iph->ttl = ((struct ipv6hdr*)old_iph)->hop_limit; #endif else @@ -936,11 +936,11 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_GRE || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF)) || + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF)) || ((p.i_flags|p.o_flags)&(GRE_VERSION|GRE_ROUTING))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); if (!(p.i_flags&GRE_KEY)) p.i_key = 0; Index: net/ipv4/ip_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_output.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -186,7 +186,7 @@ struct net_device *dev = skb->dst->dev; skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev, ip_finish_output2); @@ -208,7 +208,7 @@ #endif skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); /* * Multicasts are looped back for other local users @@ -382,7 +382,7 @@ *((__u16 *)iph) = htons((4 << 12) | (5 << 8) | (sk->protinfo.af_inet.tos & 0xff)); iph->tot_len = htons(skb->len); if (ip_dont_fragment(sk, &rt->u.dst)) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; iph->ttl = sk->protinfo.af_inet.ttl; Index: net/ipv4/ipconfig.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipconfig.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipconfig.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipconfig.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -356,11 +356,11 @@ if (ic_netmask == INADDR_NONE) { if (IN_CLASSA(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSA_NET); + ic_netmask = htonl(IN_CLASSA_NET); else if (IN_CLASSB(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSB_NET); + ic_netmask = htonl(IN_CLASSB_NET); else if (IN_CLASSC(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSC_NET); + ic_netmask = htonl(IN_CLASSC_NET); else { printk(KERN_ERR "IP-Config: Unable to guess netmask for address %u.%u.%u.%u\n", NIPQUAD(ic_myaddr)); @@ -426,11 +426,11 @@ goto drop; /* If it's not a RARP reply, delete it. */ - if (rarp->ar_op != __constant_htons(ARPOP_RREPLY)) + if (rarp->ar_op != htons(ARPOP_RREPLY)) goto drop; /* If it's not Ethernet, delete it. */ - if (rarp->ar_pro != __constant_htons(ETH_P_IP)) + if (rarp->ar_pro != htons(ETH_P_IP)) goto drop; /* Extract variable-width fields */ @@ -661,15 +661,15 @@ h->version = 4; h->ihl = 5; h->tot_len = htons(sizeof(struct bootp_pkt)); - h->frag_off = __constant_htons(IP_DF); + h->frag_off = htons(IP_DF); h->ttl = 64; h->protocol = IPPROTO_UDP; h->daddr = INADDR_BROADCAST; h->check = ip_fast_csum((unsigned char *) h, h->ihl); /* Construct UDP header */ - b->udph.source = __constant_htons(68); - b->udph.dest = __constant_htons(67); + b->udph.source = htons(68); + b->udph.dest = htons(67); b->udph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr)); /* UDP checksum not calculated -- explicitly allowed in BOOTP RFC */ @@ -700,7 +700,7 @@ /* Chain packet down the line... */ skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); if ((dev->hard_header && dev->hard_header(skb, dev, ntohs(skb->protocol), dev->broadcast, dev->dev_addr, skb->len) < 0) || dev_queue_xmit(skb) < 0) @@ -800,13 +800,13 @@ ip_fast_csum((char *) h, h->ihl) != 0 || skb->len < ntohs(h->tot_len) || h->protocol != IPPROTO_UDP || - b->udph.source != __constant_htons(67) || - b->udph.dest != __constant_htons(68) || + b->udph.source != htons(67) || + b->udph.dest != htons(68) || ntohs(h->tot_len) < ntohs(b->udph.len) + sizeof(struct iphdr)) goto drop; /* Fragments are not supported */ - if (h->frag_off & __constant_htons(IP_OFFSET | IP_MF)) { + if (h->frag_off & htons(IP_OFFSET | IP_MF)) { printk(KERN_ERR "DHCP/BOOTP: Ignoring fragmented reply.\n"); goto drop; } Index: net/ipv4/ipip.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipip.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipip.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipip.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -483,7 +483,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->pkt_type = PACKET_HOST; read_lock(&ipip_lock); @@ -544,7 +544,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto tx_error; if (tos&1) @@ -585,9 +585,9 @@ if (skb->dst && mtu < skb->dst->pmtu) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); goto tx_error; @@ -703,10 +703,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPIP || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv4/ipmr.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipmr.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipmr.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipmr.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1434,7 +1434,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); @@ -1501,7 +1501,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); Index: net/ipv4/route.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/route.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/route.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/route.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1246,7 +1246,7 @@ return -EINVAL; if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) || - skb->protocol != __constant_htons(ETH_P_IP)) + skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) { @@ -1457,7 +1457,7 @@ inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) flags |= RTCF_DOREDIRECT; - if (skb->protocol != __constant_htons(ETH_P_IP)) { + if (skb->protocol != htons(ETH_P_IP)) { /* Not IP (i.e. ARP). Do not create route, if it is * invalid for proxy arp. DNAT routes are always valid. */ @@ -1522,7 +1522,7 @@ out: return err; brd_input: - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) @@ -2156,7 +2156,7 @@ err = -ENODEV; if (!dev) goto out; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->dev = dev; local_bh_disable(); err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev); Index: net/ipv4/tcp_diag.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_diag.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_diag.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_diag.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -346,7 +346,7 @@ break; if (sk->family == AF_INET6 && cond->family == AF_INET) { if (addr[0] == 0 && addr[1] == 0 && - addr[2] == __constant_htonl(0xffff) && + addr[2] == htonl(0xffff) && bitstring_match(addr+3, cond->addr, cond->prefix_len)) break; } Index: net/ipv4/tcp_input.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_input.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_input.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_input.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -2083,8 +2083,8 @@ } else if (tp->tstamp_ok && th->doff == (sizeof(struct tcphdr)>>2)+(TCPOLEN_TSTAMP_ALIGNED>>2)) { __u32 *ptr = (__u32 *)(th + 1); - if (*ptr == __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { + if (*ptr == ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { tp->saw_tstamp = 1; ++ptr; tp->rcv_tsval = ntohl(*ptr); @@ -3252,8 +3252,8 @@ __u32 *ptr = (__u32 *)(th + 1); /* No? Slow path! */ - if (*ptr != __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) + if (*ptr != ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) goto slow_path; tp->saw_tstamp = 1; Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_ipv4.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1210,10 +1210,10 @@ arg.iov[0].iov_len = sizeof(rep.th); arg.n_iov = 1; if (ts) { - rep.tsopt[0] = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + rep.tsopt[0] = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); rep.tsopt[1] = htonl(tcp_time_stamp); rep.tsopt[2] = htonl(ts); arg.iov[0].iov_len = sizeof(rep); Index: net/ipv4/netfilter/ip_nat_core.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_core.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_core.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_core.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -775,7 +775,7 @@ if (helper) { /* Always defragged for helpers */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); return helper->help(ct, info, ctinfo, hooknum, pskb); } else return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_snmp_basic.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_snmp_basic.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -1259,9 +1259,9 @@ * on post routing (SNAT). */ if (!((dir == IP_CT_DIR_REPLY && hooknum == NF_IP_PRE_ROUTING && - udph->source == __constant_ntohs(SNMP_PORT)) || + udph->source == ntohs(SNMP_PORT)) || (dir == IP_CT_DIR_ORIGINAL && hooknum == NF_IP_POST_ROUTING && - udph->dest == __constant_ntohs(SNMP_TRAP_PORT)))) { + udph->dest == ntohs(SNMP_TRAP_PORT)))) { spin_unlock_bh(&snmp_lock); return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_standalone.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_standalone.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_standalone.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_standalone.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -60,7 +60,7 @@ /* We never see fragments: conntrack defrags on pre-routing and local-out, and ip_nat_out protects post-routing. */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); (*pskb)->nfcache |= NFC_UNKNOWN; @@ -163,7 +163,7 @@ I'm starting to have nightmares about fragments. */ - if ((*pskb)->nh.iph->frag_off & __constant_htons(IP_MF|IP_OFFSET)) { + if ((*pskb)->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { *pskb = ip_ct_gather_frags(*pskb); if (!*pskb) Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.3 diff -u -r1.1.1.1 -r1.1.1.1.12.3 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/10/03 22:48:03 1.1.1.1.12.3 @@ -141,14 +141,14 @@ /* Consider all addresses with the first three bits different of 000 and 111 as unicasts. */ - if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && - (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) + if ((st & htonl(0xE0000000)) != htonl(0x00000000) && + (st & htonl(0xE0000000)) != htonl(0xE0000000)) return IPV6_ADDR_UNICAST; - if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) { + if ((st & htonl(0xFF000000)) == htonl(0xFF000000)) { int type = IPV6_ADDR_MULTICAST; - switch((st & __constant_htonl(0x00FF0000))) { + switch((st & htonl(0x00FF0000))) { case __constant_htonl(0x00010000): type |= IPV6_ADDR_LOOPBACK; break; @@ -164,24 +164,24 @@ return type; } - if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) + if ((st & htonl(0xFFC00000)) == htonl(0xFE800000)) return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST); - if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) + if ((st & htonl(0xFFC00000)) == htonl(0xFEC00000)) return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST); if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { - if (addr->in6_u.u6_addr32[3] == 0) + if (addr->s6_addr32[3] == 0) return IPV6_ADDR_ANY; - if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) + if (addr->s6_addr32[3] == htonl(0x00000001)) return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST); return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST); } - if (addr->s6_addr32[2] == __constant_htonl(0x0000ffff)) + if (addr->s6_addr32[2] == htonl(0x0000ffff)) return IPV6_ADDR_MAPPED; } @@ -752,7 +752,7 @@ memset(&rtmsg, 0, sizeof(rtmsg)); ipv6_addr_set(&rtmsg.rtmsg_dst, - __constant_htonl(0xFF000000), 0, 0, 0); + htonl(0xFF000000), 0, 0, 0); rtmsg.rtmsg_dst_len = 8; rtmsg.rtmsg_metric = IP6_RT_PRIO_ADDRCONF; rtmsg.rtmsg_ifindex = dev->ifindex; @@ -782,7 +782,7 @@ { struct in6_addr addr; - ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0); + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0); addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF); } @@ -1120,7 +1120,7 @@ memcpy(&addr.s6_addr32[3], idev->dev->dev_addr, 4); if (idev->dev->flags&IFF_POINTOPOINT) { - addr.s6_addr32[0] = __constant_htonl(0xfe800000); + addr.s6_addr32[0] = htonl(0xfe800000); scope = IFA_LINK; } else { scope = IPV6_ADDR_COMPATv4; @@ -1187,7 +1187,7 @@ ASSERT_RTNL(); memset(&addr, 0, sizeof(struct in6_addr)); - addr.s6_addr[15] = 1; + addr.s6_addr32[3] = htonl(0x00000001); if ((idev = ipv6_find_idev(dev)) == NULL) { printk(KERN_DEBUG "init loopback: add_dev failed\n"); @@ -1234,9 +1234,7 @@ return; memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; + addr.s6_addr32[0] = htonl(0xFE800000); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); Index: net/ipv6/datagram.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/datagram.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/datagram.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/datagram.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -147,7 +147,7 @@ } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, - __constant_htonl(0xffff), + htonl(0xffff), *(u32*)(skb->nh.raw + serr->addr_offset)); } } @@ -168,7 +168,7 @@ } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, - __constant_htonl(0xffff), + htonl(0xffff), skb->nh.iph->saddr); if (sk->protinfo.af_inet.cmsg_flags) ip_cmsg_recv(msg, skb); Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/icmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/icmp.c 2002/09/12 09:41:58 1.1.1.1.12.1 @@ -198,7 +198,7 @@ u8 type; if (skb_copy_bits(skb, ptr+offsetof(struct icmp6hdr, icmp6_type), &type, 1) - || !(type & 0x80)) + || !(type & ICMPV6_INFOMSG_MASK)) return 1; } return 0; @@ -216,7 +216,7 @@ int res = 0; /* Informational messages are not limited. */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) return 1; /* Do not limit pmtu discovery, it would break it. */ @@ -519,22 +519,22 @@ skb_checksum(skb, 0, skb->len, 0))) { if (net_ratelimit()) printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - ntohs(saddr->in6_u.u6_addr16[0]), - ntohs(saddr->in6_u.u6_addr16[1]), - ntohs(saddr->in6_u.u6_addr16[2]), - ntohs(saddr->in6_u.u6_addr16[3]), - ntohs(saddr->in6_u.u6_addr16[4]), - ntohs(saddr->in6_u.u6_addr16[5]), - ntohs(saddr->in6_u.u6_addr16[6]), - ntohs(saddr->in6_u.u6_addr16[7]), - ntohs(daddr->in6_u.u6_addr16[0]), - ntohs(daddr->in6_u.u6_addr16[1]), - ntohs(daddr->in6_u.u6_addr16[2]), - ntohs(daddr->in6_u.u6_addr16[3]), - ntohs(daddr->in6_u.u6_addr16[4]), - ntohs(daddr->in6_u.u6_addr16[5]), - ntohs(daddr->in6_u.u6_addr16[6]), - ntohs(daddr->in6_u.u6_addr16[7])); + ntohs(saddr->s6_addr16[0]), + ntohs(saddr->s6_addr16[1]), + ntohs(saddr->s6_addr16[2]), + ntohs(saddr->s6_addr16[3]), + ntohs(saddr->s6_addr16[4]), + ntohs(saddr->s6_addr16[5]), + ntohs(saddr->s6_addr16[6]), + ntohs(saddr->s6_addr16[7]), + ntohs(daddr->s6_addr16[0]), + ntohs(daddr->s6_addr16[1]), + ntohs(daddr->s6_addr16[2]), + ntohs(daddr->s6_addr16[3]), + ntohs(daddr->s6_addr16[4]), + ntohs(daddr->s6_addr16[5]), + ntohs(daddr->s6_addr16[6]), + ntohs(daddr->s6_addr16[7])); goto discard_it; } } @@ -613,7 +613,7 @@ printk(KERN_DEBUG "icmpv6: msg of unkown type\n"); /* informational */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) break; /* Index: net/ipv6/ip6_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ip6_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/ip6_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/ip6_output.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -101,7 +101,7 @@ struct dst_entry *dst = skb->dst; struct net_device *dev = dst->dev; - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr)) { @@ -221,7 +221,7 @@ * Fill in the IPv6 header */ - *(u32*)hdr = __constant_htonl(0x60000000) | fl->fl6_flowlabel; + *(u32*)hdr = htonl(0x60000000) | fl->fl6_flowlabel; hlimit = -1; if (np) hlimit = np->hop_limit; @@ -262,7 +262,7 @@ struct ipv6hdr *hdr; int totlen; - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; totlen = len + sizeof(struct ipv6hdr); Index: net/ipv6/reassembly.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/reassembly.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/reassembly.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/reassembly.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -372,7 +372,7 @@ csum_partial(skb->nh.raw, (u8*)(fhdr+1)-skb->nh.raw, 0)); /* Is this the final fragment? */ - if (!(fhdr->frag_off & __constant_htons(0x0001))) { + if (!(fhdr->frag_off & htons(0x0001))) { /* If we already have some bits beyond end * or have different end, the segment is corrupted. */ @@ -648,7 +648,7 @@ hdr = skb->nh.ipv6h; fhdr = (struct frag_hdr *)skb->h.raw; - if (!(fhdr->frag_off & __constant_htons(0xFFF9))) { + if (!(fhdr->frag_off & htons(0xFFF9))) { /* It is not a fragmented frame */ skb->h.raw += sizeof(struct frag_hdr); IP6_INC_STATS_BH(Ip6ReasmOKs); Index: net/ipv6/sit.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sit.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/sit.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/sit.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -396,7 +396,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IPV6); + skb->protocol = htons(ETH_P_IPV6); skb->pkt_type = PACKET_HOST; tunnel->stat.rx_packets++; tunnel->stat.rx_bytes += skb->len; @@ -470,7 +470,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IPV6)) + if (skb->protocol != htons(ETH_P_IPV6)) goto tx_error; if (!dst) @@ -588,7 +588,7 @@ iph->version = 4; iph->ihl = sizeof(struct iphdr)>>2; if (mtu > IPV6_MIN_MTU) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; @@ -659,10 +659,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPV6 || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip6_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/tcp_ipv6.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/tcp_ipv6.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -402,7 +402,7 @@ static __u32 tcp_v6_init_sequence(struct sock *sk, struct sk_buff *skb) { - if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + if (skb->protocol == htons(ETH_P_IPV6)) { return secure_tcpv6_sequence_number(skb->nh.ipv6h->daddr.s6_addr32, skb->nh.ipv6h->saddr.s6_addr32, skb->h.th->dest, @@ -617,9 +617,9 @@ sk->backlog_rcv = tcp_v6_do_rcv; goto failure; } else { - ipv6_addr_set(&np->saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->saddr, 0, 0, htonl(0x0000FFFF), sk->saddr); - ipv6_addr_set(&np->rcv_saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->rcv_saddr, 0, 0, htonl(0x0000FFFF), sk->rcv_saddr); } @@ -1031,10 +1031,10 @@ if (ts) { u32 *ptr = (u32*)(t1 + 1); - *ptr++ = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + *ptr++ = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); *ptr++ = htonl(tcp_time_stamp); *ptr = htonl(ts); } @@ -1145,7 +1145,7 @@ struct open_request *req = NULL; __u32 isn = TCP_SKB_CB(skb)->when; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_conn_request(sk, skb); /* FIXME: do the same check for anycast */ @@ -1224,7 +1224,7 @@ struct sock *newsk; struct ipv6_txoptions *opt; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { /* * v6 mapped */ @@ -1236,10 +1236,10 @@ np = &newsk->net_pinfo.af_inet6; - ipv6_addr_set(&np->daddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->daddr, 0, 0, htonl(0x0000FFFF), newsk->daddr); - ipv6_addr_set(&np->saddr, 0, 0, __constant_htonl(0x0000FFFF), + ipv6_addr_set(&np->saddr, 0, 0, htonl(0x0000FFFF), newsk->saddr); ipv6_addr_copy(&np->rcv_saddr, &np->saddr); @@ -1425,7 +1425,7 @@ tcp_v6_hnd_req and tcp_v6_send_reset(). --ANK */ - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_do_rcv(sk, skb); #ifdef CONFIG_FILTER Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/udp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/udp.c 2002/10/03 22:41:07 1.1.1.1.12.1 @@ -267,18 +267,18 @@ return err; ipv6_addr_set(&np->daddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->daddr); if(ipv6_addr_any(&np->saddr)) { ipv6_addr_set(&np->saddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->saddr); } if(ipv6_addr_any(&np->rcv_saddr)) { ipv6_addr_set(&np->rcv_saddr, 0, 0, - __constant_htonl(0x0000ffff), + htonl(0x0000ffff), sk->rcv_saddr); } return 0; @@ -420,9 +420,9 @@ sin6->sin6_flowinfo = 0; sin6->sin6_scope_id = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { ipv6_addr_set(&sin6->sin6_addr, 0, 0, - __constant_htonl(0xffff), skb->nh.iph->saddr); + htonl(0xffff), skb->nh.iph->saddr); if (sk->protinfo.af_inet.cmsg_flags) ip_cmsg_recv(msg, skb); } else { Index: net/ipv6/netfilter/ip6_queue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6_queue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.2 diff -u -r1.1.1.1 -r1.1.1.1.12.2 --- net/ipv6/netfilter/ip6_queue.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6_queue.c 2002/09/19 03:57:51 1.1.1.1.12.2 @@ -306,14 +306,8 @@ */ if (e->info->hook == NF_IP_LOCAL_OUT) { struct ipv6hdr *iph = e->skb->nh.ipv6h; - if (!( iph->daddr.in6_u.u6_addr32[0] == e->rt_info.daddr.in6_u.u6_addr32[0] - && iph->daddr.in6_u.u6_addr32[1] == e->rt_info.daddr.in6_u.u6_addr32[1] - && iph->daddr.in6_u.u6_addr32[2] == e->rt_info.daddr.in6_u.u6_addr32[2] - && iph->daddr.in6_u.u6_addr32[3] == e->rt_info.daddr.in6_u.u6_addr32[3] - && iph->saddr.in6_u.u6_addr32[0] == e->rt_info.saddr.in6_u.u6_addr32[0] - && iph->saddr.in6_u.u6_addr32[1] == e->rt_info.saddr.in6_u.u6_addr32[1] - && iph->saddr.in6_u.u6_addr32[2] == e->rt_info.saddr.in6_u.u6_addr32[2] - && iph->saddr.in6_u.u6_addr32[3] == e->rt_info.saddr.in6_u.u6_addr32[3])) + 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 0; Index: net/ipv6/netfilter/ip6t_LOG.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6t_LOG.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/netfilter/ip6t_LOG.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6t_LOG.c 2002/10/03 22:07:26 1.1.1.1.12.1 @@ -112,7 +112,7 @@ printk("FRAG:%u ", ntohs(fhdr->frag_off) & 0xFFF8); /* Max length: 11 "INCOMPLETE " */ - if (fhdr->frag_off & __constant_htons(0x0001)) + if (fhdr->frag_off & htons(0x0001)) printk("INCOMPLETE "); printk("ID:%08x ", fhdr->identification); --yoshfuji From yoshfuji@linux-ipv6.org Thu Oct 3 16:32:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 16:32:16 -0700 (PDT) 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 g93NW4tI028181 for ; Thu, 3 Oct 2002 16:32:08 -0700 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 g93Mag1o030119; Fri, 4 Oct 2002 07:36:42 +0900 Date: Fri, 04 Oct 2002 07:36:42 +0900 (JST) Message-Id: <20021004.073642.125593159.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021003.103617.04446177.davem@redhat.com> References: <20021004.011315.05129566.yoshfuji@linux-ipv6.org> <20021003.103617.04446177.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-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: 514 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 <20021003.103617.04446177.davem@redhat.com> (at Thu, 03 Oct 2002 10:36:17 -0700 (PDT)), "David S. Miller" says: > - addr.s6_addr[15] = 1; > + addr.s6_addr32[3] = __constant_htonl(0x00000001); > > Do not use __constant_htonl() in runtime code, use htonl(). > Arnaldo de Melo told you this the other day for another one > of your patches, so you must fix this kind of stuff up before > I'll apply any of your patches which have this problem. I saw many __constant_{hton,ntoh}{s,l}()s, so fixed. 1. use s6_addrXX instead of in6_u.s6_addrXX. 2. avoid using magic number. 3. use 32bit constants. --> 4. avoid __constant_{hton,ntoh}{l,s}() in runtime code. Index: net/ipv4/arp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/arp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/arp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/arp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -513,7 +513,7 @@ skb->nh.raw = skb->data; arp = (struct arphdr *) skb_put(skb,sizeof(struct arphdr) + 2*(dev->addr_len+4)); skb->dev = dev; - skb->protocol = __constant_htons (ETH_P_ARP); + skb->protocol = htons (ETH_P_ARP); if (src_hw == NULL) src_hw = dev->dev_addr; if (dest_hw == NULL) @@ -539,33 +539,33 @@ switch (dev->type) { default: arp->ar_hrd = htons(dev->type); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_pro = htons(ETH_P_IP); break; #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - arp->ar_hrd = __constant_htons(ARPHRD_AX25); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_AX25); + arp->ar_pro = htons(AX25_P_IP); break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - arp->ar_hrd = __constant_htons(ARPHRD_NETROM); - arp->ar_pro = __constant_htons(AX25_P_IP); + arp->ar_hrd = htons(ARPHRD_NETROM); + arp->ar_pro = htons(AX25_P_IP); break; #endif #endif #ifdef CONFIG_FDDI case ARPHRD_FDDI: - arp->ar_hrd = __constant_htons(ARPHRD_ETHER); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_ETHER); + arp->ar_pro = htons(ETH_P_IP); break; #endif #ifdef CONFIG_TR case ARPHRD_IEEE802_TR: - arp->ar_hrd = __constant_htons(ARPHRD_IEEE802); - arp->ar_pro = __constant_htons(ETH_P_IP); + arp->ar_hrd = htons(ARPHRD_IEEE802); + arp->ar_pro = htons(ETH_P_IP); break; #endif } @@ -629,7 +629,7 @@ switch (dev_type) { default: - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; if (htons(dev_type) != arp->ar_hrd) goto out; @@ -640,10 +640,10 @@ * ETHERNET devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -653,10 +653,10 @@ * Token ring devices will accept ARP hardware types of either * 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -667,10 +667,10 @@ * of 1 (Ethernet). However, to be more robust, we'll accept hardware * types of either 1 (Ethernet) or 6 (IEEE 802.2). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif @@ -681,25 +681,25 @@ * 802 devices) should accept ARP hardware types of 6 (IEEE 802) * and 1 (Ethernet). */ - if (arp->ar_hrd != __constant_htons(ARPHRD_ETHER) && - arp->ar_hrd != __constant_htons(ARPHRD_IEEE802)) + if (arp->ar_hrd != htons(ARPHRD_ETHER) && + arp->ar_hrd != htons(ARPHRD_IEEE802)) goto out; - if (arp->ar_pro != __constant_htons(ETH_P_IP)) + if (arp->ar_pro != htons(ETH_P_IP)) goto out; break; #endif #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) case ARPHRD_AX25: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_AX25)) + if (arp->ar_hrd != htons(ARPHRD_AX25)) goto out; break; #if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE) case ARPHRD_NETROM: - if (arp->ar_pro != __constant_htons(AX25_P_IP)) + if (arp->ar_pro != htons(AX25_P_IP)) goto out; - if (arp->ar_hrd != __constant_htons(ARPHRD_NETROM)) + if (arp->ar_hrd != htons(ARPHRD_NETROM)) goto out; break; #endif @@ -708,8 +708,8 @@ /* Understand only these message types */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) && - arp->ar_op != __constant_htons(ARPOP_REQUEST)) + if (arp->ar_op != htons(ARPOP_REPLY) && + arp->ar_op != htons(ARPOP_REQUEST)) goto out; /* @@ -754,13 +754,13 @@ /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && inet_addr_type(tip) == RTN_LOCAL) arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); goto out; } - if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && + if (arp->ar_op == htons(ARPOP_REQUEST) && ip_route_input(skb, tip, sip, 0, dev) == 0) { rt = (struct rtable*)skb->dst; @@ -810,7 +810,7 @@ devices (strip is candidate) */ if (n == NULL && - arp->ar_op == __constant_htons(ARPOP_REPLY) && + arp->ar_op == htons(ARPOP_REPLY) && inet_addr_type(sip) == RTN_UNICAST) n = __neigh_lookup(&arp_tbl, &sip, dev, -1); #endif @@ -830,7 +830,7 @@ /* Broadcast replies and request packets do not assert neighbour reachability. */ - if (arp->ar_op != __constant_htons(ARPOP_REPLY) || + if (arp->ar_op != htons(ARPOP_REPLY) || skb->pkt_type != PACKET_HOST) state = NUD_STALE; neigh_update(n, sha, state, override, 1); @@ -1050,7 +1050,7 @@ (r.arp_flags & (ATF_NETMASK|ATF_DONTPUB))) return -EINVAL; if (!(r.arp_flags & ATF_NETMASK)) - ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=__constant_htonl(0xFFFFFFFFUL); + ((struct sockaddr_in *)&r.arp_netmask)->sin_addr.s_addr=htonl(0xFFFFFFFFUL); rtnl_lock(); if (r.arp_dev[0]) { Index: net/ipv4/igmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/igmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/igmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/igmp.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -229,7 +229,7 @@ iph->version = 4; iph->ihl = (sizeof(struct iphdr)+4)>>2; iph->tos = 0; - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); iph->ttl = 1; iph->daddr = dst; iph->saddr = rt->rt_src; Index: net/ipv4/ip_gre.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_gre.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_gre.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_gre.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -412,7 +412,7 @@ struct sk_buff *skb2; struct rtable *rt; - if (p[1] != __constant_htons(ETH_P_IP)) + if (p[1] != htons(ETH_P_IP)) return; flags = p[0]; @@ -535,10 +535,10 @@ static inline void ipgre_ecn_decapsulate(struct iphdr *iph, struct sk_buff *skb) { if (INET_ECN_is_ce(iph->tos)) { - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (INET_ECN_is_not_ce(skb->nh.iph->tos)) IP_ECN_set_ce(skb->nh.iph); - } else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + } else if (skb->protocol == htons(ETH_P_IPV6)) { if (INET_ECN_is_not_ce(ip6_get_dsfield(skb->nh.ipv6h))) IP6_ECN_set_ce(skb->nh.ipv6h); } @@ -549,9 +549,9 @@ ipgre_ecn_encapsulate(u8 tos, struct iphdr *old_iph, struct sk_buff *skb) { u8 inner = 0; - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) inner = old_iph->tos; - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) inner = ip6_get_dsfield((struct ipv6hdr*)old_iph); return INET_ECN_encapsulate(tos, inner); } @@ -708,13 +708,13 @@ goto tx_error; } - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { rt = (struct rtable*)skb->dst; if ((dst = rt->rt_gateway) == 0) goto tx_error_icmp; } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct in6_addr *addr6; int addr_type; struct neighbour *neigh = skb->dst->neighbour; @@ -742,7 +742,7 @@ tos = tiph->tos; if (tos&1) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) tos = old_iph->tos; tos &= ~1; } @@ -765,13 +765,13 @@ else mtu = skb->dst ? skb->dst->pmtu : dev->mtu; - if (skb->protocol == __constant_htons(ETH_P_IP)) { + if (skb->protocol == htons(ETH_P_IP)) { if (skb->dst && mtu < skb->dst->pmtu && mtu >= 68) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); @@ -779,7 +779,7 @@ } } #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { + else if (skb->protocol == htons(ETH_P_IPV6)) { struct rt6_info *rt6 = (struct rt6_info*)skb->dst; if (rt6 && mtu < rt6->u.dst.pmtu && mtu >= IPV6_MIN_MTU) { @@ -845,10 +845,10 @@ iph->saddr = rt->rt_src; if ((iph->ttl = tiph->ttl) == 0) { - if (skb->protocol == __constant_htons(ETH_P_IP)) + if (skb->protocol == htons(ETH_P_IP)) iph->ttl = old_iph->ttl; #ifdef CONFIG_IPV6 - else if (skb->protocol == __constant_htons(ETH_P_IPV6)) + else if (skb->protocol == htons(ETH_P_IPV6)) iph->ttl = ((struct ipv6hdr*)old_iph)->hop_limit; #endif else @@ -936,11 +936,11 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_GRE || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF)) || + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF)) || ((p.i_flags|p.o_flags)&(GRE_VERSION|GRE_ROUTING))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); if (!(p.i_flags&GRE_KEY)) p.i_key = 0; Index: net/ipv4/ip_output.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ip_output.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ip_output.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ip_output.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -186,7 +186,7 @@ struct net_device *dev = skb->dst->dev; skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev, ip_finish_output2); @@ -208,7 +208,7 @@ #endif skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); /* * Multicasts are looped back for other local users @@ -382,7 +382,7 @@ *((__u16 *)iph) = htons((4 << 12) | (5 << 8) | (sk->protinfo.af_inet.tos & 0xff)); iph->tot_len = htons(skb->len); if (ip_dont_fragment(sk, &rt->u.dst)) - iph->frag_off = __constant_htons(IP_DF); + iph->frag_off = htons(IP_DF); else iph->frag_off = 0; iph->ttl = sk->protinfo.af_inet.ttl; Index: net/ipv4/ipconfig.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipconfig.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipconfig.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipconfig.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -356,11 +356,11 @@ if (ic_netmask == INADDR_NONE) { if (IN_CLASSA(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSA_NET); + ic_netmask = htonl(IN_CLASSA_NET); else if (IN_CLASSB(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSB_NET); + ic_netmask = htonl(IN_CLASSB_NET); else if (IN_CLASSC(ntohl(ic_myaddr))) - ic_netmask = __constant_htonl(IN_CLASSC_NET); + ic_netmask = htonl(IN_CLASSC_NET); else { printk(KERN_ERR "IP-Config: Unable to guess netmask for address %u.%u.%u.%u\n", NIPQUAD(ic_myaddr)); @@ -426,11 +426,11 @@ goto drop; /* If it's not a RARP reply, delete it. */ - if (rarp->ar_op != __constant_htons(ARPOP_RREPLY)) + if (rarp->ar_op != htons(ARPOP_RREPLY)) goto drop; /* If it's not Ethernet, delete it. */ - if (rarp->ar_pro != __constant_htons(ETH_P_IP)) + if (rarp->ar_pro != htons(ETH_P_IP)) goto drop; /* Extract variable-width fields */ @@ -661,15 +661,15 @@ h->version = 4; h->ihl = 5; h->tot_len = htons(sizeof(struct bootp_pkt)); - h->frag_off = __constant_htons(IP_DF); + h->frag_off = htons(IP_DF); h->ttl = 64; h->protocol = IPPROTO_UDP; h->daddr = INADDR_BROADCAST; h->check = ip_fast_csum((unsigned char *) h, h->ihl); /* Construct UDP header */ - b->udph.source = __constant_htons(68); - b->udph.dest = __constant_htons(67); + b->udph.source = htons(68); + b->udph.dest = htons(67); b->udph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr)); /* UDP checksum not calculated -- explicitly allowed in BOOTP RFC */ @@ -700,7 +700,7 @@ /* Chain packet down the line... */ skb->dev = dev; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); if ((dev->hard_header && dev->hard_header(skb, dev, ntohs(skb->protocol), dev->broadcast, dev->dev_addr, skb->len) < 0) || dev_queue_xmit(skb) < 0) @@ -800,13 +800,13 @@ ip_fast_csum((char *) h, h->ihl) != 0 || skb->len < ntohs(h->tot_len) || h->protocol != IPPROTO_UDP || - b->udph.source != __constant_htons(67) || - b->udph.dest != __constant_htons(68) || + b->udph.source != htons(67) || + b->udph.dest != htons(68) || ntohs(h->tot_len) < ntohs(b->udph.len) + sizeof(struct iphdr)) goto drop; /* Fragments are not supported */ - if (h->frag_off & __constant_htons(IP_OFFSET | IP_MF)) { + if (h->frag_off & htons(IP_OFFSET | IP_MF)) { printk(KERN_ERR "DHCP/BOOTP: Ignoring fragmented reply.\n"); goto drop; } Index: net/ipv4/ipip.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipip.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipip.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipip.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -483,7 +483,7 @@ skb->mac.raw = skb->nh.raw; skb->nh.raw = skb->data; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->pkt_type = PACKET_HOST; read_lock(&ipip_lock); @@ -544,7 +544,7 @@ goto tx_error; } - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto tx_error; if (tos&1) @@ -585,9 +585,9 @@ if (skb->dst && mtu < skb->dst->pmtu) skb->dst->pmtu = mtu; - df |= (old_iph->frag_off&__constant_htons(IP_DF)); + df |= (old_iph->frag_off&htons(IP_DF)); - if ((old_iph->frag_off&__constant_htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { + if ((old_iph->frag_off&htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ip_rt_put(rt); goto tx_error; @@ -703,10 +703,10 @@ err = -EINVAL; if (p.iph.version != 4 || p.iph.protocol != IPPROTO_IPIP || - p.iph.ihl != 5 || (p.iph.frag_off&__constant_htons(~IP_DF))) + p.iph.ihl != 5 || (p.iph.frag_off&htons(~IP_DF))) goto done; if (p.iph.ttl) - p.iph.frag_off |= __constant_htons(IP_DF); + p.iph.frag_off |= htons(IP_DF); t = ipip_tunnel_locate(&p, cmd == SIOCADDTUNNEL); Index: net/ipv4/ipmr.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/ipmr.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/ipmr.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/ipmr.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1434,7 +1434,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); @@ -1501,7 +1501,7 @@ skb->nh.iph = (struct iphdr *)skb->data; skb->dev = reg_dev; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->ip_summed = 0; skb->pkt_type = PACKET_HOST; dst_release(skb->dst); Index: net/ipv4/route.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/route.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/route.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/route.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1246,7 +1246,7 @@ return -EINVAL; if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) || - skb->protocol != __constant_htons(ETH_P_IP)) + skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) { @@ -1457,7 +1457,7 @@ inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) flags |= RTCF_DOREDIRECT; - if (skb->protocol != __constant_htons(ETH_P_IP)) { + if (skb->protocol != htons(ETH_P_IP)) { /* Not IP (i.e. ARP). Do not create route, if it is * invalid for proxy arp. DNAT routes are always valid. */ @@ -1522,7 +1522,7 @@ out: return err; brd_input: - if (skb->protocol != __constant_htons(ETH_P_IP)) + if (skb->protocol != htons(ETH_P_IP)) goto e_inval; if (ZERONET(saddr)) @@ -2156,7 +2156,7 @@ err = -ENODEV; if (!dev) goto out; - skb->protocol = __constant_htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IP); skb->dev = dev; local_bh_disable(); err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev); Index: net/ipv4/tcp_diag.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_diag.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_diag.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_diag.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -346,7 +346,7 @@ break; if (sk->family == AF_INET6 && cond->family == AF_INET) { if (addr[0] == 0 && addr[1] == 0 && - addr[2] == __constant_htonl(0xffff) && + addr[2] == htonl(0xffff) && bitstring_match(addr+3, cond->addr, cond->prefix_len)) break; } Index: net/ipv4/tcp_input.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_input.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_input.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_input.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -2083,8 +2083,8 @@ } else if (tp->tstamp_ok && th->doff == (sizeof(struct tcphdr)>>2)+(TCPOLEN_TSTAMP_ALIGNED>>2)) { __u32 *ptr = (__u32 *)(th + 1); - if (*ptr == __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { + if (*ptr == ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) { tp->saw_tstamp = 1; ++ptr; tp->rcv_tsval = ntohl(*ptr); @@ -3252,8 +3252,8 @@ __u32 *ptr = (__u32 *)(th + 1); /* No? Slow path! */ - if (*ptr != __constant_ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) - | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) + if (*ptr != ntohl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) + | (TCPOPT_TIMESTAMP << 8) | TCPOLEN_TIMESTAMP)) goto slow_path; tp->saw_tstamp = 1; Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/tcp_ipv4.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/tcp_ipv4.c 2002/10/03 22:05:55 1.1.1.1.12.1 @@ -1210,10 +1210,10 @@ arg.iov[0].iov_len = sizeof(rep.th); arg.n_iov = 1; if (ts) { - rep.tsopt[0] = __constant_htonl((TCPOPT_NOP << 24) | - (TCPOPT_NOP << 16) | - (TCPOPT_TIMESTAMP << 8) | - TCPOLEN_TIMESTAMP); + rep.tsopt[0] = htonl((TCPOPT_NOP << 24) | + (TCPOPT_NOP << 16) | + (TCPOPT_TIMESTAMP << 8) | + TCPOLEN_TIMESTAMP); rep.tsopt[1] = htonl(tcp_time_stamp); rep.tsopt[2] = htonl(ts); arg.iov[0].iov_len = sizeof(rep); Index: net/ipv4/netfilter/ip_nat_core.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_core.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_core.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_core.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -775,7 +775,7 @@ if (helper) { /* Always defragged for helpers */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); return helper->help(ct, info, ctinfo, hooknum, pskb); } else return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_snmp_basic.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_snmp_basic.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_snmp_basic.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -1259,9 +1259,9 @@ * on post routing (SNAT). */ if (!((dir == IP_CT_DIR_REPLY && hooknum == NF_IP_PRE_ROUTING && - udph->source == __constant_ntohs(SNMP_PORT)) || + udph->source == ntohs(SNMP_PORT)) || (dir == IP_CT_DIR_ORIGINAL && hooknum == NF_IP_POST_ROUTING && - udph->dest == __constant_ntohs(SNMP_TRAP_PORT)))) { + udph->dest == ntohs(SNMP_TRAP_PORT)))) { spin_unlock_bh(&snmp_lock); return NF_ACCEPT; } Index: net/ipv4/netfilter/ip_nat_standalone.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/netfilter/ip_nat_standalone.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv4/netfilter/ip_nat_standalone.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv4/netfilter/ip_nat_standalone.c 2002/10/03 22:13:47 1.1.1.1.12.1 @@ -60,7 +60,7 @@ /* We never see fragments: conntrack defrags on pre-routing and local-out, and ip_nat_out protects post-routing. */ IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off - & __constant_htons(IP_MF|IP_OFFSET))); + & htons(IP_MF|IP_OFFSET))); (*pskb)->nfcache |= NFC_UNKNOWN; @@ -163,7 +163,7 @@ I'm starting to have nightmares about fragments. */ - if ((*pskb)->nh.iph->frag_off & __constant_htons(IP_MF|IP_OFFSET)) { + if ((*pskb)->nh.iph->frag_off & htons(IP_MF|IP_OFFSET)) { *pskb = ip_ct_gather_frags(*pskb); if (!*pskb) Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 addrconf.c --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/10/03 22:16:13 @@ -172,7 +172,7 @@ if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { - if (addr->in6_u.u6_addr32[3] == 0) + if (addr->s6_addr32[3] == 0) return IPV6_ADDR_ANY; if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) @@ -1187,7 +1187,7 @@ ASSERT_RTNL(); memset(&addr, 0, sizeof(struct in6_addr)); - addr.s6_addr[15] = 1; + addr.s6_addr32[3] = __constant_htonl(0x00000001); if ((idev = ipv6_find_idev(dev)) == NULL) { printk(KERN_DEBUG "init loopback: add_dev failed\n"); @@ -1234,9 +1234,7 @@ return; memset(&addr, 0, sizeof(struct in6_addr)); - - addr.s6_addr[0] = 0xFE; - addr.s6_addr[1] = 0x80; + addr.s6_addr32[0] = __contant_htonl(0xFE800000); if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) addrconf_add_linklocal(idev, &addr); Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/icmp.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/icmp.c 2002/09/12 09:41:58 1.1.1.1.12.1 @@ -198,7 +198,7 @@ u8 type; if (skb_copy_bits(skb, ptr+offsetof(struct icmp6hdr, icmp6_type), &type, 1) - || !(type & 0x80)) + || !(type & ICMPV6_INFOMSG_MASK)) return 1; } return 0; @@ -216,7 +216,7 @@ int res = 0; /* Informational messages are not limited. */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) return 1; /* Do not limit pmtu discovery, it would break it. */ @@ -519,22 +519,22 @@ skb_checksum(skb, 0, skb->len, 0))) { if (net_ratelimit()) printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - ntohs(saddr->in6_u.u6_addr16[0]), - ntohs(saddr->in6_u.u6_addr16[1]), - ntohs(saddr->in6_u.u6_addr16[2]), - ntohs(saddr->in6_u.u6_addr16[3]), - ntohs(saddr->in6_u.u6_addr16[4]), - ntohs(saddr->in6_u.u6_addr16[5]), - ntohs(saddr->in6_u.u6_addr16[6]), - ntohs(saddr->in6_u.u6_addr16[7]), - ntohs(daddr->in6_u.u6_addr16[0]), - ntohs(daddr->in6_u.u6_addr16[1]), - ntohs(daddr->in6_u.u6_addr16[2]), - ntohs(daddr->in6_u.u6_addr16[3]), - ntohs(daddr->in6_u.u6_addr16[4]), - ntohs(daddr->in6_u.u6_addr16[5]), - ntohs(daddr->in6_u.u6_addr16[6]), - ntohs(daddr->in6_u.u6_addr16[7])); + ntohs(saddr->s6_addr16[0]), + ntohs(saddr->s6_addr16[1]), + ntohs(saddr->s6_addr16[2]), + ntohs(saddr->s6_addr16[3]), + ntohs(saddr->s6_addr16[4]), + ntohs(saddr->s6_addr16[5]), + ntohs(saddr->s6_addr16[6]), + ntohs(saddr->s6_addr16[7]), + ntohs(daddr->s6_addr16[0]), + ntohs(daddr->s6_addr16[1]), + ntohs(daddr->s6_addr16[2]), + ntohs(daddr->s6_addr16[3]), + ntohs(daddr->s6_addr16[4]), + ntohs(daddr->s6_addr16[5]), + ntohs(daddr->s6_addr16[6]), + ntohs(daddr->s6_addr16[7])); goto discard_it; } } @@ -613,7 +613,7 @@ printk(KERN_DEBUG "icmpv6: msg of unkown type\n"); /* informational */ - if (type & 0x80) + if (type & ICMPV6_INFOMSG_MASK) break; /* Index: net/ipv6/netfilter/ip6_queue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6_queue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.2 diff -u -r1.1.1.1 -r1.1.1.1.12.2 --- net/ipv6/netfilter/ip6_queue.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6_queue.c 2002/09/19 03:57:51 1.1.1.1.12.2 @@ -306,14 +306,8 @@ */ if (e->info->hook == NF_IP_LOCAL_OUT) { struct ipv6hdr *iph = e->skb->nh.ipv6h; - if (!( iph->daddr.in6_u.u6_addr32[0] == e->rt_info.daddr.in6_u.u6_addr32[0] - && iph->daddr.in6_u.u6_addr32[1] == e->rt_info.daddr.in6_u.u6_addr32[1] - && iph->daddr.in6_u.u6_addr32[2] == e->rt_info.daddr.in6_u.u6_addr32[2] - && iph->daddr.in6_u.u6_addr32[3] == e->rt_info.daddr.in6_u.u6_addr32[3] - && iph->saddr.in6_u.u6_addr32[0] == e->rt_info.saddr.in6_u.u6_addr32[0] - && iph->saddr.in6_u.u6_addr32[1] == e->rt_info.saddr.in6_u.u6_addr32[1] - && iph->saddr.in6_u.u6_addr32[2] == e->rt_info.saddr.in6_u.u6_addr32[2] - && iph->saddr.in6_u.u6_addr32[3] == e->rt_info.saddr.in6_u.u6_addr32[3])) + 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 0; Index: net/ipv6/netfilter/ip6t_LOG.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6t_LOG.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.12.1 diff -u -r1.1.1.1 -r1.1.1.1.12.1 --- net/ipv6/netfilter/ip6t_LOG.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/netfilter/ip6t_LOG.c 2002/10/03 22:07:26 1.1.1.1.12.1 @@ -112,7 +112,7 @@ printk("FRAG:%u ", ntohs(fhdr->frag_off) & 0xFFF8); /* Max length: 11 "INCOMPLETE " */ - if (fhdr->frag_off & __constant_htons(0x0001)) + if (fhdr->frag_off & htons(0x0001)) printk("INCOMPLETE "); printk("ID:%08x ", fhdr->identification); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From acme@conectiva.com.br Thu Oct 3 22:10:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 22:10:06 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9459wtG006662 for ; Thu, 3 Oct 2002 22:09:59 -0700 Received: from [200.181.170.125] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 17xKl0-0004dQ-00; Fri, 04 Oct 2002 02:12:10 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id BB99A1966C; Fri, 4 Oct 2002 02:09:24 -0300 (BRT) Date: Fri, 4 Oct 2002 02:09:23 -0300 From: Arnaldo Carvalho de Melo To: YOSHIFUJI Hideaki Cc: davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups Message-ID: <20021004050923.GA2728@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , YOSHIFUJI Hideaki , davem@redhat.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org References: <20021004.011315.05129566.yoshfuji@linux-ipv6.org> <20021003.103617.04446177.davem@redhat.com> <20021004.073642.125593159.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021004.073642.125593159.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Fri, Oct 04, 2002 at 07:36:42AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ escreveu: > In article <20021003.103617.04446177.davem@redhat.com> (at Thu, 03 Oct 2002 10:36:17 -0700 (PDT)), "David S. Miller" says: > > > - addr.s6_addr[15] = 1; > > + addr.s6_addr32[3] = __constant_htonl(0x00000001); > > > > Do not use __constant_htonl() in runtime code, use htonl(). > > Arnaldo de Melo told you this the other day for another one > > of your patches, so you must fix this kind of stuff up before > > I'll apply any of your patches which have this problem. > > I saw many __constant_{hton,ntoh}{s,l}()s, so fixed. > > 1. use s6_addrXX instead of in6_u.s6_addrXX. > 2. avoid using magic number. > 3. use 32bit constants. > --> 4. avoid __constant_{hton,ntoh}{l,s}() in runtime code. Thank you, some still were left, but that is not a problem, we can go on fixing it, as long as we don't introduce new instances, its OK. > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 addrconf.c > --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/addrconf.c 2002/10/03 22:16:13 > @@ -172,7 +172,7 @@ > > if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { > if (addr->s6_addr32[2] == 0) { > - if (addr->in6_u.u6_addr32[3] == 0) > + if (addr->s6_addr32[3] == 0) > return IPV6_ADDR_ANY; > > if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) ^^^^^^^^^^^ ^^^^^^^^^^^ not needed as well. > Index: net/ipv6/icmp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.12.1 > diff -u -r1.1.1.1 -r1.1.1.1.12.1 > --- net/ipv6/icmp.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/icmp.c 2002/09/12 09:41:58 1.1.1.1.12.1 > @@ -198,7 +198,7 @@ > u8 type; > if (skb_copy_bits(skb, ptr+offsetof(struct icmp6hdr, icmp6_type), > &type, 1) > - || !(type & 0x80)) > + || !(type & ICMPV6_INFOMSG_MASK)) nice, no magic numbers. > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/netfilter/ip6_queue.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.12.2 > diff -u -r1.1.1.1 -r1.1.1.1.12.2 > --- net/ipv6/netfilter/ip6_queue.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/netfilter/ip6_queue.c 2002/09/19 03:57:51 1.1.1.1.12.2 > @@ -306,14 +306,8 @@ > */ > if (e->info->hook == NF_IP_LOCAL_OUT) { > struct ipv6hdr *iph = e->skb->nh.ipv6h; > - if (!( iph->daddr.in6_u.u6_addr32[0] == e->rt_info.daddr.in6_u.u6_addr32[0] > - && iph->daddr.in6_u.u6_addr32[1] == e->rt_info.daddr.in6_u.u6_addr32[1] > - && iph->daddr.in6_u.u6_addr32[2] == e->rt_info.daddr.in6_u.u6_addr32[2] > - && iph->daddr.in6_u.u6_addr32[3] == e->rt_info.daddr.in6_u.u6_addr32[3] > - && iph->saddr.in6_u.u6_addr32[0] == e->rt_info.saddr.in6_u.u6_addr32[0] > - && iph->saddr.in6_u.u6_addr32[1] == e->rt_info.saddr.in6_u.u6_addr32[1] > - && iph->saddr.in6_u.u6_addr32[2] == e->rt_info.saddr.in6_u.u6_addr32[2] > - && iph->saddr.in6_u.u6_addr32[3] == e->rt_info.saddr.in6_u.u6_addr32[3])) > + if (ipv6_addr_cmp(&iph->daddr, &e->rt_info.daddr) || > + ipv6_addr_cmp(&iph->saddr, &e->rt_info.saddr)) Cool, thank you. - Arnaldo From rtos@vsnl.net Thu Oct 3 23:04:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 23:04:39 -0700 (PDT) Received: from smtp02.vsnl.net (smtp02.vsnl.net [203.197.12.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9464WtG007335 for ; Thu, 3 Oct 2002 23:04:34 -0700 Message-Id: <200210040604.g9464WtG007335@oss.sgi.com> Received: from JHELUM ([203.197.12.8]) by smtp02.vsnl.net (Netscape Messaging Server 4.15) with SMTP id H3G0VE00.MMO for ; Fri, 4 Oct 2002 11:34:26 +0530 Received: from ([203.197.191.165]) by smtp02.vsnl.net (InterScan E-Mail VirusWall Unix); Fri, 04 Oct 2002 11:34:26 +0530 (IST) Date: Fri, 04 Oct 2002 11:38:00 +0530 From: "Jeff" To: "Dear Sir/Madam" Subject: MPEG4 over DSP Solutions MIME-Version: 1.0 Content-type: text/plain X-Mailer: FletMail 1.103 X-archive-position: 517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rtos@vsnl.net Precedence: bulk X-list: netdev MPEG4 over DSP Solutions for your organization Hello, I am Jeff, Executive-Business Development for Real Time Embedded Systems and Digital Signal Processing solutions,India. We specialize in Real Time Embedded Systems and Digital Signal Processing. We provide software solutions in Digital Audio and Video to Consumer Electronics and Telecom segments.We have designed and developed several software Intellectual Properties on MPEG 1, 2, 4(Compression standard for Audio and Video), which are available for licensing. In order to provide an end-to-end solution in Audio and Video streaming, we have developed SIP and RTP stack which could be integrated along with the Codecs to realize complete Multi Media Messaging System. Our products and services will find immediate application with: OEM's, Semiconductor companies, Cellular phones, PDA's, Internet Appliances, PVR's, Audio/Video conferencing equipments, surveillance equipments, digital head end equipment manufacturers, Audio/Video Broadcasters, Post production companies, HDTV's and interactive televisions, Video Kiosks etc. Our offerings include: Software Products * MPEG4 Video Decoder ( Simple Profile) * MPEG4 Video Encoder * MPEG2 Video Decoder * MP3 Decoder * SIP Stack * RTP Stack * ISDN Stack Services * Porting Audio/Video and speech codecs to DSPs -Digital Video: MPEG4, MPEG2, JPEG, H.26X -Digital Audio: MP3, AAC * Specifying, implementing and testing DSP applications * Development of DSP-based software solutions * Building reference designs for Security surveillance, Consumer Electronics and Telecom segments I would be glad to discuss any business opportunity with you, which could be of mutual benefit to us. Looking forward to hear from you Thanking You Best Regards, Jeff. S Executive-Business Development San Francisco ... New Jersey ... Bangalore ---------------------------------------------------- If you don't want to recive any more mails more from us, mail us back as "Unsubscribe Me" in the subject line From pekkas@netcore.fi Thu Oct 3 23:32:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Oct 2002 23:32:52 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g946WjtG007914 for ; Thu, 3 Oct 2002 23:32:46 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g946WXJ16455; Fri, 4 Oct 2002 09:32:36 +0300 Date: Fri, 4 Oct 2002 09:32:33 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: netdev@oss.sgi.com, Subject: Re: [PATCH] IPv6: Improvement of Source Address Selection In-Reply-To: <20021004.015045.96199793.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 518 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 There seems to be __constant_htonl there too but this is just a nit, and shouldn't a showstopper in the review. A few comments, mainly on the spec perspective below. Are IPv4 addresses represented as mapped addresses (as they should by the spec at least)? There seem to be some points at section 4 of the draft (e.g. for multicast destinations, MUST only pick addresses on the outgoing interface) that may be missing? > +#ifndef IPV6_ADDR_MC_SCOPE > +#define IPV6_ADDR_MC_SCOPE(a) \ > + ((a)->s6_addr[1] & 0x0f) /* XXX nonstandard */ > +#define __IPV6_ADDR_SCOPE_RESERVED -2 > +#define __IPV6_ADDR_SCOPE_ANY -1 > +#define IPV6_ADDR_SCOPE_NODELOCAL 0x01 > +#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 > +#define IPV6_ADDR_SCOPE_SITELOCAL 0x05 > +#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 > +#define IPV6_ADDR_SCOPE_GLOBAL 0x0e > +#endif Aren't these definitions header file material, perhaps (I'd guess they might be useful in other .c files too). > +int ipv6_addrselect_scope(const struct in6_addr *addr) > +{ > + u32 st; > + > + st = addr->s6_addr32[0]; > + > + if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && > + (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) > + return IPV6_ADDR_SCOPE_GLOBAL; > + > + if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) > + return IPV6_ADDR_MC_SCOPE(addr); > + > + if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) > + return IPV6_ADDR_SCOPE_LINKLOCAL; > + > + if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) > + return IPV6_ADDR_SCOPE_SITELOCAL; Something similar to this is done in addrconf.c:ipv6_addr_type, could there be more reuse? > + if ((st | addr->s6_addr32[1]) == 0) { > + if (addr->s6_addr32[2] == 0) { > + if (addr->s6_addr32[3] == 0) > + return __IPV6_ADDR_SCOPE_ANY; > + > + if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) > + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.4 */ > + > + return IPV6_ADDR_SCOPE_GLOBAL; /* section 2.3 */ > + } You're referring to sections 3.4 and 3.3, I think (similar in other comments) > + if (addr->s6_addr32[2] == __constant_htonl(0x0000FFFF)) { > + if (addr->s6_addr32[3] == __constant_htonl(0xA9FF0000)) > + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */ Shouldn't that be 0xA9FE0000 if you mean IPv4 zeroconf 169.254.0.0/16 ? (that could be spelt out in a comment.) > + if (addr->s6_addr32[3] == __constant_htonl(0xAC000000)) { > + if (addr->s6_addr32[3] == __constant_htonl(0xAC100000)) > + return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */ 172.16.00 -- 172.31.255.255, not just 172.16.*.* > + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */ > + } I don't understand this, this was possibly supposed to be the case for 127.0.0.0/8 which should be treated as link-local? -- 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 Antigen@hdi.tvcabo.sgi.com Fri Oct 4 02:35:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Oct 2002 02:35:31 -0700 (PDT) Received: from smtp.netcabo.pt (smtp.netcabo.pt [212.113.174.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g949ZTtG001629 for ; Fri, 4 Oct 2002 02:35:29 -0700 Received: from mail pickup service by smtp.netcabo.pt with Microsoft SMTPSVC; Fri, 4 Oct 2002 10:30:57 +0100 From: Antigen@oss.sgi.com To: netdev@oss.sgi.com Subject: Antigen found VIRUS= Exploit.IFrame.FileDownload (Kaspersky,CA(Vet)) virus Message-ID: X-OriginalArrivalTime: 04 Oct 2002 09:30:57.0343 (UTC) FILETIME=[BE5F34F0:01C26B88] Date: 4 Oct 2002 10:30:57 +0100 X-archive-position: 519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Antigen@oss.sgi.com Precedence: bulk X-list: netdev Antigen for Exchange found Unknown infected with VIRUS= Exploit.IFrame.FileDownload (Kaspersky,CA(Vet)) virus. The file is currently Removed. The message, "Person obsessed with stretching", was sent from netdev From jmorris@intercode.com.au Fri Oct 4 08:06:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Oct 2002 08:06:25 -0700 (PDT) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94F6JtG023343 for ; Fri, 4 Oct 2002 08:06:21 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id BAA21287; Sat, 5 Oct 2002 01:06:12 +1000 Date: Sat, 5 Oct 2002 01:06:12 +1000 (EST) From: James Morris To: Martin Pool cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 520 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 Martin, I'm not able to reproduce the bug exactly as described. What kind of network connection were you using between the boxes, and what was the kernel version at the server end? (I've been testing between two boxes on a 10Mbps lan, with 2.2.22 at the client side and both 2.2.20 and 2.4.19 kernels at the server side). I'm seeing what looks like some quite buggy behaviour (which needs further analysis), but no long term FIN_WAIT1 states. - James -- James Morris From mbp@sourcefrog.net Fri Oct 4 16:25:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Oct 2002 16:26:02 -0700 (PDT) Received: from wistful.dyndns.org (CPE-203-51-31-169.nsw.bigpond.net.au [203.51.31.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g94NPttG012146 for ; Fri, 4 Oct 2002 16:25:56 -0700 Received: from mbp by wistful.dyndns.org with local (Exim 3.35 #1 (Debian)) id 17xbqm-0005zU-00; Sat, 05 Oct 2002 09:27:16 +1000 Date: Sat, 5 Oct 2002 09:27:16 +1000 From: Martin Pool To: James Morris Cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Message-ID: <20021004232715.GC3030@sourcefrog.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B X-archive-position: 521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mbp@samba.org Precedence: bulk X-list: netdev On 5 Oct 2002, James Morris wrote: > Martin, > > I'm not able to reproduce the bug exactly as described. What kind of > network connection were you using between the boxes, and what was the > kernel version at the server end? I was using VMware over 100Mbps to a 2.4.19 server. I am pretty sure it could also be reproduced over localhost TCP just in 2.2.21 inside VMware. I don't remember the exact hardware; I can let you know later. It seems to not happen every time, but at least one time in three. -- Martin From Antigen@hdi.tvcabo.sgi.com Fri Oct 4 17:14:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Oct 2002 17:14:18 -0700 (PDT) Received: from smtp.netcabo.pt (smtp.netcabo.pt [212.113.174.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g950EEtG016489 for ; Fri, 4 Oct 2002 17:14:14 -0700 Received: from mail pickup service by smtp.netcabo.pt with Microsoft SMTPSVC; Sat, 5 Oct 2002 01:11:49 +0100 From: Antigen@oss.sgi.com To: netdev@oss.sgi.com Subject: Antigen found VIRUS= Exploit.IFrame.FileDownload (Kaspersky) virus Message-ID: X-OriginalArrivalTime: 05 Oct 2002 00:11:49.0630 (UTC) FILETIME=[CCCA31E0:01C26C03] Date: 5 Oct 2002 01:11:49 +0100 X-archive-position: 522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Antigen@oss.sgi.com Precedence: bulk X-list: netdev Antigen for Exchange found Unknown infected with VIRUS= Exploit.IFrame.FileDownload (Kaspersky) virus. The file is currently Removed. The message, "Congratulations", was sent from netdev From davem@redhat.com Fri Oct 4 17:51:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Oct 2002 17:52:04 -0700 (PDT) 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 g950pwtG017086 for ; Fri, 4 Oct 2002 17:51:59 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA15241; Fri, 4 Oct 2002 17:44:23 -0700 Date: Fri, 04 Oct 2002 17:44:22 -0700 (PDT) Message-Id: <20021004.174422.88502153.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Miscellaneous clean-ups From: "David S. Miller" In-Reply-To: <20021004.081525.51826759.yoshfuji@linux-ipv6.org> References: <20021004.073925.101556969.yoshfuji@linux-ipv6.org> <20021004.075416.20775355.yoshfuji@linux-ipv6.org> <20021004.081525.51826759.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: 523 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 / 吉藤英明 Date: Fri, 04 Oct 2002 08:15:25 +0900 (JST) so sorry... it must be a bad day for me today and i should not do anything today... removed duplicate chunks. confirmed to be applied with linux-2.4.19. Patch applied, thanks. From info@vertebrae.co.za Fri Oct 4 21:16:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 04 Oct 2002 21:16:16 -0700 (PDT) Received: from mail.avocadosa.co.za ([196.41.208.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g954FHtG021541; Fri, 4 Oct 2002 21:15:23 -0700 Received: from jan (jan [10.0.0.204]) by mail.avocadosa.co.za (8.11.6/8.11.6) with ESMTP id g94DiW702514; Fri, 4 Oct 2002 15:44:35 +0200 Message-Id: <200210041344.g94DiW702514@mail.avocadosa.co.za> From: info@vertebrae.co.za Subject: Vertebrae InterComms Date: Fri, 4 Oct 2002 17:56:38 +0200 X-Priority: 3 X-Library: Indy 9.0.3-B Content-Type: multipart/related; boundary="----=_NextPart_000_0010_01C268B3.2EF184D0"; type="text/html" X-Mailer: InterComms X-archive-position: 524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: info@vertebrae.co.za Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: file://D:\InternetDev\Vertebrae\InterComms\TMPdpbc939gel.htm Vertebrae InterComms ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/Images/InterComms-Mailshot---Top.gif R0lGODlhVwJ3APcAAKu7xNPX2Imcpqm2vOTk5GyFkejt8dDQ0MHJzlt4hX2SnZWmrq25vsnJyWeC jrrBxcTExISZo8bO0o2gqd3h48jN0OTo6pmqsdbY2IueqICVoGF9itbb3e7w89zl6nGJlc7OzszX 3HaNmJ2ttMrR1MXT3OTm6NHV1rK6vvP2+L/IzbTFzZCiqqKxuL3Fydre4M3Q0aCutOrs7dnc3oaa pMPKzaKwtrXAxniOmeHk5nmQmrW9wZKkrfL09bnDyLK+xaW0usHGyKW1vMvQ08vLy3qRnIGUnsnM zZGjrKWyuH6Uns3S1bC8wrjCyHSMl8XMz9jb3MXIyeDj5NLZ3cPM0ejq652qsYKYovn6+9TW1pao sJemrpqoruTm53SKltDT1M7U19bb3rS/xOHi4tTV1tHX2r3HzPb4+K+6v9ja2+nr7J2ss9DS08HH ytze38jLzKmyt9fd4Ozu7/Dy82+IlJWkq9fZ2szO0MHLz8fQ1NHR0ejp6nyQm9/h4pmqs3+VoG+H k/L09JustJWnsIebpZaorvX296CwuPT19uvt7rrGy5OiqnKLlre/wvr7/HePmlRygUV0ltTU1ODg 4Onp6dfX193d3fv7++zs7Nra2vLy8uPj4+bm5vX19erq6uHh4dnZ2ejo6P39/e/v79bW1uvr69PT 09XV1aO3wvHx8d7e3tvb2/j4+O3t7efn5/n5+dLS0vDw8OLi4vPz8/z8/PT09NjY2Nzc3Pr6+vf3 99/f3+7u7qK6y/b29nSXsNDc5VF9nbrJ0bnL1/Dw8WiOqlyFo9Hb4Yuovq3C0err69rb3Nra25ex xOXl5cDO1X+gt/39/q/Aytjf5Ojp6dTV1dLT0+7v7/7+/uLj49jZ2ebm5+zt7ezs7fz8/ebn6N7f 4J+vt9fY2dXX2PT09dzd3fLz8/Ly89/g4fr6++fo6dvd3tPU1fHx8penr/j5+vv8/Onq683Nzc/X 26Grr9XW1+Dh4Zqrstvc3fz9/fT19eLi4/b298fP08vT15SkrP///yH5BAEAAP8ALAAAAABXAncA AAj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0KVAPvzwQTPHrVwqnWLNq3cp1pDBeYMMK k8rTVyRfBH9FivSrq9u3cOPGNbu27tpiJXaaRTtQLVu5H4X54gu4sOHDG80CGzzY7jGde9OubYs4 I6+1lTNr3pwwMkFhwNbmxelZoF/KnCdejpS6tWvDpfuuJWwz9unXEVfj3s07a+yBxTCbBiswxVde ZE0/C31W2EGwqAcaAGvA4K/la58JPiv57z8P1BGC/x2t8BdxA8yCR3oWXSB0geB5ISso7FldX/MN pkBGNxKxY+R9Zt9s+aVFXAq8ELMWMc5JxwtdYRHX1zHqLYZMdQWF1duGHLL0m0B0DaQbL8xFwstA x9hVFzFXEbTWiQXdRtBqKs7WHWUGrPWYQcKs1aBCqyFTYyQ/CvSiB/2xVpyCNbJIkAclqgjjkkM6 KaKPUa7FjGxDKvlPil0aVFeHZJY50of/BAfMlWdJKRAzCwrzSwkD0vbPi9ZN9tldyFTFn41cogZm iwQpWExDNALDTFUkroWhkf5lSWUxwlw1HaD/pBAaMaMZZ9+UKRha6T+XcsdmJMAA+AsyzJE1HYQR uv/3IoYepOflQGOaqeuuGX3o147/0OhLp9XluF5BQhLpool5epfppoSCaKppelIbSYHw4cnQasxE 64GOy6LKC62yAhPtP8mS1WMkjw7kAXmXmYvsWsmt9ky0fk0ZrHAFBQfsjGLyy+vABDv02y/MoRbk QXBGcu4/ChKzrL7WopZsu9LSJqNAwR1K0KCICjyQfWvi6h/GAoVW5EChwbjawwWpfFDLbM487b63 mrxlQ1W1V/DPQA9kVjFhMcOksjUfhKZuJlP8z8ZmSWyQbdUKtC5qmkbyL5AiC3Rx0wf5BbNn6x4D s7VjT8t0QbGtTZCaPgct99yddQnMym5PHHbV2t7/yHIkO7N988bPaj3QusktlHfFYBtEY5empqDe WcwIg/HjXRK2+D9td41uXcU8w0vcdJcetGKM+VL5w5vfyWyzqPUdaOOCa1z1m44KpKCdXOfMOKRO 4wz5tAYkeRe8w2O6eee+e52l1mebLr2uaDruuevBbyz779grPfjtpOL5LdIhN6/96xlej5AHyDxz dCSjtW5988wnlEIJzPhSotTT989r9elrXpoMx6PcAQ92fwscQajmLKFF4lAp8phDNpcsQm3PavSa yH42hcFIJC4hy7uZ/AqCJNH474RmAuCMrmcfCX4MVXqLUdWi5j3bNVAgJcAS+srnPf51zyDGCp5D /xomkCDycGoiVJ9+LojCJr5GhUkrIPmKCC7g+McgybJYBqeyO78ZRE1rid5zupbDa8UQiR48yLtw +EHclYxzWyQh8uh3s3Q57iApWAu2ODcYJ/pRM1CUlQAHCAzyeIBJ7QLTjzwwIGcZixiPEoZ6bBg3 Gm1tWzrC0WqsdEA1MocZrqrP6y5zjMQhDHDu+mQoPxXFBd5sfJDMVIMeOKripAgYGMvVH3dZmEDi LCFQuosvjrYyYz3QF+phUnSS5R/9oSo0lMRjXdqoOMgB44NMhM/z6uKyuiwGmQvy1jb7FkI7GU9J diFGY3wUsEHy8p2+uRkIlVhCu+DlICWIEl4IJ/+82ZQwmgfpYm5eNDnoBUyIxbGVXbTTov2874HB S4FC68LQVjrQTikA01pK9otjZOkZ1NQlPEdqJva9x37HCRBCDPAVZFCzIeNb2RENUJWM0DQq5akK yoBYlZdqUKc8rSlJh0pUktxSNUosqlKXGjQjSmSETI2qVM0Epp1i0p1TzapWX2OsS04wqVsNq1gP Ex+fLsQ8CB2rWtfK1ra69a1wjatc5+oWR1iACi1YACGKoAAF/CEDWmBAP6rQDboaNidUmIAAFsvY xjq2sSOQAy3WigUqaEEETlBAC4AwADPgQQU/aAE4eFAERjxCC3iYw2QPy1qYfEALTWCCbAFA29r/ 2ra2st0APzrBikuIYquGwIMCHEAIJrwgHa0ohScoEQpXODcUoegDCQZAAwc4AQ0mwMVqW8vdk9CC DmEYRSkowYnymve86CVAAVzQCk3k4hIvsQA4/EDfC9hjEIqgxW8rIw9AOGAAUrBGKULRjE3IYhKT 0IUqFqwKXUziE7LABhR+wIgNsCAHr4BvdzcsElx8gAScmIQlVrGKW1jixChO8YizUIBGbMIT7tUw S/zwhx+ggQE4bsEj1MAK7RrmDH7YwAAosAtKEEDEq8iELSpBilOcQhKSOAUpKlEJUGTiFqqwQxM0 4ABBWKC3HA4zR2iRCzo8YRWS0MMBDgCLNrv5/81t1sMb/luJSZRiFrhoiShYwABN7GK8lGiGAF4Q i068Yrtw6QAN6ECCUVBiE6rIBCkkYQpTRJkUU6Yyk58MZShXIhNpGMAH6IAHQyNazKiWyCVqQYc2 SAIERCACCGBR6VrbutIHiIID4ACCTDRjFKxoySWQcAgjf0IXloDCFQIQilF0Ahf7fUsiClAEb2CC E7oAxSlgoQdLf9oSqkCwuBV8i0xU4hSmoLUkKkGPC4hgD7MAc6rnDZFLaAIQCNADCA6gB1KsQsUA t8UBdh2PSmyiFb1oCSsmEINJ2OLJsDiABu6gClfEIhen3ooMnLAAb3hiE6sgRbpNQYpMWOITm//g RCgowfKWu4ITmxCxuSXRZkm4oAjfKIUmWJFxevvcILhIBR0YEIQHBOENd0gDejmBjQA4PQBLqMGu iSAJO3eCJbToxATsYQs1rzkeSnhDJWSBiVrImCvu8Ks1KDEJUNCc5JnQxSZc0Ycp5MEHeO/HC3Iw ir5jwhOuOPItbJFmFOiAHpsoe55/zviDvCIWAtiAAybvgA0IwNqt6HssyiB5yld+B0QwhS48cfWV rHoCF5AEv6HMBg28gRSToIQmXvGWBew4FA5PtyRAoQoCeAMPLADEBj6gARr84QOTp8ENcqAJTcSi FZ7ghCxuQYod4EAPq+DEKDDe+O4P5PHqcAH/ClCwAxfEQAHpGIUmesEKVvRDAWUgAT9q8AAXwLrq pSi9SuydgQuY4gCSYAugkAUacASkoAuhkArB1hV5kAAvwHaVkG6nsAqyQAkIoAQOwAM+MAVSMA2l kA7fcAIuAA6PUAAsIA+1UAuaMArXpgoPoAMHMHaY0Aln530/hwuaEAqWoG96IAmNoABjoHO5gAuX IA8TUGTNYAmVoG/xQAqfMIMswX/+pwe2EG7qcAV3UAkIGAsLuBUd8AEM4Am5BwukYAm+BwCQkAFh 8GeuUGCy8IZvuAljIAZKkADgIAWd0Am1MAqc4AI60G+TAGM1aIP0dgmzQAm6AAsgsIgDwAcY//AJ MJYL7icAnGAJmfBq8RAPIGALm7ALuRCFmtB/UGYJzeAK2BABX5AJsceFXXEIOgAPm3CJsFAJlsAJ 8BABDtBogSZzoAAKtvCLvXhlutAGyKcIs6CHrVADRVANByh7i0eIP5d1rbAJlXAARNAAcIADIGBw mDALtUAChGAJ/3eNDQACenALCdiFKSGFUzYJoVAKzUADJ7AKn0AJrLgVauAAEtAMaEZytbgHPABe 16YLkkZz6gZltRZllUAGMZAAgpAOfvYECkAPdUYJqUB70PhzosAKmiCGknYA2fgGomePmpAHNAAK B7CIIGAKtlCLu0CDFXEN0AANFMGOdRYKnv8Qj/NYj/eYETIJDddAEy0QAemgCxF4CrfACbugBQ7w Ah8XctwGC+uWCSWWZLYwaW1Gcg+wAUogBZ5QAwogDqAQexf5EEBJkynxkxYxkygxk2g5EWqZkR9x CbmgCaXACZ+QCQygA0egB5bQbKPADzRQjT1YCb0XCrtQC68QbQ6BBVPAACygAEVQBFewAEwgBT2H EPaGeu34jl1ACGlwCzypjhMhA3gADhOgBJOpBBkwAipgAYypEmdQAGawCW4nCZmQeGWQAP3gCXmZ ZrBwCqBgCZOwCc1wnJtwbIO3bd32BjiAA3YgkVlgC2SJkQhhCGAwAAtwBXxVBAIgCE2QA7H/yRHv EAcDEJmTeQVacAMWkJkEgQVhMABI8AeT+Qc8MABx4FsecQYhIAQZMJlFQAOCoAIdMJ4GgQj9AAQT IJmUuQA/YALuCRFy0A8AcAiHAA4YCgSKIA0dQG+icAmsMAssuAk7wAezZgmu0Aq7IAGDSYaq2Gya YGoDYQhNIAQ2KgRAAARMUKACUQVCQAcFIAAjoAhUgAc/cAFX4AB/YAYZZqACMQU4agMF0A5RhoCe 0AU4wAJ10A4XMAKblaNg2g9OShA98ANK8AFXAA6dVaSKIARaoASAoAQ3gAj6yRDScKM2mqNTEJv4 QAFmwABAYKMDsIGf+A+iIAGM0AeWMGnU/+kJezB0vul2hWkJc+cJmLALo7ALyUVesmAJhKcHehAP CsAIAuAEwakLFmmdBTEFC/ABjKAFI+ADVEAFKjAAWnAFBaAATCAHddoQcYCnOCoEeyoQiAAAIgAI SKChRcoEg6AEBTABcZBhB2EAQMAIH8ADh0CkeOADIzABBfAIN9BbY0oQCYqnQMAAibBfanAIdEAH E9ACeECrDDAIJXgBe+BjBiENWgAIjDABh2AGRfoDt+oAGpAHTSoRFgAACuAERXABF9ACEGsPF5AB TvABf9AC8nAG42pYtIALrNAJmOADyygJKKqiLKptFCh7rHCwAyEPGzABLDABMssCG0AFvf8QCD7g AB/QAmuICczlXKYoAQKQAFogB+JqEO6gA0rAAxkgADtwAKZQcaUADy1AA1a7WBkgszKLBBnwCInQ W5nZD4xQAIcQBsmwCz77s84lBU/AAw5QBGVwtAoxARmwAEiABCzAA1egALUAtj2AB7gqAleABDzA AtxZABeQC6+QCwLQArEoCWXoCqPwAw4Ai7KIm5OQoqlQC+zXfrnQCc6HCa4wfRGoB0RgBDjABfz2 l2VZEB0wABtwBSrAd3+ntkHbDg7gBXkwhBEqEKIwAYTAA1qLBFfwB+PACvLACP9FASy4XECLDWag ABtgBjIqEO9gBg7ACD/AvLXbXK4QCkv/wAMbsAA81qsHIQdOALPDywhA0Au5gAcOIAJMwL22+w0M MLYk0AuHNhA9wAQb8Ac+QL/eG3guQAgJMADmIG8N0QMAYF1CUAZdgLbKtVyUkA4c8AQXUAQOoASK kAjmu2G0UAsqoABUhoAqKpirAAr12LoGQQU0EAvWgAnTkA7pIAAuQAE6sAE3YG2hQADHpgopFm4I 4AAK0ArVOxCIIAL9gAmykA2KCAuqEAqYgAmhQA6QO5yy8L3QFQozoAAUUGj7SxC5IL5MUAWjEH0E cGAKdmIN9mABgAQH3LeDOBC/SwF+Nl6h8AQikAyp0AnwO3QvsA3cAGjNBQYiwA2aIAUb/0ACqnBu uYkJMkAHTMCPNDeBiRdjsfmhr9ALmnBtbZdmRBAFDUAEB/CXmvCMAkEBBUAHYBALVJzGCbZg4BZu k2AHa5AAfsAOCowQ6KCGmrCpefwH03ABdpgDrcCpsczGuvANTJAAQIDJcvAHG+AD23DMzaDGstzG Q0CwMxjGB5EDhGANruwJ0xAKR/qZCcAEe/DKnzAJQKzMUMADkOACmEwBTuAAeIC2PdzO73xiDuYC G4AEfQxtdkoHjNAPMnDMnEAABvYJDv3QsmBgJ3AIwucD+4CvGyYKnTDCGHCTJ0wD5SYLgngQtAC4 nnBkqnALt0ADAlAAEXACC/0JlgAK5//WaZ02ZRVABxlACfGGaIHwCHhAAJmgiKEXeypKCapAaZCb CQwGxDCgAxjQbM9GEB2gBDgQXkY2CeW2ZE3WaVL2abcgBhvQArHQCwRtEJcwARyQk8dmCY2AA5ug DhPgAD/gDWcMc+2sC3pdAQqwCZTgAwWQBplwCoYZCrGgCDrgDbogcpKwCgRgxGeNEKKAC72QCh93 C6cQDw2w2aUse2cnDwkgBCZwbTKtZOfGaZdWCbawCi7gAAKQDM82pgvXD1kNxA9ABzhABy6w0LIQ aVeJ2goJCgzgAEzgbP3wsnGwC6EAaaYN3FJmCzCgADTQjTx3EKIAzvDgCjF3YkxgBB//UARDENOW WNM2TdjhgAaQwA/O1gQbcAEUQNrjDdxQRgq2kLPgkJiLqRASMNZ70ArLjWyZkAm++IsEbmUmpwpZ gAYOYAbxNseGpdEc7dG7IJghPdJAhwBXkG00t2YaAAmLwAaqzWSmAKrdZtMjrgewcAQHrHPV/Q+0 MAwi4AKZYI2jfApkFwuxIIan4HU92Gmm0AY4QHGGzX3/gAg6QAijjW0F6dWYhmlPVmmQ6wKQIAbO Ftm+ywoZAAaTMHN6wAAiEARewAhD4FyCZ25N9mQvyHtbwAODjZuXPAE2YJtQlptG7OAGQQuvUAut UImSEA9EEA+mMAkzKGPSIGRFRrqU/2Zpl9bVlEZrp3AEDsACraCYPafRGSABWy5yeoACCaADUaBp kzZyUOZkjS6VSZAAGLDfF/B3m+CpjW5pUtbVWVkDCXADd9biBHEJFBAB9aCENKcHAwAJEZCFXJ1m KD7qUMZtPWgPBTADAxDa4yULqxCBWTnqTw6qpvDsQ1B2+X0Qhf4Dlt3qD+fVmkZljK6QmRABNiCE di5XEK4AHe2OH13hmjDHrGAGGiBwfn6NfBADELDZf75mPbjaszzeaXYAXLABGOAJs5Dfl2ANTvAA pnCNpLwKFlcLs7ALzTDYym5rB+ACIvDpZGd2/3AGNFAEalAKm3ALEehtV9bGCWYJt/8ACiJHa2KQ AEMA2YxJC72QAUNwiWoWD7CbAEYAA6BAYjOXbrTGbW8NC+ugAztAc2WofVXACIzMqIFI8g/xob0w CqGgCw/nb9pH5HLgAEIwCq4A9sA5leDmYMi2Cg834im+ASNA3RlHC7MgADUACv8Ha3BgBFHw7wHf baQACia2xjPHbRHgBQ4ABDCn4TX3bQ329g/HbQPgAHbQjd0+ELjwAhGgDKQQ9EQABxMgyrEWD/xG coY/y+VGCtwGApO3AS5wzUp44lOJZYhfCQcvAArwhFNtEFVg9mi/5QbJ9g4mbimd9ChuBDFQjzvX u2/17vEeCvOeCSJd7wfRCz6gAaf/sIhrdgAP0AAQMP7/rgfCqQqyUIrQtdCTEHL6ZgQTQHYwiQuJ 4ASNYLormQnax1shChCYmk2ydOuWJYS3bEUREeXUJEqaXv0DV0AKpU+ZJJmSVGmVrjFu3JzjRCmU q2ayVGU6BQtWBD6bWnW69M/mv0udBFQARepUSxQJ6kAgAuIALElJK4HKdGuVrQc4YEXxEuWAnkqT PKXC86ieRlKWOKWaeNPsWbSXcmkq1WzTJk67OuGyiUUBi22cVFUypafjrUkEOIWiZBKlSpaw9PiA 5KLUrFeizl5iJ6BGpaSSYDUIAsEzhAYHTmXSBddVqFCcCExaRcpUlARAKtmqdKqv/ymPk+ASpnTY EmYYDmzIpHn2VZwI2TaaMgXrCJHPoA+QIm36JKdNukBJ0gNnw45KlUhx14N7lW5Op1Ovbg3rzYYH BHb1qnmWhQBMejEjrQR4d2HD3CIoMSWsqOSTUmqhCy0GG3TwQQgjlHBCCiu08MILRelEBQUwyCqU Vnbhh4ZbMpHFE03qO6sTHzSQBAQ9TglPEug8iwKESlS5JwAOctgllVRi2aUUTnSpBBY0EqCGgFFy uYQVNZxo5AAQJMlkE7leueTJWYZMjRMwwZwEhkfeOEWVUFJhZQoHyqBkku1MGU0XEgYQQIFHdIgA HH7SwcQTVzb5zZQ3HECDkyZVvP+klp0ysSWTVUDZwYYGPmugSo90kUWwgdrQwRQUvCCCiAMyIQAT TVi4YJLarsSkF1ow/IcWVmoRcpdYOmEl1n9U2OAFV35zabRJ1JGACR6QaAGBOFpppZRAB9WDhQ/S wETByYYRAAHxHgWlEj0q9SyeUyxxYwZ1chhFkyB38aSZvfRAIZ54QDDKL9K+QVcKazRhd5T84JRk CxwyQTQXXm1ihYMrlDvF20oOiMKzS3O8x44Z1AVylFYo2eSWU44IYlQi6sV3Ejc4yDgWIIV8dy9T imDBElfUlOymKQoIwxWYTSHlvADMYGCBBexpQoI+tmkFE0qw+00JLkxZBVFWZLX/+mqss9Z66wk1 5NDDSUAUkUQTUVTxJg1blOQASVZRhSAaGwhtHRdYAGSDDRy4oolheumlllHetOUOB3awJKJXcqni AxyM0CCCHVzRhJVLRDljgAkyz2BzzjMQQAM67pCE5ljKAUSIUmTRyOdVTphggyKAeAIMEn4QwAEd OBhlyCJtGRgQS0KZ/OZLZtlplfNkmSSbU4h4gGI9MpmkGUow2WWUwCvgQxIudBhVD5pHkYGRRiwh pRKaybpalCdzyYUVXHiVwwEVKDGSOfT1QaMAByIAAlkRbCADL4gFwDghsHgUYAHEORsuRrEtpqji E5+YRCbCVRRq1I0RDnBAAQSg/4hA+G0WowgFqw4gtwaQihS3IEE7RMBBvflgGLnoRSdS4QnVFcoF WpnFghTGsGyQAhQSVJ4tQJDCA3xBDBkoAN4KkAEqdKKGmmgFJyxBo4lFITQ/cwES7pY3GihiFn4D XAkrsQNAUOMTmCjOTSYADsEpxRIBWMAG6CCAAaDBDxq427b2sLv8qEIDVtCDLYhzM64lUpGLZCTX vNahD4VoRCU6UYrQIopatKglJnJFYVgliVOggQ4CZMIT+OEDe8DOAr1gRS804QlWZWAChmxFDXfh Ai4sog4FuIDwKCeKHvBhBEIAQguMeUwbjOACaDjF6FwxihtYZBOrQ98THKAEPP/soRQmCRMYkOAA BIwiFq0oISii4AAXyIKN9SmeAIZgiUlwwhNNs8QBKFaqezyBAQxgAhP4YQFMcEAHlZjAFeRmCoik QgobqABLQIGgTiRsfYi0SRMekY5P2AJ/qlDH7RgQhl1gYpvYUIEGNkAClu2CEqqTxAA28AWqJcyB lnEbAShRivz8phIPuIIDBMAEKvBDEfZwQAYSwUob2u8U8UghCEjxBh5cEw1UIIEZbFAABVSBlbmY RSkyOkhTNQmRuWBYGoZIPZESYBXiQYMTNsADMfCDH01AwgbWYI1e5KITo+DELcKlRae6oAg+FYME TqkFn8qAla60Hwzo8IBbjKX/ajYpxwdIMM2k2EIXYHCAAhQhBUz8aZ7qMEM7CqADJlRBEwK5AiEP VIpOULSRs6VtbW37SLCJbZJls+RZMNkizIilFf4SyAkikAABnICbBHjLEu6YjDEyVhUM+IApVBER wPVVDwegQTuY1AktzSEDMgDYPHljEkFlQjy6CMU0CuADK9omLGAowATg4QnsTEIVCLHE2xbgAHWI cxcltAULMhDZUbBCMotyp248gb1WNMOCfrmDDZxQACcoAE+AcEIEWKADSRiBEHKTxCZQFYYCiKM2 q2hGghtpCCf4oBmr2EiOsHGFApShY9ih4CR8vIAE6C4Vo8BhJqqBgxjoIiI+/8SFtmpgiU+EYl22 okQ9XKoAfszTFaohAAkcAI5d1EKvsQiFkWDhMzE4gBEq+NN6CBAAEShBDWJei/3aQYiseKIWKiJr BJSxik9QYhSz2GsooDCBBGQgANx0CwFcAAkm5Opvu+grd2ABAxts4ApL2CZK3lKBDYBjFJ2gYSz6 agQrGJKNvJKHE7Bhvo5wVAT4wUQo3NLjSXxCFgFoxwb+UIZduEIDMcANDyVqW2QnW9mywm0kx0ZJ s10ykxoIblzEPAsVJEAEJOBESnRRIlDYAhRs2MAAUNWJTuyiGcF5QyZarAkyW0IPINDAAqY2alYM gxAUyK8udOHjSehirc0kBf9EnlCA1WDmFKs4hwOQUGtZWOJbP0nKKUhhCxpEIBS4qqIqHuAAGEwi QTVh8BAcPIpUsEVQysi0CG4gBU+UwhPpkMIJGBCDB4DAC/MATSWasQtNNEEB9yAFKVRRMx8qkgqM wMb9wsIJBmwgDm0ROG3CEx5Q1HEGrSggRkARgw9caT68arJloCzlWrQyBzTYgA+2vAmCrCITkKpB AiTQCkJ3IhYe00UaBJCAAXjD1p9QRYnmDoMEIABVtmyGDbYnlliU5R99/nOgc8WKTsjjAwXgR7dl 8e1MgIIpaADwLgg9wlB8whJfcKsPmgZ3S4SeKW3YwBLw3otZYGIT7YgAKZT/bElaoEEQm9gO+pox ABFsw2MrsXp4bPGoW2AA0S3YRATWUGxPzOLYy+Z+972Ptg1BMmySJFslz2aT31J7dIjKqxA2AIRu T+IWmNnuAeyvhzp4QRUo6oQmKHGCAmiESlAnICmFSaARI2AB8AmFWKgFGaABO5i/ZuqIq9MM/pAF SmCBNSAAjbCSTwACEZCCIokTObm68TAFF9iAIXCFVhiFUtiEE/iOyIqFqsEFRjG5TXgwQlutEygC QGAC6vE0XLuF7WgAQBgA0LAFRNEEHxCAW+gIiNA+RqKFDBgEDgSlVdiEb9gACVipVbCNM8sMl9CD AtgCTsAEIXEFXSiUKLgu/01YkLJ7sigbNVyQBgfQgAAIhU1Yif3QAz80BRy4ABPTBHTThF04gUdg hCdwBfboQz+EBc+RhVIgxFSgBBLQgWowlV3IhZugPECjhFjIBSzwAQdggTHghE9QCM2ov6MABDRo BrxDt1TAhBrQtBNwGlBoCVaEBREAglMhtFFwhQsAMQSrmku4ABtglZ/ZBFf4gwF4E5ZgDkk4n/HY iGkEBQbonwKIAdEwtu/7RnBUtmYbv2fjrfP7h/Srtia5gQRoglIgAGm5P8XYrh0ogDdAEH9pBTcQ gQHwPUHThGBcBT1IwHioBBOLhT2ggS/gC5foiOcTj/MhDVc4BzoggU+qBP9diEEJ0I/mkARbsIR/ GxDbMIJ2gIhdIKd7EAEbAAV1iigbbLAczJXEIYECuAI3sDWViJSr2w8QoAqeI4JMkLJUUAQk0AhQ MLHYYqR8+AAVMBJJAAWI+IFHKDLu8JmmiD36GwAHYANOaEGBWAUNWANNzAXJiMOzGzULKMUqSL1M cI0/ZA4/tIIIMJVWSDtWyAERUIA+OKD56ws9ODO/bAQ6IINBXC0w0AEYYMlVswlPtLxcCANIAIIq 0gXf2a6/HMMDEIBFQDBdYYUw2IAJIAAC0AWN8MNHVIwD4AINcDfTS4VSMIMPyESZgBVW4AEmMB9b mARX2AMFcIFP2A7+cBv/XSi8nrDAU3gAIxAAojAFJZPCcHxO6FSkcdSt8os235o2deyFCLgB3QMZ y+yIpiDCF/kAF3C3dRmFMXCCJCiXZ6qFvZKwK1iEeJAErWgFb1BIgrMFwJgggNsUSmgFRXCCT/jC FdoEBngEbZgEjWKdTyiJeeIEWZi/AfiALNiEUmgFTyAAJNgCjIyIS3hJHPSEWOiFVzADSGAATHAF 1StO5mjR7YIOL4gBCIiHWxC0VLg5lmCxTWwkFEsDGnu6LqADBFArzfBIS4AL1aigU9ADHLAB9sIe jBgAPig4PasJs5zDTuiHIiAngflLj1yFgshFF/iAIwieVHASedCBKnAF/4FpyErIBIRoSxj4gPJZ wl2wAyU4Alv4hOyrj8YExV7wARagNGG5CvB0Ct+xAgEouIignAFQAIGQFr94U4PwnQfwgmq4rlhY rScQAaxAEAXpBSQQg9bIQk9IhiJgABpDClDQBQI4jbfjQ80AASJAIVjQilrYvujcVV6lkOkkP2jr LbNIx/ULMwHwASK1P9yAsmYAE0GpBCNggIfYilHogiJIAkm4BVjUlU7ABFmIAH8AAesKBYGIgC+Q EdKwKQChBE+wnk21hwlQ0FOAymZQAjHArGUlgFJYl1mAt0htAwcIArEILVeIARo4hWJ8hRt0sBGN gw1QAUpT0op701Vwiv9wexEcYIAG0ANNTYUWGIC2FAsXWyRaYIAMUNCnDDQJKABsUAXXeErdxATs cZePIQUrKAJD2tf8cAEHuAPSmYgrRbt+uIIE1Si/+MhPaIa3kzcdOIKjnAlcoAAlOKDtKI/+mB5n NZ+MHUA0HAUpuIIoyE0PZUwO8LNPzBVF8AMrIoU/RB9ZaFZUXIVG0IEDuLdcwAUxiIBgYdujQJ+k BZMIvQNACAK6HCcfwIEDyIpG7QQWYAL1Gthd0IIIOBKY3TiWKSCmWQ31OiEUkoQ1SspeDV3RhZBf LUfzkzbgWr/hEgAxuCI/bBtZIFeUSwVKU4U6EABTuIVnGgV4UAJsdRX/migeSiCEBfALNGkLc33T eEIVf/GXWaiFvOqEKwCC3wgLAgADRvgGWEMfRAGvS6CFD31PcSiABzjKdqWEGtCAdbiSWqoVmBTR TsiDIuArVfAdOQEFeNqEZtjft6BMPkCBKhE5luEBNHCUhEo6rsEFARACl0XYZsAEQdAA4kuKTOBT TWClV8A8Qn0AQIABmrkeSggA+GDfXhCFoF2XPFACBe0LD3QFmQWSCFOGIgiCPJuFXJACJSCH0oTZ M5xdStMFBWCm68KeaSCENoDKJSNbsw20QbuBBZgEtsWX2H3hWdyEO3CCsDUxMbsBJXDZ7TIFqHTh 2RWIcPACBsgzjuEH/8T0PeHJhVrgAXAw4OppBS9jAKxgr8l5BVzAhVYCyHcxkgMYFRxhEk4cXUM+ ZPD7GmfbrdO9ztQd2FEgBBQAlxjR1uG62y1hBVMDAg0wBbrkXSUAgqdESslghQe6AFBir3dRSNLo yuDdku+lBfYZBx14gi/MTVe4gQjArKdrkmOjhV7QPQVIAjbeJn4wgmo4SjZy3xBtwDzQAf2osVto UE9oQQjrGFlQgEYwBVUb4AI2R6UUgSagsQ/BhAloAZeFWT3DBUSihVwYhWYIB0ZAAVcBmG8ogDPG 1Q91srOMBQlQgmXYiNEYRBLdknfmhAhoBDZuQApQADtoCSuRxFQo6P8niQVXuIIYyNau5N0JiALp oQT1mbyyrTwbdeJVaI6FOxVNwOScwAQM4IMjyDNNmAUzwAF6+GJXuWBcMOhdwIZHWE80OUk1ZgOj S5NOmAVwiAHRCzRnCQUmgIRFYAMTI8thfZK9Win1khGtkAhE7urRLV1Gts5hxc71w4RWIAQGIAVY CIsWcxJEEoVeaAU0yICBtp7eFWVbkMSkvARNyIALOJ+waQsaOIFpBsXJuqR0EIEAyMUrCYUR2AAN 4APJVgANuAIaoAFCyOzMzrgrMKkYgAUWK4whuIJ1YMkEceP3XRcJ0IFvwIyOGNhUEDNWmG33qUQj 8AGPOBUgAYIBQB7/C52Fc8waUUgHOvCB7TDfdHiENgCL9JG8m6CFbpUFGkgCxT1JTsiAGCjqVMCF V+DnKLseKlCA7Vg4pGTn5+7WCRiAHHmmVHgBPhAHUDKRBHmFhIFrTMDu0TiVXUiGCXiCj6ZBJSbp 6/kBJAAFn7kF+aAPROLrPlAANlBccaKCR6iGAwDjljRvm6CFWvAEPkjrgcUEEiiCL/A9V8iVoFMA IeLTXVApVYADQChFFVCD4OaSVgiUTSCArXASr95xXgXr6hRWtCFrscApGpBW8m4FhEGLV4iFJlwK SWyFu/ZIUF2wvv7rD1nlEzjbw56MMFAAFXs6StAnG7ACK4iBJBiA/376ATVf8x9gAgYAAht4gMTd BHa1AwVIzBMZo4XNwQjHgXtQiqOTye3TZCXwATiFRSAZABuo2FPJVZKlgAIYAszQVkyQgkcIAN8x kVeRLZvAhVQQxkUICxbsGBbYAo1OsO42u+/ehRpQgHCwkig8x3degAEYoo2eAT6gB5gd27MwZVWh DgttBf625bABcJFeYkpYcQJn7JY8Ng1pBg04gdzcuF3AAxFggzumBOBGi17gBj5gghVqBpwK8XXA SAbsvxmwx4cSNBeE4jewAh1wACfgAR+YAjnohqp2pd1ZF7fmcX9/Th8P1nMkVrGIuSIPD4gA8pvg axfIgHBgyXaN8v891TMq92vADgUs1/IGuYQ84AFWyQpXmKdNqAR7gQXNGox1BRAV1QgqGcCbGoMI YAPeOurUHoUawAHl4N4EC+5/wAVNsFc47UoguQF/OIgHjqhFugQUu4OfoBlM6AcFIAefEFnnNgvo xgQGwAFqoHQMXYNFsJLZzDdVB5FWaPVw4N4dRQtWSIUFYIBMUIUzbAVcFwe2riUGeYVUuAB/cPJ2 NecKOA8pm6w/dRYCVy9dKPGqt4le8AYFGAKoBBFMQAARqAZYYN9C7vVRUIC0vpKYC/Es+JBcmQVP 0AEbEFuU2wUOZI5TgIEHuIDBuqYBCIMzkAz24ePZ1hJO/3fdF8f/8MstYAVnR1a/gi+Fg7+SBNHV 4mn40As0TJiGUH4YPnV0vrb4K2+Gwdb4u0cAHjCSK6meFyR5o7CStwE48ifNJW15C630689BQjSe EN2dm1cOTQddBvF5HUCAoG+FoXdCSwCIZpg60fpn8CDChAoXGnxVhg4MSZUmUcKkSIAqUhMpabrE 8B+rUU1EUMu0qVSrUjcESAK1aSCrYQJqWPoUqhWmGgqW2ZoUKtarhbg0LWCQSRUnTJjC8AlnS5er WKyEahqxoBKoTxUxTaiwyueoXAZzcYigbJVWnD+QZMr0yVPHhaySaUCQaZIrpQhEVJNkidOooApZ xVLAgJRJSp5I/xQR1/Nnp1qYBgBio8rVLk2aKOmqZAqWpKNu7LgYkIHOo0NVLtES5foj7NiyZ9Ou bfs27ty6FYrqpEIBhok3d/GjcSuTLLgeE4qq5UNDJb+cPJWigQbUqpedRC2kVctMhlVZK05TAuSU rbe1Cl7SlOGCRp+emtE4gZaSVIasbmTQZcuSQLu00kwmeoAAwgGmVLIggw1KoscBB+iRCSetjJID DVncsglcncwiwBCTcDhKKwjgkA0pf40y1UdDKSBGJgC2kkoqYhQBiiUEYLLebh+xQoIIWUikFSYM sGAJYtpxx9ArsajACD1ZeaIXDaeAIkspteQiE0024aTTMuOlIv9YQu21g8YqfynFVDigUDTmQu1Z VUl6FSXT1S1gifUPWWbdpxYSq5hUyizLJcTKLhHUkAlUmJSCwCNknHIZUAs1aRgpVyrGmGM+xdJL J61MAsgEt+g4SyejcGKJZ3qYkuktunwiywlJMAKICrngUlCPvfr6K7DBCsucb8AJ1wpxxiGnHG/O QScdddZhp+RCvYF3y3iYlDcAeuqx5x58ws1X3335LZTLDQuoAgpUM2pSyieZVHLKKViBci+++FZC ikbIYaJJKl0QoiGHmtTyYYgjYmKivJ6SSdV7oJiKCY1gOMBGdpgUOiyfJGgQTkscTrYAqwDusidD 7T3xwTobKaX/AiF0vjVLL1zWdFNOO4n58EGXzHLmLX+VUgqbblICp0JyLmBLnZjcWUGeoYQ1Vlln pdXKWoKetPFg1ih6VFKPRkoKpTwbhEsqShxWJyWcPhZLLrmo6kMCDLwJ6iiuTJLJKZ+ZIkm/sZLD QAITpJLLJUtyvDjjjTt+W2+/BecTssUdl1xczDkb3V/RXpfxdtV2cm22rijBbXqe8Njee/GFMq59 WpmrUC/pqnIXJaN00ksq88kyySSzyjI88cR/EvwmSWnSSy1VCCCOJQUfDKKInoyyMA7KbIQ0Q0O1 w4ItGceSygwbBLFs5sLmQoIR4oR20mTtWPKUKyvCRsssK5NB/4ouobwsgC2ktDybeSlnYdIK9xDi M6AJjWhNMVoCe1aVdjCNSE+L2tT4VLU/YSJrg+JaQl7htUUhpRSegNT+yiaUtDGgXjZpW2Pc9BNW vEIToVAF4dbwjVZ0IhepogQBdCGe6EjCFH9DzyraQAcBDOQVinscFKMoxWFFzliUS9blmKW553Bu OtX5HLV445sMWKJ0p+uW6r7VOnHRJ3b4YRHtbLeK5BxOHkxgwACEIAQg8LGPfvSjHgfAADTcsQUK EMctZMGRWSCsetczkfbeZDaEDAUIAqgEckoxvi58YAA9ORouONYLj4HsFs0oRfws4ZajTfIgzZHA B8QxqbwsTP8AmbhShwiIMzDtLE4/Q4MlGlg0ScZpgveyIJ70RDU/paWDgfqgoRAiwq8J7YRjU6FC 0Ka2evkEhuKQoVQu0QlMyMIWcNiADoawjR52QhO7oAQnNjEJSwxREkWUxCmi4IAYtKIWr+DVFAMq 0IHOpoqTG47l0BdNgzSHi9D64rQG8kRXjrGMWimF6VDnrX+wLlzyaWO54IiQ3oiBB6rYUCk0wYpB iOACPEACElgg05nSlKYw5QEPFrAAHmQABeJB4PQSZj3sRZKVsGmPD3BAjdSNDxMxTRFgRAqsUTbm FGoq0pHQF8qP9AYPsZSOUqhgS/R1Qpdf0hkCJ7lAYArzgcT/TNosRtCOY9opmVLbU5+sRglAaY1Q C21ILKjJCROikGxRmaQ2Wygcb4KTFaIgDCduIYk3CGADSvBBFeLWzli0whOuaIY8VRmdv7kgATfQ mBMJqtrVqtagx8KiQpvl0M5BFHQTZWhFx4PRM6ZudeByHexCKromZOCkJ1GpIICQCkx4ghKhCAUl oivd6VKXOp7gxDwz8UmDNVJhkNxeKw3SngA44Q4baaoZILIKApyMY50AA0SgqpQm0ECVx/1rQkb3 iC4q5SJtwVxZZ3Kzsx7QqHA9kyVK6MA2vbVMcZ1rti6oTA0yc6/O7CsIKRnYJ8RosNZM4WFXaBhu uoKxnprK/yUk8wlbFLERLKDDB5DAhDDIAFSzSMX1KOEKAkxiFaNlgRNeUoutsrbIRm6ca6+YUMz9 taHPoq20bCs6FZDRjBpNI0d/y0ZyyU6quEVAIU6qo+UBAAnX3cTwNqHmNbO5zWwWIiiwgiVUdXeo 321wMTkhgh3wT2qaaIUb6ICCK0l0WJ2YAiAqUAmkKAUMRchGdvwam07cQAfRucVgJ+MPQQHYrAbs 5YHZOtgFQ1CtD74lMqE24bxy0INbwy8uNtxhwl4zxNlMxYgnUmJONfYfj03FDT3zKjaggQaMKIAO eKCIKcigE+1MxS7mowtQSCIIBXhDM3bRC/weudsJSYEBDP+QAm9ztVgHrZyymCzbJ3sxymEkFpUt SondXtm3a/wol98oOhLQQBkTS8UszHCFeNmCTplYBcITrvCFI1y7/MIkAXjoIep5N3vgvV8tSjEB exh2FJpQVQYmsJEM/6oTHCgADCpxVSnogA2DSh9DOtECJFBbaJjgwQg4nUsBF5CXafUlgtvKYAM7 WK6orquq77pMvfIVmkKRdTULi82EoC3XeDHxDMXbC1Wx6jOS+M837OCDCxTBAQ7gwRR6YeNRUEIW fMuAFVQRilQ4ltywMQAqUGEMgRqgBADIe94BsHe7j9Tcr12yFke6uYe6u9BijLduM4pGe3v0dSDt suhmgIP/L6B0fGD4ADVMoQfQYLItpj896k1fcOy8KW51fqTF8SzGIjGiGn/JTCxC0QYH3MESrkgF kaf6jQL4QL6YIIATHqBV2PRmAgOoedhYAIT/7rxLu0Qr0RX4y2COepjZ79mpI2zXDLK6ma6WdDZl XcIPG7ZSt7b6rmN44p6lihP+kQQsSH+U4y2BCQJwABJIQS/kQi9oAiZsQibAgRG4xEBwG+Hhnd4J VDAEXjAEw9+hQjAQHkVJzuGlW+K50uJBGRg5HrxV2UVJXm+pUeUFF+aJUTqIAAxE2iiMwjToAAqM 3ikwSvHsIA8azyckD350Ai6wwusR1cXBRi4QRwK8gUn8/4smeMIkiEAdrFd7+QoWHEQv7AEgiMEp mJJSlIIAWAHuRBBzWIMO3AAoWFVScNIO3FKn8dz1FRgZctT2CV2p+ZLRiV/Skd8Gmd8zvdrTRQCH rZ/U2RrV4ZpiXR2vzR9DXcLWtd0tREf+mUK9xIisqIATOIEUaEkuPOEnuIATkE0oaEJ42R0WhNu4 BVQwlEAHIIQ05J0HaKCvGZ6SeSDMMVQIttsIhs7jmeC8oeBGdRRwdUEEuNHsJEQv7EIRTJ8i7cIu lMIaKIAetIQuTIcnXCM2ZqM2YiMqZUYn/NMr1ALF2Vnsfd9gxAI2fMB1vIUmzEIrEADh6MEkqI4D zsYZTP8AHQxAN4gTJmhAEkjCeqESJrRDEdCP/XwELXAAI6SBLRgWJkjBBiBAALFjzcAhgYGagwVd 97mVOdJhHqYaBuFVH1rY+ZHc2aifhxWi+x0i/GHdMXJUJ2ICJ3xCGZFCEf0N4GBSNtCBPbTC8vRC 7vmAE5zCKjRDBsnikV2hQjgDKjiDLCYZQtlik+Wi50QUL5agvNHb5Kmg65SCN9DAEAjXuYxCBvjD XQxHKaiA+aTImGmGW74lXL7lLNRCJ7ACa/wDLoijUMFeUc2hAm2GDfzBOshdLNRCLLhCNigAGXHC SuLGGRCCEvxAESxP74xABrwPSmCCGVyMyaBMnDCBBnT/hsssgQN8gcx4As14ms915Fpx39B43xz6 zEciXUguXav9IfpRHUrSGog15kFUXSLG3zcxIkLQwit0QixggiuE1hCdAv6BBgPggBukVC/MAiYM gQhgknYA1EJgQQUagEIYQAUq5T9ggTSsQN5FQwmQ5z90QAWWpzQ4QzCEgEFggTGgJyoAQDBIA3lW YCsiRAf4Xd45gwUkhHtmoAE4w99Fw+DphjFg4FPSYlRm0S36GlXW1rsVHuSdIG8Fo5b5RCl0gRLU gFgOxigAwSOEg5rsAiZ8Aw5swXbZ5SXMKI3WqI0aAgWsRuL8pl46khHKnkJ4RymcwAY8QFHuQi28 yye0/wEkMMAnNGBudMAEiEA6cIASTMP1uEIbMIIepA5O9AEjoEETXqVCvMIVCIEqyExFqEARrAJ6 YImWqCb2xWYdbuTQ0elsOs34iWSFNR0gpp8ggg1vth9iISKJueRUGEAeSIErXQIrtFO0hQJoZZck voEIvMFLzOUonMAjBNCc1eM/TGAJKEQJQGh94mcFBt5//gMEGkA0AF4GpsAFVuAFNmjegedBeADg 7eqoHgQEluquogJ96kapOqUGQiW6UehUzpYuWuVtzeKG/mKHYhnr+ENXJgMhDMBX6JtcxAJpxuBJ CAgn1EACPABFmORHnEEGOMAH5ABrLEmKjSNfHiFs9P9CK2wCH3BBeqRUqjTDKgBBAvhAVD0rbJgA IIhAFzyKArhBM3ACAaSBAzTCRrRCK7gCEHzARlToQfSDA8zALSQJKvFADEgWodWlnMqhqWnka3Ik nrbD0enpHvIp012Y0wHqIKZkrfnm2RiqriHqP7CACDjAD+DCu4rCJeCCD30cc+3YJEQiDPBBEGDa KMxCLPDDI6DaBy6ErqICe2LB38WiQaDnetYnU2agQUDggBqDMdAnUzoDeSaoraICrrbngI6bfead NPgq4LFieQJrKt6G16IC2BIessKWum0Ru1WllPViVgIjtWoCC1QeKgHBFZzlUR6iNhjB82nFLrDd JGT/QAFkgVF6GUPEgRNkwBSIAAloya7gZY9WXF+WokFA1gM4QAUQZjtxBilYQblyRPDFhiP8gANc gBSEgi40gg5MCPDoggJMgEO2AiUQKTABRithASNcgNsRpUBQQAEMQSa8Dyb0QkxY5Kf9XKi5JqkB qUe6rB7WJoXNbEnC2m6y39RREs8qovzNUDdoABVQwQYswB7oiuLQgqMyz8eVgv25AB28gS3Iwr/E whPowE/5rmx8LULoKgDkqqkeBBbk3X9CoDP8rUHcqkKQJwkbRNkmxINm8Nl6MEJ0MCrkLW6EACpE A1IWLuJVqJN1keJm6Ab6olamYJbFgADwC4higgSU/yZSaFvKbMYAsMxlWMgBkgEOeAEMUAK6IoQB MMAGTIAMwAMjPEEp6A4uiEJeyuuPdqSDUcIk4IAtRRxd7gIBZIIptEMCDIA3DBnBIkQYXIHQyqQq SAIKiEADwMIq6IIq2IoeYBomRJssWIEDvIEDk+lBMIEDcECaQlUr3AAjrBhAju4rnCxGap/Kpi9r hh9IrtpI+mlualigEmLOFmpLLuJP5AI6XIEKlAIJFAAjIEAtsAJ3GgQBP+phTkAGUAMpUEQsjIIL aAC2aIUm/O5C0PAKIMQENugEDu5BTKAMQ+BC/N2wMsQJ/0PeFegLn7A3J8Q148bWrirhdgIeWBFC Cf+Asq4bD2MoCWooEDuub/mAAiBz/2BCK2iDCNDzdh6EDExBK6ZYKQTABuyAFy5zZN2BBiQAGkDp QiQCEGyA6u6CK6QBI5hr/WzbGe9lGvvlSNnrJjxAArQBRWhCO0GhZwzABnyAC5jDPzEEFuRBBGyA FlBAKRAAksTDAIhAFBwAo+iCOBRAIwwKixJAOPAByv2eNDNBAkgAAkoERezCFdhDZ6TI771CKJPv atJpKcOmqeWphCnd+94mhsnvK+Nsb8pycLrkAGrADXzCLXxBO2yABpRBL5Rxd7ACFUDCA8yL3M2g IFyAvEWzbKSAC/8DZKPC3/7dClQgZltgBLJq3k3/c3qGgAe48wjLbQujwkKsM2ebtjpvdm1srTZ3 myHEQRiEwRSUAYqKQyX0D7JIAA64wAMEwRP0AwXYM+Pt4rNGzj5Pq28FACPAQJ81MiU8QQLQQBv0 wSgEggU0gQAUwCNkQDkQ4QEugBPQQ3KMD7xUwgFwgQM8wgC8QDnwijtUgQ8gQQEoAAJ0ASVswioc gReggCSoAkeI9euSY+zOxiukgitYwiJ8wBewl7Nx3SnAQhD4gwM4gR/ggQnMwRkgghyEQbowwgeM QBko596cgh4QQVEf9VdMgi60Ax8kMyU44w3BQGUlQR/UgqFIwwQUgBmsik0yYB44gB0gyUSg5tGK /7L5ZqSoreydpjX7pjJblx9J4ia6xlpcD2r9/ub9Cic4dcI4/IEYoDcI6IELrKsSMIEJoMNEWcAI bMAApOks7YI3PEINPDMFy8YEDuuDGutoB+uuDl46JwQW0PCuRoMMjzauBro1b7aiGwRq04Zra6Ag AIICFIEOPMIHZMDf+B6ylEEBZKIIhHoBUMAr7KiFMmsP5/MPN65yf4s2eIEPzJKFwEsjeAFHX4ES FECMUUEYFEEOAMzxEemb18/HrUrfBAESHJsC8EALLMAf0IETsIAZwIO0ZQIsQAAdwEE82AIoD/i8 qm/SjNMnsIEDsAA5cATzvOP3TuMbxIAS0AEdFP+BBhSBCADCIwgAA7yAcm4Cq+CfgaAADhCBHliC LGzCJ1RAkarJ9WwCKOhBXwPCCPgAFdwACziAAoBBgnuGVblCMhSBP2SvSbRCL5gxkp/yWbOsk7/s WvNhn9Lsn+rmldOvIdrvLOdvYZqDEtwgETRAA4AAKbgADwBCAQjAAJiBBKgAE7AAsvnAJnxsn+2C GNBBvAgQqBqEBeSnQbyqOSN6bDT6C3tACExg3sVtone2QqC21z+6bNAwALx2t4kCIPSDHKRDDqhD FqzDZ/ieM5YCFLDBHbBBFgRAAagATOf0Dhe3s05ZctdbQXiHJyxABKihFDO8HrRBGzQBHnBAwob/ gh0UwQygBALrAk1jqhMe4PdSojjAQA0IEgPwAwfsASaEAo/JiynEA7bDARGQwiZoGyt4+0nL7kFA 1i0EwQZsgZBVp+k/iIIoQxqQQBmUwRScwAukQylIKk2mYf59XSU8QPKegi40LI+pNxskxwzeECnA whEMwAREQBGwwCFMASU0Q9eFTJE4ABRk8l/kBy6UvFkDBBpLljiVKhWGTzhQkyilevUPYsR/l2aN aJcJ1CdKmJJNqHBrUqhRuSDm4hBB2SqNrTD9QLIq06ZSsy5JjIgrVoQnmVQV9ITgERlSqlzFemjz H65UChicqjTJFSUSRcQtDBWrViolaA408EpE/88pUBieAPEjoAihBS36TSNgqZKkp57g0RkxCRQo WZ5oIvX7LxoqDwZQRbO5ApW0vxEJo1osEYszVAAiokJlACIWy5htWrYAsTHSYKiMPY4YeXIH06tZ t0Z6iZE8TK42rSJlSg8sSyJHYdpkS4+pU2QcuKA0qtMrUbRq+dAQl6CnUjTQgFq1CVMnUX5FdVKR wVJGSqVcKRlwytYnT7Vo/euOycWGj80wxRrlypIkWJJAqZK1aRJL7tCBDVlCocSVTzIRABA7XBll llQ8UVA/uUAigBNXOGlGFlUyiQsWWA6A4IMBiCBFluxYqUWAISbZxJPeEMBBmacaOmq1S2opZf+S SlBwIAZOkOtFk1JqOyVEuVbRRRYCmiFgk09UWSUuU/arxJJPPqkAhyxsgYqSUAhYxwEBCNolFkwI yKRCW5S5pxkNP7mlElNMqUQXSl6AxAdZ2JyrL1yGEaCGLENhqQYFlhHPIb8oakcgggxCSCGGGn2t oovE48gjkEQi6R+TUFKJEpZcgkmmvpDCSSeefAJKKKKM8kspppwCc6qqQopllmEU4CqeYEGAxU5S MrFEljHOaeZATmShUxJJYsJEkEfUgWvaTtpjzRhUnCmBNJtCKAwLv8r9JzSkzpUo3X82iwixEmzy wLJz241otNJMSwGxFVJwDeCA/xKFlQ9IeNb/FhEPOECSSTxJRZNRmskEFj0OOKIAFHpC7hLmnIOO E+mosw477bjzDjzxyDMPPfXYK2mXMUTwJ6ZSYtEEE1lswc0UUmwBpc4gRIjCFllcCaUZVWBwQoEA Hp4lFk/8RFI4W1axRBVVbgGFFP32s6USELxAAYRKUuxkxRZfjBGTGWu0FEfTCI6FE0tOGSCBJNJJ pRMiMWkGLklyk4QUUDK5BaZKTrHyylWgKuWEDHTI5MtQMMEkFFUe2ACNvWKJWhZQBO/5WEu2phpL TrooYoK6u45pl162E5RQQxFVlNG4I3o00oIOSmihGx3NFCONOP0opJFKOimllVp6qWZVbWJ1/6ee SvkpqKGK0h2iWpt6KqpcreLV1x1wk8QpoPWrehVVJnnfkkwWv1OXUMxI4AkFjSUg9u1YS8EyAEDF vySSAgH6SyIeWAFn7hWRaHjAJt1aQWUuExELWEYxoBFgCBhjGdGE6zEG9Na6BFbCgNGiE3SoQcIO QAQiHMAUtthEK2rRiVRQQhVIAkEUHDAAU+xGE6/Q0cckEZ3pVOc62fGfTbrznfBoZGXnSc96tvWK WLgiCJBAQP0gdMNJ2EJwubHSAR4ggiBIQhdRCcUmMgEDL3xgCJjQRIRK8RYwRusUpKiE4qJFOFBY IkpLKMAOYAGKkqXNRTCSEY1sdCnWXKITrf9goyR2sIEJfEMTfZvFLkIxp7hIwhR9jJad0GcLkBQk BwtIwBUq8KGQoEmSoEhCAgbQjFakYhSUoFCIQjnKK/VkdUXwRo+EA8Sj0K5QnzgUJhK1KI04UiK8 G4jvKBU8aO6OeJvqCPI+tbxROe9U0avJqnJSvVdlT1bcS8pSvocrqoyvVyK4gR6X9AkAUQmU0dLj Hk+Rz9T5IAFieAspSGGJorACYJLxll88IMDCBGM070KXB5ESwBIYwxiIAYBqICJRiIDroYhBxQrW 1cB/5Ms0jbHMSlmqLxO+FFN0QIAkFqYHaQFSjrlgRSfuEyBSYAwOBwAFAUYyxOcUMWRHJJn/Ek+m ggk8cSPpYNkUXzaRWVBiElwoDnY0UYtYUGIT8QPFz0BxiiDgIAqSIMrlsFoJGNBgAwyAR1c10Yo1 ai0TedVrJq42CQKEggNJAAQfYGAKQ6qIRSRY2yha4bZGqnMxr5iFJ74oCRd8wAE/yE4vbIgJZ+nC EjDZK18toYtNFOQF4PhAEVzgSVLkCSuaCIUlSGGDBNiAf7j0BAE8xEd9mlKZYPiABtzgJ1AashXa 6t6gkrlMPODumeqUpvVKMQPgwW14I9BC8TaCiU4lD1SiugepWtGKcKZqnNPLSSut5wk8oHN7tFoK Gm4VvnfuKkIxcIAV3qAKAmzEE5z4RPzA/1YJguaxEsAlAAMcwABO6AKMc6lFellzwQr6JQUgXekK pGEvis5LpCsNBkc7euGISCMwAQwBCU2K0seolKUthemMJYILTdChDSK6kyX+m9NLXOIVPPWEKyZx ih6W7WxDvALIpEMIJJZsiRJp4lM3NQ0NAKFlVIQICn0DighsoBHnQE5nkbaJ/2xCFW8QwRvU6opW 2IcTtzhFNbawARpIIBGz0ESaKMEJKG0C0JvAkCtyUAZwOIAOMRBHJQqJnV6kDQyLbcUTRKCMLwnP NbRgRSpCoYu4gGARCdAAAizQiU5ADRN9flKgCTBoShCABIcoAB0GAI+3xIUUDtNELnqxi/9JzlID UxjFnlvx6k/oQhVYe5Gfm+CACEBpFfoZCiWCeJNhEKICWSoVJiRQBGdi2iYUWQATsOY7DiigUuCO 5izWcAHuYqIUSOCm8kJ1kvHKolTmhR56aZWTGrjqenjAQaziuyqttDMqS7jvVSIUCiA4wAFAeEIX NBEx8hBAFu9Dtip08SICgCEDG2hCKPASrVU0YyRRpjFjDGAAEram5S4HWAdavnKb37w1VmSECCJw hQjQgBACyMAEiI4EoxN9AhkQQAQSwAAiNKwUndCRGTYQgQgEPQMhR4GxoHyyGpQpAkLP+gZ8KOFt /YMVV8zPPBLwATRIoRynxmUrpvECCbT/QAQiYMMpiAKhWviGTaZ4AyE28AEglEENmpj75RjfBX6M ABBVlwAnJsEmPWSCfzqdRQQysAB/LOAC9oiAE2zx2lBcM0e5GEXd6iSJI/gD4hPAQw7KoWf7lPdy 5ZWCBOxRgKpTAR5gvcVt7lQyXOBisj2CRRCUkAAWgGEXcy9FmI5GiW/cgA4b+IGRVoEkSZx8JGcX lM+JzgIW8EADOgAbdjGlhUckfQIsQMIVnLDokKDeqi0AxAQEEH/zA2IIMiGN6C0XXqAAgK7/4o8R /CEv9kJ6akwrFEAAhI7oisAJ1gGpZsXgNOADCIEGKFADvCAL8OQqakETsEoPGMAJEkAE/xggDBIh YnYBEzyB+g5kBppAAxJAAGaAyERHEr5kJnAB54aQCIvQCEvIilSgHeJvEbbgAkYAHMDhEA6hBVpg CqMQHOxhAaygAZ7OYaSuE8bABhaBBfxhC9qhHWKgsIqGqZCiO6TABjxvAdrhAtLwDg7gFBymFpYI kjDhE+rkARYBEFZrArRgAQbhCnTACehAA2JghYbiKh5tFkqBQoQjCGJAAQrgEf5gEA4BCGwACMCB B/6gCD6AOsAAc3YJFlaBE2KBFSSLHy5gDkPvArigEfpJFU4Psh7jEnph9eDCSk6hAhggAxiBEYog A6gQHBhACMABCHhAAYxRAJigDGiQAP8qL4xO4RYOihY0Te1IIUQGQAkKoAi0AAh8gArwQAUGoAUI gQ4+oAXKIBSmZj+yhcJs7AlkcRbbwRYVJ0/wjyKW4ALqwB/QEA23ju90cXhmIAYWYRHqAA21YACA hiDojRW4gQnkkA4vwAqOwCnU4wFvQhMQoB38oSDR0BarARZuoRXVSSmegAvM7yTbAQX6yaBioRN2 5BPAERYeYAR0ABAeIQIE4RMZAAhGoAX8QQmcQATsQQIooRkgDJQqgShSgRXO7gizUiu3EueUAj8s 5gdVIU5cgSzLsiwFjE0OIB5O4ROyow93EgT0QI9sAYz0QIbaECl6IZa+psBgAQTyMOr/lohgOI22 iIUNGqEFLoAWD0EM+KEPovJDXqshWOESWEETJoRNruQWYOAGbGACaOAKaODqWEAIzOAFUo0T0Kwu w8JhZuH4/o6NDie0PiSUVIHahFBgIGn1VKFOgqMSVsEO1tEfrO4KlEAJRHMCgAAPpAA1O4Q2c4MU boF/pA4ielFi5Aw62yAGrsACGcEJGAEH/oAFfKALXk0XRMemMoIvlGPdSkFnKuFw8uqT8kQTcDPc /k5nnAIj1EetQqHakII5KJEUwsJwEucUbhKh0E7tCGevbqMSPqEUJsxRTrDI5AJo4uIA9MCgUsE+ o0m2LEEPQOBOEqz1diMVeqHXCAAU/86HKiuACS5g6YpTCa7gCjIACCTAG/rMk0CpoISkFyiMK4NU SIc0R05QFUTEN7Ema5aUST1EcECgbGboR/VyE8ImQ8VID/RgqGJnMVRvYganYhSmEmbIZHbHF5sB O2HBWEyrGTjBTZshrLiGcHRNCDXtMmWh+0jJlJhk0I6GLP0s48IDHKGzInPhxyJpTRKs9LoGFvKQ L4DUNXSzBwXnSnjCntr0aEIhFDQEUHXhFmxhcZIEFHSBE2iIPaszktD0FLL0B7MEQw6E+lJTFzLh NtKTITThKsOtE3wDVAmqjxq1NSH1H7jsN/qol/bjVjs0Ioi1EgYHfbqG7yYTIjYNh/9EyZfGNDuw cnd0EhxDKTcsxhRsUxOElSIoQRdMAQSu1E5sij5ZwTIpqzcb9VheBFM1dVPdFEDCY36wpBl2gTqJ FGADVmDf8hQOAEoZ5hQSVmEX9kmh9PJa8SrTjhNWIURBIFgWZiUhdjE2bbZMYWGEJS4zQUgStMYQ FTuDo3BW4RYGAiZug1jMxi23zDLVJHCSxGdkE2sG4hYwokqI5RQyYRI4wV+F0DrjrEqy1DdLRlhb oxclJKxAxGfh82qUNNlMh3IY1Wf/aBOOIzmwUhRwoRN2gfVwo1KxRhfONrS4hmx/di9wVVuHtdcm Rj9CNENhAVv/lYl8kRMsz2DrFmb/8VbKVG9vK6ZvfXMSgrB7JnESBrVwTSETUC4XVA5VJSlhLCYe DpYtMUFCAXRXZYEUDBYEiCBd5TJFagEXLiEXvIhWrSSUKsE6BoJJrVZxrCQshbYTcEFyBVZ3d5cI RSEX1K5KnpWghpd4u8ZOxAI7TDcpYFN+wohBk1dZa4x5QcSmxCJFXNMNX6EWWiFpwChMicVOrIRV qfL0cnXLtHcU5tESQBWUwNdaQYmUfMZxCCBGutY9LNM9tyYu9PMfWSF3I5UVZqEVEmR9+4lxesla GWc/nGJJtnYXdu0SJPdreYrI5Ac3nFVhQSlLv4bH5Mh8mehdK292/ah//xd/FSR4/wsnF2MhF94W IiSLEj/En/7IR8epaNfXeOUiEyD0P92QWs+za4JDLnaDhV14MDPnaKtmhQ1VFJq2FJpBhA3Yfd+X lCwE35ADd3lXi7d4CME2fQEkazrufcaYjCchjD+BPtx2WGe2GY5tICZBFtL4gwF0Zp0lQEoLjUsB V4VVFIIsl8IqMhd2Lo/FQLCYiXDBb2jDU4Gma6wVwQ6HSUJm2Jh4d1K3FFLzE96nSSgBJ5cWYGgB bFNhNvL1avsJfhFYjyBZFjiBEh44F3DBhSGiiXshFZ54EqjElMO3igsHWUSiFl4hlieClj2BQ8x4 Ej7hvzp5MVBXQoqZ4+xJJG53mf9zoUicWReg2V9PtY8pGECQDY6bQY8NdZl74asIwI3dZxOiOXp3 h6fAyoyVLZ0N2T0qcxZGIcCkZBWAxpQdOcF4YpV97H+5WKAHmjVoIchSoRWmjxIWmqEb2qE3AkIo c3cCuDcY2hMwIaI9uTopegYZGqNnQaIHphfrCioz7mzP9pjj2HJwMotf46CLDZPfeSDMFo5PayOw 4pW19WupuTem76IfuBdg2eaArBM0YReGDOMmAbRmeqbdx55YuT5qIacfaUXsOTVlmqnx+K9aQROC OqDdA5GNuqPHI/qCOph3OmLGuhRuyX5FmqfV+s3QBisNuhNiIaEX+qInOYIX42v/afmuF3qt+QaY +RqREXr6DiSw21qWcSEX6hk1owTZsprjvnkj+GaOCRqzM1tuKjMn9aziPhu0Q3sWOiEXhCjcXiEX Tq3iRru0NXp3UFu154i0Tds0DJpIeoMGG7oUMDoVaoEyvxrIegFq7npTyxJWMQFNZqEXhOh/m5gV OGsWortvfnsIQTkXskIGafBe3ZQsDwS5eWW599o1nNurWsETtttNM2Q8hk2xH8O5oXuOauHRxJuv KxO+Z6GGKDOYZRnIUlvP8BtthNomQHmnTFC2w/ur5/m5a+G/85u+RXrBGxxtOoY7ODtiiPtPM+RA 8jqTqFuzPxzE+bobf4zES9zE/zuGFgJ6OWjhx7oxwd1wxFH8xSWCxSP8s0f70U53xucZtvUsFX4c YmS7tXd8xWU8K5sYFwq84lLhc2Lhx2X7FR88YJr4FXrBBJm8yW9mtFlBwAGmyF18ymM8xcOcxTtG FBJ8OVp8zL18xMGczct8zTe7xxUPy4NcvvU7xPNcz/d85dLcyGHKz008zvW8zC/h+E63xXe8Nfz8 +F7h+H5M0flc0gWG0R890Scd0zNd0zed0zvd0z8d1ENd1Eed1Evd1E8d1VNd1Ved1Vvd1V8d1mNd 1med1mvd1m8d13Nd13ed13vd138d2INd2Ied2Ivd2I8d2ZNd2Zed2Zvd2Z8d2hOjXdqnndqr3dqv HduzXds/PCAAADs= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/Images/BoneBullet.gif R0lGODlhIwAYAMQaAPHx8cHBwdTU1PT09M3Nzc7OzsTExMXFxd3d3cDAwOfn5/Ly8r+/v+jo6Gtr a4aGhsjIyMnJyZOTk66urnh4eNbW1qGhoeTk5Lu7u////////wAAAAAAAAAAAAAAAAAAACH5BAEA ABoALAAAAAAjABgAAAX/oCaO5Fgcw1CubEsKAjY1bm0jwHUhie2vhUzuIjCkfshA5oKpWCQMFbKW 0mEikywkwWAcCkgIREAQEzDox8MyeUZkGLIBVTNk7peKrhKRUChrE2iDaBECPS4BCngVTn+AEhYW hISGAgE1ARARTI9/ag4YTJSDh5loFZ4PEhIPExkVgqQYEC4EC0MPf5GsEpxOgm2yEYgrAgoXd7AR b6gRenlZbZEXCgcsAsp3AE0XAHiE3hdYgtUsBNo6FxYAChALy06SE886AAAEKxDK3E+rCCoGINCD QZLBSJwuYCKhRFkbgwGkaCBwr9WqXhIaNWLILwKbCRAivriny1OkRgpoTIgIouyEAQNb9Akp2OrR g2cLRiDQtlBDATAsKhggcKagGgpNBIhoECBChgXFkFQIADPShAsLgAbIgsDAlBUDxRyoYEJMra9f r6FFEgIAOw== ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/Images/Testimonial-1.gif R0lGODlh3AAEAff/AK3BzZmzzHGKmoGaqPMsK4Caq/n7/HiSnmF6jOtJR6a8zdnj7JCqvcfV42mC klFrgFlyiElieMiWmjpTaoiisomiriE7VLXH2jBKYElidnGKnIGar2F7isq3tJy1zFpzhZCqtEFa cClDWrDEzWF6jrbIzVFrfomit6m/zYGapsLBwVpzh3GKmGiCmFlyg6C4zJ62zJu0zFJrfypDWuXr 8pGqvrvM3aW70rnLzuxiW3iSqTlSaqS7zDFKYkFbcMzZ5piyuDFLYiE6U0FbbnGKneY9QImirL3N zrPGzUljd2mCkKO6zMLRzu7y94mjuIGasFFqfJGqst93dFl0iazB1VJrfUljeGF7kImjqpGqwNeC gUJccZu0y7bJ23CKlqG40Jy1yzlTZ5myx5myw5iyx5iyxZmyv5myxZiyypmyvZmyvpiyyZmyxJmz vpiyxpiyyJiywJmywjlTaZmywZmzvZiyxDpTaZmywJiywZmzxcHR4JiyvFlzhZiywnmSoVlzhnmS pZiyvZmzv3iSopmzwnmSopmyvHmSppmyuzlTaJmzuzlSaXmSo3mTojpSaXiSo3mTpoGarVpziCpD WzlSaHmSpHiSpP8AAHiSoZCqu1lziHmTn4GarGmClWmClIGbq3iSoFlyhpGruXiToWiClpGruImi r3iTo1lyh1lzg3mTpZCqumiClWmDlnmSp1p0h4iisYmitHmSoJiyunmTo4iitIiitZiyu5GrvFly hTlUaJGqtmiDlomisllyhJGqukFbcomjr5GquZGqt4iisJCqt5CquGmClomitUlkeZGqu522zJmz uomjtZCqtpGrt4mjtKK5zHmTpJGquMDPzkpjemiCl0ljdmiDl2mDlZmyufwODWmCl2mDk5GrtTpT aDlTa7vMzkljeXiSp3mTqIGbrjJMYZqzzLaos7a4wfcaGniToLWXppmzy5mzyNKtqFlzieOqnOpw aJ+3zM/cz8fFwsrXzkpjdZmyxhozTZmyyJmyyZmyy5myypmyzP///yH5BAEAAP8ALAAAAADcAAQB AAj/AP8JHPjPwIIFDfQoXMiwocOHECNKnEixosWLGDNq3PjwoAGCIEE26RLDn8mTKFOqXMmypcuX MGPKnEmzps2bMS/QCAnyB86fQIMKHUq0KE4bH3naQBkgwLmnTaM6hRrAqNWrWLNqXUklKUGfJp16 GDs2xtNzZMueq4qSnz9+cN9ehcuvn123brfSzGuSr96/LLuILOnvXAwPMF4oXpY28WIPa1PW7bev H5p+K/Hm9esSrt01+0KvuSwX8MvJ/eKaXp1yAcEuYWMse7FEgQIe0WAsS1z7djTG507CRbNPn5g3 oTHTfTt532XNdDm7tVtcDBl8ZMToqwy9bfTvwr+D/2fel/NJ6tu5M/c7nnxp1jdvDDRQ0ulsBSgA SCjCLtqLaPjpx988kAlHmRj4lHEGPttZZhdl1ZHxRoOWoWHhXQ/2A9ob+Lih4BllYJdehXfVdRll GZ74oIorZujgg6rh1Y9x+GxwgnaVXZiaZxaeOJmKeMFn007/LGASWi8oAEA6RRSBjgJL8KAkk04q 8EKB572xwQQ7TGCNGxK+8YYYZHaIjCZlgLmdPmyyGVpxxl1XxhiA+JBPPpOI4wo+ZE7oZmhskiko mX+2OSih6cH5546eFYfPGWxMMEWIErb5JmhtJpppZcoJSdMPAoF1DgxKlkBAAiWMgEKApqI6gpVY mv+0jxg1qJIPCdCwoWAZvJZRxxhjWJJPHGOc4UaHvBqLXYdn5AFsH7xYwAqxkQAzwa4KHosdGW6A eEYdZ4SbLT7kgphHuOHmkeayHR5Lhj4lUvaGG2zEAccErxDr7YJ8Wvcor+62e6wYzqnmaUw2CNSA SR5EgwISWqhTDzUlAADACCVEPHHFS8TKzz5knBFHPoPg0QeduHAiCQnCwAEHAvkU8sgnwK5Cwh/T jsFGJoDEsQojvfSSzyPE1sHrBmeMkQkpmpCCi85jHILLJ390IgwelaysjM61fJIJK38UgIcwJGhy CNR9EKGJJpAweOKsbihDwgoCyPEHHHgQwsnanIz/UUcdbPQBNgmrAKv0MZpcUQ7BmB0s0wUKM7wE ADgQkAM99lCMcTiWY07Nq/MQJisZdRCSzylz4J1PEHbw0YMcbaQRRD5yyCEDHAUIkcQfIvgAxxyP 5LPCnXz80QMcxS7rbCav/yFHD6LgMQftdvwRhBxJyMHH9XDcEYoIPcggQz4IiGDCA/kw0r0VIqwg wyQQiLGGhvNGYoEVfySRzwdqmJGNBeKzQCdcZoweVM8OIhDFHKZhwBUkwwKugJd5HLcSyP1jYf7w AA9GcIRL5CAe8nhHOEqAAyZ4EITvKAEKouEBtvijH2IQ2elcBgfytaENpsjHAAwhi3ykoQ39swMC //awh10IQQBq8EM+rGAKOpjCbngYgxvYRIY5WWECgjDDHexgBTOogXxqSEMOEUAHHOqwDbmYhDPo kIZrTOIZalCDFUJghgHk4xltMAMcIkEGQJFuAivwYhrs4Is0ECNmghBEIfLRxA/4gIhpsJ0ZEBCE MpphFbaQ3wQpmBILYlCDI6DGJUZ5iW10AAfhMCEpTQmAjrkQhnnow+nucAdBxEwNQMzHJvbQQzqo gQ6HlMUmZAGKHvAhDUqMIxBbR4g64CM0IYuDBQRghmoKwAJpCEQ+/MDGNOQDE2WkwzbT8AE50IGN fDAnLv9gBzrYEQEgSIMZpBgoN9QiH7CIYxoSkf+KPSCgB/0zQxt6wAFFTIIDB9jEJjIgBzUgYJpp oAMc2PDMxnGyJZ6UHACOkABSXkICOChhR0kpgRHwoIXnieHICmGGLOajEXH8oiz2sIl8+BKZ+UhE IiiRCDt0Iw2jyIcW7wAHHzxgDmw4A5noNb1G3LANQTWEIb6JyzZsE4hW3WU5sZpOIJohnXQIBAcs kI8ZXOMXedCOGMpwCKG2gY12SIUifNFQfcYVEfkwB091IQcTxO4edwoCH+JwBgleFKOR80cMXoCC EnRgG6MkwBFKgAQcPDay4WglSt8CstLFTIs1HITL7kCyNPSwmm3ARD5AgIg9pCGOZmhEPvJGCEL/ kGASeIgDG9zghjrEAQ/5EAAQ1SAAH3pTfbQcmsvMsM1A8MEORIXDByZAwxXYQaBpoCkChCCOOhxn rW314lvl8IE9fKAHefRiD3yhiHyw4BZ7CIQaBAEHM6TBGaAwQT5YUQZ9oGGTh81oYTRIuXpIQQoq QILFRoADAyMYCSi4knBmJcNTuAy4PYuD6U4R23x0r5pCQMBrtSgKOASPDX/bmQVIQAhisWEMx8CD D7rYUiv4oJr5kEYcdpyPDAOXEWb4wwTmsGNJTGDHcXDeHEQRx3P+YRFp1QeH2BDcaqqhdWqwIyyq ecgBBMIHPoioFoVBiF8I9Jxy0ERhU3NYlgg4/wAemIeSkFCCVK1KSgCgs507FpyU2kIT+UiGJYiV D0gAi8qVkJ4FHvAIDcDBE0L4Ay064QhARC0fIepQHkhhgQgQQRW3nQAhCmCBUDziDxYQm+ksDax8 nK3VlsCDkF88Bk1MwHCa2EEcLDEJBDTCExYgQmGLQ4Y8PKAHGqibBVbgsggEQQACCIIVujcAIVih EAKwgibGIAk5eKIRqK4Fg9jcZpUIeMDzqM2qFBCNecAg3fixzW82axI06OMEazOb0eBxAnK5AR62 eDEnrKWJHVsiAhPwATZqUAZbwKNS1slDLHI9gWpgg9afEMcEIkCzpEKgGeTCxxT6/ShNBBwSLf/Q Fjla4G+U1wEXJADGInwAiDr0kTL6eBQJZm4JVqgCWHEgwQQmQALDxYECD+ASCZBxhjMtwhFWgEYZ NFnuCibWH045DGJgoBaywIDrkOlzX+jXLuwgKlD+Mla4utUrd/XpUrNKkLrWhaw8zN3sx8lUm95A hr5nR++G8hev1HWGPqpIHyH7lrfKVQa70x1ZCtpW3dPEuKpb/YIpiQpVqqL5tbSjHcthjoY2BZoM 7QNTgB+Um0q/oghlx09SFtTqOeUiCF3K9G8ClHFkr5634Nw6Z9993t8kfNiPiVDcAXCAr+6evrAE NWyOjl0u4yPxTN9FuX+RwUyU+9PDnfbisX7/iTzzItGA5k0lMhBlSn+iyyQnRdmnzhpA89/3WP4k 5x57hoIkHDScn1Nt4R3msUmhZzDCIXoQQn/kZoCZER3rQR3Z9xz8F4AxwoAOuB7hERfKV24CxiP/ Fxr1N3aIRy7v0nvr0R4tUYHO1xKjRyjzkxkNyBfktwbCRyYAeH8X1YHU4S8Dow8vWBf64AZjoDaa wCcjoiLtR27l8R0Pgn5KKBkHgi5KpR6bIX10gX2nFygnAAF253Da8YQ46Ck6uA/kkA+/0goPsCBv kBqUgQ9s8D4rIA5jQCnBJyYTMj9XiH2oJ3t4OEH98AZlgAt3ggtlsIbq94HdVxzHhyAe0lZx/9AH gJAPblB5Yeg4AiYvNdAzcLACR0ZRnAKIhHBEagAHupVUyUIuvbIgFIJzmUImctIrDFIZmbEP+DAG njAJk+AJY/BMdOF/cRJywFgueZBiQCcsLjMIZsgn+6CBlQgfGcUP9kYGyPAKd2AKCPQHkhBBxEEG Y9AJ+ZABfOAHd4AHO0d0xEInrIALpAABJyAas9IC5OBv1vBqv/AAizABmnAChtUWM1IGeBAEvuAL QYAH/YUZo4cNRAAsmSAJWzOE2DAGcdALV+QDBUBUtJAP/SNbyQMvd9GMrPGM+zAvbaUGppAIM8AH qHAI/kWLbOAJ+ZAEH+AHauBsySZt3cM7k/8QBEGgA1mIIPhoOBMgCXhwBz0QAoygAREQP3iYEmtA BmwAC/lgBEaAT2xABmsAjYinCUEwB4JQXA4gCHdgN3AQDELAB6PAB2eEjBGFjLpVBiXYhx4JGCC5 VpGYXakgB3fQBwUJMmMwPZuQBmmgZS0FlQOQBnwgAqgzBlZJg1UUlEjmCH9wB7IVUWowB7jgNgYz I2fQB5TEDMwQBAjQB2s2I24QCXe0B0nQO671TWkAjq21B/eQBDgVCGmgWlE0h38ni3H5F8/YlHkg LIGwB+l0B1K0jE1ZB8A1ChHlPF4kUHZQXr5gB3DQB3nwBsSRc2OwCCsQXdWDQxbgAwJQAWr/QAh5 8C7/lRdoEEP/yAHaoA0cMJBKZRf6UAahKADMIAQHkA9RcABCoAiIIATX4AJ8kAq6YAemlQ+0GVS5 lXTgAA4toJu7uRW9GTLCApjlhDxusIyzkgcrdUPphEtxRF7mJQcTxYv25oaOEEhxVD1hBAohcCci UAC4ySlwwZcFkA89QAmU0AP5IKNWqZlz4ANV4AXmAATmoASpMAT+mQ/XkAp8wAe+4AC16UNqgIxE FgmuMA464AQvGKESGjn8sAZ0iZFqkE5zsIsaOi9UJlp3gACTUE1eJAIi9lxxMHUGiZ2OwAcg2jqC BJgDEAQ+0Ad1MIm0R4tjIAM9MAp+4Aej/xA+aEoc+MCZQXANHAAEHOADIcABrmUBDoAIhkCZHZaR wzIGeYAPE2KCXooVIDkvkUhLlNQHniif+JAHPaZhQjMIiXSRxGAGobAIhbeMnBUyIRABAjUMk8AH cBA0IGoCPqBbE/AAFNJZk0ACqfM7t2VzlWGj+WABFbAHFZAPQjAA/ZMElZRHglAAJuZhwJMPc6iM 87MjqZoVzxiNrjAsEWkB4qAJLQAvxIEghfYrY8BpAdQJuWVrsZgXf+gGkfgAMiACk/AHc1AJ+eAD fGAFFkAzY5AP4IAclyGmG5APsUBrbBAL+bAB8iOfSSMCQQCWd+ADFiA9c/ALQSACodCwqP8QB211 Mm1VeBQSevF6FZdYHDXgCo3HBs0AAfDwBIX6BuRQA+VyBpGwNpHgN2XQDE/QIGM3K2wlCceQCZwQ C4DDCSSwMrjABueiA1dbqE7wBMGID0/gBMknpjViC4ZjC5Ewd4BDhJEAIjVwCAoytMjBKD/7pZjn ezg3JteRm2zof8THd4+iLH/XIDHSrwlyin0nMOTSJ5LbHNsxf/NXHDfYgn7Xd3k3Jv5Ggt8Fe6Ox gYM7FB1Ift63eguYIqxoKTnyhJ5Bg2PiJ4piKaChgHk4fqgBHZaRe5/bhL2bKO/Xka1LuBhEHjP4 fhjIj+4HfhO4hCuChC5CfjBSgD4bI77/137VZyLUUXvSF33NC7TMhxLFmxysy73XqxLjoYL6RxnP sRcJSKPdgRqsl4fOAa/pWxT5xxzXiXzCm4HXZ711sRziIYDbV8Da0aXvEX7QCCiI8r/7hx4GDCFS 5oMHzLoBjFiFi4A5VwZboibed3oPcn6ZogNZ8H2JeHvUl8Kccp0JsiUHixfE4bmJGCdbkiY1QA7K q3vcMgEbECJqRQYbAA5GSMNgGMIz8bqjJ4RxILGkOjB+911+B4z5MA7Z4S+o64ohVyloR7qGkjRV nIyy+HtZbB2X6y1tBSyQkA9fPLqPm7GVQCy7cgaRaDSZS7qoCsWPc3UHIoR4AAeM4GEn/2M4OgMu AAs4dWB3pth4kEJrkZw0UGM0vKUgh0aq6TIGh7xIxeJfODer3+LItDYGfaBhwpJbOiMugAM1O1ZD hTCOJ/OIwnKOhpNU4wbCgox/YKohMcQJcgCudpAP5ioAk7CtCDAH0vMAZCUC4tAHfbAINNMHqxAB d7IFcvAJc1AAcqABsyMCnLBjc6ABy2wBCGAyfcAJE2DM+TAHaeUcOYcND8AJ4uAInAAHAiACzFxN iaxFn7AIwPIJs5MPIvAHqEU+xWwBnkBLiUxLd6DM21p0FeXLvyxgJ8oA6hxGH2BcsmABfoBMR/RV QWAKdeQDczA9p0BU0mYMZlBcjdBhIf8QDGbgA3ipSEIw0n5wRHcgCh1tmLOlVKARQytgARZgAjIw AIUgBLKATNNEB8iYR4u00p/gCc8A1SOtTXLw1Is0CElkU0kk0rUZbP2FBr8cxYmltSTQA9ilRIiA CCHgAIqgCHvArHRgByYQCGxEBzgmk0oE0140Tsl0Q0rERj5A1/6J1/+ES2lgpURtqMZTCuKV2HV9 12GmRK+lRERlBmFVAbIQBP20B/nw1GXkA3sNCvmwB4Zg2YpgCCYADGllUWn9EiBJOosQCr+UBjWl CLOwOjpFCTMgB2I1sR+wCYgQUeP0XEDERvmwDnug2mWUWqvdXkEQ3CJgoK1zTo8dz1P/yJLWZWXi hAF7ld0H+lqqJVAgoD9CQAkWIFftNdIR9QF2QFP5sKTXrVOT4AhTWNs5AaYsqZ1vRQdwfQv5gFAK 5QcD0AaBsAlJwKNBEF+6RE52sNvetEs1BadKZAh4heDEVJjbfU5KFAfzzJKvMGS0xFwIvg6gMABS 7UPUHTvPUwGeSQkuENfjdE7lxNv5gOMIvgmMwAmFSNv+7WYAHjLi0EVxpJZ7IKfx5dcfxkaBYEfc tE1q4ABCEEaAOeGq5cx4gIxsJAKaSpuwlQRJEFMa2V/QdAaSsAjUTAhw4OTyZa6LVE11/kW7VNe6 4AuGoE0yWU1GFda0KeejSFHwUuS2/73Wa8VpMF0K+uWhQmAK/dMLRDAHJJBPbWBHNo1Iw1CW3uoL +QAKdLBI5xiJ9cUHkT7pAjAHwNbo42PohWxr4fJir5DqZtALGoAH0hDPX+5hZtBrgOkHFsAHuURN ZvAJ+AQHi5RFqC7pdxALRHBzGC3Iz0gZpBMBFjABk2AFHjaU4zMBPWABpDAG4rA6ciAE2fA7+VAJ qTMA/iyn33QHwtIseTDHY0AIc/Dt4X4MGmax2p4M+fCr8kkG8MDEyDIG6APu4k4n7HppfTAH12QH PeADPfAB6p6TE2ABrdBittIH+P7tQWABLUAwDIjoKKGDJVwLgLA1STWMY8AAkAAJhP9XBgwACICQ CVTbLL41B2oQCIaQQ9MAq24pxgmSNDAv87tSB7Gw8kllnnURGmNiKI9y9CBSLv42eGOAC4BQC4YT y2MQCYDAAJrsIR5i9DFPqERu8p1EyDPCiNoiKNcRxnEfct+FIGcgDgiAbeFD4qaae4Yy96/HgwND hcX7ri04xtqhdxMCxtqyxR2CunoHxtkRyGp/8swHjag3xHDi97bLwfjADSHgCFvAC3PIOLVHHLrn fZm/HaShgeNnGainwtOnI8T3Jyy8KEhY+wA47dR++YYrvNBXe/A6GYj3ISHiwRPEvYwS/AtIwYYL JHnI/IyyvdIBffFb+cA8wlbx9Lv/x/q8L78MfBoI2L2bgf16McDQQcEySH7ni/qy+8Hht4TkxyLL f77Tl/opPL7b1x7gARD8/A0kWNDgQYQJFS5k2NChwQv//jUgyI9fv35r9u3TuNGjRjRoMm7UV1Kf x40aTa5M2U9kP4sXMWLsiFLfiScoP6b0WFIMvjNu8OEjg/OjRo0u++ncp7QmRosPpU6lWlVqxIkD LWbUJ4YMGTFv3nj9CtYnmaFph34Vc1ZtWrYnOfLcp+/NV7hf4YErC1ZM2LNo3ZQ5MybfoTFj8uz1 2xdwV7REAY+N29TqZcyZH2Kl6O/iPjGD8+QhfCZPHdRnyhDOwybx69d1VhOu4xo2/xs2soX6/Ru5 TG3bdUyjXn1GNeG0ZV7HIYQHTr5Tc/AkZrM6j3HhpFXXGYN7zPHWucvg0wdToGb06TFz9pxRTBlO O/Ll81FrzCpg84GtitOHlwwEJsknBGNWsCAfR1bpo48HSJDBAgtkMCaC+WSYY4xyJphtgwkS48QR DYLIR4RPCOmDlQfiiGMOVA6chITCJpjPgiSKocOEfIKwww44UFQxDlYEnISV/uJwpBMf8rGgExXx eDCfSaohwzL1qrTSIfb8QUMffGKxgARCKJAEEDyCsEIUUazoQRAz/sjnD2eKmWSSP4YpRYQV7rjD DiEcUGOAHLv5M59C4GAkn9cAyf8HjzlOoS8YM3ywQ88VeLxDhh5iiYOIB1xbIZg0KgiCjz0ARQCT Qu5YYQI9NbBgkDsGsUCAO8zIsRE1ELBAFEH+CMIUMwrwwQ190LjyWGQhkqizNcTIQ5Ie8PgxDleN McOMUoQQIA0+7KCDDm7lSEMNNbptow05/mgDXDn4oEMNdPloo5FF55jDknyu9SMfeNvYtw0zuiU3 Hw0ISYy7OMwIBARZrklkllvy8YPcO0KR49og/ri2zSDAzQcTeNWQGF0T0qDDjDnKEGOf85J1uUr2 +NkHHzYW+QAOe6WzmFx45fhgjw/keJeOXLwlt+g00rBD3m/tyIWOc+34II19zRD/RJBC8vl2lHzO bWOQfEz+wI40ZMlX2u7iuIOPAykRIQxtZhlZjV6FTiOfQULGJGxDRm5DZEwC4WDAD/y4Y4wpW355 8cxinnkMR0LJWWc5ziXXZ0PGVuPaP+zY+A9xleZjYzs0vtZnqrU+d9+k996Y3qQ/SCSQqvHoI7E4 QhFCFma0SeWbWRDBe/O6k8bba66N92NjvNPYQ5YkesinhzHwoZJx7K2KeQ0yzhDHB2lVJKQTCzY2 o086upUOj1ccweP9zq+V+n08HHnlfTiWpoPrd9XYl9xD0e9Q1zJXMPJRAIPhbgJ/2IMiFJEKXezh bo3QU8XkQK5JIGBjCBABvPLx/4j3zYFQZmhDINIQCEABwnr9yF4LqZKlfrzhDIrihIoA8YlffOlq CBCCMeCwAkfEITGa6FBiJOEIOMDBEZJ4zQQ08RpH/OEOxCCUGoZhhXzd4RGISoyicFYpOAjCDj4w ES5IEQcr+CBpFeiBHf4mAk/Yi30TmIOqJiEKM4hCBHy4gwgBkZg+5MMScCCBKeAFqFqs0IWLxNKy 2rOP7pEiHxMIggUi0QdOWKAHPbBAieJARNPkAQLgGE0eiJgYJ5YSHBAYzRmc2AcnWUAOk8DiHOKg qFJCgouS6FAchBGESezAAtXoAwUm0cYe+GACSexEPhYhgj5oYgeJIYQVZGkBcf/YzjCQGE0d8gEI NOZIDhZgRR7EsAbFMVKdyspKe/RBhjLgAhIbOE5tDvFH3azlL/v8y1vwwc99CoYwbOAEYrpznaEE NC2qGcwZ6rABSDBgOGwARCSog5oxIAMSkSBNGdzghtM04xDN+M4Z9OkVfDQUF/fERR6mxMJ1xpSd ndkKaCLTGLWQ4Q0lYYpNTNJTkvhkKB9N6E97shK3rAUvKc3LUv9iEpTq06hBjWpC94GGqMhUq1nS ylJ00hGerkEpMyFrWc1qVpEEladNeQlaX9ITnRh1DTXxiEvQANeNtHUmaa3LWs2TGYHEJLBarQpX PdOemcSErFlVz1YSm06FyOT/rI91rHnOU1nGGqSyUDksQgIrWM+kUyZsZSFkCbsQwxaEsaA9LWZi 4trXLiSwY4XKapdil5PApLOtZYhhFTvZ3y42uJaVbG03S1zhCjYqojVtRYobW62Y9rjDHexW7uqT tmwEpjLjUhlIQ56mGFe5g21tlgSCEbWyZCdr5clPxYpeo9KkryehK3uZ8tfDyiQkItlvSLy6VqyG NrRoHYl9g6rdqKC3BeQgDCRqgI83oJMfW3LDGB5wIE2cQadyacp9MytTrt5WoLMJClHEUlXJRIao bREqXPY51JNGRp8yJkNuKwLfkoxlp7gdS05tfJG7xtUuP9HnidWyMvPc9Q0P/8BGHPDwTTYQC71k YIOrYAGHWIwBOZLp51psXF5HeqYu+OCOMgDBnzjEAhC1UI1pRKoKXCTGoa7JBCCaMZ6hnOEQqvhE H9gwnDEA4o/dcegY6qwKIXoHN+MplmCX8pM2C2c2q0mMmjkxBje8Iby35adAXVPQZsgmD4lRBSCU oeHw1oXKdbRVIQjBBjK4RB9uiAMfxNUGOBisFnb+83VwUx3yYLW5i4xZP7h0iDeJwA75EIAMRCAj IvQhDqjIhxzk8KY74GGLMpgEtF8DpVlO4sp44IQIejCBAzECDnfwhBDkYO5e2CsfSMoHOJBcUzFU AxhO/sQBGeWDCMwBDjJwt/8QfFC9Yj3aFfnIJaLi8IsedNsCImhOAczNyUqYs8PvWcQK6HDt+eQD Hxp5QxnwFXKAWXOc2ZTOvJNk76YM24XFfo+iEKAGbuXj5mr4wyQEXoBhgAtQxFBD1na+Ap+vKG+B 2EMIkqCGZ1gAAWwqxchMYYEBGCIQPvCBB4XwB0AQQdMx2RI+sFE+OiAgHyZ41yT85IAeOMMQuxAB Ccqg6THr8jWqyEcS0+i1qZthEt0wRBp0VT2SdK9dgVDExy60wpLPAXQS5LkIjCEIPWqsDfn4etjf gN+tOlJm3atE18CVPKhVzQxqAAEoEMCHfGzCEGYj17z6rqc2DIAFfKBEIhT/IQAhAGxgoNiDCaCg CETsARRhu5vh+pAHTcN0S2fIRD4GoAgMXGMSiqhAPoJhiB6w4BbJ/8MiznBO0JRBUfTb4unUGAhD FF4APRg/Iu6mwpNwiQ0T4EMaGu+H6SCDkNCHMuiDFRAXqBGBbNiYbhAB5YEDLYs5MMsKfuCeOsAX eKEDsOkXsDkhBxCCILiGD8iHA1CE5QuZrFm9ZxinRPidMGCGVCAbNaCDQIg9RPiGkAs55ZmDPjg/ CTS2MpiDIOAAI7AAILCAFHAADHCgHJwPR6iDlXmnGcqXa6GXdfEDCNEFPjCCW3CBJjwM8OKSMWgX 5yEUPIC1AaywzvGafGgE/8vhmj3YA0J5PJbhre3pHkVhEzOghXy5GtgxhXxwAOQTnk3Yg6oRhDvg Q3iJHhCYBW1wAeCJQZMxnk2YBUr4gODZAxM6FzOMgzoAL5gwNjcgBBPwAQ64B224hyqoguMTngMY vzQQhB6UCzzkl3PZQJzzBgeogkkQgihwAUpgBkXYAzWAA1jjCDFcIOMpBE8UA5EQwwPUw3xgBL1h PujQMjEorQmkCJl5D2TLmdLLGbD5mnzYA0OIw3wAhTTIGkaZA2nIh1pZGqZTBN77vXzYhaSRQ1lQ BBPogcIjnnWbxkSDhCc4CYtYA3wYAwHQJBaYBRaYgSDYFjrogZJJAzOYjv9ga5YyQDYS8p8s6siF iT0ByAcQCIRijAOVaQouOYOOW70Pwsa0gidNWATpgIMgkIGNMYEg+Jt8qIQymBLeGohiOzYuGgNk S5S+yxYHSANiSBI/EIQteg1kY5QV6IFiSINusACySYNkAgUHSIR0DARTEAIZeIY7EIAHMJFvUhFk awEk84d+EIMzWAXO+xY6EJBSSKKR9AQzmIZWuAIkMzZ8wAWpU4NGkB6BswJPKIVcEYJnoIMgkANg KYAQIA+XAA03mIAVwIM7CIIHGANbQLJ9eAN8gIci2hQLYARBYAQL0ICWOwTLlDlGgqHR3ABw2JDb XA0OWRENEJAgGIQJqCH/TtCQ1cgQ11iFZFCSBnmAOxCEYUgCO0gCQHlKOCiALZiPIGiFMaiDCbCo MZAEC8CFl/oMoHgASbAXQiCBCFgOIpCeAXGF8rgIjSSFA/GBTgiiMSABEam2AkgiYbAmKHmAl8KI rngAbnCNTxAQCzgn9BKDFngA1Rg1UhCBESESVNqA6AtKfzCv6wKoTkup33gN3MgDofgnhRoM4OgO 1+gDUcA5qhECCNzO61iNtcAHwhgDz0zJ2eoKoDAO4yjRofCu79IHsXokufy17fQo2qAO7TAOj5oS YWvQEXODGiOrujixnxgoJ/Wyq5LN2QwzxAKqoKIMpWKxuTjTIZMxoOBO/x/4AxOwgGzQshQDi52q i5+ogXywBfD6LDRYA6RiL8j4Ck0LMM9QMho7McdA1MrYLpcAq6fKrd+yCZQyC7ngLA01r9Aar+Gi q7x6rL0aiZ4gzQ0gAUkggVhgAwhjCrEKMn2ogQ2oMbFqGSD7VCsdsp1aA5H4LPTaiTOtq6V4ir/S 1cvULt2KLsmar9x6rN3aRs3SVNbSr5e4LOXK1EjN0vEITMfyL8nqCEsdMIzI1dkiiR2r1NqiVkdT CnAdr2UVMGpd1nDtKwTLVA0liNRareYCsvByVtVarv8Si2TV1bs6q1xVrf/K18/gUTpVL91irRv7 1mI11n11LujKqgmzU/+zkMAPC0qumq1PnVivuovsCq/9qq2x8qmwqitxvVixmgulqCkedYUsSNZm KQxOAARb8KiheIIToC+7Gtgw/Ys63au30i69eoloddiNIM1Rg4RDqAG8G6viWtjQa6eBgK8d44hv 3S/QsFFNsAWTYjH16isPfaqjQlSuRYav/VOUCI0zYIN8gATwqosyyISI08xW+MwxcCIqBdtkdScy cAVueNJxNQkdA9QhO1mostExyKQeCAJI0LDHSC+DBbEws4i7IoPBoFFKNQl4GoM4EKTEGA83+FGl Gl3a8FGcfbHM9Q5C6MnuEN3Z4LLOJYTnAISUhCQ26IRJgBo4eIRWIAT/Qlii7ygN5EhWSDqDmbwd 2SiNEovQ1SjRzNVcvPioMnANOIiAJDADOBAi03jehdqN+JzazoBLSIIETVgBEoCGOKiODTiBtNgA aMADUxkES+iOTCAFTSCFOHONQ8CFT/iDThAGPKiEUmUA0sgDQDhfEuiF5pxfSxCiOOCFPyCBTNjO to2FP+ADQJEGWCsJN8iECOgBUFgeWPgEPUkXWyKEVSCBP2CFKMstLskENTmFR1BfODNKi1KFFXgF EqCA2xkDVcgETijVCsYNXGiFUv0EOAiGHsgAPxiAO4CDX2BhXkggaPgE0HSFGriedTKvGCoDC4gA PkgCQtleJ0KN/fsD/zXAkTaaFIhLFznoAVFglGornchMgnYJAvzsAwuwAj64hnyQhTRg4x25g2lo I9ARAQGeg1aIkFy4tkFA1a4ogwS1gETwFls7HT5gkwEQgiT4AxHYAsRbg5IrNyGwAznwhOe4sGrD Axr5AzKmoDuYnqWJzPcRhR5oFysQgkHISmVju06+hp4LAUTkg2SaDx24KvHVCu45g19oA+cpRTW4 AzlABRXpg3QpQz94F0Gwggm4lj2xApe8uTQARASAGirqzzlgTOepghBAhP+DmnLxgThMAznAyVKw AFqYwbuJZAh7D0IAHa1rA1ubwXbBOTlAgDjcBQsgAmIZzTKIgzXcHP9bkYNCEIR4KwXn2YMqUCM6 0LlzMaACEAQECAJ4SYNdMAVDaEEJCgQ7UOg9AAFtSR8hWIFfwIUtflh1GsqENAYEqAJKmARK2IOP CwWcmYN2MYTGkwWoMYNZ2ZiFPCGJAZe7wQR5bkMS2gUOqIJEEIFvYAa52WZwEQEEOIBNkIV78JZu mITVG5hHkOSSM0BvARjQSRqpCZXYO2tZ6AFJuDuINsALomisRkQ4KAYOgAK3SYTkk5h+IZQ20JVt 2YPk24NE+IBAEMtAPutNCALLHhtBoEOd/tJ2iss8+AQhaMEDcBhFEJ2N8Rl0nJiBKQTkyYf4+5jG 9oO/EZlBSIMBsAD/XUiF1H7BiGFq48GA3tOFRCgZWzuXd5lGhJu1MaiUaykepfkZs+k9StiRYyiD /KuwsTGfaaygAhCC3z6Ae/iG8bPtgZmYQCDjHHGB5JMacNmEfEiEROi9RHCAQAiaOzAY8ohVL02W LAGNMwAGer6FWQBGTSydfpHHGlyea2E2nhlJ41E3PfmgJJplP0gDHwgBRUDwVFBsOcwbnMsHFki+ pCGXgg4ZQaqDGtM/VJADPZmDAzwX1Fk+EBhGNZgDSR6zMXgFVrGaWR4E/OE6RABx3+ubRkii5ygE EkqD1quCQFQa0wGbHNfEcSkXOYADP/tJSO3iMAONPOA/pis+oUEX/xkImYyJ7XWDA4Cb7jSKcGn4 kbVckSpCnTisArL56FS5Fq4LhJMRhGm4A0exlggHBI1LvynYgQXpAyA/YY2hA6kblzvoA1xYmbt6 D01AIoF7skHrg0X4gzLX83H5IPH5oDlo0XURHTUoHee4AyFAgHGxmmmQPDlIICKAhxoolpiCIX04 A/oUgEG4BnfTE0+YFQGwAwsIBT3xAUd4hGyoTgv4gEf4AwsoADxo3UEzDIMyDEu4gw8UdmK/mDsI ATl4hE64g062gkIQAHGw5jlIplPwBBEBBGKZKy4xzdcgIuawH878wD+ghWyYAFeIPlGMhHzgBUuw hEA6hDlrZHE/5f/P/ibqWMs/mABPaIQ/EAJiuAPh9VzyCfj7rIRoOs0gCALL7HXRW4ruaYVF2AIN qIRjwB1JWAQrqARWUIXEUAZxmICDG4NP6PkIwOI/g4BmSIspcF+ggAdbAHlHgHlLIJI4yIRq8Pn+ gIYHmIAduAKvZYNMeACbp4CuxXQlI4cWSAtXaAHjsIbHZYM+AISeB4YWyIKYe7QyIIIJmAAiYAN4 UHqHcnmYfwRe6I6uHaq+r4NYqHlHSIZeECJrcIXRbQ1V6HkfIAUDPgRuSIzq4wYIg6mdrtxHAylJ w7OGyg6TSqnRDYoI7SguG1zCRSnTcKjupV4fNV3vLQsbNY7rwHT/mOhTpOo0sECL4yCK8P2Mnxjd 3dixuxD9LZUMqEIp6/BR54eMzN0N2D8DbrCAPAi2AEeWje1QthjX3njUldipsdinOk2Ks0LT8X8M wsWuRyWJ8T8JQp3VmeCIuULTrgCMmAMIfv749VujT9+bg/v29eu3UJ8YMmLEJFzI0OGahxM36rPY UOPEivvekMFXDR4+MQz9sWzp8iXMmDJnXvj3r4HLjxDFKFyT0WJGjBb3HaTY8SK/pEqXEuyHRqjT hk8bUvU49em+oP0EKh3IlCrYjwsbJmWZNKrUrUo//gT7la1WsmsLAs1K9M3EjmgEzuzr9y/Lmjdd EiTK8ejQqkOL/+a9OLBvWa8t+cLsKvkyZZlcCS71yrWy2clm+VK2PHp05MiTFQ9duEYu4NiyWwrG 6RXNvoj4dkucSEbiwYN4N5bE5wYfGX2vM5Nmipr0ac+EVXve3Pws2q7XrQOGHr069edNH0JUyPBp 5tnqadq0zQ83mTJ1IEHaUOZ+njFjzpQ5fuaMfnWcwQYbkQACSRnJqWUWW0PFxRpVWI0l1lhoYOXT PlM5ldVPD7n204MNkgWZWGgJ5aCJQvmUkW74wHMCcK7Bth6NL9XGkkNknHGMBT04YoEFmowxxwT5 dDJHH30Q8ko+H8wBRwEiiCDHJPkAo1I/ODqEV3G/SSQSY0aFKf/mRmDuxBN5EXn5GzhTSNQbcEch FBFFGabXUkNz5iWcmrz9huZDwxGXzyF1sEFoGWekVGdDNTpKW3sD9aOPG5HkU4gZguAByAN4CCKH BSLQoYYZxQhhwQd0tCHEH2aYMQc0W5DB0Fn6xDfgGGzoxwZ/u+2WaB115JFoGXkMm6gbxQ573ET4 ACvscfjwF2ywZ+QRCTL3/VdtGb46e4aACdoJU0Fv4JMHt24kC26u+o1RR39eJhvsu8Meokwfc+RT SR/68efGrHvd+WhsN773RhmSyNEGqXPMgccdbSQChRAOIKJIKrpQksoefuSThhpq3BFHHbNuNSkZ kLTCSTJyIHD/xyNbLCJJu31Y4sMEVvxCSBx4kODIIg+oMkYcGviwSATYGAuJOI7IIUMv/Y4RiziL WEFCJ3HEcQwgY/TBSiWtHE3ErmO0ssgiJGgC40qE5VZGJq9MIIcGSPaBCjQkyGFFAcKs4EgIkfDK hiaLyOFDJ3Bo/UovcNyRDy13CCKAzNW0gOXABP9lMBr6lEGKBaak0YYgT5qRxsapiABEFEJsQokL e1SQjwBp0GEGHmO4oc9HYpShiQV2CCCAED7IMbwFR8JBvAOY+DBJKWaYEIQAjZjgwx3Ee1IIAiLo R4IMjQzigwhm3PEJqrR40oMdd9whh5Nw2GFBBIwgkE/jcCTT/4MGhciQDyB2t5fVUGoMQfDBKBwg BAQI4nEi+IMfkjAJO/CBEREQAZIIIQcHDMIBFnCAGeBwKTOoIR+DUIP2CkGCSeBDH2jQHI0MNil8 KCMI+ZDDAxBADDW0IQ2JSEUULKAEF3yDGRtLQxqSkI8gXIMPBYjDGcSwBvjUYQU9UAMd0jA9kKlB BnZQQxpmAIo97MEQInBACf1gOzoMwwwU5KIo8AAxNQRiD4jIBygC4YMkuMoMfFiYG/lAQjvIoA2G DAIf1DCAfMCijwA8w6y0sw8y1CEbdrCjIbohAkPSDoy7oJ2qSpEPRtwBDqezYyoSEYg2mBCM+VAj /EBmhlWU4f8NW4GhemQ4yTrMwRNJkEM+8sEHJMIOEamYxCQOcAtdfKANriqECeQghBuOoYVEwccY XmGHNmQxF3YYVRv+uIcU5CMVfOBDKmbAh0AEoQcOGMAekGgCC3BgE0h0VTE+oItp5mMTirCAAOgg 0D8Ggg4U5KYdcmFINVAwEAgIwkJZyQg2CPCW/NgHNn1AQRekQomBSEM+MAFGkA5CVawsBBY3EQIM BJMSigCpH3r4yjRUQQj1pMMd2ECGNWQOlzK50UDW4LsxmBKL9zNFIBLhC0M4wwJySEMg5JALQcAB DnMQBDcLYYFWnEE5+sDmH+TgKjWElVRmyIUc9rCJJnHUFx//GEQagpEEC+SjYobYheqCWYWP9qAH LDCCNvJxgFn0E4lp+EAiDJEGOSSSDowdqx0+cFg5CNR2+ThFHxTVkZNhNA5ySIQLXMCHD0iWDq8k YQkbYVYTpkEA5TyANlxACUQY4pUyxUQadsEHEQRTBtXcR099ChOgXvQNbmDDHO7AQ5BiwqB/oKoG CgCHT60ADnLEgykZJgdNlKEjtjqDJBzhsDmsQA7j5YMdAkHOCsTzdu5rQyAMUYG5ItEQe3DG/Qbg sV0oAhF3PAAiPojEQCAWiQl1lR1C4bD35SIN3assSBmRO0hu1iHYDEESyMhFV112vPl4hMNE6AeD msCOipBt/zxNSMJ8NMIMdFAsCO4XiRZmSbiAMdhF9XEFIsThDs8UQimoKzVd9cERf4iDJVBBiOma oRQWCOBRxHAGTexAa3Ggstb68IcJkFAEJhiVGURBATw8ImStFYIZGiFQOoAgHwNY5C7SYIhFgsIQ GZCDfXcRgkSATA4rcJgcUGFlP5vBFK+071r9cAc8EGEC49hsbs7QCiGYglR3KIAc82EJKwNQa4S4 rBl8YIL4GsJ4t7vUk0Z5B1oYkg7OyMeM22ZjvxCXKC3IxyQesIJkWGAQeIjDBKbQLV+VYQJCigSQ rLACGViABJDMEFHIAI8JUEsT1A7WFHaw5AI4NRS8VkUflv/IBxNUDA4T8PIfJmGFTNmhB39Igh0u pYZn9GAG+9TFF9+HCv0YO1hsmAAqTOmAfCRCBCFQ8RwiYIEovqZz2BSHBXTdg0Xoh1DUygck6LUv OJwiHybgQxCC0D48aNprnXbEJGSQbiuUjKez3lykBgKfGhBBE5rABi72U4ZynABQEHnCCaYFiSlo 4gq2SJALG2KQE2zAV0x3un3qMIZMkEITJECGsWxBCkngrV/KIIIkJFEJnnntGJLgcSVWkVw1+GGM JkgCHMaArf9s4AS+2gAy2ECIO5jCDxXwRj6CUdVJaILhSblmgWxOhH+5oga+Gofjd+MKBuiHApIg QSxiwYn//UACF/zp/BlwUXNJdK2FA3x5X4DqD4fYSlr9QY6YLuIUg3BpN/9KCa0kRZ7g8J5Pu1GX n4zDn9dL6z9niFay7oMfNnyiE89IwyCE8IgxdIsnvUcIGdwwBhIUQA27+OUd5vCJfNiCxjiKtnF4 Y/3rB6f2w78Ps4CzETEYxw2KUlB4UG+jmJ+FKDsxD1WkxoZkxJkkxHI8xllYiAIu4FTs3vW9QULw XgTKCUJAYLNEgg0tkQbsB5p8BFgYhJQ9AF1ZgBUIg34QAUpgDoP4X0+cBwMqoEOQBwT2RFBwiP9F 4LjoX+rFHAKWiFxsh1coHVFkRaOUxl/MxVWEBVpIiOwt/2FBfBWAxIF+uMEbLAd2pAUIuoGhEEge IAdwTFFpEEQSqkXmzEWE/OBSmAh6BJcOqt5kGOERssWM1EhZOAdqSIpb3CFBfNew4EMV1piWfIhF kMSftOAagsZlxAZT9FQY6iDMDYZoNIVlLGJO0B6anN5jgIcdUqJ4vMR7kIdjEMYMJUoXvoGdJAVu GEbsBYdVpEh6TKIdOqIsuoTq9R9QREVrZAhV2EqyTMAGYMkKckiHuMZF5OJTPEWHOAVugGBJJEpy vEYPTlIZsAEpPECCmKJFQAQZbMAE9AfT4aALMqGMNIhdTEVnsOEs+pQbsp6axEmLxMlBSAvRANDu nMyk+P8GnKwJRRCi+gVHO5JJSeDKzFCUCykFbvgOG/TBCkwAGwybvCTKIeRDrlgb7Aljmugjl3QJ oGDIIaajIxJXjmnhrsBLohCIrvyH7RHNVe0Lw+XJt1QLgOwKG8ALurgLGywLf4BLuEyLrjgMdc2B Tr3GhgwVxPyBHeDBkOlHlllCPuABIRCCzimKb/zeNOpKrgjLgEjduySKF9aJrHmk/qmewxVJPpCg KPDMA5CAFdDVA0gNLlhBMPnAKP2WhUXCBKzCAzhCJ+DBJ8RbPjyAKDiMXsqlBfBCln2CDUUcIfRB HMhAJwhACMhBN4SKHOzABuiiNBJBlUwC+5jVCtCVCBT/AlUVQj6EkCfIQB8cAkP+Bxs8wBX0jADw VrM9zCfIwS/IgCOwQjW0QoBsADjUQIaA5Ufy39ugAjGkgSn0QC4gWMUoUoe9TwQ8Ax2MggmxAT5k BcIAQllGwB84wDAskCEQQxDIAIfZASOYAWmKJixYwMv0wngy5yTwQQYEQw8kAS2oAnDixhucASBY QCHQwS74AJ8RWA8gFQJQmhoMQj6EzB/NgShYQN3MwS+omh8IgRpVqACwXVlaAR90witMQinhgThM gPkJZ1jGnIWNwR2kAQhswjXw2WIplCHJwR+0wSKVQsiY1iNY50LoSCXgDwm1AQLcg3/tgQBYwKi8 Eqmo/4GoaZEd9FEj5MMuRFUScBMSMVbc4cNrfFcIkCcYIdbFCEEF9Jch9AAC0IHHgMwfCYIZWIEP uIonTAIW+YADKIIi7MH1pIHHEIP7zEEvmFAbPIMFEEEZSFH+mSgMcY7nxAEf0BUliMBs7QFjLVRk Edg2cZOOWmdHkAEbSENpopYdQGoi6EIPfEwgvFJlfcAlRVbIYFE/7UEiCBJqMRZQXucMHQqrZZE+ 3cIB5AMlJMKvooqe5sNH/ZGrYEI+gEAg9IBk1RYGJMKoioAdGMJahRAePIkPZMAedMMk4EEdmB46 Iup6AFU/SNkfuA4zaANiKYIhUFAfxZKq8hAPfdhv7f8SUyaXj8lBEhzAJoDCJqjRqaoREqnqHkSW qrjqJhQsH4zXHVBQ7tjqV43BpVipPilCr27CJsiCLPhBpSmo7aCXj4URAgRDPpgCHZwqB/DrOoDC AKQBdSKJfhCCx4AAIs2B7kjRgogrLgFVbuTBIvxBGthpKtkO/MiR/PABHTjAJPSRGbDkrLxNRCZJ z0SAD8QTDxkSSMkCFzVpEviAWS2SydrBH7hLHBhZH5QMQ0SsCHhCkIrT7AyAYlkaHJAmqYTVtZrB Q/GBDziTGYgAAuxBIPDQM+UDFBXLGJjBDCiR4DVkcnylzhIMufpOBIQAElUA+5iPHNAM0RjZHfwp LcD/KQAVqk98FSTkg4BI3Y8KgDOVAtuWUO04JywIAmkOQAOFgB1Q1XYNy4BEQAS8i8lMUh5EgFiZ ATHIwTYxlBwUQwg9AicQwr3CwR9QXB/gwZ8KgQA4DB6EAoKaQS9oAB786P3hAy/dDx/lDjjkg0q8 0OMmasw5XCyIAPv0AM4gpbEZyxkYW75kww2lHKHQmEOIgSvkA7GNAS9YQBA4Qj7IAByUkAGDSivE gZJ0wg3BrzBI4QRAALEhW8iNA0MYBD4wQBCIwARMgvFg1zRMgFOJwCQIjnbqh7WVZByEgAXEwUyy QWPmwwT0gAWQwhhopx/aShnEATFcStzlwfmm7/qy/+9gFIa51AEgRIK75MHxLUpJ2F8esAEuAEIt zKQ1VUV5CEd8jAF9UF4fiFAjDAAj4AJJygcDPPFWMos/4gMuuIIO4CzrSYuBuAtrjkEzHIJ9RMsU 70azJN9x/Ib9MQB99MpuHIW5ZNMk2Gz1dWASa47qsV4V9yNiXOTvIcdmJaBHxGCLOIvUaRoNXyP2 ecv6FaMqmqLAWHL6wV6fwN4EsmI20rJh+EqcTAgQTwIJCEjjjsWhTrJsgGQM8l6FKGEqsqBj1CFn YIcM0l+xRUL1yR4BdoRQ/qAQThEg6oR5ECMrXjMMpgUyVzMRruETksNv+qEL3pIwP8o60gURsvN0 XP/hHIpHHX4g9hmFUDZFEgIhdnzGaLiFGVqIEprhiNxzAF4HOx6FPIdrO7MHJJ4FAQKzJ+JhHT7K eKRIQTv0bGyGEqKFLgZzZTRFUHD0Qz+ibazeSJTEMwrMFU40rcRiEJqGZ2yI7GVja5hjZ9hzJr4h JYphNUtgRBggIBKGJl6hSJv0SdfaG5wAfRxCDQBKNpJE+vHEMDYchXyyXdQy70UE8CFHFugAYmRE UIgjUmjHR88eUQCdcRBLsXBjHgAM7+QsHpL1eaQ1MlrEACm1MNcaPliDDe2ANCOHtyQL4ezAGHQh PhZiUWjkYv9Jl7T1GOyAkPBK6XohRjY2b7AyV6j/NfvpBjhogg3PDGMSwo9C5bcqx4J8IiHm8lZX M53UCSaeNEqbBUaNwY8i5UwCiEl6TfZOwK/xCq5cJbEMiFUKS35Qi7VYJdEoCRzAz6LRMK9I8ela C7FInUlGEa30DlVypbVI8ZBglx2sAJuiZ2mGn3X+oaQAMbhYd1duhO3lx7/gLG0XDHHiQ6fmw6IR AicsggbY0CR8ghkMgAgIgRzIwV7+QgQEkxz0wmLGwWfmg/weCR7IwSeQQNB4VjCR4DCogQdJqx0U ACc4AgTPAS9sJitAcNl2AmGSguj2DjCQTRwQgQ/wTBzEeGNmgxl8uPHqF+3YkAiUQz1+hI6QAopL /80ElIPyTQAnxAEnyAFeTkAL8A5fT7LqYVR+9+kj5IMPBEOo2QGLJkEQDEIhEIMZ6CsIfF8QZMoD BEEjEXirlJCBh8IfwAEfIFUFBMEHGAJ9JgEm+EEpMIJ+Z0+v3cEgAJSPLZFqIYAF4II1XRMwJIMZ tME1uFmT5cMnPDfS9rkfyMIueIwPmOzRPNtBlgERFPqh1w3JdU3FPcIdkKYFiIMmTLk81zdEp/Rt /2gpwcGWG1IbeOwe/BE4EfjF7MEnDYBpCUAfvdGpdkOmOI4aGAIIyMI1zJYixCqY0UI+HFKruMof BEEWhZTgIooUCVUZsMIkGAIiCEEiVMEesACSBv9SGsDqMNmOxxZUlGrqQohvEHS7GXw7qXwY9l4K HcgCI+EBjxa1rf8UD942UwoCxGu7ryuoffmCHGDRYVkAtFICJeBRmq4Z/JDRaUG8H03To37DLCBC rDJMmhHrqYoUwyCrnNkWwzzSrAjVGfxpBXiBOXiBCDADFCRB4EaWnFFQyLQBadqOGkTpfngXfkOO vCLrR7GY5DStHxgCKOg3FIlBrS98TFw5fm+5q8jup7b8wH7Rl/bAAfBrv4LAxxuYL4g8KZXSCgiB LKQrmCKC2EIpsYLUKPg6dSLRaXEYIDxbP+wnHJzRNXCANlhAClCCA6wSY2WR0ZMKafYRaTb9NUn/ bCH4usyf6gnVfMKuFRwQJEB7/dffd36bzx0I+nWJPVnJgY95uAWUke0wjKG1bCAEAtGD1CNozRwY mSEILYzSqPvM7YKqgd/2UffM6yNcV+jirOcQQhLcgxAA1jVUQcmSzt6f+Qoc/5ZbFx4wZTUdBTYt v6sgwCQIFKC6qhopKPWpRJX39X2PAVNa1aZIpH6oQj4ABJw72SbNEVhKyAM1ZswggCNIjg9vIBxY +EDHTD5AY9iMERciTZoKPeQstGJljkFG+QTyESHKjCgRfO7M0TgGZz5I+PT167cGH5tO+YKE9JNv kpmajl7hmRMhWUo4lfL1wQkoXxky+/atEVNG/9PLmJNoChLxR40aBPkKmVl5hkxPf3Pp1rV7F29e vXv51r3w71+Dufz2kYGXD/FGSPnO5MmzeEycVUEmLfoDp8CkSXIsBDFoTE4+C1V68DGDJ9+hM2Xq 1BLRw06PEBOccuocBBDWPn3wiLPAWRweqzod58nnSsy+fvzQvDmDKx8JqSKsxME5YUpk20FwH8pX p7F3nmv6odEX1DdnlHHiaMg3YdKDfIwIqco3nl9f/fv59/8bmK5+zmOtjjLcwIcMMsQQgwx88Gms DkggqaEOjiI5BJkzKsTDjDQMSUMEAazTakEy3KgDkEg4GgPCGiRcrYzVzhijmUOaYfEMBxVcUP8M fZTjB8g13sAnxjOMLCNGB5WMEZcXDUSQR33IA3Kf8/KosZk68kCyjlgAyQQnNpKUcrn+zDwTzf8E m6ufKhlUUB8fueIqTn3eTLBBJZXMgwQZGvHDhx7iqAOf5Nags8EDoXxTxwXjZFBJOOOcc040+gmQ zjc01bTOOfV5A1Io5ZzTp/z8adPOSMUANVFFJf3RVDRlnTUvNQfjx6dDuyrPp1551ZXSOh/FB5II HJGDBFzg8tFXVCedE9iugv30WV15LdWf/LQtD41uvW3W0mjJaxbIupg7dNRcq5yUPEvLpRXeeOey dbBsgbw3L1x7tdRXNOgksqMC4/Ip21t9vVf/337pFFbYXcuM9Vb99LWU31jfpWvbUhEm11SI5f34 THrNvLfXjrNFNdRCe7p0ZFyrBJXHUOH8kdaM3S2YL4RB3plnukQuOOHlPE541259QuPQN1oVtd2D tQ0aXyr1IUNGN5CckaMyeFIOaI4jNri8hXvkqlmNgSy7ZJJLxvniu9ROO+gye+5L5LMXJvVoS+nU oQWGU3UDmUgay3GKE95guOif1vURDVPbxAcCTTRphQ3JUVkhlFc0gaeFfRrXd3FpwW1zcUhrUE3l hX0E1m92p1VO7rO5zZtfdJ+VtsquGp+bL3qB9DdlBWHWlFFsHnBQUTfy6AiVRawSE5wN3HAj/8fp VR7W+oHP1ueMsOTgpQ9JVljBinxW+EMTbDz3qco8HVz12ThZXbJCrHDS2v1G84Tx6kZlTk5oLlvX 8IQlBiW5yn1keIPn2sY7vwBmTcw5zxmUkRuOrKY4ZXCMBsMUmUwA4hBxcMof7FATQuBkRdb5YCxW Y7U8MCBFLOJJ4/rxhjLEYQJ/mMMY+hAHODQiH4IgRB22Uh4huWEMnABELMR0BkUhL0Ydyc0qnFII lggHhZ9YIkc6ghMvsacPSsQFGzTEhg8eQiuwQ9oENVgHLSEpRss7hCo+YZUV1eIQghMDeRxYKwie bB/4GEMnfvOaXszhGPngBB7wQAILcCIOqP9wBB7u4ID39CAfnhgEYhATCtQwYg4recAkJpAPIlil D6ywwASCYAHGFLEfX+nDBD5wQpzgwYpw6EMZ3tCr8+CiB6S0gAji8IAgcFEZppxDAToTmiTQgZP5 kMMcRGGHzeTDIXP4QxAC1QMhDCA2rewFHuDgiUvmwxoAXIM+TpCPTxjEBz6Awxw+kY9YECIfIpCD ZnoBBzhYYZUisMAGeuKxPvqDXrEsQyy++aF4+jMCkyiGKYTgCTjg4Q9yMEMw8jGANqiBGAIIxAfk kIY2KCUfjVDDURCQlj+IQCCb/ARDBJAPNvDEJzbE4R/60MU+rAQOY+AJlWz4kTZ8FAFz6EX/PgqQ EgTAFA4iQMBHd9GNQIAiHyZliBWS8KEBdFQNfBCCH9SQBjkIYRAntUMEzECMjp60F0TYCle+Momp psGVu2iDJ0RgkEakIRB78MEzHSCCZ6hBEJUoR3IM2kd6AYUNMjCBIhCBiKMwZBdBSEIiktCGmqxA Dm3AREdDsgfT+qIkZhAEHPKBiTQchQ5qaMNRPiqDEJjhqECMQxlWpo8yjEEOrxgDHNlgiXzEAS77 oJIY8rAIH4QkDQsxgxyuQQc62PUOGUFAIAK7B0NsIqtpKUY+QKAIRezBDnxIAx/sYN31lpQObSBh GzY5gOjeQag+mlpkfaAIFnDHAYq4RxJk/xuIAbCAD4mgBCI+MANvmHSHRTyoXWxFGHzEITTRzAdu DZECIYgAEWkwAxxISIc0+CAfPbiGAyrrCzucFKV+SIMs8iHblWY1DXbIRVnTsElC5EEMltJpDodr JBTlY7hBZpMYzsAIIVggER8wxVG7YYFdYHUY2V3LDHzAARAgArxpMPFRNPyB9dohLXQgoY0zGpIQ EOUeDpgDLw9FBjYIwAKIuAYHOOADbUyCBWkAQSKEkIhUhIEStwDBJPKRCBM0og9uKOiEffZHC4/B Dh+g7B4WAgczBIIFQhBCBUQMBz6UhA57SMEHUJyKPZCUIXe4Qz78EIjLCuIOK7GujssaiP9R5GMO ZxCDT2Q5gRUUmXpYYYOk0TAX85RhDs5wQBVmYIFilFUEDkhCEsxgEDOYggNJEMKCsZrmo9ziFiEO RHxPrVozgFa1gsioGlK9ahT/oQ573IcYxiCKfHgYC1jIhxHIa4gkBAEEs2BGKha8B0Sw4ANByEcl eCs3Sj+WDGOQQRACYdI7OGUOwbAAC3wQBDV8/A8T8DS9Q2KCkuZCDgIxCFvMAESQP2LDajBBEExs CBoHe9gK7YMc/jDcA5UBK4SSy6nOMwY4lHUX+aBFhz6AyUHcwSocokMgatrjDWd3GPkQgJgXcgcS ywHkzUuJNlVuBpanwQSLADKd8oCHINj/IQizmEUQQlAUOqQ3DXtQBHvF3PGQ9EATZ5g0pRH6x1PZ kAIWMMEzBKGBB7CnBz4wQykmIQNC9EHtj7DCANRgiiCYBs/9pIBNBgEHnKPQO+QkhhA+IAsEzCAf eMjDG4SM9CBYoRw5apB30ngpl+GjGtkoRRsQYAFReNoURBGEddiwAwGooRhJsIMZjCF2pd5BBpPw gxl6sYJKxEESO0DhFCaAQk1MYA6iJ70peiCJij9O49i0bjfyYQLVrqAHiiENukEItg8B/sAU1KAR LAAQcKqxeKfC2oRqPgHFiIIU2MAaJgAXdgMQJiAS6oAbHoANoAEYXMkCQmHt5CM6xmAH/1QkEiYA jsphAtigD+ZgAHwgEaqgpnart/BhAnZgAo5nVcRgA8AhLpTrZLziCiROmurIh8xABDzhhGKkGhgt HyJAGJyCF1wpBOYAD1ZABEQjAmoBAx8AjlrADJEEDUewBEWj6PDhR2LpDCJhB+6JEFZhAgBhN1ZB HETjARBABuagEjJsEogguViG8XynTcTAamBET6YHEvUEH5SnDroIgzLIap4oZhxkRkRBDTqOD3zg pn5kH4YESbYmU8gGY/yFDFiDDbRkecZgC1dh2RYEYHACFhsDjvLASLZE+HYkZngkTyiRDdggDxzw VNZpEo2EGZ1IRooxYNqoGAWGgRhvXv8cz27sJEEcpXX0S37uRHiCkVrkZA3KcZ2GpA4sIAL+AKA+ oQwYiznc5HDGhX3cJVZ8Qht3pEHKYAKqIUeSw03wZAiD8U64kSui5SAzpSBpRnYWx2/mx3/wRIEY 6AEh0PHsRV0o5WjQplsoxSN1ZVz4hWJq5zwgQRNWgBeU5Qj5pSsOxR51xmL0BSTRpQbg4QTiYg30 BlqUwyN7smnM5m38xSMtLmPQhn0+ciiFxhqvEUDMBSO9Bi9kxyjx5WQ2kn0GBDy05nCgZW3sxSvd BiNJ5m6w5Ww2xl9cEig7BmHWEmzKxaDWUmfsBS71pYGs8Wci5mz8JW0w5i0Txi0Hw4j/DpJX9m0S 36dEZmZ36nI/XAYtFfNcqiQnK3IpJ5NuLnJbwiUgx2Z9roV0fAV38kZd7OQJbrJH4sREkAQSy4AN bAESNuAIr0V2viWA4DIjycYo20RpagA5aIYye5M/fMdl6iRRuscWtKY0GQZUDkc5nwAcDqdOeORB zmACNGEMjnE4p8AWUigZLMARfIBQXmVhQOV2cKclX8YgVUdYAAYr3pFrfNM9ewcbF3ESlQcn8KkS eooXi6R64AiO3KAZ4CF5rCZGcAKHPgAP4uAVKyQOJo6c5gAW8sEURgxBW0hHlhGOdEQiY6ZB+CdH kGd6nOhBeAgPcO6mlu49T/QuInDf/8qgFkhAEnjhkL4KAU6BEeIAGj5hDKABEHChFljhD/6ACLAo Ew4BhcaAFCThGD6hqcwgvUzhACnAKWT0T9QiHzZhFLJsFY5BE0gBF7hoR+PAEj6BE8jwKqYRGTbg DGLhGFABSE+IDXCBSIeUTKUhFBCA/3arl1BUTx8IQHBFH9wgEizACkKxxkwgxexADgQhFDIPMR4B APngDyZh++Iv9/BAFEgiFCLgN8oK72bCB4TgsAz17uwgDSQuEexgAIYhCHJIDnrg+WZNBlxJDmRA 5eDgFPJBA8zOER6AEADwD/hgM1brVj8AMVbgn87CJXJP2JptT/c0oWwoBEzgqNLAvv8MIR9kIb7M 4A+E4A+MYRpEYRraILC84a0uywyswA4EgSHYKxAMIRGeKxDUwK4Ci9ag6ygQYQ/SQPtizQ4ITA3y wQ5UKqTyoeMM9R46TggEAA5KYesMgVwHgA5GKwKIwQxggREsYBhM7NeAjlmbFUUTislKzr5MyxD2 gNbYTKNwzdP8IBVw8FpfC8eyLS3Cyg5MK8pCQg0yzRAQIR8GIS1mK6sQ9voWAs/atWcZgiGuFRFE QAmEYBZSIB92oaxAIRQToUr3AKuQVhAiIALawMQ2iWM9Vk9B9gx6IcMogQXwNR9G4ajUIKNWSyCS YDSU4ADy4QD2ALy4i9ZMLA0+IBH/TEsO+CAtpku9TJasFkLXrCuljqoNfs202KImsitwU0AEgEAE vIADKCFfM8ACoIBu7RYR1uHrzC6H+NbHgKxjxdY96cU8ziAOvo3k8qECrHX8GCIUVI6R6mkAEOEW ZuFaDQGrQkLsTGyk/jYQiM6f7iC9TGw+BGG1VgJpxW5ma6rjeraHfOgPchAKmKEKruEaXO2rdrd3 r/YoLoqR5GAFZtaKdilPVfc9E+qX7sBr06Bn/5UW/IntUAgrymoPyJWsNgm3Bivw9qAKEiEQ2sAO XoE94sARPkBdezYl8IAqGAkOfMAK1FUQrEDzMkIVVqNCVmIGUgARUsACZgBbj6K0//xXAZGsGMdA EnoAaa1oDCQNEd23N1WUDCbACgSgEUpOKUJADhghG+bg/SBkDKjDDxxA4hgh11gCDgZACDIgFXpA BNDsDhyBOq9DEuDJESyhFeLAO7LIAv7gEf7AAgoAD/BpJyYxD+JgmKQLk8wODibBCpJ4ie/AuHYx FsaYFoDVpuCwhm14MiuMMN4AEh5gEZhCGOKgDzIhAnZAFCEBG5YkFsTBEWRAGP4gFsYgFqizD+7A FPjAF+wNDuIAG1xBSVrgECoxE8RhAkTRFiDAiVijHCJgAiIAR8kIAk7gUVqRG4hAf1sBhWLBWDBZ k8cAGSBAQfYxEsTBMjhBE9xggf8kU5AdKz4JU4N8UUBPUVJSpUgco0M/NBZ6oQ3SYBcmwROQ63o+ BVI+VPhKE1I0iJsdJSGVRhIf8Zt5EUo8xYCKRCvbs5ops25Qhhvlh1MSZ53exCBTZTHuzgJkYLdw sldwx6Dl5CjtxCDR0jN7Umxihhz3JaG3kUwUM6APyney5Sw1Wm9gMy8RkmKqBB9g6BCUYYaT43M2 hjMrJi/Lcy/5ci43klR0GjBTen1IuqStuSnrhSrNxWTARlrsER8N6H2YBWf4sl6uums2El8CgKvP 4Ry4OgD8Aay9mqvbQS3bRi2x+qiX8mfO+mvYZmNeZqTzg3SohWzY8iup8mIaEnb/gMSrPcADYAAG ANsDziEGAFuwATsGvnqtA7puQOdQrkVvItszDcgNbHKByuQqn2Uwy5Ez26QcNzOuMZpM2sEDliEa FEABUEABlmAeYGAeUnu1W3seCruxq/ln8BFmjhOjwXNqfmsMUgOn2MRNokQhC5qdF2QrKWWdGsQV 7kNKzsEDlgAFRqAESgAJAEABeGC1rRu7tbu2w/q23Rc4BYRI3IhC2ygrEWRDRWjWAGHucEVI8CEP 3OhJJpFACmR6+DNJthE6VXM9t4ILXgAFkEAFpEAK6gEHRgAAAMDAEVzBAYAHbHu8VVdkzFsTFiEi OmEOrOMYKqEVfGARgBmFWGEC/+RgLRhhDIpoRTPhFU78lDqCFIBBDiYAAX6hhwiBBBZhER4AENjg CiABRk5AEzKhD4zrptwBDJYAAMKBAC7hErahA3AACUrgCJ48yjugBFDgBWKgwi0cG1d0ArJhEBxA CLoB1zgjAhhhLcYJDjZOAAaBD3p2FAUEibhpFMwcAZwiGRDADwRAs5TCBHpAABjBBHwADyJgEToc /QoCD1Zi2ZScB0ZAAqAcyhOACXAAByrd0hPgCABgCTzgy8U2oQqDDeAg1RCB8P5OWo8qCP7g2/IB FtJsPkq0MOogG2oWXwvL7DpkZ8MMmvzAutqgFDAjH4KBISahExjJuIRKyZm8A/+2wdIvgQnCAQei fdqpYQQmfNQ9NgK5pw96GAMQIxEUwRDSq20BDwFMzmuh6RFKtOl8IL1cIBXuIR8+qgKSgBI46bwA zL4wQg2CwATSQACEYBrSGCtyxB24IBpQoATeQR7iIQeoHQdKIBwgXuIv4Qi2XdS73VkdL5bygAjy IRUOQBsYDl/tANbdLtP6Fs0+qg3y4RHy6zwwLBFcgN4/gA/owBQsIAQOIArqFl/z3QS7wWsrQhEG C+s4YhLSiAvmQQFGgBrsgR5ygADCoQSse+qrngBwANQ73uM/1vH27QwWwQQcbvB0IV/tYAVS4g6I Lg3WfSEWIh8sgYjiRJBCIAn/TGvdTooPgqCybiFv+TYNgkHccAuvUqGj8MAYy8Aa8OEN1kC6mbwE qKEe1EELsr7BK//ytQAJUCAawD7s33fsvyIEZMBDDEHeT8rYFlgOQsEMvgoWGOJBVYE9yb4VhCAB GeIT4GDd23UP1mIhGuGo6ADPPI0OTMAC7KCUtaYGdKBH+kG6XyDqSyABCKAEAIC1q9v6sV+7YeAc Rl/sm9I83AArZODvYSMldmAK3IgNJmCL/2kSPiACJK4BmaXpfOMB/qAHAMIRnl8WfPCxIyffHDz5 eqwwYaETHjhmTOVzQKgOPjE68unbh+achxcK0BUpkg6AAh5LSp5MqeCFh3P+/2ravIkzp86dPHv6 /Ak0qNAL//418Mev3z4xZWJJIhELWqQxeTacwId1Q7M8bMYQ0URqDKAaYtb0U6oPH5tImjQRYVNn TCYSqD5lOjRmTK1WmiRBG9MVjycLeMbg+5hFh9l+IuexKyIBAAoF0V5Eexx58otl5wII/Qw6tOjR Q4seRapUDL4zZcqcwUdGjBh9tGm/EUMGn5vWr9/s68fPH9rcbrDCxtq6dXGsbty81s01yIMxbsr2 Q3MWuMhl0XgoULDkBYxlMLp/D78shmfS7Nu7f4+TqNGa/JLus/2G9r7919FgV3qfPm/k9xFw9aEW YG374Vdbg7W9QYYr+diCj/9vBhroTwDbvcAhDB586MEyHIrnQQw0wYdiiir6JN9pSKH233/1BUff jNedhV1wNCKVVIzZ3QhkkP4tKFuBO76oYQwgfnhOk0ou2dmKUk65Yos5zTijT1geuBONW27Jo031 XbffYkfeFICGTabJppqdrUdlnHKSZuWcpOmYnY527smnnHX2GdqBXAJKaKHt/WloooouKiWijD4K aaRBOSpppZZKSumlmm5KaKacfgrqlJ6GSmqp7I1qaqqq/oTqqq6+WlOrsM5qqqy03vqprbjuaqmu vP76KKVZigYmsMa69yee/uX4Ik5n8vijgXoeS21p80G7hm0f/fZsUtn5B+D/gmv8Bly15gJVp32q sVacGCBxOeaCD+Zm3Gwf/SftkWNi+Oy5r9bZzxpi1ADIIargVQYZ79qEllWrtWbLIQxsMEEZbtRA jn77lRntxuQO6i+sVvKDRlqH5DOBHEFYQEoZ7vZD3z5v4DOBJmP00UckFkQQhyX5AAZJPsYNbe99 uGFFhoUgh7zqyEvlAUg+aqjRBi35lHNYufzsQ0YdjoRihhkDWJDMQozkg0ccfYxxRlxddXXGc/iU EdcYdZzxMtOzjrwGGWw8kk8agaShhhyalPFGuf3o48YYcnywxwBCRADHHHAMko8gdxQgRxxzZCPD CpPkswgugHklQj4i+PDA/xm+9as3qU6rhXkahgSiRg8knKEPGsEtXsYcdvABwiT3mFE5HpirYUYj +VD0Rz5/PFOKCB/AAYcGFpxiBiw+LFKHwrDHDmqd++Azxin5GJJGGg5YUIvrMAunTx5w2FFFEEEg gjwcykuthuWpgQ9yaEMbBiiHsMnBBGaYGgHZcJjxkY9T5kOf+hAyiUlwgjruGtMb7GeHfLhACA5A ntnyQQc1jAKFafiAHQyohj/IoX35GIQa2kdAtuljfhOslWmQcj42nM0PjChAHKiyEW4BT3ghmIUD LnKHO8wBcFTDBAsPEjYzyJAOaaghF9OQCzv0oQw77GGqnEaGM1TieXhYm/9rNrLDpDDOcXxoXzdq WDnMha0Q+QibDPEAyD/YwQxtEAEC6DC4g4yxjGYs1cj68YYzRO2IrMGHhKagj8Vw7QwT+MMcLMcK CxQAD4A7Ifb+sIi8jEESjriDFidhCkUIoAdyWCQPG1m+H9qHDEErA2xkQ458wCOTwLkPzWzGhq6I wwKciFpeTpYXTUwgD9SUZhzwYAYT5CMfPriHHeKAj31IEJeY+iGCbrOtceljNtyyzzpjQy/WJKc4 uyGabMiwGzbMQRB0MIQhriGDMZBhDeMkJ6T+RCZy4WhcH0NNwNbAUKOJAZ0O0tiC0ngIcQjAD3yw AAXIeEuDbipdY8LXt87/giWHeussHuuPS02ammY8YBFykAE08Matm3QrpezxkqBEyipz/g4N+4Do YrSmr5SWNFrRgldq5naGPFTnNzpFCnb4Y9KlCQVPRS0qSiPlpTD9pF9hfU+yiLrOIpGrWT3pkY9+ 9NN4CahIZhmUO2UjGwJtDEOfkett1Oo7thpKR0n5KU/wxFR+mVWoRE2jayxGhgLhC0sdC9BfLdpQ hyaImDCjEVqgKs/lVGitzlqp1nhE1HXxJokgyRNlE5sv2KJ0fPs6KX9ky1R5YTaxr3VtbcsVK3Mq hQwn6AsqJBGJu21ErxHdrD5OMAXWIGMDFoMNPJywrW91tUH8sVFauCEJ/1Sg4hirWFvUEsbZk6oz u1xlCgOuMIEJiKMFNUiagvizsYrqB6K6dZBXYXqj/tbGCcP0GGYbdBt8NKMc1SXDdSva1fzu18BF Daw/RlYyN0QtFCt4gAWscMQ6+BJp9xwaVsoxgTHE4RWLOCIb8jCBDfxSwgKiF1ZetsszLGICfCCg BQZwuZ/50l0ShlC9jBQwpnDCAuIABCBIMIkJnKE5xomNbJiTHOWQOJ5Zfo59tyWvBOtGtPjYADhg kxt6WZlezqHbKifg4jKAQ8Ym/uXRqGxnNfvGd/xwmhjUmI820IEOzhCCBvyXCUBM5W5xSTQgknmG MUxEEASsHCFUyYZKGv9nN2foiioAoYwzKOw6aRlDJ7lIBz4EgQ6YgwNg8Fbi3eQFEJBgQNbOkhZc WIAEa3txDVqQhzqwIRaAaEamXdMVscQiDnHAxSE4kcy6jYHYzO5DM3Eh4uJYWTWcVuWz85LMTOeh 07iAxCEs1jZOfJoQgLyDIC0N7rcxQNF2G7cqI/Hou3WlFoeIBN7McmFd9m0MZxNcIAJhh1yowRP5 kIMIevCLiWQDZUHIRyviALg2+GGb2wwFHPLBiDlIB9xEyEcm8PCJh/fAApXIA5H1cYY4DK99gdhE 4DaOPFRMs5opJkQBLBCECeRDHKN+GglEcOk60DMPN7OCBeTAZDwsJB//DxCBHYQgA0+IYAIWkAH2 VhAEH/SgB0IYgB16sDIKrK1m1ISxJvrAkAhMAupen8MamT0HXlhgB5OwwFQWYYGzC0EAdFghxz2e j0dMpBP5cIQIgvCLhcghBHOfRA8AOYcIWGACIrDABuI4OzbUjn2GmIEDNj4AM9whBIO0yADaYIZg aGAOVgvEHlJhBzrA/g75KMQdPDEJy83BCla4gxpE0A32IcAChinqG8oQh8ft4XYOmEEaQBE4M4TC EaqUxCLgcIdJIAD2wiDFYbKlFmDIgJKzmdsY/jAJYwhCFCL4Q9jykQRnpMGK1yiGGpxnCgMkBIVw Q3IgBIMAe3ZgBZXj/wiSoEqLsAKuhH/D8H/5QAyCwEfYw0efcET0xgg3ZAgIIAJ7sAcEpHvIkw+N 0Dz58AlRxHphYwdBEIDPQEJm4ACT4H+CUAnl0EEVlD6BEwimkAQ94AwZkAR0EDbBkA+mgHqDkwaw t3GGcHtywDyak4JmMAz5IABtUAyDRwezhAhh2EWAcBgyUwaE8Di3IwAkRAcbhzt/FEgJpAb5gACD YwZxwDvGNAYQ2AevsR9kwHST4AlZ1A0iQEOj8EX5gAm6N4d+EAguNGhpQEBpkEIHwTx28AeAhAdy 8Adt0EWYMDVtUEMBBEAmEAJtBBhsEAeCUAGbwAfXkA+3gAi4V4W8h/8JaZAE15BFSkgMgSAHfEA1 bYCJAzQDIPCEcyBQv+GD6rNNQpAEw0AHw6N7gpYPfrAHIdAQSeAAe9CG67MHvmAHzKN6vddASZAE 7jMDB+cLHMdxh1CGz0cIIbRNPSAAgmAGbiiJg+RHL5QGHJAPMxACCCAMdWAv6AOBR+QG+YE+hJCC MLRC/pQPoyBodDCKB5QPm7AHH0CFakAHgkQ1MTRDdMCJWTQ8g1NDBiSKfpAGG9c+mDgHhHBEfTAH D5APiVAFsBiGlphF1WgIdvABB8SRF7kHPnlAbfCLaeANqZMIJtAIfeAGOyQfP4AUA3c2aiBF/gMH vwhDczgKgaAIKeD/C9j4ASuZD4PjQmFzBx9XCA0kC/ngDT4wlnTwAYmgCIqwB2oAB2ygMNkSc7+o eoTQB56jPoNGQMHokW0QCMHAAUmweXpJG2kkCT2AjBqxGpLWezBkRYLTe/ZoBvlAC2Zgj9XYQglk jytAmu6WeyKpcAbkkybZCIIQmqNAloM2PHAAmMzWCWU3C8xgc4iQkfoogSqplVNDkSqJiaonCJzo iXsgAB9QcZUAUl1QFAsARGIANc/jYmzQBzIQBFkkAPlQCmbwRYFgAi/ER34kB3MgRQyheHCgBpPA B0uoet8JArgDB3HgMr+RFmzgCJlYb522RvsYjASkOQ3ERd+pl/sR/0m1kA+WEGKR9gl40AMMFDYm EATMk3ifNAf5UAmfpJYgKXVzgAqLoKEyBIPAaEBa2ZmP8EkMwQj32EfZdHlqw2ymmQZ7gAg2Fwip lp5StKF+oAYP0J1h853+55Mtyomu9EVp0AOawDv9oAdF0QSoYTI/M2VYcQbQYAEIcAe9EAQyMAeM YAUDoAamEAR/cAetBgcCYAG9AAcUEAf5gBd9AAcfkA8h8JLXFAR2EAxmUAAhkDWpVQY1Mwa+lBtn cDITcTZk6gBCkJ5wMAECoAbOEAGL8G9/WAcexgurMAacUA0TMAfaUwiCwAgWMHsMAQiqJKeqGnKo pEpTkGLRtAhSF/8KIlAKzxA9f4A9q5oXiQcHgANIvbBrcbAKklAJj1B2geAHFad62uOmFMAQg3AH sLClXfqlabkIDpgXE4AKeEACfBCAjWABZLhDC1AU/3ADwrEUZgYbtUEGZRAJFWcBD3BEsQAMFpAP FuBxObMDXdEHNJkPJGBqDMZ0tbADRMA2ZcAGuOB0+TAJDzBquEYGD9ACrLVOFJMX/5qvVkAC9DoG 4pA6Q5cJT5kdaVEHRCB0DisOU9EHvJA6IsAKRzSwyTFnrQFjG9QKD5AcLaCzrYEN0zEGq+AIDrsC MsALRzQBDNYaExAJbMAJKdYVnyCvPhALc7AC+BoCAtA5gQmwArv/Aywrtfn6AJfGBhSbHA9gDWyg CkPrsEQgavsQAwZwrtRJMvfhGwq1FM5RB3djMbshbHkRN7qBHDZbXXhFHHamGo/lBgrDZyylH9ql D/SCbOEWN5wGaWVoIPeRRm1TB3nAG64hbHEzYtuGV3hlYqWLupLrNnkxbjdmukNDHDYbVWXAFeF2 bPJEu+iGpXGzt5pGuvHUNnCRMCARpedqAFSgWTkiV7hBBrExV83bvPbyEbRRuhrDUAfGvOw0Pz3y MTYCIM9LYgPCvM5LVb+jFEZmZ38FvUUTYR6zXRPmvhH2TlVWNAzVXNuSVut7NCRmG9XbIOM7UelU JgEyvkkDEl8gt7fn+g9N8AU8Iijea7+/0b5mAVNFNS438ls2ggYRNVsvolSE9SPN1VxlYmFiEi5g dhYRDFdfYlq+1VvYMcKT1cLaFVH85b4Bxl9AQlQcvMI/csP9EAM0oMDn2gTIq1WExcJ8NSxgwsKE 5cCGJSY75VNNrFhXslLwwlNNzFNP3MRcjMVajMRgHMXDUiNL/CU1Mls3IMRDbLw/EANABcc5YQMJ zMYK3AQ/cAENHMfkBANU0ABrzMYBAQA7 ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/InterCommsOnTheWeb.gif R0lGODlhmAAjAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACMA QAj+AK8JvDanoMGBCBMSnKOwocOE0EoZLMXqocWLGDNq3MixIEKPA0Eu/GiwJEiRAiVaRClQJMqX DFvGlEkSYUSD0DjqTKiup8+fQIMKHUq0qNGjSJMqXbp0p9OnTgEASCgVKk8A5Qaik3puoDkA6TBW tUr24jmp6gSq4ypwbNupD9kOdHtt7FlvYQemE2dxrTe4bcEBSHvtbl6Be98SVie460OYJisuNHmN lck5pUJiLqnSokSTmTWb9BRZdEnSJSVbvlx2J+uRmhGuxjzw8xxPkmErvFmwVM6BvH0nhFmTZuzj 12xTbM28ufPn0KNLfyiYsFoA4N4ipKuQO92xgrv+e3u4tuvWtuYHXwtPdXxdwG3dO2S5ciZUiZ4g 5p/OPzpx5Ch19tF+LNGHkIAhhabbgi7Z919Bv/WH0X/GLRQhNLcpFBp9pO0HXGYYOjhHhBTqViJI ClYo4YostrgiUzDGKOOMNNZ4lIsSegefVX9RtSMA8sW1I44YCSbVkdm9daRU5gi55FRPMjlQOVEm 6RB7daFzXmACUfmklVFyR+R2Q4713ZBk+pjme2GiOZA4UKIj0HneJNmmmT+6OWZhRoLjmHZz6dnl kXydiZA64xzpTTnWOZSonFoBwNehiUq1KGFc/QVAk49RNqF9911m4J6kIjfSarmJWptBuY0EDWr/ GHroUHAR0vRZaJ+16tGtKRXUKm+07QlTaLGaSlCKEklWkKyjChQiSSQGGyKxDVIr7UmgpujiiTNB puqC4A4HqokiFsdguTJh1iqR3JqKoEIsFevQu8eaSmG7DTU73WsUzuaRvyWpaJqntk1k7rn2oiuq tqU27PDDEEdcKpx3VmzxxRhnrPHGHHeccTgShyzyyFCJ6bDJJJelI3NUQqqYXliJJejD5/T553vX eJmVk0virHNCex25c1zyjWP0pOsBFrRUQ/sslZU0o3UdAI5JNY5Ad1mk49WFAYkYdtYlymlDX2Ha VlprNZkO2AOJ/dbQgjVdqph4runQyoEqGabWQXwZLdA4fcNVMaB5P1zdodgRjrOQahaO5UZnrb1d 2gI93h18a0HdsJFLggkfyoP2bGjoUV5kNUKVIuRl6Wx2nlBAADs= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/DistributionOpportunities.gif R0lGODlhmAAoAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACgA QAj+AK8JHEiwoMGDCBManDNHocOHECNKnPiQ4UGL1zBmZFiKFUGNAkGGbDiyIEaQKEkOPKlyJcmU FGPKnEmzps2bOHNGBMCzJ0+dMX/qFHqNqECjQGmeAwDOIDgA6I4CIKiOqVSqVq89VYe1KdKiUwka HRv2qlmwBYU+jVi1rMmWAj2p1AitFMM5pUbetWgRmtyGGi2y4vixZeC9fFvW5Qit8LXBczwmrYn4 bl6Xevdehnx348K5lS8/rtySc+KBdhGLhjm5tevXsGO3/mqWZ7mBT2+D1a0VgO6lALhea3sOrLd0 Yt2iHUiWnMCl3piXRSo0HVPh18gBMAcWezpxshX+0j4bvrxN0ngdOxSJ8DBNkezNA43PsiTBy/Dn eHrrUvI1u5KxZh9m10CTUmMbXWbgfvIpxJ5cBH424IQDwoefYRjy9x9cGV2oXoMghiiiTuL4ZOKJ KKao4oostujiizDGKGNP4Yxo440gopMVQU9FhVY5PDUl3TVA7jjQOU8xVdxV53ij4nLk/VQkb8uh COU13/VE5Tkl8kQOcrMpN+SVVSon1Fc/oWmmW2QlNyaZZz5pHU/imIOdaykmZ6KQYO3J44lCflVk T9eYY+WbUBI1aJplLepTnz45N+J4ZOKII2KeiBZhQvFJSOFE+Vl6E0gGpgcqhxWhGlGnolKGqqn/ GJnWGWkJ7uVZZrZOeBhit26omkuI+Xfpqy8Vi6CGm1YIl366ZqieXQt5mKyN9Ekr0GIMIRgqstsK 2Kt97NU37YikEmafprdm+2GEINmFoFwIplbYsbeWOm+zrWKKbq+p4SUsZ3mFC5pfDAk7WmTfHpwe qamVQq+3rUYssXnqVGzxxRhnrPHGHHfs8ccghyzyyCSXbPLJKKes8soXT+zyyzGZ4yQA3nA3qZg1 EUUdzjcGKZw6SYpI6U1Di1rinQJVBR6kj0p14p9+gpXkk21KZ6LNZZoIpaNZGfp0mAjFmVZ0cJK9 VVeV7uwmojpPt6ZAa40Nlo+xHW2Q0uSVmVZYcWqm/TbbbLqNaNaHXsNlT3RP5nPSQUv1M09L8vQ4 AEsCN3lxai4pkJNLahf42olSvjZ0YAr03TXilN5WbDLzVPPerW+XXOxYH5kkOJrTNujSU15Z9ZW7 X6mO5zSXw9XwPYFTe4iUFg3z8xA1zzP0kwUEADs= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/ImplementationOpportunities.gif R0lGODlhmAAoAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACgA QAj+AK8JHEiwoMGDCAnOmZOwocOHECNKnDhxYUGLAzEKxKhxI8NrHBeKHJnxo0eFH0eqZNixpUmP K0teTPnyJMiXHSlKzKmzp8+fQIMGBUC0KFGhP48iFaj0WlOmAJZKPQcAnEFwANBBJaiu6taBXa1e w6qOq9enXwc+XRtVbVunb9EqxRqx69uDOS2WWlhK4N45rGSy4ouy4F/AM6/97at4YWDDIh/fvDYY cUmVig8zhkmyI7TF0ApXlpwwps3Tk2+q3KyxsunUqFuvtOiSoOuF0GabvM3S5GGRrHHWlEq8uPHj yAuidQu13ECszuFGHwsgOlUAZa/ZPQfXWzqCcu/+sh0nkKo35mm/pqua/do4AObgtk8nLjnE5ejt 6zf+WirP/Q/9V1pNAvpH4ByM5YagQAp6JNlej2m04EAQlpQgYdc0uNFmjQWGYW6eFNaQhAcy6FJo N10YYoAlyuRiXoxhtJdDtbk4I0I1xtYibDbdqFCMwu1XIIBEAiiOUUgmqeSSTDbp5JNQRinllFQW FU6RWGappU7oeFUQVlrBdU05RIm1FZleEnQOVlVxt9U53jApZn5iojndnErOKRB9Rd15zpFEjfPd cfjheZehyrW13FGLHsoWeOLFJWmiUC15zXpEiWNOe8hZ6haSZippJnWgpicQmkVdY06edDbVFKr/ jL4Fq1FwIUnelqZCiuuuLJJU3JC4ApuYiMkJ65OxWSKLGpF5reSJShHO5iJlK3E427MjScbbhLNJ Ju1sKH7rW7WXZQtRs8SmlteKMg43x4o81uhjRiHmyCODpfw2bY/uApnugMPquGxInL1mb0i6xRsk hROehu696i5M444K6xjuRyAaFFy6GGVsWMUloXiTyJWFLKKGHl38r0EGSxwxK9iSltNhnsjs8swi 1SywbcBluJDOHbnWl2egcTwcf0fzqvRP6jTt9NNQRy21OgtNbfXVWGet9dZcd+3112CHLfbYZJfN 6dJop42cOXEC4E18uxbqk6uOHop2mdmpwyauu3IL1XfaR56tHQD11Yrkp4c/l6RYZTqp5+NKwm3o 4a8uLtCqSXZq91dynfe4U56TZZZVjVLaaqT5hScQXcqdR1SY+gVuUFeFq/65UqWXruvpu+tpe5MD /VkU7MbhLZDedOdNlJtEKQ+Am9c5z12jbgoUp5vvoZ66pNXPad6ge9YnDvh26cc2UW8nej58kK4v efBsglM9fqgWbifk2j9e/+PqZO92OWXpX1HA8b4tye1vaksgUg64OQUCKCAAOw== ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/DevelopmentOpportunities.gif R0lGODlhmAAoAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACgA QAj+AK8JHEiwoMGDCBMSnDNHocOHECNKnBiR4UGLDDNqbDhwDrRr0Dhu3CjQ4jWTC0Vy7LgS5cmV L0uOzBiTZUqKOHPq3HmTp8+fQHUCGEp0aNCcRo8mvbZUYNOjPM8BAGcQHAB0TgEQVDc169au16yq +0r1KVOtBJuqReu17dmCSa1G5Mq2oEuBnmBeK5WRFUG+dksN5MvQr82B0AiX+miTFUPBNxULJGz4 b9/GhVOShGp3JmSBjmcWzPv5WuiRMgeP/Oy5Z+rDpmc2dOny9F3OuHPr3s17otm2Q8sNtCr8bPGw AIpLBTD2Gt1zZ72lS1v37cC14wRK9Xad7dOk6ab+Nr82DoC5s+PTievt8Ldb9vCByi6t+3b8nfZz 2zc5pzTfynN4MlBeJfk3h2EmhQQTQ4xlNtmBLEGmoIQo9WeZX48JFJKAsPV2G4F76XWQYycZBlhC Jp24EGR3WfjaizWpaBBtC4p4340V2YgjfOIU5eOPQAYp5JBEFmnkkUgmqSRR4ezo5JNQGoQOWARZ hdVb5QxFVXfXZEnlQOdYNRV0Xp3jjZDWvWeUl8dZB2Sa16hHVJvn9DjUONPl5l5S36HV53temfUn l4S6tdSgQ8ZJlDjmjKdbkNT5uOVZklb545ZmeUnUNea8WWiaS2lqVKiQApkdlO7BGeWqmjHkCX3/ u+XHKoo64ubShB7WOutFukK1H2S2ZaghhKB5FNtGrK1EmEbJosbSRnlpVFmwLs4EoLP12WiRjCVx GGJHgnF7EocpilitXgF2SOODMwq4boe8/fqSbCt+O69oNd3GH7ot1diTbBj5C2+sMOEKUroF0dff ShsaxCJHCqbUYI2M1QRjggj/ZfHGDMIHLawPuloZYsYmnJEn1xKU2GMVv8RKtCNzLLBqIl+s12kg 7xqfrDoDpc7PQAct9NBEF2300UczhPTSTDft9NNQRy311FRXbfXTPWet9U/mnAmAN+ehWp1Ph1aX qtjgNKeOmE+eTfbYWvfoqEBcrUepj939aGmlqmeJieZakRYVtpt6k8p3p3rrCTfhcHGn6tcCiUWW qo/XBXihZcOFllyNn3Vlb3IbVDegfJrt59ijom46daxj7t3qdyd+TZ1EfY6blmqznZXaQ5E5FO8A kLkc8NAJGjxBZ5JZnuXMu05mW9vlKZB614gjPV29dT0U2Jprbx513g8OppjgPP+bpnazCeflcKIP pzrLf13OWPATBY74Tqbq9tb8U6T/4v3TTUAAADs= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/DownloadInterComms.gif R0lGODlhmAAkAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACQA QAj+AK8JHEiwoMGDCBMmnDNHoUOFDB9KnEhRYkSDES8S1OjJ0zVWpa6VYiXSo0CN1zReRHmyYUqG MFe6HMiyos2bOHPq3Mmzp8+fNgEIHSpRqE9wQ5MCAMq0KUWjA6EKlCr1GlKFVa+hA+AtIVJ1BNUB ABd1aVmCVM1OVXstq0CxbDfOHOhpLrRSDEtBI1h340aTEVkxJEnTLt45egmWOozYIDSGngTPdUq5 Zcy8ii83zkz42mOTLeUWHsgYZkjPmlWmrsy6tevXsGNjZSt0nMBzXM8OTDcWrMBxAMyt9ZZON0Lc AHzDPVdWnMCtAJxrTSsdenWoQn1fSycdY+rTsmv++hQvW6f4iI/nMtx7kn1Hl48Ln/48GrX6Oey9 C0wvuvzPmn2JNFlK4KVkYHv39feSQHhhFBJLFwVYn38UVmhhheIopeGGHHbo4YcghijiiCSWuGE4 F6ao4ooGVWVUOUKVU5ZSAnE3lIxnneONUFt1pdA5SI3FHFrJAQeAbeoYieNaSdZ2TZMALHnNORnW VlyFLtKmVpYcrlWQW0S2uKWWYXppXFtm8SaUOOZoV56GZsYJY1LXzAknmgd1KFCQSZF1ZpZ/komm UrYddJknBYY34HiLsugQSukl6hp5PFHqKELnnVYaZgIJNpBg4M1BWGqdabTpZi9dlt+pjV6K6aL/ ETVYEKqbNeSSp6FNeJGsG4F3V2kMTmapq7PC+uCAGnmaWHyiTrhgrjXFiuqzELZKbLEERbofSuv9 BV4pEj6b67P8FbZXt51eBOqnw15rGWSSenZYYgXhSlNn4ooL6bz52RdZvoeR1K67BBfsmjoIJ6zw wgw37PDDEEcs8cQUV2zxxRhnrPHGHHfsscIGhyxyUTQ+BCZO6FQZnXAjx3ZynnHhhBRxA6mDjo8t u8ZlUixvWKeGfqLJZ3QAXInQ0EIFPWhSOya15IZN3yiQOT5jKWicVV31pY9ZvWxVcmGNFWiZeI6N JjosAmrczndmlaHRYsYdZ9lYX033lCqjbTXZQHQLNeSUXMHN3dwC7UjzQOiQhZxyfptdN99QiWM0 XBS2bbed0kHJVTm+nZzyUOLofVuQ4Pw9t9p3q605OCwPFBAAOw== ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/MoreInfo.gif R0lGODlhmAAjAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACMA QAj+AK8JvDZnjqeBAksVRMiwocOHECNKnEixosWLEhcKnDNQo0aEHjl2LEiyJMaTKFOqnKiupcuX MGPKnEmzps2bOHPq3Llzpc9rAABYDPqz6ECiRpMWRSqQKVChTaFeOxdUnUB1Qc9Fdei0K9Sg6AaW Y5oVIVKqAKxewwpA61OzUhku9MTqGrSDHxWWnFNqpN6CrPbyVUq4cNGPIEUKhKa3FLTEDv/SNUy5 suXLmDNrLuwV7lGp4NIixApua8POnxGiIycuKNm4b6+FVnsVQOnYphsC7iuQVWDFm4MLP+kx8EaR CnXzRpxc7sHh0A8DH7kYccHHBIFDM9iQd/Tv4MP+i0/Ks7z58+jTq78Z3bVrimidfpcvf/xJr+4B mIv6XnZ+25+F1t9/AHiTXzmf5ecWgbgJ6N5tT+W333io5fbaaV/BlhtusYUmTksWwoZUfSPGVd9w /214IULnCAiOWxumJmNuaHmzn1NjBSUOhy0G9aJnM8qFWHbT2WfkZQspxhFijBXkGGR3afRXXUdW 6ZBH1zyn0XbAXXfccxt5d41CVFpppkaBURmSbiJZJxhJZsY55HEJFTlYdgg1F+eekLE50F8keTfk b4LxaeihiCaqqHitEejoo5BGKumklFZq6aWXhrPoppyqZE5Q3nSKaIoTGUibePRpyGlnOSLIH1OK PdoG41vnGJihOuQERc5auQLgqkDkOChOOgm6x6OLsxLVqpFe7TpVgTOipRZbCxZILFw7XoOOjgJt q+paK8oobW1tReUsVaFSaOK6M5KYIVfststgjCViqOK3KMYb4kCzjQYgh0GilmqQHYo2EGn3oppf whs66BqEJ1YYW3wLC5Tje0w57GPAcQUEADs= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/PricingInfo.gif R0lGODlhmAAjAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACMA QAj+AK8JvDanYMFSAxMmLKiwoUCGDiNKnEixosWLGDM+nBMR4kCIHht6DAmS40KTGlOqXJlRncuX MGPKnEmz5sxSBvWUssmzp8+fQIO+ZEl0IAAAGI8WXapQKdOnUJ0KlHpNqtRzR9UJVHf03FSkDamK BXsU3cByVgF4NQoWKwCt17iq/ZqQ6sm7BOfgNOhxL9+PKPkaZDXQ71+oiBNTDIkXcEJong42Jony 2l6EjBVr3sy5s+fPoDWOrQu2amlwbxNyBUc3bGnTpBOiIyfuaNqmYFHD3QqANWy2HVGy0hu6uHGo gkdWzisQp0TleJ03Pk59YuaNCiFCC4kQu3fvw7v+Xxu+vLr58xVxEkZ/Xqj79/Djy5/f07xt2xbd 2rX/+jf7omPdB4A5X+F3DWoC+mYagk4JeJQ3ApbDloBrOYiUVAzapqCFBP7n34e3tRbbh8CV2Bpq 4rgkol0N9vfbaOw5KKJ/dp2DIDhrzWgiiKW55Q2BVKF1lDgf2ngUjiPqCJhg1pXn0HUeRlkRZdhB dphAVhLnGHbkrTeQlZ5s56SUofWlZUGe4CVmQuIp1912aV6z5pZkUieYeMzhBWWefObJ2J51dgbl nyZF9lxglUFk6HSBljkmoYUlRyeVG0na6KVlxonppshZyulmtVko6qiklmrqqaimquqqq4bz6auj sHJmzoOx1mrafRZBuNt/LLpoK4/XCClhgVfdmCNs50BI1lvkHEVOXM0CMKxA5DAoTjoT4kqVkb0d q5SwUo717DVYeWOiW3DJVSEA3mBLGpHXoDOkQPL6GleIJaLL21ymjVtulDCuWNp+LToUMI0W7vii iwUrfN7B+OqmWm9KAltirwo7JfFAq824H3UyWvxhhkc6LPJv+gl4lsoYOrjha1QFBAA7 ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/InterComms/Images/ContactUs.gif R0lGODlhmAAkAPcAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/ mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNm zDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP/ /2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZ AGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkA M5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZ ZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswA mcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZ zMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A //8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///M AP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///wAAAA0NDRoaGigoKDU1NUNDQ1BQUF1d XWtra3h4eIaGhpOTk6Ghoa6urru7u8nJydbW1uTk5PHx8f///wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAANcALAAAAACYACQA QAj+AK8JHCgQWqk5CEuxIsiwocOBCB9KfBhxosWLGDNqvHhwYkWCET9eEynyYCmQcwSKRLmxpcuX GNXJnEmzps2bOHPq3Mmzp8+fQIHCHEq0qNGXAAAwTHq0qdOnUB+CA6BuoDoA4BxeVfqw48SDCMOe HBk27EKVZUOmnQNtINiyZNNGndvUoNi2A+3OKYWXLEuCrMReg4bQ00KR0DwlBCyYruPHkCNLnky5 MmSmBDEnrSownbivczwxTGx0JUzTli2jdpuS4V6/EFujbWjwbWuvDVenpqxYNEGDg0myhT07dl+E fQO3Jiz72ljku6NLn05dYtDr2LNr386dZ/Xv4MPvi5+LeWD5c+KSAhiXbrz7puUFYk6nXpw5zu/z E1XP3zz/pONYZBtcRem2kYH6DUWYbxLpxVds1yh3FlpylfLWWL8p9lpcBCZYWnO0CdfWYsExSBxF y5VUnIdOGWiaWn+tSKFcJ8bI4lELSoQbRCcJZ+NKFSmG4o1QrRWWQANu6ONAyoXF3Fqs0dgkgkRW aeWVWIqX3n9cdunll2CGKeaYZJZp5plchpPlmmy26eabG8V3jZxwXiknnXVWeSdX5nSZZ4J7ygcA On8SGehA6KlHaKHv9ZmVQFOZI5A47Qm0FaP6laNeOQSpM4564EhKUEAAOw== ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/Images/InterComms-Mailshot---Bottom.gif R0lGODlhIAMcAfcAAKfGzIScppe3xSlWaMXKzBMlL1Z5iN7j5ZKuuleFjYqptZKmrtbb3o6mrufn 6+br7bLP1pOttXukqtbX3Bw1RnSMmNTW16zK00Vnd6m8xcjP0mOIiJayus3T1ZustGiUmEh1hrS+ wwMKEe/v87vDxs7X21iFfEh0eYWkrKOzu2F8iyAwL7S5vg0YI3qSnDVkZnucpCdUWn6Wor3HyzZj V4WVnbPFzCNJV5u0vCNHSaOttWiVpEd0amuKlu/z80VsgTtrhGaRiWODkam2vDRkeYyyt1F7dztp fXGTnUZZaXWbtnKbnGuFkmuNmnijna26v5O1tiFCNhtBSnOco1d7lThle4SrrmOLp1Rqd2GMknSV orTDxoKjpTFZWTBic0JsaChVSJu8v6Sytr3M0Yusr8fX22Zye3ydq8bT2DJHXVqFpKLEwHqdnSxj cnaFiIyzrDNreZKmstff4qaorIOrpHGclExzl73R2LPNzjJYSjxgcWGMmzpxfpS0rKDByWyVsjxr cTJpdKG8wZSrrUJPW8/b3pS5vYGmnkZqkQ0hHHKdq1NkbW+VlJOcoz9qXnOXjSpeapW6tJuqrufr 51V8oZyztC9DS3KVrJy8tYygqK2wtp6ut1Jvgc3f44uspVB5bWKEnXCNpZijrNvX3mePr32clOPf 5evn7D9cg3mWp87SzqK8tsbb3oGftJKiqpKspWuEmq3KxzxvYqO80brR0H6lv8Ta1s/P1Z6msvv7 +zc5SVBukvf39+/v7+vr6/Pz89/f4+Pj59vb3+vr7+Pj4+fn5/Pz9//7+/f3+/v79+vv8Nvf4/P3 9/f389/f3+/v6/Pz7/v7/+Ln6dvb49vf3/f7+9vb2/v//9/f5+vv6+vr5/P38+/z7/f79+Pn4/v3 9///+/v/+9vf29fb1+fn49/j3/Pv8/fz8+/r7+Pj39/f2/Pv7/fz99/b4+fj6O/r6+vn5/v3++Pf 38/Pz9/b34CQlP/7/+fj49PT06GhpNvb19fX41xfb8DAxv39/f///yH5BAAAAAAALAAAAAAgAxwB AAj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmyJEh/uVKqTOmvpcuX MFuanEmzps2bOHPq3Mmzp8+fQIPmbLmyaMyjL4UqXcq0qdOnUKNKnUqVqcuiK5Fqrcq1q9evYMOK HUuW6kusKrWqLcu2rdu3cOPKnbsTJtqsamPS3cu3r9+/gAM7tXs3bd6kghMrXsy4sePFVwuzPOzy seXLmDNr3vxT8mTK/jiLHk26tGnNMg96zgU69enXsGPLns3VdUHPrW3T3s27t+/fHXUPxJ07NPDj yJMrP27c4Oriy6NLF+qPlw9lD6Qt285d2gNlPng1/59OnuTz1uWl+vPBvr379/Djj0/PNtcIaQxK dChRqJAc7svIwUAh+vG3zDC/zEffghadBxqDTknTARoUVmjhhRhe2IEyEJJljDQFLiONMsiwRBBK KfnwwAEEdlCINMZ0KGNEqxl22IxCMSAHLzz26OOPQP74Io5e+bAMGh0so4x4NPKiXQloKKkgkVTW +FleVP7EgDQabemVMQ+EKaaYykzpGy9HlnBAjBf582EhaDBQZpZ0OkgZnT55iZE/elbljxwlMCDo oAOWMIJyw5RQgjS8dJTLAwx0IKeZeKZnJWt3VqpTnxbxySVXuZQwzF2FDINcLgdEyeZHuQwDpxw+ aP/aoZ2ZynoTpxV52lUuhXB4kBwPHMeLHB1IQ+lGuYCIRrC2poeiZOgJ1yxJuFKkK6i9IsSAqb8Z U0gH3JrkZAmNThtdZNA+KK25IVU70bVV8eqrQQww2xsvisZaEy+FlMsucmcRh96/Jrkr0TUGPyWv tuHulkt+/tLEb8QE8xYTrbVW3O4BQTJ5UHVBDontvAXV25s/R67aUC68/JLdyyPweKxBE2ts8VEY 32hzSMvsp+jPipJMkA9AF20vVQsftG1v0qAhdEK5KHOAomgEWkh+UAYqzQi5NFTzzrGplfNaYIP0 6JhiioqQMiWgHeaou2ar9NGyjYDGASu76uKB4V3/ZQx2gO4njQ/Hfl02aZRd+uDhJvlT6tpy1Cc3 vQ3Hhq8cM/vzAJRrzvzPeiBK+vRAhjOeWW6KL266SLxWPpAyDEg++j8m07YMuQuhigasEj3KOcUC lb56Y1jibOXAw5v9+EGwy84wbbwsm7scy3oO9QNVDzOf8MkHpu7FAkPXvaPLG9R8WUnTS/drLHYN NQNOZ2QM9cu4H3y/4wNWnFZj65y/Rq1bW+zQN7mSuc40xtiQQnJBvdlN5FG78xf3/ueW/R2mf1uh ILLKV5DzkSV9JVufSa5Bwmt8ZWr2M8g1UnXAi4xAUWyaoAbFYkHQpA55M6xIAJk3QHENQzsCGtQy /w7wAOBJxHGzW1pJ1pOdABHqP94hnFTw9SmE2K2KHSFaCWIlQ4e4DIhPFNEwjEiTqGmHUAwQUREn wosmBlFQQ3yAyiT2w2WEcUQpfEgbz0goNc4xONX54QEGScgDeIdrNUQXBo+Sw4vs0Hw9pJExgjRJ g/hDGbfrwN68I40DBC5QD8jjQtw0SesUkCBb6hiQKjmREbBIk/4hYpg6KYdvae0XnSrlj1i5QF6U cpKsOcjm/jgQfwTKehThVwnAgz+J+AA/miyBHAw5ywPkp2r1ImNEfElJBWGyQNPkpCdDpC+GtOqT DKDmipbxLUmFMlfc3CXwLnk7bMqyk/nZz5oc8v+ofAaKiNKgZYGUuKerDON2WQsUoRSlgaoV4kDi 2d8NVdfIB3KQIB6EiD+mVrSfMcBf/hgG/NQ0ghIVBCXPhFMhysmQzQEtfr/yWUdn2jaNKoN6ixpj ME/KsgcgdBkshQiIaLrFj/nAmgQq2tUOdCL/mHBtaAiqR3gRqUCJciG8mFqUHsCMnQ7kGihx2Uil cdWHvJCoWPQBTvE4HrDmwhhT68AByioQzakURl6ta0/hxACpOsSlNCUZ7Ko2OGS0NSWYFFzulLWl X5j0RLn4hTTgtAxtPqQlbSyEBpL0AB+wrCg98oVPs3YgTMHkc8arkfgqatEWZvQhvBrcCGY72+v/ GCp4aVqjOROltoYE6D1l5cUI4kPc/+iReoXQbUPcNNQHPBUiwIqPMZZBt5COlLqdbQ92JltUgfgA ph9TU0mitiSNurRzDllPzy4qVDn8Ij6erGtzLTsQuMaJjGiKkzLoSpCoEaiFC/kPcdNZ11S1jb91 NVKUyjqCSMkJwQKB4DLblCgNJDeiiRPu1DSgJgynJrWL1AtrWyvAB370Yww4VKLQQNZtUk+EBhni R7bjkLO+cyLMmFr9IiKHQx2EiARpcJzG+FznTA5EdB0GGuibk/zy7mBCPgAyC9JJhPj0H/OLEpNP dFbguVR724QfgBMCLIQM8h8+gF+LL9s0OeTR/x9NO3BEfPCtFtpGN6iy8H4TyYubcpislakrYY6X sRHTiL0CeS0/T+wcOUgtTrh84JFgTBAZe4TGLe3AjtqEPTdDd3ZA/pyEeuU5XvnYccso8ol0tBR+ deABU1ZNmyFsEO1YWUn6AbMzr2a/XBzpyb07ko8fUuYfH4C3DlyIMqLUHF/fbcsHGVZ3Rzmehy3L w4n0xy+oJ2XXgI/Q/jP0oV0bSdgy+jYDuhutE4IyNAwbIZbuCKYV0rQdZ2TZnnaIo80crGGxeN0P 83H0HPjdMeeEV7fNiJKXEet/2FqYUGIAMR/igyQFjwFlWDNFHoa7h9TOIFo990SUjDcswwnWFv/B VyEa/qcOnDrblfE1AxCDWkWGr9DiNiei/6HolTGAGR87uaqFqVwjl4C/8YZIzDwW42UsBHtSPhgy wkQxuzFc36AexlmVMfT3+UoZHdAmCqkDqEhrxG4lf8jDDQL1ddPbaQg3uEOi53RiwzhV9rZI04ar KLk3xG6U/tjtyhma3NQ8JtZEzLdDfNqcw3bnPTenyIcD1L9S3UwVx2KM0w6RZ37nqvOGuLHYKCZj zGcYr8a6mfNT2UP7OPEICRXnfdJuv15k2ZpfyNoLsqKGIwRl/ZH4RrD37oV8vCBE9L1qsDZ5vXe8 ISw8kaDvpJXEB3rxNw+343MH+XIvGuiWhPb/P7LjHW0iOSFJp/jLUF6Q0Bfku6MnPSeL7/DnK2Tf P2ax7wP+uULMPshRJRRNk2wWgT1+JxC7RxC/4HYMET32tydpZHcIIX4N8V3LgAwcIXsOsWzMIhMw BxPW92GDplo4tH0L1H0mRoFWNiZmwgupB2//1xAfsn7z4X7D4R8zcw199kMBNQxLIlxiMiLoVncB lnUbVwiHgi8OxCLKJxJot1y54AOztYCewycPmBAJGBKD4xGbA23HFxJwxoAOcTtMxiuYM304I1zK oAwxY1pqEYLGcTE8QoIlaIKqgYK983NHZB9rqAwBFVDfMXHWhH7d5hJdd3jV4Yd/iEguYYMI/7hk CuEPI4BQgSIgPwMsnBQmpodR00ZmoyOJOpRiaJZwlhSBQMEnhYBgvDAMgFI0cgA3CpFARKh7swhb 17GGmzhK5iSFa7iADbgo+hZ4v6eGuCiGHxOFfeiLC/FdBDh+HUB4R/FM16QoEyJNvvALJoQUcIiI RDGHjNd4dhh7eEgjzacQwkWJBTIGdyAH3vEAGGg+aCCICjUotmdNhFIIYzAD+jgD2CQo4mUQv1As sYhcB4BIbnUftoSJVNdfD8UQ+JeBSMhzR4cQzFBTQIE9yaY5EXdsxuADw2BN+zEnCYE9E0dltZg7 k9hRL6KCxXRUBQI0B2B2q+cQX5g7N/WSP//DKBuXkjKlKBwTiabIbmlUZDBhJA01TcPAHnUEJ/rl hi4Bh0hxKU6Jc+F4g+RmYuBnTpuDBv43DMzgSw8gBzawBYviHVlJOhZpEHBFSLeTROlUSNSjAXLZ UEM0SPN0O3RlY3TlO2OgRt6hMl1YhO/iS8ZQmLywU3xyKJBiJi9keziBapSCJpomRSc1WFEnjid5 EFn4ezdVNQfylS5zJAo0ZzhFRJNkDAeVawqRKFtWbAwRUhv5gyqCU/Q3SoPVlV+pIgiVbOeXEMx4 Ui7BNs8Wlb+gVW2DbVCZhof5jYFWlXd4lXm4ZcrAV7BYEHYTAmUpRyfVkK95SgNBUANxH3//GCbv eBCAlxB2U45q+S3U1I7GQUWCeVkf0opFIyJ8xyH4gZ4T+RPf5Zj+xn6/V2+UgnpMtpk0kyrJdVVp 5m6wZWA6STNH4kAJVJvqU4HIpWvvByfil1+iclXe4nIJsWyOOX4TGY0WRjgXJFIcFkpPOXN5wTLL mX1Y4pzPWWJ5eJayVjUAehA+oAFboJDFN1ml5p0CUZNMxEnlB2/7CZC743Y+MAYstn5zgjIzd3/N OBBHVTXsCB5S+EO1FE2NcgCZKRCw9xMBYiYtd6XjdzdQA4y0yBAjACcad4dLqhDb9myRCChlFSrC KBCuGaKKMqc0I03WI5yCWhD4UqXR1lsn/9KIVXoUgIJth+EqGrAMCbJRLio23sicTVhRj9RB3udz luUteJo7D2ADY5CJnhWeV2hkSXRAyJCJYgI80QNjoZKKEfEAM1AvgIhHEimTBvGQCyQhxwk1xvAL 5cKOv2dcP6GEIYoGB/iIjslOCGagEYY9EckQBTdKLnWl+AJjfDKmIbRAB6Bp0hmAkdg0fdUQywZg uAITW4IUvyAqFpQs2YOpFySVhkejRgad5IijBPFlD4EMJfCj67eq/9CYOpdEImQfSNqOcxSYP9YB wLpcJZCqmbg1//CtVqqt33Ko8VmKuacTrBl7/3hZOoJ5DEpv4spAC0Zs4voP9qqHDlGmtf8WqsFK aXc6V+nlphPIbW4nKGbCrEhRL0iBZIlEZ8siIPk6UVTpnJ+KUTibO+qpZOvKZmSJpJ8ns4wKNURK Oy30KO24fmfpiGjGYhTxAGOgkJy0JNyJEMJqSQ9wohPxir+XXJ3Sqb8SOQihZCz5m6pxsghhoP+Z qyv3s3cTa8tGRiLVEDUpEPOaljWLq8snPULVqv8AezhDatwoDZiTbb62H7D2opsqo2TDr1Zpo/96 h/kGEbkwBqn6MoDYEpIrjgyLEDo4S73aWRE2YT9WpxCBL4siuy8ziJ4INUeSdxBxDX/aX117RHqL qD57GyUQswqRsmZWAsdioJujpgSBL7b/tzl9SjMgKkyUe393R4oP4bdmBq3ONJoGkSjuczF9pY2f C3Myc0Glmy51SKNR+zpTu0DlyH8TUQIzsLulN722+zwhSryAGCtxelV8ahG348BhUgIaQFdxS3mW +y4bHDy+ay3RG2QhbJ0rKxEkCVWWxb3W+3uPO34B7LUxmLDAOzdmNsMLYQydWGktHF6zszlT2RLV kGJHu3If2BowGqP8+7RQO46uS7PoRqEMIQ1jAFDkB4gKfIe3mxBgkrEvYyRnaD6Y6xCJMkuyix8z 4EAfXH/e+zE9NoE7HBEjTBAgYibs1IQTfBAJNGYsTBFrPJ3KZ7bzymTNOxBn1ju1a8g9/6w0I0ui kkoUSIgUbIOiR6y/+3sX+4q6qctDKbh8UryMayurs9SXMwNCqGRwKuLF2VGpZrbIXLxMFrwMW3AA zDAla2xIbfLGPBrHOSEHYUy9jTyGirqdwexwY2qtCyEiCEFnyiemcFyS33l3OAyUjey5FLEdXcc2 j4wSpIYz1VvJGXbJhdG/TeyvTwywMisnFGEMW/WwAcWP0CyzX/vC9WXBnWQDNew443uCw+XA0jAD wILOt7zP7KbLBkE0LGk2iRw8JzxykHgQZ4qFY3plE3HIBhGnyue5XYcv8fwPhUym03x/M4wfzTzM gqbNUWm0SLFwQQzOV9Ej+srE4fi/if8Ww7E3wKLIRtk5ttnBj9rpta/KEGDiwLJMXXmEL4cCuq84 dVp7ALsaRcEKagS9rBRKNCMqMQv9D/JrETrcQr2pmcfsyiZpRYeLwiaNlh39whbNY40MKcbocOdb cyhdtMaiFdhzYC6tnOKMyRTFrzTNcza9fOj8MG3cX07DDGccUFCaHSLpqtrSp9dgwQywBdj1bqh3 NWiU2ZqNRjUltle8ti/DdQQx0LlMoeDrE1YNb2ctxzv3XeY30WJNx3LQdRg9cqu9sSXQ0R+duSFN iAL01kLaqJdELlpxx2oxnRY2OC39gUmsxHydyaj715FHtUZEwIjsXLpLfvzYjvulxQz/vBBMLbsG rE7l9Ex/eN7ond7qrbHjd8Zj8CKhbT+k3SlrjNQ+wTZlxawWMU0IkUAlaaDIrBBhSdtlHRGuclUc zRBq3dsw2LcMANwFftLEjRRd+KIq6pkPQIXg3Nyc2px+7cTmNtjq/C41dR/klx2LDYjGIEqmHM0b SLxocMCZ+NYOkcrkt6Jj0t0eLdUXgTC2+rw54SpT4jjFXLO/rIDqO9bCFNsDMeDmGeEPoc2LqtvS fM0zLFJvvTnz0RJzbaKj+6KhicEuEl3LjcQ+Am59Xc6q+8TVndNHZJHbpd1R+sWOrTQHeDacpAF3 4MUJXeNjwpXE+x0mNN/7Da5ZbRMP/xDXaBmtI6noEfa1xjy4TC4QTn7RUF7jrZrgxlflE7EdU4Ll I3d0R9Hl9PvgYhMZwtVJUILhl1qvZ06HaV6V0h3YzgHF/TXib84se8RJPr27xdfiRUrQnucdd6AB uwvVIGHi0mBhaOOehF4RawwvO0HSi3rVDbHVloS3kn5raTvbT658CD3lDsnpEuG5n/7goR7EpB4T SlYmUckSRhFW37RZPebqMA3rMr19s97Jtf7JkZiWM/jOc56JOi7PQc1Piqi2Y2DBD+DvFYHYYbKi onzBPH4Ru/0nk/4RntR1RFOxEoHfKEZpAJ7xlW6dl16BmZ7bCk7uEWHuBwHqEiG/o/8+4VGpKNs8 GeNcHa6EwX2FFy8qlTaS74637ze6fIVdTGmJ2Ly+LMfuqwb/2BAR3iluwQibgeLJ7GOSicZ+VaFG wThsszqx1iTc50NTw59Dz308ESUfZCevrSlP5TdMES4fv+ge89qLhsO9zS5hgUGM706iScZyJc8y gjEN3bIO4ovW5g7/e5K769ttxu04IhgI7GAbEX6otlHqxd5R8BuhOcveNhNPxbZuyFNtZnzLPGZv E2LPqjRe9lfFJyIf1t1O4OD+9isf9xMx9wUB8wZ+92i47kcxt/WDffE+lfYBPwz3bYTvtELvEMVA DMEQ/dI//dQfDMRw/dif/dq//dz/3/3e//3gH/7iP/7kX/7lDwwk0AHdbwEkYP7Xj/7CwP3obwHu //7pr/0dIJdDwAJzCRAaBA4U6MwZCQvEFC5USKIDQ4gRF3bQMIQFRYIZOwCT2NFjRAYanpDQgLHk wCEkhUUk8PDjS4UaSHi0EGICTJw5PxIg0NECiZU6O44L4ayjw2BJlSrVQCBpMahROxBwUNWqA19Z s/bi2pWrMA29Roz9VfaXNA2/eK1luzbXW7hxcykr4cPfXbz+eNW9+8/vX8ByHgAGfOAAYcSJ/UqT 4y/xMAa5FE/2O6yE47946fLK2zkv2mWcO8slncuzv1y8Dmg4YPr03beoS8+G+/r1/7++lHUDJgbM 929gzoAPJ17c+HHkyZUvZ97c+XPmwkJsLN6BBHRgwkiMK64dH/bsITQMd9ZUDIuM6TUQpU6eJHR8 GjQ9Ua9hxv37FvTvtzDO/3/+AhRwPwKGEK++lATqQLjfCBgPvN9UKcq4CdCD8ELiCJjBuJqswRAY C1jwkDhn+nlwuJhmgEipqZ6KqpirsNLKl65C8mqsEX4JRoMReFGrLbZSK40uH1zLixm+ckuMgcES M2w3xRjDjDDIJIMyM38euOy0zWzr7AENSlDGNblgi8uz2OBC6wEv8aLNTNLavO1K3YLh6M7efOtt TzyD81M4Bn0D1E9B/zR0UEQPVf80UUYXdbRRSB+VNFJKH5VOlUWtq5RR7Sbg1KFJF5VuHkOBMQ89 B1NtatWmnljw0IPG29RQC4agb1VVWdBhVx3EeCIEYIMVdlhiiw1hCB1IQvBAArgD1MFZI8WHBWdh DWGGaEPNFlENG+1Q20dD9DDQ30jaM6KmFkqKmKSmehEqByapakYavbJRLLLKQutHIHl5y98hk+xs L7uUREwwxZ6kEzApH4tsYdyyLMHIvLqU8y7LNJBjTNnyOhPNM3NZhkePYyv5TTc/vhgviCfbxAOY Y5Z5ZpprtvlmnHPWeWeee/b5Z58lcSETmzORAWgPhF6gZklkcAVpmIemeYFMmKj/IACsM8E6AK23 DoCJAGyWGuhBKrh6664DqIcJGdqWoYZMXJFb7gVcqbvuufPWe++0vd66ghq8zmRpD7CGWuYFXHja 5gBcOPxxmgOoIeZNKq888Tgs11zzFMTo/HPPUxA9hQVk2GT0FIZIPYXBh7D1Cdhjl2SBX4kVQ5It crcBP97H8F2DMQZCY4sh0Cjh+BIKUV4kBuRYxvllDDtAGuqpf+B67JeZQRpllMHRBx+GGeMB8I0x hpl+kSmhtdKWWWZlzxpGbJhCrIT4gQ4o1qwE0VbmRRqKMEAavzBNmWADMiPtpX4p0x9tTDYa/bWp ZZSJwwIsuIAGYFCDF+SgBjP4/8ENenCDICShCEt4QhOmEIUrVGELWfhCF8awATOkYQ1t2IBMXO2G MwxABXb4wxrmMBM7zGEAgHhEHFZABkS0mtvaVgO3QbFtKriaK2zoCiUiEYgVYAIUpfg2GVRABU5s mxF/KMMUao2MUWziF53WABfUQIVHNGEOl+jBGVqwh0Z0oRb9aMMOWlAGLshgIIUYB0QmEpGDYGQc BuHIOHggkpGMWSZcIImZVc4DTqtcCk6HOldkInWus1UGnuCBBQwrd1uwASt7NwPfjSEEKdAAGmxp vOON4QnKY0Dz5OA86U2vetLAnhy294DudW8sDxiDNMpnPvMxA33oWx8yrJmLav/AxXm1gZ8/5Eel +k1QS5LxDF2Y0c27/OIByzheIQ7gCx8ADJ3K0ACbvOTACKLTYBMkTAVh+M8WohGgAxVoQQl6UIH+ kYZZ3GHjrKjQGQrxhzqEaA0ZasMcsm2NZHRBE4dYQywusaIz7OhGB6kCF6zxox2soUFDaVIZNHGN rkhpIfP4QS1qkKaKsykIc+iCgJ4xkEMlKlF7eEFFVvBqjGSqzCgpswjUrHGU05wH5Ig61A2Baq57 wutgh8oQZCAEq9Qd7/ATSw3Mspa2RF4hdFmIXv7SeXIIpjCtdz3tcS+ZOGIm+aB5vvPxAn17OQAy qmHYuDyPm/D7JmDoZ7+FjRP/S3exmD71MoxlFKKWJViGM/sHMo/1Mp8MnI1l58RPwFTQoKu1KWtd i1DYvva1FS3iD3s40iR+FKMUHakdMXhFs8HUiVQsI0gBh1s4KtGkKqjHRnWrUAvitIYBMKlMydi4 GiDXhmGk4W+j64owDm6FO1xtUTno0AVUUL0VjGNSH4lISU5SkoybHMw217QFYHV0Ws2E6wQBO1Oe MpXAIqsNSLC7s/4ueGpla1vfGtdfui+Yw8TeOo+51xH4oK8+gCYzzjdYXqivsMggzTYfuLLG/uWx 4pwYYPZ3TtO6ScPLYABFOPsAf0HwS2j4xT3jFGPboLafsgUokY0cWyQfeY4K/7WjbXlK2wo816Jm xO1FjZtS4Q7SulybYUiRG0aYEnejVNYuDV1B3Si2zbpkrMCTy7xHIFbtjicEYkHNe94KuGK9iExv Spk6CEk48pHzHUTMohpVmckgbB7Y3CaExmj9pm6rtvKqgMVK4FUi2AZjuA9aZZkCW3YADWVAnkiU J9e5Tviu2dteMrvngxFsmMMdliZb1nfYbGbzLYo98cVSXJlwtkyyiKkskPPCi2EcoAS1lEPBbMML NAzDxwY0tmeEnNroKhmF2uZ2kr3NWiiTebo+7G2UichbKMvgt1fO8hQB5zYuh3TdEN1jdTXq3IeO lKVoBqOalbtGqzUg38ht8v8PaZpnQNKRoHe2oBDT+3A+DzK9iXyvBwpdaPnWbGyNjoPjPKlf/lLa lCMHK6Z1d+BXBm/BoA61g3eJamCqmpjExGurMazh8f3Vw7UebDVzHRcTj9Y2v/7HioXdYmLzL2Is W3qMczECZXfgAJ8djQCrDeRrD/nbLOx217fudRNCtOA3dGi5pbxQcUPUymZWIr9N2tF/lzFua//j Ar6mxjWKUbiZODtEMRhKt/u7ukqMW5kPPnAbfi3tSLQzw6l2NQuuN705XABTA83I+VLyqTNL3NMa vYlM1OCTIJ90pS0dLLLOAMGwhKWCZxlqUrfT1L5EtfQoXOG8uloZsN5wNKP/Weu13BqxiZXDYlHc mMcE+35IJ8xmFHP1u/BiZAygel4MA32sZ/0fqv36trsP9u+H3/EcbAC6x41bid6wtn40pBKHCkd1 B36NYiZjEcfP0iKeeY0uQKlwqXx/8tMg+VszJ5KpxaM387syxCskolq4CzozrgkkwIG4iYuDIgq0 RYIvShq0SEK0SqoATGK0zcGa0cOqkDOlIQiwJ9iEARsr3XGl3kGrtGI5XEqeZdsl2os527MemrMw vVKmDOsrY5i1nZumEPM5bAK6ZTA+X0O++VG+yGI+wHA+3bg6X2AN23Af7Isx7ds+8BuhLxQ/MQxD PEpAHnIzJjO3HTLDMyIh//czIS/Du42CO5N6Q4SKw41ignszKT5KMqoJPAJ0my0rs7G7IbsDG0P0 ww46OLOxm8hLHKCCuERagOYStMvjwM3zwJh5G/tqNLj5ONLrL656ggBjwUtzwS1AOQTjNJUbgzs4 lltCnuR5sNqjK8O4PVb7wVeLtfEhwt8DMeHTNbjgNaF7DaIzuuWDrL+gQn5aGdxgp+q7CymxLL+A vi7kvi8kwzHcxi9cP7IjNyjrO29kPBLyrRNKKQwymjCLuwIkpGwjKBcgJDl0GzHCMpjqQ9miGjIK RMGDt3mDqIPruy5zAXDsLiPjoIPjmihDqgWogQqgQEUKo8rLwIwLtPmamf+OIxoRrCrFKcH9Crmu IkUAY0HUe0HVO6vWC54ZjMV2WrYMgLAIk7kerDldHAucewCd+zC2EDHEEsZcMDF9OkYopJNhaz6l Q62LqUYfKAFpO40HaAxqbLrsyzp/ykZuvEpt7Lbyy66GQsM/Sr8bYkPycsM58yAvqxv5axs6zMMo s6LyCiMrAi+OUoE95EPxEii3tCn9E0R25MvrWsA/UryxbICvQUMliy6CDIDHGxw8Gxz1qsBDAjRB k6+M00RLIpyNvJxLAsX9kjRRrLQMMMWSLKuTZEXg0YBXZLkOiL3kmb1a3MGZwz2bSybeyzkO8zCd RB8RwzW54LWgdEJwUsb/KynKKTzKxEgNXpgMdMqFErAnz3jK7Ls67cPGMcxKrLxOIxvH8zO7czvA RPQg33pHDELHDJLLjaK/fWSbuyQo+yPMvOu/LItAGLKkNrvLv+M3foypvvROJPqpIwIvtmkpJcuh KlpMlrqax1QkSISk+Bq0QsOkTPSAlKIqzTGaTgI5kBy52CFJk0u9BPudGVwrUUOeBysEVHMfW7Sr u8q9m+s93zPCIyysn9OmJSzG08iFA0C+KQE2cqKMzsANyeqL/UnO3HATBjAe5zQ2q3NKqAwyqcwM F8uLaoSf6SRD67xS7ISt8jvAsgvHieLPhPMgOzTLLIqutNTPOuw/xTyo/7PcS7fhv7qEqfVMI4IE s9Zy0/zkRzAFohpggueat7opKfaDIT0yG8VsuIXsoHoAqqRKpB7Ss0eSTEK7SA+kqcXJzMqBm9Px SNUJuVEsxQU4RVYqMLOKpU9bqwa7QV6SK/eJHpm8HmM6gAcYhmFwtQfYHvDJ1VyFJsLql7X4pVwg MXwijQOIDKfkHymN0tfAn3wqtrz4hUJ4StawUTnJhWh9jQN4Hy9ZmGTVp2ujTrDDUnHNUjTSThq6 Le5UP7EM0w8yRxMiz4ZLS/R0Iv7DMj4yKO7CIPmD03YrLvEUuB6qInj1IDTL0750G4FEojYTUIM8 OJGqs3+iz0RFVMbEM/+IRKTZSSnNo0xKlZkJ7UTN6bgF8MiP3CqRDLDQbEGygsHVY8XgyQBaajkS xUHakzBbHKYejFVlQKa9ulVn0lUOu03BWp+dDLEQA9ZhLY1irYZjjUY50ZJoNKfX+IXIwFENoD4g 8wE08IXXiB6W+VGIAVt0+lYrJVezHdc+Oq6uBMz+VMOw3NPuIssTOssPSks9DLN747KC2qN0lD8x ilM+zEs9IkjIs6Q7EqGCPVg0tcuRiindCqHfOrihUTgXClin6SCHw1zI2zOM3aNFwjhJCsEOhJnG wUxMlRwRjDTXqRtSih1SFE0XbKXcOcneIQDfUStULbVdgqvac9VbrJ7/Yrownh2BncVVXR1CH9i5 XjVaZDBaYBXWpIWLYs0nqLUsZuUSZD0NaOWMXMAfpqRWbNUAp2WAA2C6a+vWsUUtcBU/tD1b9xUh c+WhgkxDcVxXgyzHN3xXdZOuAWQCe2Qz+ovAsKOzRmy4jfrb/5XTv5NYuImuCWwtgF1cgFNcuaso LFKcf70ggQujq+k7F9Ias3GBQ9XciuWgeJy4CoSk8GrQzLM4mWmcRaPQl5GBTLhQE5Q0V0hBABtJ lc002u00GXw9mc0lmmXVFFXRnJ2BA9hZDPNZoA1aY1gLJDmAwWpeK0ba6I2LpW1a683ezpBa7S2E /vGBkJCDEQDfvBgB/zQo39PghQ5Qhi6cUsyISn6qyup8XzxuXy/rSqEqqvIrYQ2GPMc7oTH9ILq9 IHV0onp8OyaAT0W7qTMjSBEWoUNcU31co3pQAbpM4DFrHEMdIg0y3NYKZQneRwouI7cc5EPkSkoG IbsjXBpmwBTSV8IVYVmOPAuMskbN5UzYZUdqSPeDmYyjpNKphxiWYZpK3UjzzNY9WdhFxS2gXU5L yduNWVtiTVPjXbnK1hTFWVgV3r2SBuOFtRFAXh8oC2NAg2Uwn37ppSDJYhw11uf04m663nKi52fF WjdRBs2KVqd9TjQQ49cYBg3wgThuOjmmUvXN4O9rX4fGyr7xGjbsof/A8Rv5nCNzqyPIgy13JSF4 9SkA5uQ31WT/RVhPDuE2E8+ATMe3EyO6bLP946KXbuB33Eow/K2qUdz8JCM2TcxZduVI5qKU4poh CiU1Ity2u7PMfUT2YtSkujy7azPFvMhJ8uRjptBNqmEbNkGQFEkAK7nYdaWWlcGVRIPVbCvXNGKZ BN5YxR5a7R5xlgYcybAMK5+y6IB1htG1cGdffWelZQCmned/9pLqvWcY84ztRZMHCAnO4pgbVQY5 uNp/zizhFDL0VeiF5saH3uzqlAE3MBvQNhs34NLQLm18JOQ5/SAdeq0yJaFDxqn5O+WO0mSSfmnA GaITLqGvuaOXaun/RiZpPfxtTYZpFBLlbNsgVzDYfqVhOyPQOW3l8gy90p7ueLxXyCVhhuQzz23U y7NASQ4cvpOcOr3UTKocS5IEy1FdZv7U123BsN6dsf6dVyyeUesAl1tVI/bd360eY+ost55VcV5i 3Xs1DvsFdRbatuDrvnaLv86xL8HnlbHnL4bwdBLox14GNAgTuuLZYZAGdgqTBxA6rZUGsLVspuum alzosuVsFv+6+uQ7GOc7IDLqGOe7lGboPz6h9mSt8NTfWU5kNRujLEPqJgqAVD7hFAqv8hzyeOSi 4K6ARXUiI8ejGXrg41ZtkS7lLEvtgOqhoWnlEAIhK7LorGHAEhqq/6WWxMR5SPdiUFQymlqOxxog b5qpnI4LAM5Rb5PtKpQFa1KNb4FYMPouAdbUrAzQZlaVsLoaJgZQ4gqj1Q5X4gG3yVw98HM2i7Lo pShe8L4WGeorDahlwjYp7Ak/7M5IbC/hBWUo1hIwa1EL6GVQhsH2B2gscSjl1hP31jpe8Tzu9a5b gPxlqYoqZBNaSEI+bYMidoFr7REyz7ZZ5CyToi+6y9ym5IOjISDvVzeS8pWKqJq68r+Lx8FbbkXr 9hiK6i+H4HM3rzPvoApaas71radm0EgKNLxJLw/QxDq3KsfZHJATna3KAB3m4bAyORtYPSAGUeJh SRtM6whT9FtEYv85sAFZvZ5hmNVIPwBIH3DvGQGNoXRdhStMNwtOZwtoLA1pKAECymLZACCKgQtn xQtUr9bmBR+3uBiCJnEn3dHdEFtdn6D1/XVfH3pucz86A0ijx2hQxl9LPqiO9qCPHqFsn1dyB2Uk 1/E2c8tsJ3fnmjcrB0M4whq25PpHZmhKDiN3VPd/uimwv25EnlhJRCSHDIBEkoRIpfeM4xnQ68g8 /3fWHUWR5NCxCoFWgu+El28NWHizbklDhzCIh00Ka2uLp9UHCHBIv/xeSCaCZoDMn+uxOJ7vAdqy WHBo9BfTT42UX3l4zgW0ABi58IUOcDbZeAsfsHAfMy0FQmMhzfX/OZbOzLbKFg9+P2R2EkL6skRt FVpt2CL+v2N+8HQiN3Bksh+caj8hLwflMyX7tqlY4wZ7muKasSf7pg8qAP3yw2x3zCVIR4x7PiPI Xs7Au29hjsWZxMFzf19mrcphwG/vggeIEFu22CA4w8aMhGMWjtFwZ8sQNGhKlClRolAhDRkKyeko 58DHAyIPSCsp7QHKB8tmnEw57MEwaTMODKs5TNlNZTp9+SLAgGevXr6C9urQodeIpEqXKv31ywcv p3JKQOWVKxevrNI6VM3q9WvWq1+lafh19ezVYVzRovVRgpe/q/7mxs1Vl+1Zunrr0s11gOvewIIH +/v3jzBiwYYX/zNu7NhwnAULGkyuTPmy5cyYN2fW7Jkz6M+iQ5Mebbo06tOmK8j43OA17NiyX7ti PbpBhUygM1UIoHq3bcmbXbTmbDmAjOQyVDBR7vw5dOUBXLgQ/rlGhdwLkEfv7l257sm2KVe27CKA K+7OmbD+3j1AJuuhJ7uSkT186s3kMXuWLHl6dr75F0dkBBqImwuZEDhIHAx64GAcHkQYgQcVWnih hQuc58EmHXqYAoghhjjEAq4McWIGT6SYwSYLhPDiFgIRREJCNTKkQUMhRCSRRRdllAEDHi0Tkkgm lZQSSgeMcVJOOikjkzROSqlTUL5oUEhNvQzji01GETVCUEyB+f+lUgx0kFRUX/3VFVhtgkXWL19h xcsDGviAFV7KvIUXn336KdYBGiiTGKGFGqrYY4k2Ftl+spU3G6SRSjoppZVaeimmmWoqKWuRuvIp qKGK+iluMkzKm26Q9rYpbKuqauqpzlXAnHvfVeBCA668Jpwr1gUQYHru1VCrdJlk4sKqJc62wKqZ QMcesdH5Vppl6VXARAD5ddaZcZIdm50Mvfq3QIHkGhhHbbkRKEmDEboroYUTYmihK8Rx6OGHIopI YiYnDpGiik+0mMGLIRREkA0J23jjHTpKhEZFFmX0RCFBdjRkkSSZhOQDSkbp5Ag6PbCkMkrpFLKU GvzEE8s8GcX/0wMtt0wUzUlNcNQIv4Dp1C+B9sKzm0HzEmicbdY5glVzhjWCBgdUpfSfUZ/FixxN 53Uo1lkHpijXkFnn337lCccq2WWbfTbal7Km69m1wRopqpDyli2rvNUQ6dqUOqvcrM1F+xwTuOY6 2a650vYra3v//R2y2SVYma5jN3Dea4onB+3izsnXH2bHBo4ebJY5SrilzjoeH3njqj4ub72Ze+4g DEIIL4UUWjidC5Lgu3sKm+gL4gL9+pvBv0944GIIGQxE0BY1KjQDQzkOoQGPEZcwxkYMcHTxSBof iaTHUiblw8gP+HA++uknhQYDytAclFod8OSAA77QXz/+9QNF/1QJGgz1fi+W4T+kgClnSeEZAhEY KKQVzStk+VmawMKAhhwAaW6amtTOMgIGWC1qWvsgYrrGNSb0oIQmPCEKU5hCErKwBy18oQtjCMMW qrCGNrwhCmcowx3qsIc8/KEPe2gAFQCxiEJkjhENIAQgDjGIRuQEEl/IBAMYoIRMEMIVs4hFIQiB iiqgIhYwgAVOULGMZSQjJ9KoxjRiAANURGMafxDHH7QRA0kYACEGoIc73nEAXfAjIP+Yhi6kIQaF PKQhLSGFGwxyAIB0JCQBmQZH3jENg7zkJGOQxz924Y6dHEASOtnJJOwxCXU8ZRvDiIVVcmKMbEyC KcdoADKW8f+LQ1QBLnOJSyGogItM+CUu02gG9mSnmMWkDjKTmRwXMIFWAXgmNKFprGlmwhXV7FUA 6nErVzRoXhXCl76seaInkLOcAxOIQAqCEISMAXo3csgWnsCjHmFEAyGomEc+QiTvfa9jJJPS+epk vvMZo6DMYEZBC1qCAzjFB0/xQVIYUAKayWx+LaOf/Trgv4r6QhgEYJlQAPi+pVBjDEhJ4C+C4T+U ItABHWjITxp4Qa/0aWga6MADMsgWEPK0MCJMFAKCKtShErWoRj0qUpOq1KUytalOfSpUkSqDVKCg qla9KlazitXzJDUC59EqClyAgqgK1QUwACtXhxoBBKx1rQr/gOYZAnAGGMxqicSZqgu0kFctaAEJ fkVCE67IHL72FbBNaEIP9pAFLgqBCl/Uwx71gMo2Shaylr2sHhx5SD3qoQoYqCxlQYsBzlqWs37s AmY/K9nJ/oCOnJDjLXW5xV+S0ITGFIIZhuiGW9VgWL2NJjWrWaISBaAG2qxHAETRIR2IQQwp8Bd0 y/mEgg3kRWJwhSjEEAIaJYQA3v2uBsIrXgKwQAc6IME8jGKBDligBBZ473snIF9hMIABwrjvDEhg lP2u1wLeDQaAg1GMAd/vfiDlUi+E0bRgjEQawZAGA9AAlQYyIysV5gUykoYWPT1gSiIrwS/2wphr XMMfy1iG/5RqwhOOgIVnSqGo/ejXgRlM4L70ra+CZ1A/oewPpCLtBQNmIAxgHAAYRibyBAjwgDix 1CkjcEAJZkCADhzAF04RGk3FoowD9E8OZtEpn3qatZ8ClaxmPjOa06zmNRs1AH9NJpzjLGcXIEGs XaWrnJEgAwWYOQK/qjOc6zxWtrI1AmsNagRQIFe5znWuWmgmc5pQAcL6tQIl5GUZhYCEVPD1r4dF 7KW5mIBZqvaykw0tZCGhWUBa9tR1XO1nAWlIQqYhj6aEtatVuUZd9jKLtD2hMW9FHTfk8pe3kgFw p/mpTDzTBcetgSskoYNNNNe5z42udFlQMBiRoNvljbYOWP9Ao+96d7wz0JF5WTBlo+ADvvAdxzjk Ow5hWMMa96WGMDqw7X2HQAPBIEaApVEMBwwcfy3bUi+CAV7xipcBCIxglvFklYlLtEcWL4Ec4KKX xzwAI9rDCEYsMoy58OkrOquS/YTR7fx2u+Vb0EDBC1zg+emPZcDIr/O6OwP5hYkpTs7ZL3zBQehp QA7BcADQTR6VXjiAy+H9CZj91Be5iJkwZH4Mm7Ou9a1zHc0RUEAcFCD2sZO97GYv+6GRGoEGnL0B aSfr19vO50O31dAIIMNb46p3ucoABpzuAS95jctaLlELqUiF3zvt18OWcA+M7eIsORFa1KIWlH7M 7B8HMEj/Urb6CG30/Ocx4HnPYoD0n+U8ZkGL61SKUY4/wMIJyJjLxzMHi790oTGpI2zqaBOYzPnl bnNvzHrUID4Woja1QTSEaw8h29seSMtXPoMniEESopC2Dpr/BBawYAjNNa92183u97L3vfEeBwPs bV8bO8MZwnC3fOfLAGAEWMAEpt8kKkozB5ykwChBOtDIVJuIxVnojFKkD1RczVw4hj9YmJtcw4gF hlhkxckJRTAYGTEcGTUYGYANmAcOmP19oMxNwgUeGTGcYJE5wI8RkA98SQtCWAcQgJQRwE11gEXs V3h510INQ8RFnQfxhWBQHdZcnWN0nREeIRImoRIuYVO1/xVbKQAK7B2jnQEVwoAVyoAWVICkaSFi aWEFbNpc+V3iKd6nmRAXfREngIAa0dGrQRbnoV7qnRLondoctmEcqt5kYcHrvV4aCV6v2V4LCR+c JYdv8Z7jHBd19Fbx9YokXEiHVFsKiAG2ldPzbdcWRB935VcIPMGJVBt0iZuU7Re7qRd8yVuNWUP6 0dt9OQM1tN+RmeABANy/daAHOsAkGNiB1QwLAp1TGMOVYZnE5QIy+GBgkBgRPgbJTWBUGCBR0BzB 2Z+AQWMxdKCAkeA0XuMHeuAt1twK/pgDBMMy3NgEtNcE1NdHqKAAggVe9CAx7oUCjtkx/gMTziM9 1qM93v/jUhmaoi1aXD1TGJ4B4lmh3x1eKuwVX1GhXA3k4SleKDBeYnGRGamh67VWa51S6pla6GWk 541e6B3BRWLk6omRSLZS7MVWLzEWbf1asO0edTjHsCQbfISKf0hCI3IIhzBX8kniJE7XdMHIJUZf zs3gwjGcBqiCKIpiu5nfBMCb/KGivQmD+7EiMLSfM5jgCcpiCBZY/skMADEF+gANxF0Q1EwcnrTj YEDgMU6dMjpZM8aY/VwjgAHcCXagXNZfXMriJMQcRsXYXnJlNxKQASYQlgWNDwrhXbzjocSjPOIj YzamYz5mUa0VBwjVoU2mUX3domWm3oXhFVphKkwVpxH/1llFYRUi3kIWVhkCnhmlkRq+1g+cQEVO Fh7WERu6Wh3N4UfO5mRJHm/Skmz94a/1gKXlnjJJB7I9E7NRE6iMSxzU5E1Sm7XppPZRYiX+pPQ5 D7mVGw2Kl1HewlHiQ/nFF1PKVyo+pTBQwwZO5StiYIABXDEI3P3Zj/4NQ1cCJi9eWToKTTBexTCW XNSdJVqS2dSZXFK8D09s4zTe5VVi4FVmYING4wdaY8HppVvODAAZYM4MJmEWpl0cJmIm5jFCpoiO KIkyoWUiGgKcKIr6mRT2YxXCAEB65mfOaEEiXgCgQCswmkISVl+lJqaVkRpKpOthQG22ESB8FpLS kZLK/2FGFmmppRZkIemphVErpdEQ3dIZouTtsYdwEicySUc0wQd8GMunDJdk0OQ3eQgkMl/zaZ+2 UZdAYGLOZScNbqd4adR3ll8HnB95lqN5sl9VVqV6XmUszqL9yVzN7Q99duUBCmZ+iiVNaRhakCWe 9KdZFuNP6cXUmJyLteVbJigxTOMJAkMGMmhd1p97gmAx3OIt8uXM7U/NHJBgaqg6cuiHGko8lqiu 7iqvntlkpp2KElUDtGhmBgCM9p0YXiGN3mhVcQFpzpVpUpphNcEZrqYBtCZsnsAJEOmpeRZFciu3 0hHoHYG4thEd5SZl5RoGtBJseZFs+VJKltBKfqlLFv8Xco4pmZbpmdbkJtwLdEbiTpLTvlnndXYX uRHlnR4lf8Efn6KiKrKfkVHles6le0IoweFiLv5PzxVQzjgUStHqxCVNWAwjWZZsf5ZsMEqqTm2N CLkjWxAojNEPCP6bLFJsgz7oXB6dLe4sq3LjUGjszxxQU/wirdrqrRZKrgZrry4t0/Kq0ibVW3EB XGWmZ8Jo1RLkVI3mVbUCFYYhQZIh432RLb1RHHECbFakk0oWRbJhbLItuFrkRyJpSLYeldLSlZ4k Y21AcA6nl94VIR6nNCmbvi4AuzjnvUBiwA7sJf5kUMrgwdppeOHpd8LfUlqAKdabjZ2nerqiVeYs Nd7/H/5x1I8d4Ph4bAAOZlmibMl+BckS4OpiGMiy4zsqZjIqzTIWKI9ZlMx+IM1SLP3JZTaK4I6F FNAakM4c7y8+3ABCja1qTdI61ds1rfROLxIaWtpZL6EJVQMEQI7uo4sqpGn63VRN1RmgANs1wFV1 7YuGJmoCXgKMbUSCALaeLWu95trSZria65I+qanp5inVrRn9JrymZLAhC73+LXDh63KeaXM65yM2 F8D6i3QJLIxYIlDqHJ1Cbnh5p8K6mwWM51KSZ+ZCZaAKKgaSKsVCKIFRqOguqgsa733+ojHEbliI rO1mGaWyLg1v6E75Q4CmZe0qTaeCyc/KJ8ElaO96/65daiP+hNSFwrDPEa1+Ni88EmGKUi8WZzE+ 0h322t0VIwAUPpPU8iO08ujhyWgq3CgUYlVccW2jDaTiIQHg4ZJjmZEBxN4a7mFt2u/9EqnbKqnb 8m+URqltrpIc2e3g7RIX6e3edukxHXByQFMNIKfgigvhGu4DO5d0TicFUxfBZqLBDiXDKezCejCf +in7nWegRqyRlQMK22UIxtxWchTQbmzpPsXHpskMz/AOZ9hM7TAwy0mfiNhPlZimbuoyMiPK7S4S 3yxWDlyr+tgKQnHRgOXycqjzhujTajE3d/PWefGKfjECRCH33qg/Gmto+hVfYW0qlG9VrTGOkuYU ev+m4XUa4PHS+8IvkKZR7G0rIJvta7kmbOqvuYbrksat3LoaH9pxbGWp7cXQSrKkc9hr4OaruEiC ZERImv5rBI8TdcIpCVgndoZyuSEsKXtwKcZb+pmn++EbVLKyqcZlgIEuRtVPzMgMwrkwAS3F8Z7P x8YJLwdzm/iyL+/wLvNCUCO1Uh/1FFuqYfrwD3dNECPzz3lqgXlgLMecND/xyQWmNdcqNlfx1Ymz UXGAWZ+1WZO1N681FjshZRZaBJCB9YJzUL2V9+odswHktKrzOqeCs1YV+lqVBHCB+nLmaWrBPeOz F61mGqpRtrZWY4PA2Z5t2wLykv5A3K7W3LKS3Zr/JN76Wm3x7SO3JJgmm0XPZHM6InNp8iZL1yaC 9AVjcHaatChycFJ6cPzF2wifJwmr56BepaHS4sUa2APMsl/2HFLs9AhAlOkmEC/LVFIHc1HHbnQr 9VIvNVOjrtTpRVRLtVoKsZMpc1t66l+KlPFKMQ7L7p9ksxVvs1BNJnynaFqbKFqztX1HlWS6NWUq wFzL9dtxAI7eqIv6o98BVg98mjqfVStY1YJX1YIXdtfKaF8lNh3rMxWpYT8HdGNH9mudgB5+62V/ K7rOLW129t32kiKnJAlFNCRTtGkvcOE6InRqcsD2JHW1XEJwl+MeLMJGbgejtOWiH+ay9CoO2Xqi /3DNzvQ0DrfMtbAucqxXOqpSF81RV7fQWDkwV3lWaLlQX3MPb9zVuew6UiCGjkl5i5RXo7dYrqxY k5laL9WJOqFZ63dRofVZExXd3beer1kE/Opcx53YfZ2hkQFlJpo5l7OiKRoMaAFicREowEIPhEI7 U2GONviCEzaEWy0cJ7YQJEAd6zMZtSZA01JrSvZE6jHaArIgEzKJA3AAm+Tjqfi8FmckP9MkB9fg XrIHOPBqN1fAapuNdxvjgjKd9nhtk2J7Afk4OOxu45sJv2IKY6WSI6p83rSFkokt83Qu/8JRA/V1 c7lX8PKFhbt1a7m5f/uWJ1R2VzeWa6gwhhldKP/mYqhlyCYzLoe3Ab1YmJxUk/Ewmw9he/cZB+T5 wJ8ZXQeVe++5wqsVoXmx9SoA25kvxI9d2oVxoic6P6ZCE4BCY/GSEMDCprUzjKovF7ixGGa63yHW HgjWEL3vqIG6ZHc2a274a1I2qq9tZpN4G1npq/OaL8ErRDvy7j1HmCpwr3wKRkeIc04bJLa2a29b SOM4KJO0BmhwB3AwsgO55Yrwn0IlCa+yCQZ3/dUioubPwQ2FTic3lI/Pci+3cyOQL17ZDFdzL7ZY UFd5tyO1L163vRfUUgMNl5/73KM7uK85WghGdwvoVE+q7TIZ8uZyWBr+ere5CMG5nV/+id65fG// PlNFb1rb+cKHvlr9ufXindi9BmBLPN0pWveac44umsbzkmNRwccTFkEC5OGpr+EhZBWGIWJf2qhh aSJHJM+/0RmloUR2+OvBph5++KqzuqsVfwCLbeAN8O0VsAHLwF1JckVfkyWj6fE9cEdzso1XsJzK NnhpcA0ahXf2l3uh9FI+7L1BZXoeOXsaKlweql7mn8EBhC+BAnv56jWs14iECkc0dDjCB8RfEylS NDaR16+LE43xMvaRo8eMHzuW1OjRYsqNv0Zq1EjS5UWPHTNiFFnyJi+dOnHi5ClyZ1BeuYgWNUrU X9J/S5k2dfq0aVJ/RYcKzWgVK9ajW4tK9fr1/ytUsUwRlDV7Fu1ZDhwQrG0rCMAFuRcErbXLtu1d t2kRRIhwNgKHwHwJFzZ8GHFixYsZN3aM9q9fyZPJRCCjgAwZFJs5K/D8t0EAFAECtBq9+czoAKma CKFiwIAKUE2ahEKiBXcq3FpSnTmTCrhvFFwCnIFxHEkP5UJUxE4gBDqV5rCpV6/OCYQBEJxO/DjB 6Qf47j/Ik8eAQU96PejZpz///j0nTrDnU1fR/P59IUz2M/HPpIIeKhhwQBdckOFAGWSogTTSMgkg kwhdmXCBCheQRBIPNPRgk03EECMFMYYYcYgnTDQxhBRT3IIEFkkgYYYYZSSAxhoJ0ADHHDvYkf/H HS34EUggJ2BgSGGMPNIZaoBR0hlgnHSSGGCICWbKYKy8MphitHSASwcm4dIXB8IUcyBfhhEIoV4S WpOhh9ysaKWYMLoIJDp1qghOleRciU6X8OTzz5g+yokmoQq16tCshOIKKbDGevQfcJI6qiqrclF0 UUaPAotTryCF6rC/+hr1r71wuACCVFWFAIC98CqLrVjbMmsyvx67Fddcdd2VV74kI9Wvyi7LrAEU iuVsswY+i+A00UYzrbgGtWjNAPJAoAKUPW4LZTckQuG2N916a4UL38xFgrblYKMCOiGeS+C16lRI YDrrsLt3u++62/cHLH44z72A14OP4PoMMDj/ttj0U6Hd//wLkMAKDJRYQQVrkCEABh2MMJMJXbEQ ww051OFDEEkc8cQnWFAxBBZdhFHGGQiQ2cYcbe7glh1vsaCDIH2eYIJxhrTGmiOFSXLJJp884Eli qqwySyuLCabLqq0Os8wzzzxITTUbYtPNhn7xgWwf8PQzpYnMrojss+M8G261145bT5IIBeonvPXG lG+dNM3F00+hkgrwv6ny23BNO11ccKfy0gvyyGNFdVVVL/Aj1ld99UsBFGBAoVS87oI1c7TsIt2s 03tdnfXWF4sM9mCDHbaBY5HlTFm/UGhFtAab5d04JECh4gc9rDUAFNtyuwTdJnj77XnUzD2j//km emAutnYZzo866Oq17uCDt8tXvu7A+3e9gNkDmODz5HtfXtjy0w86h5kQMGKJDaxYwQYf5LhjFKoQ hjK0oQ59KEQnK1HKVLSFlr3oRTOA2cxsdCOb4WhHquiRz3wmNKAVzWhJEuGTSCglYFgJalOLmpaK 4YAWdmlMYCLTQNS0tTR5DWxhg4jZHjK3sT2Ebj7EU9mIKESKSKQhc1ubQ/KEp7sBpSMWyUnfqFiV v3nlGo2DlD/+4ZXEfRFwi+OUFpfyOL3MSlajc4sgKAeBNl4gDJCjFV8UIAQDCOFzkREMYTQHq1n9 0Y99dN0gFSPIw8hKMaIi1ajKUqvJeIZYt/+TpAI41yzR8O5ZvTtDKOz4ryp88gdUcF4orAcK6PRg D3uYjRbOYBrpnUELpEyXHUHAsHa5Zjq2dNf36KMd7WDnOyA4gb7C8y/0pK897YuPfMAnv/nd0mHK yZ+BqMm/Bm0MQh5bwMckEYcCauiAIEqBAhnIspdFcIIVvJEFddSBeWwQHz0LkgeDNgFrMOBI1Dia M45WQhI6jUpXUqHUttTCF8pwTGUyE0G45jWFLGQhOowIRChaEYfwsGxjIxsThziCX3jUo0akyESR 2LYffvSjHJVTRXhCkjqdpCd7qyLfLsWoTmWRjIMTI+EWF8adBk6LpJNjGk/nFrYIIC6omkv/XSR3 xkYqAAkg+MEdkXAGSorOqELdyxwjQ0ivftWPifyVIhfpSEpahlhksN1muNDW1DRAMtcsDWlU07vi TKsJw9PO8UBwhAHcALBpGMBgbzCAH+whXKngQitggATH0qY1IMjOLaHzHCHsobLQsQ/47oUv8XCH YOpJJsHCMx9mIgw/z6zff6RJIBfoL0EVy9g1ASjAC32TQx5CoIhIVM4GvuhlMYtRzdipo3fyiGcc FNpy7ckAEO7zaMJwktKgZEKASg1LV3KhC7dkNTF9dyBaM9MNu+bQiF5UhyN100Q1StKIsC29RUxi ekPaQyB6lCOBglufYlqoRM20bzW9IlBz/yoWpfyUi11EsFLIaEbHcAAHaxGAH/wgCAHgAAcCGB1k HIkAFBhAD4DojgE2oAUuwHVWsXvkWfvSVbC+mDEuxtVkGgmYFjsyAmf1DGaMhSwusDVaKKBkX3qn GtWYa3dB5lwqQAECPdxAChQogJQpUOUpV7nKA4DNAPRQ1VTYpgLo6kEC5qNL7V12OZWVX8KqM77x cYeY73HP+pSJAfj1crP5YU7DWJs/2O7vQBejLce0OUBvGlC3IOJtb09kzhZBEGYzotEY1nlBDCI3 ufiYZz3HQaTn6jO6zmgSdaFEJYCmMLsq3O6qYUimGS40TbEu73l1WGv7UtTWub7o2D5KUv+J6vqi SxTbSvNLJ5r0V6bJBrDfhvJFTuG0wIIjMFN22uBQdRhWoePAhQVw4aKyhax0FMJfRYwBQHjHAD2Y wo/ZOhzfsHvHtmIkjOltGFH9KjEyVnFX912ryuQ4x5hZ63Da6tYzSADFZOAd7+yKgjPYla6gQ0Eo QHwDKhdgylfG8pQBi2UqGyAVjkUXujALG8tSFpWovOVmm/m+zgqzfeobGHxOezDUOpN+/XFYBQAU MWrGFmODlpAACSiycH6InI1m2QMhGDMa0YxGltZAj3zUAU1vmrn2NJqR+Nl1f0rputkVe9S2W1Dv IhRNZzIT1xCSJmUoI4cPUQaw6a5rX9f/Hdjvne97Rzq3Pr0EJCyJ4t7+u+ygEMWKyHB2p6Ld+KiE Jaivs5UiAyPhbmO426ojzGSEcAOMxwADwzR36A2AAhvgYQZjuMMdVL96NKChDLGX/expX3vblwEP ZhEE7G/fe9//vgxjwEsGeA984xsfD7CrMWBwzLmA106SbQ3AcY4j5L8ooMiZHE1qkKysJgxAyi0Q //gxXn6Pc9zi5ieCAZog8vaPOTvsEsL1hJCulAvBlO5SGC9tnp03SzW02EcAMaC0wqeZ9i/ndO5h fO7PgM5/asu2usnoSAaBhmDRGOgJfgvShEudNKC4MOidbuHqgKQEhGQcLMCD7imEuK6f/77uacZu 7KaGhc4O7bJm7Qyi7dqua0YA7t4O73LNB38w13ph7n4wIibqCHkIpITobewkpoLi2AxvUayo2cBI jBwPC6PtrGqFknbMCy9jWbSN2zAswgSjC71QWVBjCrSgBwag/KRgAABh9ACBDjehAWCgAThAEDKA D/vQBjLABgAgAwRREAcxEANxEBOREBWRD20ADfDCBu6gDyeREivREi+REgHABspAEMpiDMagDxex EDGRFElxC9AgMsjgxuZtjlrsDItl4AqO+mDgxDjHdyzJrs4gEzajCbyAAsRPBFogGMdvGMnP/CgA yqQM45BxADhhNprHNe7olGiD5JRjD//oj14SIBtVIF5gIztMaztAK+bkDD7Cw+YQZs3mx8wUsLV8 rpoWBGM0BkII7WMuZAE8AEM2Ibd0K4FOxrdWJLicDuoq7WbcCbmsLrlMEAWBhgGcC0m6TrqAgdSe BIUC6kqgBktkkGrKjgYVCk0IYryGQSRFkiAQggd1CO4eIu5UkgcToghRMgjd5CUbYiaFcL6YSGyO MG12UvDyJgrzBsAQr6aqEIyMotqyECnHwguX0gstw/mcTxWH7C40zAw7R5I2AwamRQhAQArKrwBy IMTkUCxxoAlgQwhMzPqyysFEh1bwYjD6QnR2DxJtYKu8KjAk0RNtADJYsZEMKVRIhQP/7mAVWywt 7o0yvJAzCo4LYIANjqMxAyB3kMVZLmmuHs7hfoACREAzi3H8OtMzxW8Zraz8WmDKvEAIHst62kU5 3O8alUPldik/4oWXTosT6qzOSus7DtA+9MyW7Ad/3HF/ZOsBh47oQia3dIAfx8kflU4Dm87pKGgM PNDSqC6efmQEf2S5GEBoHBKE+IkaRs2fmMZppgQjYZCgqOagDupqPHKhDKI9P3Lt5o7WiNAH6fPt 7vM+FcIH8ZM/81M+d/Ak464mbfLWeuiH1ubvKGKKorDwgpIoi9KmGCcpJ/Qf+I0vF8Pyuk3DCJPG ngoFQo4K0q8AWoACIOEEzI0OT0AM/xjBO07AABKgB6rqqhgJkVLHL9NCLsvCBvSS3jgADToRAcaA R2+lwyivVhBAMJ1y8vit3zhHrRITyBaTDdhAC2AA4TrnmrRPk0QDBqpAGDXzSz1zGME0GDnTMzFO GElUD9iveqzHeXDjsZTDeq5xl7Rxfg7wXmyTztzHtAzQOlJLz/ZDAXvOtX4O6OQRAuuxQvCRQ3Kr ZPoRZUyEBTKwgc6JAweSINtpR6pTnoTEAjitIZ8ruvRJIksoSkwI7CyyIsVOBs3uhdQTvE6BS05B Vl9NvEZyvHgQId7OJfmTB5VhGOZOWH8VP91uWIXVJdmua4L1Pl2SWHlVh2gN71DqCP/jxGw2YiNE wiaecKaQgdkgdMAQjEIdz4w0j/nkzUbXggwvjAy/ragQoHMkAAk8D02/UsTk8AswIAV6IF9PdJhe tAnOgAzuItzCKjFyFAF2tN58FEiFNFdkDFgcKTApQ94CYzBc7JGUJRYX8ziW4DhEIzSI48d8pzJ3 EQb0IE2BkTTRtDM3s0zJNGU/EzQpQA9itHqAo1sgy3pe03twyQC6kTpMS09Ji5lcFB3zjDdXq89c 68+saWPoUVGLDpx0gAIhdYGYc0U28DlrZjqpzjqVC2gYkmgcMrr6CTxNVUouUm3NU7vS0x3c4exi qGpoNbxgLSSDdSThrleZ9e3wNj//iVAHdZBr6hNYeVVZRXJwCfeh7HM/5fMkhfDulMiHshUjQmKK DE/AwHVTFozBxjWnHEwtfGX5zAjzyLAM0Qh18aJzbmBlE6EFViAGRCxfX6ASGMHc+nWYXDQB2g8G /q3y+PJGde8RdXRIX4xh8/IxjNQwm+8v7kB2jtRiN+cylMUKioXdZHEW2+pjH040UkM1GO4MvLQY g3E0NxMYXdZl0xRmyzRlpwwDmMB5YABntcD9IOs1Tw428XRol8m0+jR+cmlhlNY/2vG1DNVpnzaA LGQBDg2cjg7pGA1Flu6cIm24Kkg6NZVHrq5TPzVsO625upPrRGgiUZU8X5Btscug/1jtoOT27Oj2 VttzJLXGWPF2WfOWWGsohhE3WA+icAP3IHI4TYhVB09SWPuzTSC3pNoGQfNrTljicqnIWw9Pc7ui UTg3Ka4B2jwXUrRKLU4n3CInw9iVKt81jc5CAQZgZUe0AKRAD06ADgFBDPhVDnM3d43ALJEgjwTD LdH1MBBWYXv0R5E3eW9srCSjC4NlYlmskfj4cQiZdtZK+hzzOBZTCxTkMa+pFSyzFUCgAMh0GNF0 TNH3ZUX5S83UZQsABPAYOLJSN0auetLsluaF/w7GmM6jlom2T49WXlRLgAm1UN9R0BA4gKK2gPRx E5Bzt5YTRSi1ZSyVA7nWZnJmg/9+ZIM9KOvuSVT5KSKn659MSFVPWKCkwQHeltW8yxdOgYW7hG4H glbR+T1Dku2AOIdxWJ4DF4h/WIfneVnhjoaJUD95mFcdlybz0+5QKqTMxogAxSakcCcE7EETx4ol VIsfJXQ1p6kyRy9KtwyziqiW7wgSofwSIREoIAbyNcQqgV9DTw5Djzvs2I6hA4+FLC9srI+HN2F5 tGBd53iDtHjFinmftzK2cAx895AuNlgwo3M0IzG1lzFpsbEYgRFELjWixTIjoAkyc5RDmURHNH1F 2avB9HzZdwCqSn7llzfoFzWbgE4piznghRuvo1/e45bl2uUMwGjjJx0DeFB7wJf/G7B/5AoCQYaB RybRFu1qI9jR0Gm4MBVHiovqemaDF9Kag8bThOHTRK1URzhKros815ZVtcsBNjKFaZBLHqAjfeEB atWdz1mG87ZY066eYTufSVK2c/CebZueRZKfETdxGUJviVXXek1s8MttnOhyG1RRhBJcI1qiJxpU yPiiMTpd1TVyUnemG8kA1Lhe2ZgOMaASKgBfQ+8LchfOnINhmiCPQkcx/Linv2qnHbYwcppJ/42+ A24pI2AMAM5CWbFU+uKspndj26oxj0MLGEE5NmADeuBzAqBcRKMv9OCrT/kXwbqUIzx9wxpMC+AG OIGsWxmtdRaWKUs67AU8CNDE/9vH5bYDz8AHUPdsUPvaUBNEHhG40G6rgZFZnJIOsbO26SKtAz9w 6jI4SHqmBD+VnoZkHLZu1JikVF3whIDBFL6ZbQcKS0jbyq2cbk8htdF5nnPwblv7TFK7tnEVzMm8 nmP4IOB5JJWVcctrWO0O1zQqiegGpp6YijJ3ipm7c52bolM3ut1VL8Zwo62bL7LgF71ypLsAA74A EFCa0UUsd0PvBFzaCOzYsmJ6yNbbpv8Yxt67vU2Hw1KRxnx3xShpDLaQkfttWBSgAZQakmVRSg18 A0xABewYY56lAcoiFLDawtEXw3v9ws13GCkABFZZN+DU/e6PPyiLG+vlfeLaX/9O3M5czn9ZfDfp x37upx2b1mn/hzgVeBBwAdEQyGpThpl53DklDZox+CDBlkiWSxjItuuUREmcfLOJIcpNuDwzMgZX rYXeFm4PSpyvHExU+wHA/G5PgbYPfrxQW8thLYfPmVZje8wjvsx1mGtOcle9JiZr7QiH26BRar/m BIp2ArkbGs8hVM8TjM8puozrsro52i4yDMOc6lzlLRVuAKRHU8Nf4ERRGhAYXQ9eQNLruD5M4EW1 sQnWzfoOdtOHNKdZx9MR41UK1khrzPk+I79pBWId6Umhz1iO5Xq1lwumVNY3wACM4DsWfDMiI7uB /deB3at/PU31AAZ+Q36PHTX/XZOvl117EuBnD+Y7+uVfCJ9/c/kAATVQ+6M/tj3GhXM4h3mAjPM4 H1XHz53pIuiZa0TqHtsCrhNImItIjOS5+AkYpKvev866puQAUCjKwTkY3GHsqia74JbgW/icU3vL XfgjXfgBft+dh0HLH17tYvicsyaGuVztjl+24XPteFtwdVA+B7TuQp7OSf4n79yKptinOLflt7hc EQAH/AAAyt8PcGCm6zJdwxjC1GjDUkcBiMArMW6kIUHEUiAI3PgFYoD/AeIFhhNGOHEyYsSAARMG VCTY0ASJFhgoFESIwCGjRgQaBaHhgACBDRshOYLkWDKlypUsV3JAIyjkGJIt/0OCPJnyYskINS9G sDiGjM6VPotGIMOFC4qlS8k0QJEUKhcYMLiwcRFkwwYDCL+c0ALVIkgFBgqIOIs27dkWa9W6fZuW rVwRbOneEHKGqpZUWvoi+dukyZ4ehIUYPkxFhQoDIDj9OPHjB5bIkw1yMmD5skLNCjsrbqhYhWEm TISQZtKjQuoKFVy4fi0jdoAaATLVzpTJle4FvBcMkuQh+KZNYoqLSTEk+ZAnzJmHeB5iyxYS1KnP uD6DgPbtGgho+P69g/jxFjpYOI/ewoT149YzsPZeGDVhzoQBowYsv/79pg4EA2bKf8AEQ2B/phBD YIIKLphgMcG4A6GCEBbjQP+FFl6IYYYPYHjKAx76AqIvp4h4yikWluihh6cME2KIK5L4AIvDzFgi iyB2SKKNINr44ow+DtMLkEEGOWMvIyijjJEjLMlkk0o26cMIv0j5S5S/XFkllloawwsvXHYJZphi 8pJLl2Xmgmaaaq65pj9uvglnnG/+Q2eddt6JZ5567mmSRhz4cQEEgkJwwQUA+MlSRjjgIEAYAgiA AweRZtQnSxEkQEELBRRAQQGa5qDHCSkwgsEXgHRxQ6o3xPDCCScolFACsm4gRAJC9NCEFmdUxBMH GKEUkkcajYRAryXhVFOyOaX0UkwIzKQssIki2hJPPN1RFFHFXkRGt1JFtdT/U1wEkFRSMLCBrlYb mKACQhj8IMNSxYaEAhF1wRWXp/juuy9bBeihayowpMKXFoAFRlgPpB1mWAKLYWbZCZVVxgkIEHPG WWegLRYaw6eRpvBqrL3mWmwyBIAyyrjlplsDvEkCXHAeDKfDcSkgp9wTyzkH3XTTWYdddtlx5x14 4x2Nj3nlpWdBe+9ZIwwDwkw9tTP54We11fvlR8wB+ZkSoIJgM0h22dK444A7CaLtAIUZvg133A50 SPcDI1bY4YkP+DKM3X6XSPeIPNq9Y+AwAo7iiCH+2MuQRAIpZC9ITj45k0Y+yaSVS05JZZU+fO7D lcaM3iWXX445JjJkssl6/+toygn7nP9c48+ett9+u02UChLooIMa6mfwGjEqgCCOUrsRpcdyAEMM m3ZaQCKJUBDDFyk08cVjgMQgxQ05dN8FJIAkxJUBG8hqWA9ZRIREKgEIdZHyCHiEA0cj/cQTs9Hu b5NNMMlEk5D4RH8qGUqxfIUsAQowftjKVk6Owi2ooGuCXPCEuahSLnKhixEbUAG7TIAQHmAALL/i iAK8wK+43CuFLLxXC6SAl4HBYAoF+wsSEEaY0jBMCFTAzAkcA0TISMxiBsEMxDajMYVwLDSKOUxp PqYa1rQGCSQz2clSdptMNMAVvVlAHGQ2M+IUJwViUM7OnsCCJ0AnBCT4Gf/QsLOdOIInPEcjD9PQ M4H3SA1qVJsaNeoDDPtoDRiDJMZ+/LOgA5hiQGVr5IIcEAxIVkgaFXLbhc4mt0xa6G+Bw5DdAGe3 uXHybyoK3CdjJKJN1k1xMvpRkVwZucYZSRlHmiXlMNckzukyS6HTEpa8hDrUqY5Mq3OdMXMRu9hd Y5m1w50zn/mPPmVEAL3zHaEEITxKDY94j7qJS6R5EwVgYFPkjF4BbqCHVTRhICfAQAxWQIEcxCBV OVgVJFz1ECGc7zC4asL6psCFbmHkJMIKyUgUQAaLHIt/NQHJAP3nLGgtcF75A5a1DIhA3e3EKBxo 4EN3ktCjoIANjGhCEBj/sQR0WYUNVKlKuTbYQYQgBIRe4UL8DoiAKrBwLS5c4U7fIhcKjDAvBOOL Cwx2wyYkDGSHcdjFGvNDyyDRiBhL4sY6JhonniZhImsNbEyGRdusbDcvg5nMNlGzm+EsOc3h2XO2 wMbqBE1ocpyjBuooHnxYQK8lSI97GDABPvaRPlMjpGG3trUDKJJBYXOkYwnkDge1TRprY9tk3YFJ TXIoQ3kLnInwxkkOnXJDoDVl4kKJt1XuaEewdOWQICc5WiLpSLSdbZOYpEvcSqmXxvhFb3nxC2AG c0xnOuYxkwm7a8xOdtBsLp6kOSlAFYpQhRKAorKZESjgwBCOgtRGlte//5uAJAsUSASnykm9UZ0A EK5ynqYo0L0YcE+e4nvVBtRHq/tmYSs90NVS4seBgorEBgoocEWlxdCFbquizQLgRA1YQKMw6yQ4 MQpGPGqpbpFhpByc6QYYwYhHgDilbBjXSpewLpkaAYRG4IEBUJARYyGAEz5toVl+yi+53KAJMMjL Xmp4sMIk7DBIzIyrMnaZJBvRqp7ZmBCy+kSQEUaKXq2iyWiTspXlposxC6MY18rW5qzxOdUhwVzj yJ054pU8fcVjHgMLtT0OtrCBHCRig3EgsB2IQQhC0GMT1FgCSRZClG0QgSR5trNZtkIQ0qyGEudJ SGuItHqjtChTBLi3ff/SRq2F5WslN0tbzvK2t42S5naJpd+ebrhiOlMxjcsm5MZpdrRzk3NvbSeN ckAACMABoABQKENhk1rSfNSjwnA8RAWvgMwbgKbKad4c4MAF6yXICSjAU/jOk57ybJURNpAF9Zm0 Vhv4wBSowqsICPigDVBo/xK8LIcu+MKCuMgYADDA/FnYJxbJt03ip28Ld/SjRtmwVTp8gi98wcMb CAISliCDCbJhCUFolxEIouJXwViBGaFCjVNYl2fjOC50KXkBfoCEgQnsqEhNKld7QOQin6AxGetM kmuusSUycYem2SprREYyF1hxNirTMlkl8cWzEudmZQyzmHvWRrkGjQD/QyuaXdd8njbj0Wnw6fqc C6s1OyM2bIEOBoLKXja0MwizaSOQNAodjERjdu4PQlui0+ZoDtHtQimam2bzpmm/+Z2zhNvb3vh2 I755WpaSO5JsZ0tLUpdaSrv15ZVKB8xVBxNNr4Z1m2Qdp1o3E9e31nV0g00oAAz7u8uTFA66Oylt Js8lZPhB9KAXvekNAgkXn7kBXnDjFgifU1Kop/dW1YVWmQ9XjOjBBh7OhokoRQHrJrACGjDQBMKb I9bq9wFhwpOZ5HsoRikwQvd9wIui36M+gd9PoAIDFF/cEV1I/hc+8e2TuoDE6HpEuz6BcQixEAiB AgYUAWegBx+3U5ui/4AjRxdCpStUQTB+EQoux1WGYXNU1RhMRlVLZlU6t3Om0XNQRGUj81UygGVF hxtktQBmJRw1cxxm1FZjFh1SB0dVl2bfoQp1dEcTcB4T4DQTEDXx8XWAJHZbMzZmp4SIpIR45md/ BoVmQ3cSIneRlEmL5gClFHiO9lme9DeDt1l1cyOAIyKK52lA4nhpmCS1JHlLYmqU1zlaknlzyGpm QibIkAt46HmvA3rJRHqlB06SIgDANl2Fgk0ooTzilRGGsCjCI03gVBJNkCnk1CnmlQk9YACu8ipG EANy4YnvJQXypSoxID5GkAAfwAh/sQTxJ0MwdgcnwW4IBSzyw1A64f9Q+NMrd1Bvz4JvCoQ/CWV+ +BOM7rdvxcgBY2B+ydhu1zcVFLcBRvAJX0ADYNAFNMADJhAEJwV96FIHz3hxPBCAK0aAuIgAZ1AF N+aA6Ygvwid8FPADPSAwBCMDfWEwoYBDQyYERQYxD2NVOJdED8NETeQxHzNlJWhlNXBFKriCvQEz XYZWYzQETTeDakRmbnRmaGZXd3UL4rE0SsM067EeXQc1gkVn9mGSiKUfgYYgAOIffgYMiOQfiqRY BYJnakc2NtlIikZZENJoefeFGpJ3mtSFcaNaQ1kirCUjjUM5SdJ4ttWGUDICoROVW4J5mjdcnOdq xeV5/sCHfQgnf+j/XLN4XThAiIRYKPVjEtynO4rSiMqWPMuGETAgBeZFAbiXCDXQLlzhKgYACJmi KezIjs9jfKuyKq2SACi1BBDHUmdgU2MwLwe1FGKhYAmGQNbifgrQYBGABzZgLcUiFAW2jAUmFCFV jA+Fi6MZAUHRLU/RAKy5FFaxBB3GA7JAA9V4f9jICC7Qf0vwCCn2CTzwBVjwCfhnAixWgN2CAAoA ClKgjg2IY8OnLy1wAwaQci21FxRYATh0K/mYgUrUEBzogRyoGLbSRFA2gjlUgiYodGCVgkbHRbzx GzGDVpVgHGs1g2skHdZhZjhYV0ZDHnbENO0xDoClR1HzdfaxDEaI/5IzuSAv2Vgy6aCKdUj9EQyK pGcKAncUGoUJ8nZu93ZzBzc8yXclEpQWgoUlKlqr1IW+4AAioiN881rDgCRoCHm4RGpvSHmp9ktf YpXERUxZuYfIlCZe+ZVgCU2BuGvSFWzBZl3Y5SdtuWzi1Xo3gQJeYE7PEz01gAWvMnMJwYmeUk6e ApibEl/yNU9dAAgGEBEsRRUBkJohNRIb9l8atX0Y8SsQ1G8dFVEAoEDFAppMAagNoGFHsZqDehTJ KJpCMQZMAS6MCpscBELRKAuycAIm0HCMMHGlUAqMEASRmnAKxwPEaZwRgH0IgAIGgG3q6BacQgEr MHwrIKbsqEIFMP8AegCm7qgreaFyfnFDN5RDMMePS+ZU4PmP3hmQITiCIMMEBhl0Q5dlY/WeLeiC MwODZJQzTwd1NniDOUhHG8mRd3Qe7cEeejSSBxpI+WEfKPmSFgo2XgMMfdau6+quKdkfTOhIFiqT CmKvZKNoa3N3b/N2mZV3lCSwKIohIvo2nqU3goN4roQkQfKwSxl5koejlrejdRgmWfmje+gmXUmk Rnqk2URNvVMohBgGThp7ixJ7blkp+oOq5hWm9ZAEenBxRgACpggEUoBe50VO0EkBqwIGMVBPMZCm TcBSSZGaTQEAnMkUCjCZlDlQfjpADYYAdxBAC1Rgr3kGW1suSgH/qOGSUGErtk+xFDZwLi3lUiX2 qFlRnCy2Ypf6CCRWBz3AYr/5BY7gCF/AAytmAvhXgEORCgOgqmpRAIugAliwCPyguPxACLoAqwwI mC1gCVigB/MkBRQAMLpqndiJME2Agf+oGIkRrMSac1iVVSL4MajBrCUzdO1pdAwpCQtwVjpAn0x3 rW71VmW2n9dBdRgZHjvIkUnjkR8JhAwwoF1HhFRDSOkqSIk1IPO6SPnhrjLZHy/poIuEvV4TkwYC aIhUrxTakni2rwSCDZAlDQ6iNnGnNpSUIZiVaJbEaAVroopmsO1LSSc6oqi1aYhnhpEDWzIqW2wo eVVSeZbXW6Yj/1x1qLFBikxc2cBEOnogmzvYxTtLWl0ZEQZ+EAaTAqWCqLIdPHvZlAU6y7OdIrMx 8CqZSD4DAD116cIvjHusKk/y1W0nsAET8aZLkQEZwAHASAbvtn0xdoveR7UStUA/kVBa61IBcC4s JXFVAbaCanAkxQZbgFKZKnETxKla0bYgVJxaAWKl4AJ10JvQCI13SwM08AJ7uy7gCGMANmPoqKoF QAhmYMcVUAONUA9mwLiOC6uPO3xpoAdJcBk3IFRXpLkFYzDZqVSeO7qi4RAO4Z3gCZCh4WRPplVS trqsi5BEp5Bb9p6S8BuzO0ZN53QUmbsWOXX9qYN3hTTgGq4DGv+S5Jq8JZkfRzgg6jqhYDN2BnJI 3mtIilWv2tuuBsKEFtq95ru+cfehdXdJASshaNNodje/cyfNltWTF4KwJuoAcieUlEZaONJKsEUk jQPASumUuBQlUxmHvnV5PcpqQMqxHgvBEnw7ThpgFmwohSgohhIpjaiyj6KyjiiliggDbUCJ5FQP hEABL6CXr5IAfEDCxCcFFW3RFl2JdFl8ZhoDaLoBKEALEeAJKLAGGeB+84JgDCWlEGSL/1O1V1t+ CAWoSeHEsdkDQdADI4YuTTxxWxwEgnBSIoaYIEbU2ZgV6lKcfHtSKVUHINa3Z+wIadwFjvAJxRmN JwBjQoABqQD/Ej/gnOu4FpxCCIuABW7QCK6gx3zcuH68Am29KStgCWkwAAbxs3gRAIlMj0iVnQpj yQpxGMdKyR/YMU9mnluVMFRmZbKRglnEMqHcgh4AHA9ZnzLIHCzAAvipu/vZu0RjdR0AvP8JrgIa WPEBHwcKdihJDNWry6sdofMqvRT6y9f7vQ76vMZczG43hRyqvormvnDHoXPnzdX8odecNvIrzXJH dzrJaHCTShmyOEjpWv6bziOgzgVswMGVwAq8sXm4lfT8sfbMJ4roesVjloTyO+adeuDEKAMdpYgo 3mSAKTDbKSuw0AWAwgoB0QnAwgVw0d0ziqLIPZf7uBW9KvL1/wIqsAophQJbEAssbafytn39I2FF HEASxi0a5i00vQRNsC4gpC5cnNQsZgKV0MUNh9RakY0gLuLLh1KPIGIbMJy/GdVpbI0I8Qmy4AhY kNV12QQKILhApS85xilpsAhu4AqZUAM14AZ83Me64ORuDU+6AF96gAEYYAAncwZ3jbbX+Rd73UR+ zTAO8xmj+50AqUQ7d7qZjBrLithVhJAoGFbuCbvyKdnWmjM7k0aY7Ua7u9k5CLyfnTSw3DQhKZLC QJJVg67nytqLrq6urR/ae0jWq0jWG731GqHXu1h159tnA1nAHXf8Otx3x76TxMzAjVm7baKerukP Qr9pc6I/ef8hOMK/rWXOrySxTxmVm+POB3x5GGsmWsnAQwrBtgbeeoKkkUJN1qTsv7OyrsfeIYyk IPEBzpPQNUAInOIFXhorcHC58OXfNzAA4T4AkEDubUDulnu5grkqepAJGGAEQRAGW2DhKQ1vDuVu HOHSVnvEG/WZrdma30JSW6FivXcCPACcCqe3r4C3eKu3s6m3fNu2AmiplzrUHfabPDDjtrli0ZjG WO0rPaCzOgtUdfnVdFEAupAEZu0K9cDybuDyZrDWT97WK+C4FDAAKoAaFHHXd721MkSPFYAEwErY PBfJOtdkTDbmmDyQUrasXZXYi62QLBi7wCEJmxBGxmHKYXb/2XpeZjMANGimHeChCnelCmWfV7As rshr6KRNNfWBH1jD6Kttku0gvXHvvPQqzPMqoevKvbq9Nri9IL6t25z+rxbCzJ8OzaUud/2q29bM za9eN+CMOD1yhj6CzqHWhqe2JaLjW74OJvIcpMNO7MX+XE6a7Muu7BeATRy83t6Fz9iFAraKpQVQ A0lgXjeQwhdnAAnQBnVJ4Kki7uNu7m3QBoEQCMXfBpbrwlKQBFzQBTGgB+8TUBBkEvlDi/xzi0NB 4cvC7woQLt8Cm0GQADMFjQZ/8Aift4cABmCQA+vv/jRA1diYjR+wBBJAB1ZABlZQLucCYgCxwYQR I58c0UDo/4hHwS8IaRhBwUFiqhgiLF7ESIFCC4wdLbYoQCGJG1eiAlRg4kalGX6EdL3UtUImBUtp Bhio4EIGCp4BzvyEASPVlFRatCBBUqHJ0h49hDyFKkTF1KkGrBpQYTXrVqxUpUZ9ykRsDyZNK5x1 kVatDLZsA7wNkEmuXFcL7C6QhFeSB746NukQE1jMEMKEnxx+wiLE4sUkHD+eETkyAcqVCWi4rEGz qnkdVHnuYEH0aNHjTE8YZ22CamvCXLt25hqYMGDOgN2+TRv3bt65Z/deBix4b+LETR0Ahrz4Aeam gj2HHl36dOrT3UlzkF2atGDbu0/n/t3ddXfWyY93gN5ddv/2px64f8A+u/tTvk7d9+Vr2P5evfYP 6w/AAPtTZgQDDzzQhxF+YbDBX4xh0BheJOSlQgsvvDCXXHjRsEMPPwTRHxFHJLFEEv9BMUUVV2Sx RRcRkCjGGHEQwI8LIMAxRwgu4DHHC3CYEQcaBRBSRiOPlJGMBCgooMkVCqghiSYpOMEEq4wwIAE+ bpCiyxtuGCDMASBpo41AAoEDjiP4AKFNPo4IZIAcpOiihi9j2KAJA5rgIgI/OYgAAUEHJbRQQwXl AAE/A0UUDUEEvcOGQxVdlAyeeOICBS64COCRHgYiyIgTeCC1VFIdcaSUKFZlNYc8aJDlExM2CIIR LqBYI5b/C/DAA4A1DCEDhiWCMKFYI3hwiAZHPvmkoVe/MIAMBMiIgIMzBvAIoxY40raAFbZdIY0k VKigEXNrqMCNdM1gyaWXZJJJl3GFcOGtS1tBwSefggrKKKSWaqIpp5gA6ymqqNIqK626OjgqsR5m ooIezqJYLZ3YqgEuuOhypeO7JNmLL742IRkwwQYrDDEWnghBMcYaeyxmyWawjDLMNJhHs84+w6cD fPAhzQLUhh5nggkYWO01pWHjjTbdcBsOauFk020a4a4O7uniriZOua0POM656cAeW+zqqNvuuu/O li5t7MqLzm3ypLlOPrvvdqA+vfMbJj/9/gNcQGUKRLBw/wN/WdBBCB9kEEPHH68QGRAn99BEyy93 MXPNX0SSAyHDAIBH0XcEwEbRAZARSCFpLLJz1znQ4oYpmwxAyia7OMEAE0DIMgEvvBQTEuHbIEJN Po5vs82rEjAAhBNUiKCLG3KYKoYX9oSB2hgn5Z7QRBcdlANHBR1D0kEDBd9PBRq4VNNN2UBig2M/ IZX++pmlX5ZUc2AVjDxeVZYseGCCIDgBCrHAER501KsicCEI8jtVskj1hTyAAQw04EECyKCATCmA A0goQLZEKAJC1KsCQmBCvTqWiUbUwIU1aEQ93MCPlsBEF0wKCSfiwj72tQ8FZ/DJGYJSlKMkhSlN IRjBDP8mlQRURWEKY9jBVAAWiI2FYmix2MVkoLG5ZKJjHtNLyDxAsk2cLAViSEFhUjYElbHsZTGT mWMIQDPLYGYeBMhZznjms9AAjTTjsAAgi5aapRWSNrbRjdawththLKORu7GaI2Xzm6htrZKm2Bpv wHYcskmnk89BjimccxxPBuOTbWMbeIIxnvWo7QBoOw/e8HafvenHln3jG+D80wvCGa5wPnBQMBkH OWJGjkOUo9zllHmizTVzczDqnAAE4YfSAcCaofMDNa15AUF4TgDepFEYWJcoiSCKnImC5oxgAIkm hQRKjmhSInIAiKsYQQUJOMEApHCDGIyJTGSqwpqQlzz/A1AhAQfNQlNgkAEhGAAQPdjAnGIAiA2g oFqKwmj3DnVRSoVvfAgoH0YXhT5FkYGHPeQCDNjABkaYgAdf+IKpeIA/gtCPBoeIggVp8Kr/5QFV y2LEGwCAoxvpCEcAwMQSBoKsCiZEfzTIgf+WtQFLaQEFClBAKEKIESmgggLZKoAQJBIBD8QhDh6Q hCu8KIqSiMKtNXADS/gBE5kUwBJYyARWG7DX9rViU0AZor+MKLCBQSUBBjvYVZzIsK9MESpJtOIV sZiWtsggY2/p4hftkpe9bGKMfkFjCkSrRjUiJjEsU4zLQkCC1cJRjnSsmR1xpgFVqKJnHfBZ0IRm tKGt/0Y1hnyNM6jxm984o5K3iZokqTYbpy33uFtTZCZxA7bk3OYA2IAO2LRrSkxW95SvfA520XY2 YJTyOXNbm9mgQze6yecUsszbe95zS7/dMnD+UUYvfIkgBQmzQYubUDEdhwxeEBiZyVymMp25YBe5 jkbTtCY1s1k6avIIAN2UyOqIFAYi1eiaEy6dOKcpiNZxAAUGYFKKo/SkkEBCd1gSAvMCEQMwjalM RCBCFQCxpuSBIAEGzQIoEroHJKDABjBASgQacIIuUCAHJ7BqtQB1KHR2D1AjDZT4MqCoSAkKy5Qy afs2xYWVstQEX3BETGc600+EqiD6K4X/ENJTAPrUCP8SWANRi7ojH63BCvJriAV9iiqorgqDn9Ag F/YwBQQogApb/YhYDcCRbX2EE5lQlAcANYizDsLTg5BEHDJRDxg2Iq7uiskNV0CIAKxvrz3M1xl+ CFihaMEFRQwYEpUYFSlKMYpdKVgVyyKxilmsLZfF7Fw0u1kx/qWMgTljaU17GBasrNqMUa1r5UiC mtUxj/NQxS1qK+6f/bFoRFPNBITRGuAq7TfDJY7VpuGarL0GN+6Wbr71zZzqJue6zwlbc4IhSn8D Q72mDIZ4zXs2sYHXlF57JXfCAx5WwneW+KGv33CpSwLtF0GIMxAwhQmhAAs4QwdGeYItx2CWq8hz M5L/kTSvWbppZlObF7gwkDJMJNYNVUd71rOeAaDzJcSgnSuIEg7l+byrZAkEkOjn8HB8BKrz4QQE 7Z0QEpqFpRg5KFwQhCC4kIAcUGAAG8geRxEVPo1ydKQwclSgykfSCFCrUihNaZlX2lI0x5SmoTIB /RyRB1XNmc49pUEQwqBAoPN5RxdYAxk+YARHdEHOB8kDq6KAQSNQlQtNSEUEUPADSLcAA2/Rw0e2 SgEZcGAQfhpEWfUSB1fUoB4qSIIuLMGPdsGEAjfMYV6xqgAUwDpfXADiGWQAAxnYuohKIaxYwOLr rXClYVN5LMQmJtkstkVjcZlLA8CYF7R61tmhJe20/1+2/vWzVtskgG23M6PHz5A7NKMR5ASElhqj WYMB7S6k34gu5IIaR7q3ZZgG5aI3fbs3SuKa3uC35BAl5Pgk7eIk7lIOgQuvhDMFhYsOh6OOUTIb THI3bPAOgGuburE4u3EP+6qvvoFBXRqGAtGv/VKQBUmcYFocCaEQk9uQH0S5yVE5E2m5IuQADxMd C/MDCLM5CpswnMumb3q5IxQAAQgdxwO6PctCP+AAMviBJ9GIUkiCFcAhCrieBMCSg0oAOIAEG2sD OKgCODieq1Oe3gGFPeiBpUAKFMADfgk7FGAEQHAyA/gAi8qozqEyRKkUSuGAOxAEPwkpP6EUBYgA rP+6lE1RqTIjM0BDFTZzs5piqlLIAcPLA0vwH0t4FUYQBMZrPKIqnSJgAxN4ARroAmXZKTCIApnY vJlKAJ6YAhSIAy0YAG4xPT/hBEgrAG7BABjxEw+IgNirPRVYhCRIA11Ixm25xnj5lgIghB4AxvUB Rx/6IeTjFyLCNcIiCxTiNeyjvob5iux7GLPYvsnSoi3aGGUDI70QGQ/wizIarZQxLfYTyMZoLTiq GTq6mXn4tnCrrQ64BT/CP9Q4N9RQjVEAwEKKjUyit+HAt9wYQKuxt2UQSUYiLgY0uN0QpbDhJH6j QJZMSeUQJQ9EuFN6yePwQFOQgwm4hZ2cAGCgG4D/A8FVYi8HGErskCVasqWkpKVa4hteyq9e8iUf ACap9K8K+QWTsxAN4ZBjCsIPGUJmKkIGMx2jIioQs7mzDB0Kk0LW4TAcuJG3zELHk8sdwYEiSADZ 8ZYacAQpyIG+tAQ9SIANSAATUEMQYEMygYMcY5ME8DHeyboEyII9aIIP2MMjCwocWAVNSQApMEMD QAIymLK1IydoMhQZURRKrDs/cURIzAAs05TXxJRNCQC9K4UgMAI0Uxa/czNm4YGnijOHOLz/cYQg MARW9JGiwjlBKAIUyAJkSQgaWJVESIScghUeiJYGSAUUaAVYGICtGoBM4IA4wJaLAAmLKAAYuLJB /7iLAFABl/i9ZCTPRHASbkkDGfCTOBg+V7uXfGkFn1i+5nu+I4q+6WvHXpsix0KhKpKsnDA2y7LH ZPMiL6oLvAC1kTk/0UojgDyMgXyj1irImJkjbpO/y8AjcKst2/oZiBQNiRwa1fi/iwRA3qg3SRJA e0uk35C3e3sNkeRRj3wkk9yagIM47zKO7QIlbAAb8UJSCjyO5OiO7ZiNW5gjArgFYQiG9EA462Cv 80gbvPEFB3iP+sClL5WvvYlBAJnBGvS4EQCmHIyQBgmwHiymH+TKrtSQrwTLsGymK3zLxyMdbZow EDsdP6jCDQu7MBCEK+SzVmRULvygGMChADCDGP9Igy6wBEvoggT4gA24JzXkA+HJMSAAATXYgz3Y gR3Ygx/7sSyITK5DiiI7slSAgbDblCV4AQq4AYrqkyMxp3IqFCm7stSclgi4AxyouzHIgCKoO01R qSVQqTHTRDYohUewzYagRadqM/wplYMohVfBvMNTlg14AwT6OSz0gzCAAivgO+CMAulclQsSIBV4 hTMw1VPdgyrQiB6QiAr4Km25iCogA2M1KU+DK3YZw0r7CJjglhVggjiIALMCRx4Sx7cQolp7VQEd 0OmTCoSRoneEx3hc0O5zi3vkmAnFC7QaGdA6oww1jDbi0NXy0PeLP8v4Nj0Ct5/JLQtQ0d2aSGv/ GAV1KyRHqjcY9UgDrNHlMiTfaLfcmLcBvBpFesnlsK7diEAIDLiHw66spUBNKq/vAAYGuIV+YIF+ IIAJuNKJozj2eg7uUMFZClP9KNMytY/6+BsCGZwRuFuP+4Wp/K8HqRA5ndNjqtOuxNMR0dMFG8vG 46ZEjbBq2iacu4BzxQFETUsoDJ3TScLM7RGcUx0uEMREoIBBMANUTIM0uNQTYFXmCUw0JAJIIAI+ SABSrdcdmAJUPaw90DrJbAIksCobqFgSW4JNucvO/Mwr257w8VVGmTL0UYBpQc1i3SA8yAD2ybsl YASkWILs1YLslVZGIJZmAU6dUgj80dYvkAVP/3AIQrPFg3AEE7ACAFAgolrUyDUEKCADJ2CEDWAq XFwB6VwBOYsVFWgAGEiAO9yBn0ioBghPDBghESgALdg0u2Cheui9a7QICmAXa9wWCqiAh83PiBVH 5HsLoUiKfyGsXEvHXTvQqWgiA3WYBAXZK8qii6mBBwU/uRC/CQ21kCEjwYg2Dd3Ql41ZbZvZykhI ndkjnS03czMNazgN1mA3pUEk5ioki9xRG6Vid0skGAUuYGjapu2NH9UN8IIbgiNAIJ2u22jS2xCv qtWk6BAGCyAAsR1bfDgA7QAlUZIO8oAO8ljB+XiP7CjTFhRT/dilGbzb/PolHEQc/2qckhMwrf+0 U68sXBE53M2hEdPRXJnDuct9XAu7MEHokZ87HVHeEQgTnWyCwiUUkgjIAqNbgUyYVEKIgVLEVEA4 KCPQVAnYgQQ4AjgY1VKd3dpN1QIu1TykTFgNgKAIOxhgVkBYgYlKABgAn+MlzfP51brLTzIYAxzg CRtYhTMgsyVACkYwZ0bogSBI53TeAAg6iFqsoCiIquq8H/sxgT4YPGVR34RwBCNYgkjYJl0hnV8p AjKQgDoIAmJxBDDgn3Z1V6maqQ0YBC64gh1QAnyxAkoElFTo1xFKAgUGNVc4FzNINWtcAV0gBBUQ hUbgh29pAV1o2EoER0vkq0uh2H05CoBBYXT/LJjG4tjre2HtMwu0YFDKGlkILVlm28fzQyNpUxkh dowPBdEipgyFnK2GRFELuL8/6q2icWJr8L9RiGItBi4rvuKjXRqlVZoX5WLX+OIHnA3lGg5TYCW1 GbjbsBo0ni43JiWvMY7wEgZ8mONq64db8Em7DhtUghu6qRvGhq/7COS80Ru6hcG67bgaVFPDkUqq 7NurxEogHNwgrGTDveTM8ZxE7eRtorDL1dzTKR0tJGUofEs/mAXVfkLOfTk2OAEpgBIssIQbsIQ5 0QhI0OVdlgBeZsw2UYOKPtXa7eUCjswe0N3d9bopgIEUEAQ2gIFNQbHOZISI4ChfxWZGyajT/zQp BSADbuaAlIoFHMjE7D1nRmiChGZn+WGIfcZF6nQEWfA7+mGWe34qfeZnVPkCE7AVMogEP1iDC0tX K3Bw/M1fHsgBeJHO6aTOAZqVDYKBM1CAWpAAWauWOJg0ESLGJAiAZ3QrXGih3iMEM6gAGciECHAF kt6W+lyU4dur9bmUTOiJWEMynUZHFJa+XdvYJoqiFaaiKppHevS+y8qEG3YF8bsLUBOjz3o2ljUM NqK2xBBI9yNiEa2ZO9IZ2mJIPgIaFR2kQTKa/5sAsR5r16CGtm4kqnGkpg3ApWEAtpbzpQFjpQHj 5EAPLAW4HKXaB3yuqfXrTfLr3mi4wCaAlv8Z2yrtjjI2uKDEjvXCDqNcD/gKU0G2j0+v7I3DL/3S L0XW7AXh277lBc+G5Meh00nOhdG25NJuMBixkbRk7dY2Kh5ZwrHEQsitMF6vsJmrMEL1nAj4vC6A kkXgTI3gnxzoAkJcgimYdgmYgmJWVWEuVVVtVTzc3cqEAS2YgmbebjIougKQAgxAOykD1l6tMvK+ 8Q1iH26OgJXKgEpYAjZYAhdgBOs1Z/pWZ4EARcEbvIaWKpgylWIxgVUQvGT5qYfngQ1gBCegAzKg Ayfg3k05hENggw2ggQKocBFIhBXIKTDo53ZOgAZQgEs4g1b4CYt62AAwgBvglgbGgEx4PQ//WGkK dhd+yARnfL04cAOTJgQm2PCrUp8cJz4fQj4hQoKA2Wl0JIskItAVPtCNTfIENYsmKLa1OOq4AD+1 MtnNQtkxIiOTCQzSatnEuDbGiGrXIlv5uyP644zP8Jly21lAMho1/y2g3XNDsvM9z/PBx/O2DnwF TOuulY4CBEmosTfgEI5F7zfiCI5Gl1I67od56EmhDAbcIKX1io7x2FIHWCWLi4/4wg8H0Lik5A/C cUobDDlHXnULAdyTC+2Uk3Va5xzQcW2yzFz5JZ1v4tPNxXU+pW3VtqZZkDCdEz0JMAApqIdFcPZK Nd00OAEksHYkWILjtt0fAwGDUkM1OKjc/51u6j6yKRh3QeCX9DYCCliBF0gAPml3GBHN8CGp09Qr SxmDCFApgMhQaYmWJUtKMUoYJEiPhUE2mDBhZKIRHrJogIkSJQeYPDQcfeEh8lPEIH0+yXL0kcZH Ry5VOuJhYsPCDxATMGJDhwxPOnVorBAhIhFRjWBoyIRogA4KLWdaneGiIEKETLBUpOLUQihXrokK UNBTIdOCTI3qmSGkq4AuN648UJUUpx6hAi0KSImh54cQGCgUAG6AYjCKAIRRnEmFpEkPxj0eQ47M ZLKQykJUXL6sAjNmy54nT45cYTRpF6ZNy0hdIwDrAJlew16wQNQCSbU9SPLgYZMOMb5/i/8ZInz4 ExbGQxwPoZwE8+YzZhCATmA6AQ0E5mlQpV37LVX4OuCzEN4C+fLjyE8YN27CBGHWhMGPL38+/fr2 6zMYlZ9Be/gMhPEH4H/06TfKKPYBs4x8E6DXHjAPmmLKg8DIR+GE8U2Y4YPLHLCMhhp66GGGwQRz gDC3ENAPC/30Q4AFwgTjDokZmhIMNiTiSKI70rgjozQ8uuOAkEMSWaQDD5wi5CnD+OLLME8O00sv ylCpzAjK9DKCllty+csIv4DpA5jG/EImL2eimSYvuazZZi5vwhmnnP748yadd+KZJ53/8Nmnn38C GqifCABwwQUAFGroBRAwuqihiTIa6aH/YeDgx6OFQnBooYgq6keiimoKwCyC4IADGTDAkEUM9biB xRecbGaGrEyQgQkUZBQBhSFQWCGBEopIIEErwkrABWEKNIAsGVRFgIMNMKQyhbOl4iBIBhFssIgB LnDBwRYA2BCuuOOSC264GaCLrrW0DOIEDOhWEm8lEfTRRwSDkPEKGYMM4kkmXBxSisClPBKERCaQ NNMjjxBcyiGe0OHJKgjzoJJHLLUUU8ImGDxREFz0wQG++XJhxAqJDJXIClEc9UXCn5zABRlnSPCU AghwsEAAl8URAQYFFAAJCBgAwkkTWgTARQBMLMJJBW4kQcFWIuhSg24R6BZHDfwUIFQL/3eBNcAP PQSQ7GGEcXFGAGw00bZjjTX29mNCMOHZZpVx5llloPHdAxMV9EBaBacRnpoMNcjQmmuwZeKKK7LJ JonkuunWG3DDDcdCcU8ox8JyzYHOXHTUkV6dBthpN0934OHTegcW9AKmOeaMIGUvvqTXnjUD3te7 7/j5px97DPw3YID9Ac/7fAoKw/wEt1hX3S0W9JfhfBQKg72FH27PfYYeZi8ijgygaNyKBLRnyo/B ZHgAMDXmiOOP6+9Yv5H3F3nKKU42+WQvUU6JSlfiEgG15IMv/cIHYgLTL3jRQDWpiU1rkhMF51Qn O+kpg/4QFAc7+CdCKQpTmVpUpDL1Kf8SZsoPghBAGC7lKETBkFMoLOGjVIgDDpChCQlIwAAIwQQ3 ALEeQhxiBDJgLUEgkVQcQAATOcABASBRANSaYgqQiK4IaGEKU0BBBsaFhy1EAIgBiEAKbDCGMdAC jWO4AxvZuMY3vvEOY8ADHfEQLkEojQ0NWEMG+NhHdK1CEKsY5CBTIK9K1OsVmRDYI+oxMId54hWv 6AMmVoEJTBwCYS7JAyc9koeXbCwiEdnAEsjAAXvxpA9kMEEUiFKUln3CCBGRBSBQgIBhteJmHIiA K1wwuAY0AAlMgMEgdhkBJzrRA64wgyXSYAaucaUFuqjHIDyQTFHAoi7R/BrQCnCDHzT/4S/APFsA zgADxlRAbm6LjN8og7fMaEZve+MbEwInuNEQDjWHS5ziFvcaxz2uNri4DW50sJvLEecJm/NcckJA AoeGjgTRkU7ppnO67GRHFeDZaHjwETsGeql2vVjPBHb3nt/9Tnn2MV6B9jOB/ADIP/DxHvZUiqEN CcMCGmCRcVhUndfBh3n3mQZNs0fTDW3PqCTCxokIYL4QEAAfwjhAjyTUvgPEL0fSiNGOgsEjHuHP SElywP72xz//RWkYVxJgAbv0pREscEwNNAYv6ApBNCHjTBXc650wqEE9eTCwgiJDCzU1QxRewA+K PWENcSCARH0KhoudYQklBQA/SBEF/wYAhAG8QIEVUEAKUqBADqQQBSlY4gVZWIIEDBKsHSQABCBI wBV2YFtFKAK2QsjCbvfQtg80AQlI0AJxtQADLnABBmww1hJiUIAcGICUx0TmEquLMyYykVk4VAAZ xpnc5LIhvAVJCCOWoBDGMGIDNIFIRIzwiS/QIA9g4IgnWyIThxiMYjBxyRdc8hFZiDJhRqCJzCrB gSJQBYcGiEILihKFj7zsvYCwwsz+ggCqZII1mYiDB+KwgOlGQBKZYJUKzIAFfmAhCUl45tTYogtC YIEJLsgELlzhhjR0zWtfAxtY0mCACpzhMIYJAAy0wJi2sRPJkpGnZTrzGbqBxm/2FP9cPvWpGsVl mHGOg1xtcpObylnON5hTaEOV87mIkuA5FZ0Odi46D+10gKPgKc9HZTcCc/QCHbmzhklRep8A+bl4 LTUQ8Yg3n3bQFKb1ydA+LJAiTUBaEz2Fzi2Qdx9gEBXRF7KQiGgqVKICw6vBOJGKNDGHFd1CGKbY kVUf5L4DHMAUsc6qV3skoxiF9X76Q9IDzuokKUXJSlZqa1sTCNIy3TXZbtors3Px178KNtp84i4C DOEpQ42QhIldrKc2JdkwCMBSMAyVYi3lqMrScFQ3RECRySABIqA2DWmIgSVGGwXSgmAKXNCiBFAg gR0YAAR7+IBtp7AD3O5gDwkQwsL/s5AFtwVXuEiYAqoqjlwjAO0FCchCt3aJzOs68cJUwdkxI8AT ZA0mbRUvCBIYkYUeJKQJ5FXIQ2YikU9YrCMYw5gsPoFf9opyA4w4BNEfYYKKyUSU7iUJI7gQgSLs EgoGZsMLUPbKmAS4YkawggL63cQIsGYBcJnuvCRRAxUkwRIrANrXKCBvS+S4BSvQhS7WDpYkuKEC i6BAV3TMY7DcQA8GOEMm0AaDxcANbhB/TDB8YSTc2U1vlAnNZAB3zyobDnH99GfjAFqbLn+ZN2EO zpgV2jkzo7k5o6OoRTO6nTmXhzzqUc8EEGhnkQrjQCjVT0zx81IDHah4vdP9foRn/9Oi9j6mA5qQ gm4xg36Yeg7Sn4Ok+zGDSmevdxRyhvUo1OmiKmgaSiURqU2dD030I9WmcIA7Wj2hV8ua1l+99Y5y bSRem7V/TkorlgZYO2J/yQHFVZnMlbKlCZs0W7M9mwZJW7RNgTlJQBGwULeV2wSqUBiUm2RdYKVc CqKUW7dhG7pJih/MAqU4UbUAQBN0QTPFQBrkQRrkAAXIYBd8gAS4CxsMxhTEVgLY1m1NAW4p3A5Z hsM9httIHMUpF6o0gXPlgBEkQBOY0sdZ1xKZnHZRBXcdBnJV3BIgQQ9kwQZkwcwlRB0wwkOol3qZ AHxxEkv41xoCWElwzEMEQR14Av8mrEEs4OEa9EEQfAJJLEQfioRMNB1PTBcXAEKOJQLLfETS4ZxK 8AAKRICFMVEcNMACDAJVeEAD1AATmFgarMDU9F0oek0BrN2O3QUobpMpAg0FgEVYaAFhEFkXRsaR OQZj/MIx4GIu4qID0I3ebEDd9E1o3BM+Dc5pGM7h9JOWbRnkTA6YIVRCFQdymNmZRdTolE52xFns WcDslRSf0cc6MNDsiNQwCAM1aN982FR8FBrwyRR9CF/uFc9LyaNKFdV+qKOhZQ+sCcMEpAgLRF8+ 4IL0oZ+LGNU5JhWnHRXziB+o4QipzUE+NMKppZpXSYP7udr7xNqN3Ij8fBVY2Zr//Q3JKfBak5Ak lADQMFjJlABglwygXT2QAb7JBCWgBS0gYDVgYBmAEDYBbnGdAnCdFfwFYBRBEVRbuH2gH4CbucmQ B3abCIkgBIgKZuEApUCRHyjAD1gCIRBCF2ylJeSAJVBADCTAccEAa6HAFARhFuzBDiwBbp3BDuwW w8nly3lhEQZXxaEKG6yNEcQgIPTABsAAB0yRYFILFU6XYDILT/AECoCXcrVcQhgEGxjEErCBC5Qh e7EXzrFhSKTERSCFH+LXI9QBGaxBocQCosTCGniC0S2EfrnEJ2xAHRwCCniCJ7ABDwRFyiiiI5AE SvjXC3TLVJDcvfDLICwNBmgl/yHIWxrAnSg6JzcBjXOmoirKIFj8gGsUhgwsxjqxE2Tcoi7mIi8y GZRFWT09xjBi3jGuxmpkGWx4XuR42W6MHukJR3F4zjRSI+hAB+tpQH9mozauBwPsTvKVozA4A0jR zjge1YNk3+7xR6HVB6GtY37MI3+wh6UZFffknoHIB4ReJHukSAhA2kPiAqSxAAGkGoMSaEGq6Exl aIgwX4JcCIY05C30wxw0QkSywETKiPvQFKzJGqzNmlbJSP2B5JAgif7oT/+YpO0IkO0Qm5fEFZmA SV0Z4LLJ5ExikLPV5J7cpAcdwRFgwA/8QE5SgcKpwR4onJqupSI8oBUMpQSyEP8LyVAIXRanOOVT jtAKTaUgAMAdZECWNYJZBEAj1EA9NIKz4EEs2EAs0JEN+EEGhAESAYAdAYARJVESpQsHECEXhMsM hAsezAAejIENjFgADIEg2AAtoEGrlsGrwmqr3kGruioatNEdpJENNEByVQKobsEWfKoNzMCvEusT rIKxDhIiDYIk1QsiSdKz1ssgrcEabMEq0EEklCYMTatq1twniERKYMx9KQQg5KZuclLPeesi5kEO sAEHCOcuxQG/LMAmYsEiYIEb1MOhZkIDMEG5SmdX7Ni/miI3QaddWEIPEIYMKAYSjEbbAA47fSd4 HoN4yhNokGc9/Q165tMxImP/azBO43CZ5HyZbgAHfdZnNE7jQ0WUml0jNv6neazHOPTZfFDDgYbj neXZMAAD98moiFADMPysn8GH8bWH8LHHKFyohV6oPC7tfxCag2hI9nGofBTITCXIPkLP8/ljpJ3P i7To9Xyti16t1WJP+JTt+I2ajT5kRPYDPoTaViGV9wCpj8YfrdVPkLAfSIrkkjJpWklJSq6klnjJ 4DKQlV7pAWppBXWpl34pB0HCAAwAJECCF3gBEYQpERAB5VZuFRyBbCXAWiqBBMBpE4VBDB0KuYHK uYVgozQKUoYBBsqBH2CBcqaBI6iYihFCEnDCBwyGBPAEUE5BEwzcDkxBsEzB/8MJL2Ps1sOdQQZ4 YRM0S5DxBDAtSyVswAsaQQ/AQLNo6hFlaqZmwGA60RhwAHIZUXhxQQNADG2iANEdwhI8QnqJ0vyO EkS4lyz1oR8uDBvEAmGV5qWkphMYwUvEBA9gBBgg8Gd6aw6gTMqsQAKThAHTwBfIQhSsQLs2ALNQ xb4MQiYcag3kaCO4gqFmQgXw3b+KwFYMrMCmsCqCDSsWAAYMWRKaBhL4EmkoWcSCJ8U+mTvRk2ho rDEi42q4hj95nm2IbOVcDn0qlOndJ+qFznOwnunAGYBuY0kJKD06g83eLLAtaNj6DtI+6IOKMfEI D9M27dLGB9JCLRirVPBZGv9/dAD09KP5tEilvU9N0Yf19M4y+HHzNI+MVkiopS0JaEI+nF8/TAAh YwOmLWis+eiQ0hqJSAORBEmP5FpZkeSvRQk6POn/FVBIGRsD0ZVdJVteoQmcZKmWLi7jNi6gQO4A xEAMxHIsx8AN4DIu07IXVAEInOnBSYBQckAGxtBlhQpjUZakhAEHlK4cXAAGfJYUwGAOULNXpgEg fMBkahFaBlxOsmlsyZZsnUA4G0APCAJvZcExTYFx5eVxkQEj3MBznYDQQaLHgVx2UdcukQF3dRcK jEEfJNcWQEFCsMEhhNdBk6H8VsQXhMT9Bpi3hgRoOoQorQIXQEFpnuZlrUH/JGxAF3DEIjqCfGmE RoB0DpwMUaxMR8iCe8UXS4ABUSCBMfXMLvHLLi2AK9QAEJmBCuBrPahAGqCwV5RiUH9NC+9YN31N GiBBYbAGDMiAU2tBDQuX2+iwLvJwZkzePIXGlAWxMSIOEbPGoP7TMjajB+jAfJZemS0HRIWO9VFU f2rU6wBoenjjSRmogf7sL5zDzYrUgmYfGPvegehH8ZBxfhhfoQ3POsIxe7ioO0Lo0MIHe1jALVB2 9LDIZfsUHtcIhQBahTTo2S5PUN1UO16kMOCDU5loqmFVI3+xj14k/EyyjtgaWIEV/uQfk0DJ/zjp sIGyWw1gAR5uKq+yAtIJ/5cu7isLyi3n8g3MMnPjsmhBty5DQiDwwWy1qehagSEk5Z0uVqGAoAiq brYVygHcwR6wIkdQ81d+pRR0QRZMARu8txZ9wA5RwecqHDmL8w+cwDhnwTk/XAQMxBKQpRZyARuc ACu+QDkTkxSGHM7kcwQABgoIRgOMQQSgyhpUwkFzgRMctEEUTMcwNA8MGH7dHA/EUhBcqx3aihXA wBRkgO9eNACkZhi8QRDQgAVHwSc5gizkgUaswI8fxY5nhAWvTI7zJs55kkkPRUxfYoKB2C65QgBU gBnkHQg3ghvwAypK5ykS9cAWLCu2AAWowGDAQAA8tQy4gAxEtQtIXDpVdf94Rp5lAOPFYqzlcXV6 rid7GnFAgR5ubIIYhFlak5k0PjEUM8cMpFnLwplcy16hjUN8UEPNcp8zZIntSAlJHtVnF6R9FEhL tSM88l7SovHwbKjS9o7SGhqFMggdPx9mYzaKSlUeU8hLGY+i2YdQYZqCCBV8yMHyPAgD4MNOsYgG LLKsXcj3PXKsRUhs68hW1Rre5s+u8c/+7Z/f9t+VZEkoCy5IlXJwDzdx+1WXInegQHe5m7sMymB0 D4AXdO4OEW+wwKkFeiCeckplJTMNGcoBsIIVxABpTTMYwKAUrMANgEANTsHE/dsezNYOMfwOqekO hTMIZEEKWAZVFIRkHlf/ch1XFsRzDswzEngCdTl4yD34Pu+zhJNvQEMB+hb4QZeCeRXMBvDAF5yA AQQBIwxMwUiELI1mGNxhHR2KH5QBFBQBGbxBEbzBITCCCYDBST/wSoh0KyXiUWCEBU+9LMiCiRvw UTS91WkBDjk5iGEN1uB0DRyqGzwTIfjrlhd1Cj9n2w9sN9lFDM9wmbMBmks1w7YNL0jsLrpTD9O5 MPrN5RHOVwcAETfCnjNjWaM1NC4UoRd66k0xFcf1eMyegMbHpO/sF3sPi4I2On668u3jfIgxrVso hy42Y98HGjuthU62sCPH1kpaCPiUBlTaBAz2gzKtrTeoUbE2H6sU74AP/wNYQAfYPh7DWtkelWu/ n6w5P2wzO1flLZHs7W337Ul+MgD+dgGasrIh4LcrbrjX5LgDCnSnu7mLFrqHlhTcwLrDAQgYwHVz nSHIu+luiqJICv5LSqMsCkAcKOMHBAUpXSzlsBTDkhQKll58kDDlwxQYFEFQSaAxwR6PCTp+NABC CA4DBhI0iMBIyxIkbGDEXMKFywkpBboYyAKDDAefERD4DOqTKAIFZI4qUDAGBwouWzCxYUNTalVG jB4xMnHihIlHU7k4cVKKUZANG9jQgeIn1gUIb+F2uuDHEJkPJ7qAWZFIBN9EUcDQADMYTJQoiVYA zlPYMBhHjnjIkiV48P9hESJaLMHRYFCEnxE8e97kwVWNCmb4EbKki8KKFpdhx4bdgvZr2bFr18Zc u0Bv2npkoAgQgE0AGcddaHGBpALzJryORZce3QETIdevW2eynXt3JhW+V+hRgXwFF+ddyKihvsbw TAEyxXc135UoUQsWSNLvYZMOMf/FGCLAIZ4g8AkWWDgQwRAQbDCEB0MgoR8JSaiQBAIwzFADAjRQ RZUOOsAnRAssGMdEBqyxRpgVV3TGRWeAiVHGGWmsUZhlWMxRxx1ZZMDHCXwMEkgGhBmlSCAnSHJI JZNkYEkkfRxlAhJvuUWDfhjUZI4tNdGkQRb6wbDKJpFkcoIcZwxGzWD/ZsyRSGHeXBFHOJu88QBs 2CxyRWCW4bPGGPuc8QBgDjjAlAPWTFTRNd1xoFEHII30lAd88eWUSofBdJhehlHGU097GUHUUUkd 4ZdTUeXlF15YbdVVV3PhJZdZaa3VVn9o9UfXXXntVdd/gA1W2GGJHdYhgxySQlllc1hW2RtiGACS I0AAaY8pJJBAgSKKMESAMPwIFwA/ACgXgAvQdeutdNWFoF10IZCDlQsUuSEKS27IIYc0ms0hijQS YGOKKc6YYokdsgCpWjWySDgBNUDKwqM9PjAJpQYaaGKJlmCaCoapeuhihRtOSGCJnoTyTCiihEKK DIzJuKMpLmzAQSqa/7ioaomrzDLBCBOamKoqNkphoyw2PHkjjHPxWBfeTiCIBYBIPhA5Eb/6Qgyw xiozDDAw/OU6Dxp44CGPscEooK++kOCAM9A4UDk0DjwIQAUsktBlhd5W2Nu223DDDPDZdMutgBYK oODwAtKoAIX3hkNOhuSWY66CYCKFtBhIS7AOO+9AZ6KH8cgLzzz0zluvPffgiy8T+u7LTz9JPKjd PwD/G0L3IRJUUMEFWYDwwQktlJCACzNMfh4C5mleg3k8xAcfEkscJ0UdY4Txz+3bBFTHOHuEc0Uo hxQySSnhHEVKJZ00n0knlVxfSQuqvJIFLbfkco4uvQxTAwuGJD8lif9PGGkKBjawIaM5ie9N4JuT j6aBJ2kEY1Bo4tONuFejQRkKUcE4lClM4cEQJupRDpBG5iB1ilNESlPD2FQvevGpUs1wBD5AVape lUNYxcpWPfShr4DIq2INkYjAosARkSiFfN2AiTdQIrSi5YUjnAAle9iBIiSAAitsi1uGMEQYwCWu cpHrXOy6QLngBZcznksgEDDEDyxhCTDkSwoKiaMUTrAECXBhIgPbQQJAEEiQbGSQhdwDDDKQgJOg oAFZ+AASkPCxJcAABTFhAwiksIIuqOADMPAMDhAwFJYVJQJkcFkEZIYCFMRiFR/jglOowgYtlGUD BjABWpxCnJxJhRH/aXnDWtIIFwjcQQ5uucAa6CALvlzGL1f7C2BoIJgo7CUxe7laY/Igi0/wgAaL scxlWqAFDpABNOUkisoW4AIspMESh7tMbwqwt9u0wDWz2Q3gckMbcPLmiIgbgOOEYxyiIec8zHHO 6Ea3HSF05zoq+NxCFwo68ZCOPKhLj3qGszrX0Qc/HZ3d7HTggdvhbne7e8LvHBS8BxWPeMdL3kuV 9zzoeUgV0yOR9VTkIhkRI0bEWBMIPVgoGZnCRsDYEfiIlFQ6sY98ZnqSmZykvgnIz0c5MtKKpjGN fUzgFjNAEP7ylw8uhaAf/zvT+JwaJQsuYxnTKOA0ZiQHHrmpgIky/yr4WMTWDG7vgxwM6gjV5I4T ClawKHTACiFFqRa6EIbKCBUNR/ULH9TQVKxalTF0qMNZycqHnQ3iZ/1RRNEKS3F7a80RmdVEJkYL El4ARLX20ARsbXGLXfwWuMI4RkGQ0VzoQqO6jOmH3XZiXn7YAUNykK99gSENUaDAC7KQRQmwIVsS +EAC+MAHEBhAIycBCUeuBYA9GMAIj9tAE5DgkknCgAsxQQEjIFGAGxghC03gwihZJspxmhIpHJAZ GVBgA0G4UpU4k8rOerABoHHBE57A2S6X4AQ6/NIPxlTjW+SCBw1HwgTfzJozAeOIbcoiD4dxZtYS Q4NPmOATjogmGP+W6UxGcKAzcIsbyzzQgApwYhFmIARsDoc4xWFGCjHQw0jUts/B7VOf+eyN4hDX OFUGAAaRYwN6kLAcFzShCQjtgXewowIxO/ShEhVPeU53HvXIIAAadd3rXNFR2X20diLVwUgBpAkx aEJ3vfsShIhXvApNCKYvncfzZBo9m5boejolhk+LoaZIKwoYbAJhjChI1O6xyKgEXJFS30cmp0KV RWSCn1M9bUFsHGAZXCXAV7uUv/2F6RYW2MenRz0lEFWp1lUCUZKAgSc1VZBHb6r0mjqdak4Haq+C OhQwQGgowAZDGhOsdmFPaFgWLnZTm1LGCB4LWVOZalXlzmwOedj/Wc+CNoijdTc84bkC1OqridGS lh74oJNHTgEFXOyWAARARjGaS1xnRFdbeuu0uXyrE3c4IxQwYAkK0LsL7MxkFxIAg+pW948n2O7H A1ktlIAEkYA0QCZQIIQsQFIL7HVle9mQgCPqYQM7iRsZcMABHAAc4ALnwFFKGQFabCbAgmjvK2GJ s48xYgNCCEJaYJl0T1iBDp4A5rvUJRd0CaIPjICxMxHTtxSv2ATcNIzYEwNNHiiYm4/5pl/YQGMb q+zGEWiAaSoQgQBYYjeLO2IaVBAA0KAABEm+5+AQ1+Td1AaJtBkAE1A+HOKsh6CQXE55EqpQ7ghh zBCFqHa482WK/1YUPcepwepaJ5/5eHQ/HthPSO8shtvpWc8l9RKBHCQ8Qc9gQjModEybR1Pp3dRE KdLpsYuRfOUnyqeJmramuSdXBqbvfafOtZnS177rA2mumIYUmyYwj370A9ZeYsEMah2n6k+pfhji /YTG7/tbnClRB8gR949qJKTuCBjTYLafmo1QPuhQFmWCAivbtG3bMsWFGGsYRsBTRsWxSuUXRCVV VoUXMAuzzk1WOFDdfojdesXdRgve4AmJkugG0iAGWItaOqIirKAIoACMwoVc0qWMfAtczOW3xsUG 04UuBKATysBcEiCTkssSuqDinEsKMAAJskXjsmgKsiDkpDCQsv9LI0BhCgQBBIzAAF6pviBpktrL Io5OC2JgBWIgC/jNEDggKHBg52gQXuZCEKCAnIoglYoOZ5JO6dhgCRLs6R4MZ0yJDg7BE/pgadpi XdzlAuQCAMIgEt4gCLrAxNKub6IgD0SMxcwO7ULMBEwgCILgE2jgMWCMmd4p7jojbnKOlCJgEDKh BlwgDnBABpIgyNKAH8wAFpiAE/RAD3YBCVTA8P4Gn3LjnmgjcaCsAAZABYIjE7ggo46DoCqHPJDg yzrP88QsOzQPdEaP9NRszSTvzeJDziRBdlzPdmJP9nAnd3and36HQYaHrFjK936PeZgn+DwkRGzK enBKGBzt0YL/QfmUzwEmbVEUJdoUiEbCp6qaRPuuD4AG6EwYYBSsb9SUjdNC6PuMCh9uAUPGb/wI AB/OCq0cEknoZ0Ow5H74p0vABP0sAIOSraoKKEaEgX7EpCXnCntkck/gqkaYrVA+iCAVRRoKKwFT yBcYkFMai1Ri6NtKxYYqEIc0cAM70AN7CARDUASLqDeupgASgStJMJ4eIiFywMjyLQFkCwX+LQx2 i2nw4ALaoi39QC1zEABiQWp00OAAwFsa7lwAQAK6wCCaJQ26IAdOi2SwxSKa8Lo8bgrhwAvgYLsS oGJGwgAYqQc+gBG+0CKm4JWOLgtUEASmwAqWxg8EAAfA5V0g/2BcwiUMioADhk6VBCwP//DAmG4D ZuIQdokLrMAKwoILqi4G14AuhUkR/QAH5pANTIAGzo4S045sOLHsSow5K5EHOrEOPjEU84Ar1+Yy VgAGcMCc8gsoRiMAOMEMUCA0hCANkoDNXAAWdmEAjugGfoAKKIBwEG8Ym6wYj+hwKCANfsAFGuA9 mlEG2OA4CpRyLk88VOAkyMxzyix0tgOh0CzNKK89auA9Nmr18oMc6+zO8EwddYfPWEB3UEqlIiRC imcGLGQe61EVOqSmho/4jO9FgAFG/PEfk88BJgGFBpIgD0WobOSoIvKs5od6AGgkc20igwR+lM1I jATakE0Ypv9EI6sEH1SErUSyA2ptSEqS9+5nDvIhTMN0f7yEAG4BJIlEfm7EFBJoAuwHTG6BAWRS qW5SR/4vJ2XEJzsIKNdEKIkSUiylUoySsb4NVMRtVGzoVFhFA6Py3HiIs6hyVqzyV7CyiBKhBS4V UzHVK7kSccCyNZSoC7yACEpm5TTuBQ1hLc3oAgThNNuiLXyLt3oLABjuDtCIICYuWZpFWeQNugZm M1HAugzgBLSLK4i1ChxTu0AgC0xiCxuADLxQC1riYyzCkqyADE5APaOrCM6lOFVVmFTTD6DgWseA A2BTEGSTJmBJkmgpCGqzCRhhCT5gA3rpEJzgECYMCjBhDYL/ky7LwJS4YAmCwARIbJq8xjBUjBMH 1hGmCe0s8RM24BGskxMZdpmYKRGk4L7KSW5GKQKYIAlUAAXYkAMCAAk4bxc4IQkGABUGIA1QsD6Z bJ6GUXAMZz9boD8xoAcKLHKe8ThgIDkgqTl6gPNUgKGuEUK748smNM3UbD2+UfXkjEPNkaRKikRP qkRNdKVYyqUwZB2g4WvPIWzPoRmK4dDsUXqmx0TUNqesgUaB4dGab1XC9oZGQCADclF69KeS7Xsk En2kNEmQ1KkCl6kYcq5GwSGNRK76JEfkIEYMkk6ohESYhCbJT0vCtBEwV0z7x0wlt06ODRgs4NX2 hwUIICbv/6oi+W9GcCTZBKVQ9pRP/TRSHkDbLsUoBxWGkvJQJytRza1RN3CzIrVWekVSgahSs/JS uxJ5+WZvtpIEjyi5BuAFqoCKOgJbyKAIwGUNaHBcBEEQdLAt53JWwWgv0+UDbgBZkKVZ4ikGEgCS kGBgrCsBAGGKjPUHvCAQjkBZE6ASTsIAMMYLl2BjJslgqlU0kYAGYuAEQpNcBCHnBGFV47IuVEkB UokM8CADVKnA1BUFyCAs2KAOmM4ItrDmNIYiQGIDgqAOxOJePcGU+mAOt4BnsmADjMARLCHtvCYP qNMTP/GGNTFhH8EJHkFhHcFi/aIAYgAF4qYSzgm/MoETCP+BCYZCAc7gDFqhCTjhB3bhB1BhF96T AhIvn2Q2yGiWN4xRyNJAD4QA5QLKOIzDQGVAWiuny0Qn87AjopAWPEZnaV0gzdjDPaAWP2anzvhj pKr2ahPkS1JKeLBE0C4EeZJhOqbDF5pnpmrKSNe20V5Ep5wBbnnhG76hVdhBVQJyc/LWsNxBTUwh JoUUJv9WcKeEeq5P+35kR6TEAtAWgIhkJzGN2obNqJSk15DUAkrASgigH2JNTDNXrDZ3S41NJm8B mcOUdIXBl3GESAJQdTnNqDTodYESAR1gdjNHnAV1AY+SKSFrsmoIVTDrsjBQKlkl3YJ3eHPhs4x3 iHKABLv/km9agzaSd1P3Wd7qKAZai3pdkFtiEIwUmgZh9YxkFY0Y8QdTs4ygQA8MYt6aRXGkABA+ 4GA+oCKmQH5dK5BOIBCSVX8tJiUyBr3SS4Bb7mMkAHunABIo4AYSAC1xjgMEoAZvVQHUdVvQQBDW cAwAoJRgaY9QoIUNLIQ7cSrIAAoEwBAO4QOek4cltg6wemAr4TnLjgYs4eyiQBcqUcQ8cYiVUxMf 9hHsVcEGNg9WgBSv6QV6IgL6gG5YRmVwoAIIYT1/rmCaQAuAogkMABRSobBhARHUpgXOVzdkQ4wX rxiNEYwLQArS4PEY6XEeR/KoTAZ+FmjJg8u8zDocagOQ/1Z0ROfM0KweKqAe0EN1Tg+QX8ejOrQ/ qNZqD+Skgie3dY9CBC1MkAdDvkGSpaMXDk0VZiqXx6F6rAGncmqTbZQYzgGUpbtVAtJuFeVSVChS UjlPuPl7XDl+JHJKYHmWo6rYdI3XOgBI5ICXCaVNGIB6SgBwA3dIl4f8vnRLxpRMyypOcS1JrASZ t4SahW1vHReoFuXZCkgY3Ip7fJJPGeVPixJTyhmGwE3c1Jl3LUtV3vl3ZQUZgjdXdIV47fmehUUw HQLe5M25oqBTr0ZTwY6flYig8U0n3lcCXpBbYNB72UU1eZov43IvywgAhhC1lsW55I19BwYJOtoJ 7sKkAf+BD0o6ELKLpEsCJITgf9GrJVpCM13CCqCgCCTAAJpFgZHgDHTugX3rXCAgDM6AvXoCB9Ag A3ziDmwAAYxaXa0g6SQpC56OnDhgadBlDaAAOb/gCz5hm8iOB76AB16hbHjAEUoMrA3DEnS4Ex8h CHigYcXOEmigEw/hEB4BhYPAEfrmarIGME6gAXCgD+hulHAgDjjhBpIgAMz1DLRFAXziDKgAFFqB ikMBsTEjDdIgyBTPNgpn8Z6sn6JMPWEBY1QpE1pBszdbjrUgaCugCcSjCRzUtJkgGMANd3vBHIrB dNDMolzxtU+vEVKvPgS5dmgbQEqqQHD7CR4kax3ZkWf/gPd+O7iF+xh8gaYUbXoWrXqY+3radpOj W7qnO/kmYRKKweGTb01wFx0qZYXcoRgQcm+LRONZ5JY7N62SNP/k20iTREqTyn0AqNY6l0TS+0yO jU1GAR+O2b67RAf0WwMmINiktANeyr7LagKYjYBoxFAKclC4+U6HngB/atqC0h1KKIUmxXYX8HYf y1Cb0lR4150ZFZ5zwcM9PFJ3RcTbjcSDBRB2sQuWxSDi6I70ucWRd5+N8VkggQh+YLv24H1tnQwM ocJ6PM1zUA5ZYaLLyApioACiwFmOZbLzyLqU3GAAiStIWllDbgMEQQgSQAhehstYbgkMRsthgFvO wAok/wAvuuAEdoIMdjo1adBdDMHNP6kM5Ny/bEAoFACW2ICDRR8GGKEHGAEF+sA0dRxd8CAWimDU yabFRFFfwKAUCMNfKPFeDDZhPfET9AKtPyEIPr0OULgOTMCHrakvouAFjCCnW50ocs4FkoACdGER tCCUdK4NEaAJAgkUQqEJQOEHErtliV2M9QkgRIhoMbBFgYMUErZoQSGNlAE9FDRAQTFAqwAYYWiU kSqVFhdIQlYY2YQJEyFMevRI+euYy5fHflXoMXKki5sVbt6sUUMGT4yZAjTK5KqoqAWSJHnYpEOM 0yFQhzyZyuJJCBYhsmYlwbWrVxIzCHAlQJbsN5gwe/+pUtVBFb63by3InWthnLW7ePE6c2aNV65v f78J5hWsmOHDkw4X6zViRK/HviI7AEYZmDNgwjAL25xZM+fNoyaIHj2agekJDEiXZvB5c+oJFkbH Vi2argV8HeSqpjtBmKlgp4I7MCUMn4Z+yFko18Si3y1hwYIVn6G8X9iyZG/dEu2adevNlcNTPiC+ PLADpkwdiA5MffTo5MX/ju7OgYPgwSMP8zVsWK9hyjimTC8BEtjYgT784kOCvzTICy/GPCjhhBTm kotfFmao4Yb+dOjhhyD+I+KIJJZooogJGGAAIDHEcEMOMXTRRQyEgCFFQgVQcNBBifToY48HrZCQ FDf/DODFESAkkEUTWlgBRRgAXADAlH5MaaUfWBaBwh0AhIHllGEYMCQFOeQghRQFCPnCHlMgscQH S0yxRAInnGAECEkakCSeQgiSgBAbNNBAFj000cQSWiCR6BJLSFCEFRKgQAYSekgRgwpLoODHBRdg ySkEFygwBQoRcGBqGYKYeocNpnIQARlcwGBFEVBAoYAVMExhRSQ4QFElp5zigccah2xgghN01LEB D2BEscIKbqzQ47MrRKFLFNhGkccXJgQRhAk0UPtsFJY4YsIjTtTxrbd5iOvjCmDwYEADOAzCQSUc 4NCqqQFwomOOKiCgb74IoEDFDz+A8MMuVKBSgAgF/6ShI0ELGVTxQgIJVHGOOU7M0A2WpCFEABI1 EFRGG6UiDS8NtvwLLww0MZNKNKs0Alou9VJTTTrp5BNPNQTw01CZEFXUAkcltdRTYkQ11RNYaRUC CVN/9VVYJJAFVlln4XyMWm7BZZtc45Rtl13WoJ2XM4L9ZeFg5RAjNzGGRXeYOS0f2As6vlR22WWU fdZeZa3RhtppwqAWmuEMjDLKabXBRtpsssHWQW5jz6bbbJQFY58D7mCGzy1kIYccAc957oAwt7Cg yRyaOJcZ6wSYTgA+qNWm3e68W8Ba5++ZN9556KV3AHrvBYMZbLON0ll09vlyivT7Ve8fgQFmH+CB jf8pyOAvxrwcIYQUlo/MgxduqD6HILbf4Ynwn4gEI3QCogckM8qYhIxnRnEjBSvY0Y4SMUAeIYQC RIoBJPQACCOwCQVFMIQhsBQGAQgiDGEwBAbDUIQzjMEPGPzVBRRxgxVIwUz/QxMFbmAECcjpTWyY QhZAcIIkJeCGBrghCLIgCCEoqVRTCGJI3ERERykABlxwVBEM4L8TNMEKUQKAID51AUHAQAtkwEGp cIAqVbFKX2RQABfYYIU3WMEKdJDAIaCwBkHgQABRugCoIAAqPwgACnAEgB/IUIdPNAta78pWtlZQ rk8EQV08sAS1nKWtT5igDo8wQbcYcQJnVUtaPYr/giyMkAB6cQAKrcLBJjaBA1eYISENQcUlQhmB VIACTwhDRRV+4LCB3MBjCymAQXaEMY3tsmMT61ga0qAHFZAsEyjASEZkoAUt9MJrxziAzJqgkplY 85k409nOeraTnvhEaEAJQNFcYTRXiCJpkmCKU5oGFapIrWpWm4E85YmdepoFmmATGz5sM4663EVt eRGHNZwhDsAYNEPfAEY65jY3b9DNG784h0RbZg7HBIMYFz0AMcwTHVOURxjO+44wTBNS1pjmpCQ9 DeSYFxvN0SZzFrjF5loqOdE4bxkdTdwERqedfTIAGNK4jzSEQQAWzCEfsbOANIbhAAv0w3WaCAEB /2bTAQ0QYAamyyoB5oG7zJAnPprBzHk8ip7jqac9wXCHO6QzAe1oYB49tUBmTBFU/Dxgevzxj38K RCADca973wOf+MpHWPT55bDrU5/73Be/xo7IClNoQhZwSMMT8KFOL2jRi84kBf8JKYACLMCPRBsk BObgBjF4wQkS8IEPSMBLAhCABiW4wTCQAQ1WmhKnDMEHIaEwCqgsgBQAsQQYMIoRQfyAAWoIAj3d cA97MEATBLGBHcBAEIKQwBklIAHjLkFREISUdqFgiA/csgsJsEKVNiVHKSGAC6QylcDKkAF9rSpf rkLBGbRLBk9YgQtLcMIbwoADHLBXjhAQlpSmRP/HBF8ACn1slhumxchqMTIPPNgAIx6xgXaJq1o0 6JYTgsADEzCiw4v0URRCHAQVZPGT+HWVB1yhAks0JA0DAEErCowDBQghYXraBSKOoAdUDIBiEtPl xXQZWozlEpUKMcgKcUyBATRBUMlcZiqY6QtoHqBmYK7AzXA2gm3mpGcy+Bk4xUm0cRrlnEhRmg6a ws6nSY1qV5vnVe1pz65l0y0dENtt9km2fwZ0oHshKNtcAhi3fcMZDJWbQw/zMgmdw2WKSR576BM8 8XBGDiIdaagb5x3QLG43hqPcXGTa1rlIrqWBzs0ElkE4nbJmGu0Jqn2CMYF5uA52M5iAA5jq1Nf/ zYEFqEuNBayaHOU4+3S36GprAleespL1N2qVTkyxowHtyHU9n7vP9PbDn8eMQBl7ZcyAuPeLEbgs fOF70PgK+6DzpQ9DidXQYtv3j2s4Nn4osAIKuHAGNnz3A3vIwmRpCIgXQKJFYCgTZ88EwND+CEg7 MmEMGMgHAxShU1DSo5WkJAhW4CGOugWAIqSwgjKhErg5ikEWkhsnJ8ypTs1N0Q0TsMMMfGAKMMAg dyN1RuMiwQpkIIMLzxhBCQDCfwZwlKeAFYaCoaBVpUJDBlSFh4HBCoJFIAMd6IACRjBCwByAErA+ hYdY6LbBworFG4JAgygE4cOCJJe5HvGIIHzB/5KAx/AhI2kERnwgXGl61rTAcC4TAIILPC7wJiIQ BxdgwcYD+MEA0oCKM+A3FT84AhWEQAVOIAwIu6hlC25JgSX/kpcZk3Jwn3zjHAlBARThAso4ooUu e+3LNbOmzbxWZpucWSc9Sb4yGyFOopTTFUhDiiiSIok507mdULuzV+h5HT5jZx4E8DNa1PIWVWSu bGnLi14UnehkeO0bkUbMJOZ/DsF8g0K/CHdi6lYY6GU7GOnhUeExO6H2HSYlagd4aoyzUpUTOZHT UnPRAd7WG9+xDLi2HsGADfHRVkXVHFMFDMGwDLfQD5pQgs2xHYlDOslRgibYHP1AFt2GO6UmVv/C cx7tUR8OIA3AwIFlAVcylRmqYx94xR959RgEcj3bgyAIwiDwRj7zRm/IYCGIlW/ss28d4m//diKm UgSvQgZntF0u9CY3ZAQnAAiAEAgONyMxIHGcpSP/MkBAkgiEZAmoBQlWICVVkltX0gl4IELAUgSA MCb/A1wmBAI/11qNMgU8V0N3kiR7kCI8pAVBhANhECkooF0oEFm6ogASECcSoABeKAEGcCaAsAMS YAjAokemwgVcEAFPMiWdAABeVGAcoAAKIFtQYAVOoF2MkAVB0Iph0F5yhAegMnJ0hAcX0HaYcHhg EC3Sski6UC15YEh1UAdG4GHjoi2OsAHVGAT/n8CNRmBJipdJPNB3stAFEoADlTAwHtAAMoABRIIB KrALA3ADXhAK+aIA0SUEoEB6VLALu2AHVEAEBBExuPR6AkQQBeGGqER7CkEBKiARyXQGAQADMsAG XOZlYAZmYzZ+3OQCP5NmyvcTzVc0z3dO00d9SmF9TyEVUBM18ERPfGZVNDkPNvlWvHB/9md/voAP ayFodWE2ALU24sB+zoBvGgJ/c0MO3oAYkTEh92dpkTEJvhBuVnkK9uEOxfAe6VGDYjU7nvEZJhUa CPgahlMaZ/lquyEXJWABsoYanEFrwIBr07AMrrEZsHELNok6MiWBHehsyQZS21ZULNiCWRUW/6zG GTRYbecRDLoWOsIwmN0Wbb2BbVYZGUTYH/3xH5y5buzmboHlIJVGbxWClFSYIVb4Pll4IlDQK/tS KxL0KF44BYa3AQlgBGRYhoHQBQ/3ImaCQgj0hjySCBRgCdiCQGyAh1Gkh35QCJ0SR+3lB0uQA0Jy I8B1IznyAofYWlMgAR+QAIBQQzxHWdO1B0gwBQU2dNwlQx9wBmekCOcpAV74XYwACJYSdVMkJWHQ KrESAQgGAXJwB8iIBl2nRRGwXmGQi3QAWRuwAUtABgDQYKAiJWuQQYIQJaAiLGvgBNeYA4/wjNmY LXsHSeGySHkwon3nSE6wAWBALReXBxsQSf9gEAOvxWMRkAlMoAc4Jl2XYAebNwBUcIsoAApUsAc9 4ENUYABU0ASXUAUE0RCtdzG5xGQHEXvAxDEbE2UQiWXLxEyJ4ns482UmYRLBh01oMQI+k2YBIJIY ETTiVJLltABIMwiSEGcraX10tk7YFzVdoWfcpgGAqgFrIaiCuhaGeqg/CReERjZBqX56UZSJFqmQ FjcMNWmGQQ7FMH8OQJWY2ameOpWYaZWfo2kdZTxn5ZXAYJetUWogRWppmTsM+KqyIRe4wx2bQWuq 6hoOeFKicQvH0Q8hkFUvqAEdwBp2GRoq6GzK+mwv+INguZiV8VXv4Q7SQBwM8BbRtk/OA4L/7vAA V4mZmqlX17NXfzUCPuBuLvMyg0Wa9XZvp1mF++ZYWKiFvEJeBIZBawBCGWQIsNKJSPABk3WbltVw vNkiBhtxv1Vx1WKcAEQBWbBgABALEEslnRALB7Z2hhCIwYlA/7MCMZAAtPkBbhJEM1QnzGVZJ7AB gpAFe6AFpiKJ+yVDQtAol/hdo2IFSMAkS5AFMTBcUwBHFyAAW4QASNADRbAGCBagCdYJrMIBCMBe J5egtCIBQeCgvgKdALAG/Ip0r+gHsRALYRAEL9AsUfCh7zIuKzCNfOeNipS2jvAJj3AIb+AJkcQD 1PgFK4AxiSAQiRAFPPAteRAFgEAGBLYJ/zXABFgwTHoAC5dwBjtACahQJFVwBgKAAGfwiPyYpCAA CmdwBqggEBSACsG0EDOwD7yjHf3gS1A2MQOxIwMhBQZAMgMXAGfAETeBBGCKFgcwpry7Ej3QEjjz CyCppspUvCY5TnKavHKqNB7QvOq0TmKQp5owBNPbTsqxFVwhkzAIg6pArIZ6OZejqD4JF2FzG3Nh NumnfnwhDNYgDIlWDpBGDJQaaYXRlPM3f9rwqfq7v1U5CZtqH1tJqgIMgNZ2PMczgCLlPI6jgGgJ q7L6gBBIObbKGSvlarOmgazzVK/THN0WU7MhDLSGHqIDfrVjOsrarL3xUcIjlwZ8AKAhGv+/8xui ah8PoB+dej2c2Vfcc648nK4sw671ZljvCq+L1VjXMK8m0po8tkF5qEcgtLWXaHD/GrC5aYZW7HAP t4bASSSW0FnPcgIhxyl6qEed8JycIkIA8AHUSQH+g0BRcBA3cAKIuASM0CgfQIZ8wAeAcASA8AMn IAQ4oCQfEAH6GERT8J0JsAP79QEb8AEw4EJZsAGHggQncANdkAXqBQBT8AMGUCpZYABTUAReAgCd QAtTUgZ+UCpwREdnjEFQAANuYgW0FQZroEf8KgEGdwh0IMqRIAEb4Ag5kC0TNi2LtGKPVAfgonci 5gme4AQm4Ah5QAMbcAjhmDEi8COMZwL/7RIFRiDKEeACi5AGupAGSUAFqaAIO/AHVwAEA9AQV8Bj Z5CkCZCkVBAKCtAKAyAQNyAxUsoO8fDP8WAP9nAM66Axq6tLGlOlBkFMPdAKyWSRzDREuQsTu2sS QnDRvMsABmyDB8AAN5FmMmC8JXk0y+sBSuEBYpACGWAVW7AFNmADMwDTJLAFITAVTrOsWrF93UcA gDoPhQq+sbaocyHU/IS+jnoXAgWp7yu/kbaUiJGp88e/Ug2q/7t/h2E3AyzALexpBeg8pBEajnM4 DzxTLOU7pJEar2GWtAEMGHwLM2BsmkAAExA4pAGEDvAA7uDCo1M6Jmwd82ABo9Ae2BA4/53xUdNG 2IrJreIWbliJVzVcPTkMIOV6IO2Grur6w6NZWFE4he/aIahZxKpZIkhsIkXwSfpSYPiqh1KbdAPn QrSpcDqnIndSJ2b4ApnlImUiI5tFAS/wWig3xhWLxtBZBC/QMW14IzmgB1nAKHKCBN0Fnmf4Al5g xQYQyErSAFzAWiHxyTN3yArnWpAVyU3AXUugJ5i8nwbQIwnAAb0IQZ8kAKwAAIZQBHiwdRwQR8VI Qf/FBWQwW7WCQZgABUpXB63FCHTABYxgBLKQB2BAtsMshyZKjcjsCDTwt07QzCTmYSumLjlgzT/C zSPW4YkQCK1peeI8TOWsBYqAzqSACP/tTAFUgAACgAMIoAVESgWjpwQc0AppALr8rGQt0JEwcQoL CWUIXTEFIQXDhAEVgHupgAQgEQozIQe9UJXh1gsdcBIYjdG9SxM7c3zDG9LKVDQNcDR1uhSC4NJj MAZ3wOZo8OZwXgZyjgYaMAZUUxVXkdN5VhY0KaiXwxbmF2jn10/8RDZnc9QChWiR2tSSRgzkQDeY iqmJcb+TkL+W7gv566mQUeWd6r8AfBifUzcBnNVcSTiILVJn/TinptZpyRs0xeoPvA+ZsQwM0AGE yRwEwADYMNg6lcKmQMMOwFajQ8I9KFeNyesgXNi1tlLeAa2KfVdXeVePnZmPkW6TzcP/lq2u6vqE FHI+iGWaieXZFhKvoS3a8YN0ZMCFtKJBTTwlFVorSfdfrv0BkrVzO2cAs12GDZeGtv0CM3JaCYCK qWglNkDKz7mcw+gHCYAmZ2ImbgwjRsAojPJz3gkIaggJGP8C1f3dr4IEjywBISEpnMgGEAQFRRAr ChBBGFQEETRBACABFCACUsAF7E5BYcAKfqBfeMAqm8LKC2ZHkgIFguAHbWTyZPAGR/8GdMAGH8AI 1WgCn/AJPEADFN6iE/Zh0tgtfGcCGeYEXOAEWfACb7wQiZAHWVAHsrC3fKtiNBAEfeAEeSBaYAAF EWAG4kwISUAIVQYKf3AJ6uyjCYEK/ygw45WrBTwHAlTQChygBDegz/x8MejgNfBQ5DjyMBpj0Ps8 AHrQBDJeMGegBTMBC2N60UKgAqSv5SeR+r1rTV/uAmD+E25akgvgASng0jCNBzOw5mw+BnGOBmVQ AiVQCMLfAXZuNV5xVTvd04Ae1EUtlM7v/Ok3lEgtqc5QDtYff4bRlJGuGPtH6Zneqc9ghOL/GOFf 5ZxOlf9rlYbx6aOuaV1JGc5QgN0xAapOaqwO62upG/iP1vgPEBMYCBM2wYKGfixY9LslDBiwZQUt TJjgEFgwacGCmQImjIFBCyErAjOlceNDgg9VdvRoEN8tfCJHEaT5UKMDnDlP7Xzgq//nMF9Bh/Xq NUzZiF4jlC5d6uPX06fGov7iVdXq1aq5cvHS2tXr11z+uvojW9asv39p1aq9dm3t2iZItEyBIQGF FTJQDO3dC6UIGStWUHCRIIHNEkYfsizesDjBYwNGTpwAVBnQC8svXsSIAokMngsARIu+ELrThTCj SYOOJeFGAQpSZEvJkcOSpUBZliyZslvCkg8JDBh4vGEDDDx3yYguorcIiiIcDD23AiVMGDJcDIUR 5Ke7H9Fh/MQCYKBFCxAAIOABDeBCJz8SkAMQdAFCafwA/HB3D2BNeDq48IQMMt4gwwkn6DgkCBOM +IQHHmShIYoV3EhkhRUoxDAPHoL/eIRBE4Jgow4TuogikfNEECEKE5zIIgoVYxQhkQIyNCKSN3hY oQBLoBBEhSQI4ceMNChIgwpFFPnjCkoQuYGCAWqZhQMEBEDgDCpAoOIMBC6hQIQWKHiygPPO6+UY NNM85pQyKXDTzRZkPM/NNJLQIwkDzhDASgVQCIUJJoQQVFAVCjVUBUIBVRTQChp11FEXIpVUBhlq qCGASwMIwJVKMsgghE+3sGFUG2aYYQxU0VAVjRJaLaGQQhgoRIMZSKjV1BkIwJUAXgnQwFcNOlBF lQ6EtaCDkCwYZ1lmrRnHGmijlXZaacWxxhlssyVm2229IaYYcorxphhyJyl3EnPR/00XXW0mCSqo Z57pRV6i6rXXXl96eTeoSXLyNydyTTKJo5VqoulgjxIWZhSBKGr4I4cjlpiiURiAWKCDK55YYgtu uYXXWyYa6OKJKEpppWVYskgjd6RxZ6MDVHbIIpU/esljmCYaZeeKZyIpGHeCxukUB0554BSgfAGK qKFGUObppJgawSmnpqIqKqyw0oqrrcDy2quzwn5rLbfaGvsEEIgTYg+56gqMQMBQkIALLuQerLDC euMNuA8UeywBySb7AhA+JrvsBQpymOICPFRjHIBYOgFAvP7cw88QQHaULbYcbrBEihgS2G03Rqao zpA32KDbCQmKuKMI2G0AgEAr5v8m4y8JprirCCumkAAK4K8zRK/rBIHcCktauCGM+0qDAALJUUBh jMbze/6C/QwBgL383jjEkzfCh4LuN/o4ZINPHKGBBh4cyQOMKNzAcP4MHdmgDic2MMIERkwAg8zz XKgAUeABHSSgowIIcEf0ywMjIuGEPNTIEBzAAhbMoAIs6CINdlBCEZSwgz/8gRKoSAMqWuGHWQiA PgK4hB1AcAUFhOJLLZBCkcp0HnSoKU3wKBNsKFAAMsVoTkYaQBJQkQQMgAIBCFBAE88wqENF0VCJ UlQPevAoSWXRBZSyVKYulYlMLCAFnnrCpz4Vgi2ksVS4MhWqxqCBVbUqViUggK3/ctUrPPpKjxqY hwaGhaxkMetZ03KGMKgBLWdYK5GJFEcirSEOSDZSHdlyRjnKQYx0cItb4wrXuoqRrk+yy1378kW8 6EWve6USX/zil7r+5a9iOKAYGlmJSmhWs4opbGG5nAnDNrYxglRsIAhjwM4cVjKRGESZy6RIsiby zJKdrJY3yUlGYiaMaViEZjNTGUjwEZOSuSQmE/AZRvzFE6UJpSjrVEYvjiI1pVANKlAxRlXqmbWr dO1r+9RK2M4ytrSY7RpoWcsAvKCHI5yAOFn4gO8kEBiI4uV2wBve8IAXAdj9pXZOQIxjjACCwIGA Mi+ARA6iAIL6qCYW+OlELDgA/57KjSYMH7jBCt5EmxtIIQo5MMLepsCIJTghMFNgqGI+wAUbFAYG glgF69hQurv8xncEQgESuNAc4PmlOXxJjSEwUCMF4Mc+0PMDChRAizvkxz6xCENgtMc9PAhCCybY QILocDvxeeIRn4BfFMAgC8DSIA/yo18UaGCCR9ThESagqxEsgaJEXGh+YNjAGyC4QPpllgZ06IMJ dmSFBugBAxWARZH0cIk9/YEUSviDGlAxAFQoYU8C8IN3inCFH7yQEjM00g9veCYdruk8QPRhnGLk w9iU0IgYMEAr+tSKACChUMMxgAo4YYDrVleKQljUFbGoRRfUYIuXylQAMuEBT/95ClShSqOoRLXG U42BAKjSQH3hyKoSdKBWJODvHXn1q/r6qo9/JBYglcUsBkCLGs5YMCUd/OBsNdLBxLikJr0Frk+G MsPrmkS7SIlKokBDxCPuxYihoUpS+sIBvnAXTlrsgH7BWJayFBjBaukMlCBMxxXpmcMsdjGJ0WRn OiZIMUHizGRyDMkRC9k4h3mwlQTjADbWMUo68pAD1LgjxwzJS+ZBgHmEbAIkkUZOVLzidA5jKENh J1Gk5pQR/KJqU+FFPe+ZNWRkpStc4yfY/GkWs7GlbAN9C05jYFBAKDQBe2goXQqDgoluRxCCWENt u9OdNawhDMMDDBd6w4ggLIb/MQkAASBqqrjSiAY8jIuFHOIa0zDwjnZ8gE0UpGCJGBAiBxSIgh6y MAW9AXsJWSiOcbIgARt4eqmCIMxhnLoENtiFQIaxS0QhitUiXOcDliiABJw3VlbgANJ3oEVo3NO4 IjAiC05YAx6eBwFBGMAShv2ECfD3BkxA4RAfkoVJwUCDepvAEZYgLIWiwKEgHMIJJvhEEIJAgwSu wBKEyIOGovAJT9ChC5gtrMWN8AY65KAFZ/CDCwKVhAJIARG1uIAAVBvCK9gBFYhQAgJqIVva+qEV dvjBLvRQADClwYYAbMEIgnsMHhIXNkFUUZjeREQjLoITqWhFK1IBiupiF7uc/+B6182g3UJxd1Hf jVQFwFuDSmkqjB4Yo3rbSyo2xteNGnijfe3egVZpgL97N9V/gVXfYQVeWB0A54GjRQ0JP5jCFbYk hSGcrQpbmJPk2jDlK6+uUZbSXvPkPDSoduJ6gTjF78o8ul4psI2YImYFkxmRd8kzngE5yEWeiY4H wmUl/9KZEeuYj3/8ZNdXmZvAyHLRhqLiYLBEnF/mVZgtIAxTlPlfpxCK0tTM5qE8DZ5T4/xTeOH9 OuOTa1zhc5/9/GeyuIVs/3ALWQodGync4NBeAETaHsNQJPDmobfbDnf8UOlK0w/90LQwgAIDEQy6 wZvfCIIE2DgKOAE/SLXVgP8AV0uN9ggDCdgD4vgAMsiCHICNGOgCEXwSKeiCBJgCJwg2NviAxkiA xjg2PCgMJ5g0LuAoaEMQ1nkowWADOggMudk/GPAd2LECBbCCPRgAKQirdwsNNBA3K7gDPNiP7Zmd BHAERzABKCANQUiAH1qBPHCEhmODSGgrhzMBGgCDv6q3IDCCiiOs+TmsUlgQxmIQCsmDFnGCvcoD DKEBJ4CCDyAEjsusDakDTNgACmiF8FAAFdADPQAFAZiFWqiFECIFNUCEmVMCSdyDmtsTBaACVCCC NIgT5RmAHwKiFiiAXzi6YRgupROiUwSifnAAUwgaoHGAYXCAJlABreM6LOD/RU7oxa4zgAsylEVh gkchu/GSAfMKowWIgLZTI7hzozsYgztYFTQogzK4RmwsgxIoA7xzlVapoxDYO1vBIz4qsGIhlm9C lsJblmiZME2KR01yBmKgR2xpPArTJHIghnDpJMpDl3/UMHbZl3gJMWjovqc4SKjwAVW6F9HLF1KK sVlCvZJgvdazJdcbCF/iGYoAPuDbsWPiMo/RgFvoAN4Ts4kJp1+amI9MCW4qPqNQiltMPmewhmTB h3nIyXl4vuh7paHZFzVjmqKAGnj6BaWYJ6n4vvC7M/HrmvIzP/RLP4JiC/YLNLVArti4gRsYAET7 AbT5myZoKGkrgv6rrf8Q/w0AFIQwiAQo6IM+EJ9IYEvAmAJAyIEVeIGwMjfIYQ85gADxWCk8wMAs EKks4B1A4LUuIIQ0EMF5S4MTCKrR6Y0sMA5jywIuwAMugAEuYKoUrIMPGB0nuIvaCarbIQO5wYve QYJq+409SABIuIEicJ7nEQQ04IC6wINYMITaCgM6MMMoOLhP0AIrOAMQoIAFygMacIQgIANBgAJG 2AAT4AEaGIdnyIZs4IZn8IV3UAc3XAEw+IQ6oAMnYBCH+wJLyINH8IRDOITweQQ9jILKioQlGDhB xBANcQT1/AEBECsA4ADnEoCb+4ObIwUqQATYWi01AII9KAJOtAPYugFRFP+6UnzFUTgzy7OAVyQu 42o6IKKAfYgHewiuX7CurqugX6wgYOQ6M8iuYVSBYjzGLOKiAGgAD+CATcCBFEiB9xoVPJA7aryD +1oVbnQVWIkVWPk9i6EjcuQvcwQ8YimwLnMmQVIwCYu8bSmGKx0Xb5FHLtUkjSCGYLC8DAslgIwx FUMXUtq8X1DIeTpINvU8z5MzOGXIhqyXoPgX1IMZi6ylHAs+2iumISuylsyYjXmJXwEZkWmmJAvJ cJI9YKqyK7MJd1gxdwIKB0g+grAGRZ0AaxCGYDA+onmlnbC+oHSno9A+ePKBOJun77snpsQnpzS/ r4hKfyA0qiybsQEiGiH/LjcxtBiAhBcIhEQzgMVAAt/ZHeLxv0lTyzDAhOHBAbZMDf3YtCJIgBvY KSRQj9FgHAg4gDsQjwtYKQAQAAV4NPH4gBiwBBHMtS5IV0v4gg/4jSWAASdYwcl0wb6xghh0gs1k No5KjA9gBAnoQU9jBC6wDiionbtAgRRkg2gjqizYARA4AgFYj+vhgDGIAHptnO2IhENwTUtYARpZ gTQYAG7T1fn5AjrAhNQJgg34guSchKM7Bzc0rISjg8VyOB7IgzxIuA14ARMsHxP4TYxbBUzog/nM LIPDEEtYziwQhOZ5t/twOVL4A9aiRJlDBSpI0AGgglrgAHKlggHQSlG8/4Ei0dAOpYANBRNW9C1X fMVbOLpjGIESxQIMuFu7zVsTVVGwEwIXHbtG0SJlbABfMErOewBSIZUexRU3atwxiKMSsIpvkNyq WAY5oBW+6wf/6hU/+qN2FKRmQSRKirxxIVOAFBdy0dIu/ZZ9DBcx3TBXcgBtkF0Xg7F9UaU1zd04 ZVOEREgfoNNVwolYEhgw1VM+Pd7jzchRaL1g+lNf8r0JeAkC6AfqJYBbIKePuIUSWNRmgl5j8jFf 0iWEsbKHKAmcOBqcSD6ZsQlKfZpb9ElfGFWlWad6eaftW1V6uprwE798eso+o9X0a4uBArS3SKDh 2tW0hT+t/FXMULRi9f8dvICdrNKLCeIAKOAADsABmPKPNTCEJqABCrAETsCB9rAcCqQFyrGP0Eg1 8fCDIviB20jMdrUE2zBBvZlXGAjCJUCChjoDMhiDzJSAScvhKeDhzxRNLkCM37kOKCCD1XQqNkAC hpqCx/ADi41CK7ABFGADFMBNTMAEMliClwWDHRlZosOQiEsAA/yQ/nGELpAFbzi6Z3DDPPgEOngD EvmED6k4HliQKKiRLpCANQgCosW3VfCPCJC3+dGQDWEEOgiCNZBa2RSAHVCDK5hENXgAo1zVOPuG YdiTMziCJ2m6EhK6Ink6pmNbpUvlpoNbue2Fu8UAO1kEDFgEW67lWv7/RU5Y0a8bxhf1LrPbIvNq gDjIhaP7hcRN5sSNu/iqLzT4BrnNhQO43F65IzZqUmKRUtB9lkFSMG3pFtjFPBbDvNMV09J9XdNF U21gMRWbXRhTlzS1lxNTyN3VXXvuPt5NpTMTXuKdMlP459U73pThpkIKvtrz02ICsmLyiIOY3oWY gevVGCRDpmfqSHKKGEBdaD8liIhwiJQpCZdJX/W1iU9FGqV4mn32yaIh1XVqmvvlPs6rCqrgX6uQ 1a8B4AE+C6v8B+KKrFVeZQzp1QWGBPpz4A/YAWCrC9EkEIyKACgAwAHEwBMAA3XVgtLwA2WAijw7 ymyQ5Nr6anRV1y5I/4PO6QJ1PQFGcNgpYIMgZANHkwAn+Iwa7Fd+NQxo4wKIkgCgwmu98Iu7YQN+ TUFGQILEWIwwiAVNKwI2yIJVAA42iIVYYFmF+4AT0EMUMUUwKawTOAQrUCwGOUP2KQc5rgf7dIQ6 8B4jUM46+AIM+QQn+IT5OQEoWIWhZZHyqQMjaALr2IA/FkQjwAQ26AIOWMILmIVZAIBWAAJEuGRS uAI1MDpVFIAwEIBWKM6mQ4XXMmVT/iE5OcUMXdseKoC4PTp0kOUkMKLzTu/0rmUUVdFDGTvvihRl nNE4iABeOLoRWOYZgC9mbqM3oi9oPrpcWIYSONRq1pU66i9z/KOQcP9HaqGWbyaGcYHnzBs9ci7T cj4XcfaFde6w2mVneL7desndNu28Eu9dowxegMlTjbAxlfhn5GVeIVtfmhgZjwCyGu+AW6BeheiH nfwxZUomlcRojO6ZQd3oF8eIjMjTSUUao9CXUFXplb6+NauX+5Wz7lPKV4VVmwYLAI7KtTDgMoms U/RpBAYim4K/zhkAogaE3CKOBCjW/ANs6bGCbMO0/yuCLPgC2zgBDtCPAD8Gf1ATHxCrr64tACgC QLi1HKCNxExXX5sbh62LHIbruvhhuunXuiGMTKcbK/A0h3qDvnbi3eCCQ4CBw+CbIDgqu94AWfiC PtAfE1iFSKgDhwP/NVl4LMlqgQuJgtsAgzwwggQphcQyQzB4Y1lwhqPrBfk5uCDwHh4A9jo4BBrY ETukTEZ4gzWIBNa2hEegAx7QkC8QDwwIREdYWfOMTRRKIQQwhFogggJIA0pgEjWwA+gOLgcAWwEQ hFa4ARWhAOzWbqFDBbXtbjLBbBkBk4Mf7+AagUUUuvMmBPVeb1pub18G3AqgFE0Z5vq+74YfFcdt 3DsYeQ2oRmscUmMWcDpCcF7ZL/7qBxKoXjwalm8yPG+mhkOClm6GlsQDZzR9F6KQF6GPyH4h53BG s3XucHYePYKsF96FimZoBqjnhWagehTnvFXa54kkXuK9iNQL6Fpy/8kcezIrq/GM+QjgO4gZSIiF sN6Gwb2KZiaJQftc2mgoe4iUwTKvRz2XmdTzjXIpX2lSrXL73T7Ok4otp+k96/Kw+HL0S4ufVroy TyCfBupejb8YCEGibmBFa4wPQIJoy4v+a042MAATSYMsAA+PF3Q1GYH/II8MQHTwCAMPtKkSXMw8 WMwEUJ3DiDbfPwPWwfS5ocFMtxvRNIzDkADRb+IkDqp6TUHEUIwscLgsMAEJoYFDkE5ZMJ8GYaz0 OZHCOk+ezQNZsDfP5iu/ghAasAY5bvYvcII+CIKQhc/e7G1LAAE6WAPIXgM2AIg0BaI4OWSpAEI9 fgAsQrjiYZQNq//YWLIUJsyOVgJq/fnDp0ULCqjsIEKFqtexlCpTOsAhgAOHVgNAijSZ5mYaVAJF 8OQJskALoD2H/mxxa+XKERUqcEpyk1AaQlIJJamaZNEiLFg4cTKj4isTJktlBAiQ6WymBg3iROCF NOUIGzbwjKl75w6avHnLlCnht0ShwIFzvU35jQCJxIpJ9FvcmABkAvNUdcBnYRzmcdasCeO8efO4 y5k1f3bmjBjqSZN8sX7W6zXs2Kxn+3Iwqdht1bhVq/bVmzZwX65jQ/tl/HizX82a8WruvPnx6NJ/ 9YLmw8eI2L1mOyhWLBj48MSCAQM2HrwpU+XXs2cv7D18YMLKz4f/b9/+tPcWbvVj4b8fAbdYMMF7 EwxoAYIDTrAggw02yMB9EcK3zHvLAGOhhewdEB540nAYjDvSuOOOAyWaeKIDD/gyzIosDjNML8r0 MkJ2NNqInXE+GGfMjs/5+GMuvOQS5JBFGnmkP0kquSSTTSb5zz8ISTmllC0kEtSViWiZCJUrUPCl FGHmcEMMA3TxAiAnGGFAAlksIQEKVhQBBRRWfAAIBSu8gMIFbqXkz0rDhLGQH4KEAYUhhhRRxAcx fJlDF12k0YUlXWDAiAROLDEFDJxyCgMMZODBxhJOCLKKBBJwwQUKdLTaKqlLLMEGCmTMaQUXmm4a 6xIfbJDABh8w/2ICDWAYW4ojYDjyihMmOGsCD2BEMe20XTjyySfJ0sCDCUEEAW0OiayQh7M06FNY L24kEgUPTryxQRTiOnLIIV+sUICXNGzwxhqRLJHGQxtwcUJFSaAAAAwHPSRuHp5E4sgKXyzUyg5q 2AECJED9NAAqA9zwQGHHPHCBHwsVocdPNuFEQRoUtDCUCEHJ/DLMMf90VGG+cAKLEBikYclTUVll 1SIYYGEGJ2BV4IJZaan1dBxsRdBWYSNsIVdddmmAl1579fWXX4QVxksIZZfdTwiNJfYYZBpM1gGC oWHGgGYMfDZaggli9pk1ppVDzG6saTf4drRpo1tuue02yeHBzf9GnHTLMfejc8tFB4120BR3OXU0 aseaid5xSIx55ZFHOnntqR5fffTJJ6F99FmgQX/+sdCPBhZAKAyDCiLoIPANCsMA8cPDLgyFGaoO zIYfoud8iCaSeOIprL14PYzK1Ggj9yNcF91zxlAOJJFHmo+kk+k7GSWV7U/JZVFbcinlvV6CKcUN ZA7gBSBpsvkBEqYggUUh4QQ5WIEUEhAGPx0DUCrxBZyskKopIKFXWchCAhyFwEpFKgaVSgAMuDAF NoBKAqDqlKgYAUAc4GAKskoVF+AkwiWokBGbqhUZyCBBUtXBhbIKQgLadAgnbEAWYOiCLAZhAkfI 4hBB4Fa5pDX/LTBsq1smkEUepAiGPOQhChD5RB0eIQtrFGYdblhBFMh1iEfkIREiiIIJPBEEQtwL XytwxBIwUQRH4MsSCeACHSLghzAk4CB2xFcQYsGGaUkAAhcQgBLsMAAKIIRmBbjBANJwg2GEzAEA gAAoBVCFl7FMJ186ZQFqBpJV1qwnq8RHyMxBgRskAQN6+NlTpjK0rGylK0xgWllQ0ACnRU1qHuDA JhiYFLnIZQZZe+YY7jAGDWQNDRq4pga+ETJesOBsIWCMYmYwg7ZpgDJ6Ew1mRJO3BFkmbnvbjGlO A7jf+KIXw3HNcBzHm9vsZnGqOdxqtAGc2ExncuNrTnKOgznY/2CuodGxXHR8MDjulMh54AEGeU63 PPewTj7Lg900KGSBefRHE5q4HQHwwQA5FEhBC3Jpg0YBPAZMgHjF293x5qO89TQPPBv6qXo+JI2K oihFKwoOjGK0vRnRCEff4xEvfhHVgz6nfEI6H1bVp1Ulsc99XkUI/IAi1vl16ZRiGlOZ0HQCEBhg A1YwBBcMcIOHxAAGDExSLpKkDJhEgAwNECYZUABYNrhhA26oQD0SW4/DokAQAHhsBtYQCwCsQRCC WIMNaLiEIsTCspe1QSxACwDPenYNAIgFHmiBBxuM9rKVXQUOMBGJSOAhFqvowyv6sAo89MGJnniF J3Tbh1I8ov8U9SjuITCxhtvS4RFu+IQZouuG6U7XE5i4bS+clIt6QIQGQXCCEVYggkTwgA7vskQd H5IHLRgiAfWzxAsMwIgmvKB+D+ljH9YAMUcIAgJ+EMBGKHEDoYigAIhARMsoMAx7FEYaswClf0EA FJYl+JSUhNkqWdlKV2oCH+1M0AQIUACgYcCWuIyKLomWFTMY4JcyIAta4rAAY3qAhThQpkriwky5 bKHHNhAnkJ1JgGlOUwNo0ObYyraYcUZmHuU0Z97Smc51erjKUYanM/4GuMA5jjWN2yduwuydfu5z n417XC98sDmD8iIZbnbzjxKqOcK9ZnPIifNxJCob0HXnOx//Gg+gw7NR+sSudYa+z+7oMwHaaWIO czgpASyAvAI16EDBq+lM4YPT98iHQvNx3U6ZZ4oDjJrU5Bl1eoQaDAeAiHrVO6qLepFUz3Wvqb/4 XnTEJz6qCumqV8Uq+raq1a8Su9jFth+YyNQFSBABBoKAwgZiUL8TKJMwQ/IFIxjRgw1sYNtBaEIT GKEFRqhgK2YwAovNoJUNoIBO7oZCX6cGBS58oN5L4IC7cQAFFkKhD/iGwpzwjYPLPhYAYcA3TKCQ w8CSYRWV8MQhPLGKNawhDJigAxs88ds1PuIR3A5CHV6xCkxgYrjZmgohsLKI6G6gFLgtgTUuc4AH TKIcqqAj/0SMQAdGgAEkjuACJt7wCBrUEV964MIhklA/O6b3vvgywhoYgUZGhIFkRaiFABSwBwr0 ZAAcGTAF0BGyAwjgAmYHABUQYuG1qzLDG3ZlhosSlFKWmBMGwEBFgIZiqRBtKyoQiwtgnJYZT+2Y Nk4BkpHyiwwwPgNmy8AThjCEJ1wtyOIcA5ATjxReJEackbmmKigD5XXKLTQWsEyV8VEZBLWTNPFE zeL0yZsxj9kbxPBGMchB+8QVA6D/XI3gqmMcNrv5SMlwTp4XSmfhH4eqx8kObOpZuD5/x88WDcZ4 Bh2fj3L0PoomaaPzcVINdKA+NL008EYhUwdBqP32oVB54P/v0VAzrzykvn+pUf0hVjtgetSznvVc T4zMCFPV2i+MwC/wSAI2364d1JD4GrAFm7A5ibFVoAW6z/3gTxYUyhS8gBQgxA3gmEocQKQs2wuc IJqo1Ql0QQ5EgRTkAAzmAAVEwQ2cwAf0Sr3V2wXlIA8Ki7DIigrVWxDSkLBMgRNIgBVYQQ5JQA9+ AAYlAA+8AA18wiPQQRFcxBsA0iHUgQkYwSfwgCPQgCx8QhDQixPUQRDIQrz0hLhMC0SQy7cQ3QrQ gBPIUR48BB6awBsEQRSMVxdMwWxd3CcU3QokACZ8QBS4Dx7ioSWQQSR0wQp8AhnsQMnUgiVa4g54 AUIAAQL/1EIahMQ+YAMwxBM9OEMwoEEtzMIn+YGExczafQnNEIWGvV1QSAmYnFJOcMIuYMDOVAAs YIEl6IIloBxVZAVXeAXgwZgwrUUEbAILpUAKWJZU/YgvCILkDUEGDAE0QqMO6IAYiME1Sl7kPQE5 TuOP/EJkEADoUUYHtCPcwM06xePpVUbqnZ7elIY8xV5wzB7u2d7tkQPg6F6ZJc5AtkaaDZ9zJIPx 5cLxIZRxKB8+2RNsRI45jo9xVMee+UZthA71dYfzoEYwpAf3rY5H1Qd8jMKnycei9YMm5EM+zAEL RJpOoZ9NMcj5sd8EqB9O7Y78sQeGLM8BAEOpCWVQ4h+H/5DIqhWVA5xC9WBPUsGG9tRaU+nIcfDI rlVkVVlVBJrPBKpPAVDSBYYll4xlAcwPWX2ll6zAD0CBH1jBBrxAIhbAL4RMObwAJKAgXqogIMSA FERBDPYlBUjBC7gJD15QFgRBEyamYuIgI0yBnCiKBCwBEiDBB+zAHrSJEcRLFHwCppDBG0gQHSTh EoAcGn5Ct9TBIbwBHTgBI3wCGGjJeInAInoRGjnCI3AhesHREPEAbUYBDdQBHfAAUCRCF2gBFLzB G/RBH/SALtRPF7zBKjQE0zEdI37AGpjAuKhmDBSBHyhBLSjBH+yAErSCGngBIlwCKVDSKTkdQlgC KlxBEf+sIgakUgvkhE7kxE5gmM3EoipRiUgkWE78gAGAAij0wBlEjQzgXUVMxYp5xd+JxdIIXtQ0 IwdAo2VhYzYKwjbiQApsgod6AIh66CZ0ow6MKIl+ozg+QTeFwBZ0HpN9njpi05N1ADvKI5XBTZXR o5XFDT7CHpc9wz4OJEEqTuLYxkD1wp01R/EpJJNWTo4on0QOx0Qqh0EdX0NSzkW+BnCshgP4xiSU yJeiyJh9iCk8j3p41JlyH6fFjoXwDgGwpEvOAYDoDjDkB00SyCjQ1E3alDDkKQOgJH5UiEetx0+q zgEcKvPcn6j1FIisWlKiiIo0ZYvASPZIZVN5j3RAlVT/NSD5QOBWDklXpk9YjqoF5glYQoIEKEoW fMENSMEKdMAD0MgDOIA0SMMDlAC3fVwPBMGuhlu2IcEGqFu6oZtWqAAMLIqtLFwOvYET8CAZ9NWi FEEEvEEE9MGcAFwESGsfGIIgFAoOyIm+wVsR5BAXwIARLAIVQicARIITmJcj9kElrEEfFEQfKFcs SNYayNEnJAEh5IFUrFx08QNWmIEbSFwfBIEZLELBltwgopHO1UEUgMQKdMEHQEHQ1esaTAF6PZ0g 1IF9USce0oAnWAF6nUAkhFd8KgEpkEJ47sAlSAApgAIloAJYHpLGfGUaUEIqQoAA6IHa3UQptUwl yWKB/33JhtXiV1KYJt1AGgzALoRCKmhBKgRAK2RCK8BCEhQMLyGNV7gBExxWhJZFJsQBAjgjh2po BlijZaUAC4FoHEjCAsStJEiCB9CtB3hoN34jOJJj2bSoi77oGKSjjJZTO9YoPNoo6+XNh8XjO/VN lsEe8NGZcNCGkPIGbUgpQk7Om23ucyTUL0BpRDJUkrYZsDkpddgT5X7pbKiubxjpRhZDiVifRbGH eqTpR3nfhfAOf7TkS/bDPBDI6zwInxZInr7H+hXP8NTUplXIMtDfhdjfoRalUKaHogZlqoWHO7Sa UjLlbGDPawxDVFoqpmbqplIVkXjqp4Zqk5BqWYoV+/8SmxQYwACxgQFAggyugBdYAQDYwhaoRQQM AgAHsAAPQrVWggEPUw3UgFkEQAIHAAdkAGjZgGmtwRaE1hrkoBWAVixUcCyEVgd3cASHVmrZVgOY RQRAcG3ZQNpa4ytkwitgwhbQggyrJh1Q8CrcViPUQB/Egi30cA+jQSxUQg0sFnUpVg2UQiMYVyPs Fi2sQiPUwxLLsBjESyLIws7FS1BQbBhEAhsEASOQQRh8gC60JyO8gdKBLB7mQR1EwhcUQB7oEHoV gQBcwRWwrMrSsRJ0IiXUrMaAhCsOgB38wQPwwgi4gzy0gylgAzbsw000J4Fh2Ig1J3/6xE98yU0w bYD/2gEnIIIBXAEsGIAeYIAB3F1VZEWDRldYLE3gmQUzcsDhRSPbdqjbDkLc1rIoiMLc4gKIeiM4 Th7f9i0J+O1ikECQpSM5Ee7hIi47rR7qIe47iYNpQG5rSOnnsEaZndk019maPYdCMiScma6aQaRE iu7wVWmRMClDPsflaKmXzYZAdVnrhmmfsdr1pQ5GoZrtusfrCKpK7q6jaUI/3AKEeNqfqp/6adrw /Gn7LQifKu/xNO9GSS+pJepEk5p6RO+HhEj2FlWkBmBSwYj42sit5VqP8JpWfiqoqu+SvC9LK6It QkIWqEoQYICjFED8GkInhAEgnElenuAXfAEgADUg//AACJwAIIBBDrzgDST1DHZBAuTgYRqmE2zB ByDmGxRBFvDgEBKhrGzKFLzlClhJAeRAIJxAFlymUb/AF3ihEQTBbSbSFtbBKpRCF4DBCohLDgRB ckJBJCgcG2wAD+TBAUGELkxLYVMLudBBKfBmFNgmv7TRG30XD9x1C1gCI0TCB9i1npCBIEAiviSA J4SXQywiGpkAJjjBQzDCGoTXDRiCAqjBJajsH1wBKOxAKs6CEghEldDM3KUBIqiBMohNStiDPcSD MQDtLPqEK1pYKsli0rIMx5hEx2iSb4OyJe8ME2CBymlFdH2F1y6NArNyKz8jh3IoB3hA1NSyK7jC Av+w9wLM7S738i+bDX2bTTetqNmQwDe5qOC64zldxjKrgupRRuotLmkIAzSjxjyxLjx7KeJwmXBM qVRpbjczZDo75EPGRui+BvgkZIUz6ZVGVXRoB5ACaTs3+OqKaewGg+wSw5mGBz7fbny06QTcAgGw gEnFpKSZZPEqNKYZT5766fnpaU7FzvMCJaoVJfWWmkVndDAMVVGdwgMw5atNaoyEr/hOhwLyWq89 IEoXiUonSR+vkvu29PvmACB8ABfQbxdIASXdwBR0Ah5kQRfEQBfQACTwNF4CwgmmiRGs4FnB4Jfc AAgYpqFnARtccFX3lRNWtWLWGxt8wAlIW1lyyQr/5EAMoAkk5Lmdm0AYeYsJfMIrPIsnbEAWYXEi AEKpkMFxksEhsAEjBMEGGAEPfIEj5IElUMsiOkIZmjoafQId4AENuFEL0AAZ0AENlGVEOIHPOkQd xALEFEAXtAoh4Mtov6ETPMzEhgEZ3LUJhIECuOxsU4Ia/EEtXN0VTNKY7yfOogIlgMxb2AM6CMQk E0XSIltYw13S3kR0Cy0FOO0uTNIN/ADUpoIMqABW8INWHE13g+2Lie1asIXZQmN5e0AEtPd6Z8J6 u4IovDfdemMK+HJ9lw05kiMLTJ7t2E5994PaEHOMqsIttKM8DnjoCbiHxbyH3aPjQq7rBulAjplq /5QImtmZOZ/zlXoulL4GNRN90Q9JiGN4lkbfM0y9iRsOindZUcluPYdkeuSz6jBAB9AOyweISSa0 TuqpQxOI8fSpTSFvkXNa/KlOjN8f/t0f9IBHlPtC9byai7zIjGgPARqg91DlAi4gl3v5r6VvmMcd mSOtmY/qCtQgG1gBI5zAXH1lIKDBHVjBpJ9JpPS0LKDJUJ/ACbxAUofJC7qqFABCm2QBtxnmFFD1 BeXQoSNmEN6gDhoQAnXBWp0AHxhBEAURm5jABjACvZQmD7zCJ9AADZSCEeTBFxDdeEVBFxgBcCoh CrAKGfTBRRgCGXDBIyxRHjSnepnAFqrhuGxALP+YQLiIQA54AhS08dNNgb0khGdagrgIwRokAP0A xAqBAqN8ohNEIKMwL0REQSEIxaVLVBARQUVFSa1dFAq08PgR5AoKaVAhOnAMZUqUw1qIcPkSpkcK KwrUtNnxZQEKO3em4SgzDSJEA0iGQiAAgQIEKFQkWcQPi5moKlS4YVLBhQwZAbhmatBAQYM4ETjg SIEjgiRXmRZs2uTBwwJRoiRJ8rBJh5ghQ570DfEXcOAQLP6yIHx4cD8Si0nMIEBAwzxVHTpYsHwZ H2V8qlTd4px5Hj7Rl8dZE+aMGLFikyb5ct3LF2zXvlgXs327mINJul/36vULeDNew4cnM058eDP/ 4L+g+e717Hl039CW/xJePFmuXNmPJ1cOvLlz3898kZ9tfnb69NLFt3c+20F8+fMdBHMXDH/+YKYO APP/HxhhLLjlMQLwGWUZYJYRhgEGGHxQmAgjdFDCChusEMMMAdzQvwMOMCWYDz0UkT8Q9TvRHWno O8UBX05xbRhfhplxGOeUGaGXEXTcUUcfRvjFBx9+4WU5Y5A7EjnteNGOySadZNKfKKWckkopQbqy oyxv2pLLLr20aSedwIzhgyKK+ACSmRKRIoNYBGHkhS4g6eKFOu18AZA88+TjBEBiiEKKHAKVYqcY jNggiywSSDSLJdb4AFIyyPiAUUYhvXSJD8Cg/0CKG0CYggxDwhAkjCJQkICLVAcx5JBD6HAiiA0+ eWWRKKJw4xMaZAFjhSgIAoOGILiQlAyy/LgAWTzwiGUNKB6hYaAoeHDCkyDyWCGRPFZxwhGa8jjE iS5oWsESI1DgogktwuBAj45eiEQCSzpKZKBE6LWkjkNyaKGLNTbw6AQEBElFhV2kEMkSIOxIoyaa WgIpEY90SsMnYVRSaRiYYrqJJy49EkHiMD8WQacBEMFgAFSuOEqBWgR4mamnnsIiKjNUMIMJN7DS imeufGYrjjgWGNoDQbY4eosQMhjCg7qcxksMvfgCbAvGGJvB6sVm2LpAyObRgDPKOsDHArE5O/97 nrTTFu0W0dwmzRprnEFttdbc88213XCzbTdteqPOOuKMSwa578ALbzzooJsO8GYcx67J7LYjznDE 7y4P87vb+xHI6jz3ccf3YpMxthjpc8cBd1LMzxRTNhRmggEtGwVADB28MEMKbc9QQ/+ECRB4AD8s sUQPiT/xRBXpc+CUB1x7UUYaaxQPRx539FHI5YYDjkgkk1xyySfF167K8qnUGGSQr1y/hSzbf1/L L+W3SYoTrIBCAkCkaLgBFEo14AUxuNMA9ZSnE4DgBDfg1KB2IgVAJGADJoBgAhKAhEclSlKVslSj lpCAE4iLAi9IgBOsYCYoQKEIVkgVG5bACC7/hMEJdYhhEEzgiFJYgl4bMEMe8gCGcZTDG+lwhjxQ 4wsNDAsKALiAEpOlLDyswVq9ikIeTEAHOnxiBSJYQR/eIId7yMMBI5iEPMiID518AVQSSEAaVtAC S1DDBw4YIhnJSABsreATkTACvRhhBQqIIAdsCAaOHvAAU2DDHbcYwE8+or6IgaQAusjSPi6WEl+g D2T0GpcuOOmw9tXkIzYZWfsohgg1qIEKoVBKLVqhFKQ0AQtJcAo/pGIGW1LFDbCoAFZc0Mud1eBn QMOBDYhZzKPZYAspcFpddNDMvOyFL08gTAiq1hiudU0DkAFbBzTQgcmoQgORCefXsCnOr81j/2yj sYA6JxA3YcgNGKpp0XSyBxwf4C1vrGnNbHyTPeI0KTnLsdxznlHQxfUCGo0TnHGYNLgjGY457VGc 5sTjOe8hqTo/yhGP3DMCZcTIRae7T35E1J8AMWgCEQKGh3zHu9zpzqUu9R3wfvc7DhWvdcP7UIiQ px/ULa9F6ZHejHwzPetZr3PV2d6QLjocJY1vfOaTapRaorGquoR9WY3f/L5EkwKsoAtZkAAMQJAD r9ZACBIwBBsA0QU5udWtLzigERb1gSVIQFIJiAGnBDUTKXRBgibYAAUTsIQMMEpSkKqUXafwAQDu TwovMMEUJHAqCVhBAo39gBaQMNglkKEOG/8IAg1lcaso0MsNZrAVGKBRSZSUgA1WOBayLgAB2y4r FrF4gwloYAlb0aAOnjDBaRPBxUm49hjrsEkULDGTjqzgBMpIyTdUkg57RcEJb8hBImRBhi+IIBGi PYdr29GRRqpvfaCU2CiQCw/0JUKUNeGkLn7ivlDixCU6ocANgECKVvxXAa24RCuSkpRWIEEF/CDE IhZBs5rdkgk5u8oud9lLFwAzE65YgAdSUMwxzICYIEbmJuwiCWc6M2pi0ISK+cIXwwgma40hAQG2 ds2uYTNtkTnb2y5jgXaa5jRzi+dqytMLfxJpOfcUj3oWx73ibGdySP6FcxRXUPEkNDjCYWj/Q7dD OF5AdKAU/Q11AFed6yxJcgA9UpJ15Bsc2Yh6ysDn8+ajuhO1rqXCSBAwXJdnC8UU0DH9j0059B+T 8nmn++FPT/WjvOU573nRo1EvlHGj6m2URz4CUj2JZAymNtWp4YOqk6Zqvoc97CWoTjV6sQQ/rr5a CoFYlF5tUgMsJIAMVjBCF2Lg1jYAAgRZmIIVyFCEMITBD2sAAACKwIcGSoFQBcgBCAZL2MIeloKJ TdSlKJWAFxxsBVLgwwY+MIUl7IGxTuCCojbQBEVx0AkH4QEYEuEGbN3qE6vtBXI7QC0ojEqJTFz2 GtYQCScYobfM/QSsTguGNTiBGMhdh0Bu/2KvAhDiDQ9ArjpakIgvYAIhUWhhIkQABjoAYt+VtMDI sLo++H7MJpR07SVT3cYWePXmIvFkKD/JETD1xJSsbIXQW1mLWighFWdohQsMIMsk0BIqtbwlVZhQ lavUo5fADIArxLKJDBATDzYYw9jvMAYbpODEaVfxijUBzbYPwTBxHwxg+qGYutu9Hzd+zDm/djbP tA1uQHZGPIkRDL7ZLUfa+7TnRJc3fhrZybzgTkAPdzeFQo473fly5akcnYNOx3NDOnOSoBw5yYNv 88AZATTe3B74BJWoMHreA+SzOv0U+j8LCvTuAf063HdoQzndD6ORB1TmNS/SQx3GjTaaI/9MX6+e RRqSkUAdPlGPmnylrlIjq3rVVceE1ex7dU18bpNx/RUERkjTV2uwiBiI1dt4SsAHnFAEKPQCydsb jjLCkAUF8oQjQmiCJsiC9gCDrODdsgBSEgAQbgBbCuAGTuADLquD8iT9GuUDGEEDYQAFPsAEyAAA oAgMTssNfOVWFqFXaCDlLiYXVCHeisAQBMAP/EAAOMBMioALnEAHn+WOgGu4VsAI8MAIgEHiGmYg BiIBBOEkXEsfEgEM3uAC6KCwUGCPViAIrAAMVlAl8CEmJAaUXu5hyI8CJgC5ekF9viokPonidq59 KKCTyI+TRgIRQOEPMqIVUmHAWOkMtCD/FC5B6RAgE5iAH2SJwQqRwWjmlqxCZ7IuADCMLQaBwzJg C2xgBsZuBrZgaVJMEzfx7eBOmqaJ7kJAMRhjFBdD7wokm/gO8CxgHNrpNPwjNVYjqGLDzbLnO75M /6pDydJjPvapySLPyygHPNwDywJH8rhDO7yscsRjcQzKyhgnOC5qcByq+jKq9VwjPmxDP3ID9mLk FJrnG2vP9vBjRDrEpHTPpnqH9wSNQ/YM90bkABRt+IgPP1TH+B7gG18EpGZERiiN+arnqHokqTzN 036B+qrvqbAv+7RPSkDJvD4G1bovfcAvq+7LS3wuADkmB7zgBAJhfwqgFBYhshTFCISN/w5gMAwM gReQ6xf8oAhA4AbAJNzA4AQIS1EMC7HIwCY9CBI+MgpEaAIT6wTw5ARMIAsYgQ1ggA0oiww6yBAu ABNMoIdo4BU+wRFsqFbAwBFay7UIIAjoYBXW4Ng4wBCKQAI+IIJMoA7qwARywCUKog6gJQrqIBYs wRnK0AiPsAuKQAHI0LWcYQU2oFTeIAwqoQ/WzQr0aAXMwbW40JFuruPQsOZEph/QQT18AR0AE+da gl7ah+K+SpI+YgV0YSDkiydIwg5IQQlWczVb4QxeUwkGTCkUQABmIQ6aghAIQZZ0sxCnwmZ0pgKw TusygTg1TGjqYhNSYC9SQDmhyTmf0/85WcATX2yarEYUrcYxThGbyIYBnOEAysE/8OM2eKMWgyT0 lAo5kmzJ4GM32nOfeuM3Pu2hOO/KovHJMo/yImo8LvPzlGr0ptHLgjE9uac6liw+JqEYgiE1YLHw cuP1jC8+Rko/Woc/OKSmJGSmTmodVco/9sxDhWdDDg2neIr4pCFFINQXZhGkJM0fLS0geST0CrJ7 LiohFRJKGDJKMtIhr0R9JtJHV60iLdJLvIom9osBpiwbfIEXYGMENICuQKXYzAQFfgG5jAEKBKAI EiAQIAESAgGB5EqCKKhRMkBMI8AQKsvcvO0GAKULDGDYcs0KMOvdlgAFnGAJ2IAL2ID/UpYgBz9g 137LBNbAEw6hFFZhuLSSSispGUhgWjBBLI/NEKwgCHjgBWTBBGKIBuwlEWgAVujFCA6hD1bgLl3r HLzqq3oFDDbAEAwAHzYuBpwgAUSiCQSgWdYAD4rgWhL1YhyT5yQTq8DkIbvQDWeijbDKYWxuXBrm VLNkNAXCuUiCEkCBFC6hNWvhDKj1v4buKBAAAZauKSwBXNNANwkREW0mZ4LzwrjCFdaCXddVw+zi LsSgOaOpL+r1CVxMmj7xxQCDMUKABErxX/NuxvQObCxAGKRBeS6TekYgSOqpYTkNo6TM9fImGxG0 PXVjn/op8uZTPzvPN5xsy5KROIaR/6Bgwxk/r8weR3CcRECFw3CEZGJpQxtTgxgGr0GXR3VQJzeC QaRylnUObdB8j6YADR2DtnZCdKVWanhyqqR4Kh4ZDWHvA0IdAB9XNEZo5EbkzKOeD6mqgyANEtRy wfpsdCEZEtoAsPzUCyR+FJOsSquAtfzKTwoiLiX8ISVKIBBqctjiNE59gCUVQFTKMk6NzQq8ja4k yAA+IAPKTQLwgBaaRQL2wAAAoSY/gAvsDwrg1ApORQfjdAmyYAMYYQoYgf6ggA7cErxWQBYYAQ/6 wBPeIBZKQSvrQFcvhgQc4VLfIBIwIRLeoA5yhQYulQdJbi7fIA+ccAmCoB4KQB6Qi/8XfqCNTnUF aAAKPsAS5gG5nOEE6iAGEoECnCAWkOALnAAPDsFWxquSuNAjXq5YW84LP0kiSaY0QcYmIua5bu6r zM/mPIJIBYKTUGEXKOEKSOEPsFXALqEWWiaBjS7AQMEAhEAFCIGTwDU3CZGWfnPCamA4A4A4i9Nd 5QIuNiFqmtNe524wDCNfWeAJ5q46rzNg644UCSDvVMHHficYpAHSKu1GHjbJgoRhe8T5tAfU7GnO sBFj6yY3aoM1ZtE5NlYY9RM9aJE6riPNoMzLSJbKzuPzEMrMkGPLqHGpCvQ5XEMbasMbaDY1DA83 8CONgYGN86M+fqr2pAE/KnRD3LH/Q/2Md4KW0DLU0FiKQoVvaSlURPKDjn1KQqdWRWdjeijNoyzN kQMy+ghyRml0bG0UR6PkBjb5BqDtbHVUbc+rbds2vbgEIxuGCOs2JfABEogAEMTqBqGgdlXiF17m ZWiQLMMACrIAEtqArhZFAmgB2cJgWc4yAQyggqYABlGIbzHLiiSAhZaghRCFsS4LCqzgeK+LBw7B FiLhEDwhFp4lCDBhJRWVBYCFB0zgEXQwCHIlD2ThEYIgU0kuEYwgEuqAJr6ACxLADQpgVCuJF8LA AHSBXujFBCKhXbDXtYiBDVDABIyADCCgCOIECi7ACFbgBcp5V1ut5ew3fjcGlH51/yDwt42i9wg9 M1lvYjQJAYCpYID7MDZJwb+SQgFqumXuEAm0gCs4wRJ0AVwtoYKdolzPNSs0WOs4uF3XVS7q4i6e iV4FAzBQmDr3tR9E0V9f2DHAhgGAQUUKafl2mCCZgTgets3cI/pATTiABJ92Qz7aczWS2GIPbz3i s6mAo/EeD3CeLBekRGQNZz+pzBnHoz6z7EgEdPOoI4tpozaKwRsUVBvzgxiAYfAk+xVh0Y3pcXh+ r9AqREOPVs/eMaeUdtGQB0RG9IZN1KfyI2chFBxJp3R6waj+0UUzbdOkb/rCVmxrFPtwlJN725MJ BW1FiUdHGauAVPzEhPwKgBpUwv9uUaIDeg0QEncP9kARJMBvXYsXlmgGZ1AAwqC7JeAEJLCEiiAW OiEMco0DdDILkEAC2ru9MYsR3i0IkBKaY+UoGeFOueCyBhcKNoBXnLCKbAETrGgVgsBQNmCWUyIE VisPaIAGHIEHPkEWGlwWtsslnJAO3oAGCiBb+LQBmNd5L0AQMMC8HKEIliCLFLqSfKESKsEKMEFZ +rtxucBWPoC60rejT63j2rdt1avl4sshG8YzQWk0xZU0+1cXkqClpVUilOAPrkALVimBVykVUqEV UEAB4qACYskpuvwQbclmVCDCdEY4NbgRiLMRlHoulqmpo2Yv/OIvkmYxkiYwpmn/mqq6qmdMA1hx GQ5ARVqj0hrWII2BGZjB03wYNvQmQW82qKiH05hKPWVjsfeG0uum0RPPiQdUyUz2MmmRiz8tGahE bFNvyjY9ccZYi4nRzCCKPlGdjPUJQYthQSkbyOLG1mVKs3PdQjMUj5F2pQJZp0qbtBXNROjRPkzU 0YAKer7x8Rq5zXT4qIQk+obktr1n1HObbPeaIXub2zv5t4NbuHk0Ir+v+7AEIzliBSxGlZ07BwQI EIhgr3TCAZDLF3agut8bBmEwUhPTD1IyDGiBUj6AA6AABqA5s+6KAhmQKOnqA4IgC4zgUDIQv6XZ 3FhInlfLUrfA4BihwG2lACzA/zZio82eYQvS2QRMQBYcQRYinAd4YFewxeJewIq6IGKgyxBsIArm wTI1KuSBoaJNoCVWgA2g4AVaggUq3Rek4RB4oAvYgOAEwQ8ggAxiYAV4gA0egBd8YW/6IZMgUpRG GX7LHX/Nj6QhU0tMlRCwYBEk+DN1IQ2SABGi9QqoVSKolYERYIFTIRT4UAvOIBNkQAU4wQDC/Det 4ip0BjixwqiB6cwzbF1FYanhwi6ayc2jiTCqScawpl/9tapZQM87gAGooc/9HIcfYPkE/WF9RNKl IbKdgRqEjGYhOxh2ozcYltqRbBd1wzYKr/BORK5p8dOyT0nCeD07fa6FeDumZP/4pWzK3KPKKKo5 EqrMzrM6ELvxWsQBElRBJdsZ3umdrGEcSmMcfIz8S8MVOTSQW6eOcepDdP0dR2S0CXm0jZ3+U+RE p9ZFmP0UrnZ6AGJYr17KCo5QNqLXiIUjfvn4BREiL14SJ1q8yCtXRo25Onr8+NGfyJEkScY4ifLk jRsxVq6UAlMKhZkFatZMlKiFTp0ieopo4TNoT6A7C9A0SoHBsaXH/DHtkCNHDC8vbhToWYyp1mPB kMK8MYCIFy8nEmRZsmQKkimCPrjFEUaCXDYSrJB5Y2WJkRd8AQEykmCDiR+Avpw4fMJIYsUnTBih AQZMlByvHpkwEalOjhWJeib/ilEHr9xDRcKsMUTGiVvHlz/JAtM5EZg6dHhwLmDJCho9BVqsSLAk B9EXhtYA0gkozAegPzsHTbSBTQ4RUdCeyLLmgiPcXJDcEIAhJ3MRvXf63inUZ4uaPH/qLF9gxXn5 8eX7jm+zpq4kWBYl0SXfCrqkQQgGu4CiRihKXPJHK2co0UottbRySShNNNEDLE2cEUAATHBihgoq uMGEGxWcWI8LLtQgQw0udthhJjK6QqMroogiSQpPhBDCEGLo8COQPg4xxI4hkEDCDErOQMAMSD5J AAEdjMNAlcIIs8wBB0jjgC/DIDSCD8Yw48NBAynTiy/SOCMMMMAQAycxwQQj/6ecwRRTjAMOTOKL LwP14kOgCQ3ky554wjlnMXfeWcwkXQ5UUUcldUTRoIT2iWmmmf5Z0UYdJQOqRRH9+eczvZhK6kDQ /LJqRL9c1AwvscoKq6yuQjOopoVOoiidbrJ5pTDWWGOBBRMUi+wEE4xypZvAzAlttNIGY4opWlJb 7QFuaqmlswdUawq01Yp7QDDAhDttuurO6Y47er4LL7y+nJLpMAIJRCpCCinE0EKuumoMLwFjhBFH IB0MUkkKixQDGDeAcRLEKU3sUkwwzURBfjiJR1R66g1VEwUriEyBM1o5tZQqKL1wAggD6ATPVkwF Y15RiRgVQyAgmPUBCnjMhf9JGHRZQbRdeC2RgGJGLJ1AEFkkfZjSRoDAGCA8BBGECTzkEcUK9UAm yyuMSMZZT1F8gMkamBgSBgAXvH2BH1BYEYQsNMhigmVR4LQCIIcskUaAINyRBX1dZGFCFzn8QEYk CdCHhBU3BMUcczHQAchPRtCRxwonFMFGAYmYsMYJK3Dwwwr5mYcTeh6/Vx5ROYm+Xm8BnqffCrrv Ht96lmDRHyG7W5JGEovsQgkopECoRPOXKFIhKFSAEkool6TSigRxtMKEAZyIKGKJJlbgQoo1wBjA jJnQuED7C3gwRAhb2GCDkls84aMYmugvBpFPsCA/JC2JABroQAkYIAc5LEP/DlViwAQQuIxlAKNc XHrAA/pUEIJgiiBp6tOf+uSAC/KpT9nwU6pOdSlHTYJXiqoTneSkKDw9KlKS8sdHJgKRD+pKU6Rq yKsykgyQXCQiPjhhplClqlbNyiJBbOKnatWMf/1iXyckVJr0hKcWuulKw7LGsZAFxmU1a1umONe4 oCWNNKZLGuoCV7nWNadvvXFObITjtNolDXfFa496ote8huGle/UCX2baV79+4a9AVeRVAyOYRQyG sEjmYmEkiQoYchCZhmnSYS1xSVRuEJUcWEwmNMmYTTjGE/O4Zz0Yw5g4TvaUHIAyB5DYww5epol5 RGmXBJgHC3IyO/hIQWdZ/yjmB/YgARt8oJhkIMMyP4AEJKBlCW55WgISYAJsbmADCTCACTZQzGI6 rZiC2UAQLPOaKLiBa2A4xAa6BgZZ7C0ROTABFGLhtljADW4AEMAecpCIFVyNB1FoQUA/YIgTiA43 gigCbwwq0CXU5QNd6EwLAKGAH4znY9T5AB2kIIIceGIJNDhB2l7QAktAoQhdC8MPVice9rRHKAbt 3VBqJ5+cqG4+NYsPBXQBIF0UAEC60wUhOIEFQhDVqElAhYEoUT0ItaIVC2oCFQywoalGyAoKUIAM KtADJqggROEr0YkqwKIXpW9963PFAiSxCR1tYX5Kqp+SniCG/uVVE0TSxP//WABAEhAADXLYUhql wa0DLJAay6AGY4HR2AnGERiOpQYwpOGnMEkEIopUJGcZQqo+rbCFcSLGm95UWjvJ0IQ/9MhINIJD RIZ2h7qCVGsn+VrYUqSIpergEUnVql8s0YlPnEgUR1VFHz6Es2WKSJgW8sF3zclZXLTGOMCYrAlY g1nO6u4c60hHLsVLvO7Iox2jNS50nfeO5W2XA4KhRz7qaV59ohcgvTTIVAmkX/x9iCIpAuBGEowj GfGUJENCSX+EUpRSWLCDFzzKmFAgCiTLmClvUrMM/yRkM6FwMGC5FAs0GCZdSIAE/mme/Mi0KCEb gF8AEQi+vMAIgwAEXxj/wYgXn+DFVisMj7/gly8A2WqIYcxheMCDT5jTBLLgWikckYc8lOITBYgC D+qQANiIYAUmMA0AvrzPtwGgCEboTBTMSQNg0oAOjLAEfQJQBCQU1DMUuAEFOJYDRSiCAkJxTk+8 EIYwGCEPWWBEF2hAhgsYAqD2xMAKugAAPQTIJr4Rz+vWY58NA/M9O9mp63o6E6D+FEAUSAMGzLAI 4enCEoRoNX+ocIU/XCJCEyIFKEBxhVogAAFdVcCued2KAFRABQYYa/gqYKIUuQBGMmq2JDwQ1ww8 4QkZkB/9lrSF/OW1f/sjEgu2MIMCFiKB3EqjBQ+LWMViiRrCcOA4hKEt/wbgwwLCSFSjQpip+eYb Ty8EhjP+DfArsQngznBTnBK1QtZOxLU2pFSlZktbD5IqIhMJohBjq8OIAxcisyJuLpJhkShCI1Wm MqGqOlVgR1YKtFfU05xMW3AualdZX1QWA5gVrDY5S73S4pJ449Xe965XWu0aOrR6lcfyOsAdweDj vOjlxz4BEl9/wldBrs6vhjTkISMA8A9V/sgCHzhhCR5lFCIcYQrIhJQkU52KMZxhVQ5lw2qncBQI 0N0RFMoBY4jBJyFxgimcWAo17U1+1L7iRKi9JaGE2Bcy0YWTiAgMXag8SiqPeUhYPgabjzzmOR/5 hnVBFkYQTJPB8OQ8dP/hEYtIRBRM8IY3mEA4LZACQv3gBzHDzQ+CwIEnCJoIGtTBBPZZwQbewIPy uGEKYdgAGDizUd+cgGgv81hPCpCAMMQtDFAABD3vuYQV5CAvXesBBHhju/vM9Dk46Y17aKe7FJ/n 00WB3e5+OmpLJAGpShUQIZKQBsWzCwoSCqRgPVdABVQQCrUgAALAgLvWgALAARwgAArgAmNlBmRF IieyIuezVpnwPimQASM4gk+QAjrCI9JGJHqlV3wVAuFWQCUggwZUJQpkWNJgQTmYbtwCDO32bpZV Lt6QRsUgDVlUhEWoRc7yb8LSRcMSLARncHCyQnzyJ8vVWpPicLJ1KRH/J3G2dYUk8XEYl3G1lSoU x0RNBCusAg1rCFzBNVwfdzBhJyqIBF2EgkVJCCzB4kXKMiwTMA5eZA05p3PdZUY8R0ftlUd6gkdJ h4jt1S7u9S6OyF6PyEaPuHSQKF+FcgoPcApRR3WCRHUIASb94l9SBHYXQWBjh2ALg3Yw8WAu0RIT I4sVM0qtZIsiAx8T5opR0WA5sABJkwUG4Hc30AUvAAmBkAUSkABSgBQXZhRgwWc+UQBSIRUOAzGO AHmXtE2cdxKY1wWa93me143d6I0RI3qlJxhbAwY10DkrsE7kAXtvUAfAtwJG0DhhEDSC4AcA4Ac4 4I+eUAeysAJRYAR1/1BROpEDh+AElqATZpADyWgFdPABBlAFOVAAN2ACTmAFHxAD1jcUXcAGCTB9 +JQAOZAAABAGXVAAWfAGFWUJhgABSRBMt0NTq2Mebhc7OjV/cacTu6M7+KEfoXZUBvAfRWUJA4IK KhAKVyA9lJCA03MJuiYACBCBVSkAvRcAPSAEY+UGKsAEZqUiL+JWm5ABQxBX+BNXOnKCm7AJOuCW 28ZXQ/BtGoAGaNABdtkBeWlAMlgIDZQliaUl7cYA1HAA5bAMzqAlXXJ1aHImvpUpiHJwB3d09zZC KHRywqVycDhEEJErjrlDZUhDk4SGYmhCXLhxXwcqDmcrEcGGvbCGHP+HmRXHCxYnKa6FMAQjKNCF KVj0ct2Vc03oh3w4LKOAc4JonDnnLOEVdPLFnO+SdNDiXnhEiYrYnF3iAPTSJX40dfklSPl1EKPo LwthhQLzCwIGdqmoiri1MKDESRMzAJAAn/D5AoFAnzAGB4AAB/kJB3ygn/dJn2IxFm3QBvQZCP7p BW3gBQNwFS2gdqE0S1HhCkYACAZgBH4HeCAACVIQAwmwAyBwZzaRMUBRAJAwOdLIEuboeK4Qetvk jcUICS9QeZrHjeRYeTImY+B4Ei/wAU5QB4zwCU6WBzjxCYQgAomQB6FBB0FAA5hkAoxAB7FHBkUA BRXoa2TABnUQBLD/AQZsYALlkQhGUATe1wJm8BNS8AImgAQSUARFUBfKeAMb5TFSIAFOIB9fsAax cBprAAAfMJBJKjpGkHsvozr0Aac3g0oQJR63o6gds0o3OSCtFoC6cGEjYwmntgiWYDsDwh8qkDxP OT0KMlW+NpVWGYE4EAcyoCIVID7jYz4B8D5xJQgpwJYnSKse4AHP1pZuKSRPMANjoAF0Cax2WQJ7 uZczqJfHmpe/WkDGQpj4JhAIESie5SoToQy7qSd80iU8lCZVxK3duq2eyYUmZ1uPhFuqySpbGK4m 1ykXRxFTVEVKJJugYnEL53G3qZrtWoeX8i69Uie/4m/VBZx9uF1//wicNGewfjhG5xIt7pIn1cmc 0gkvjugAxfCI8eV0nKid+NWd9nIvYJJ1DIFI/xIw5lkw6Jme6lkSsngS8RmfBzoWBBoI+AkIfOAX 9wkHBDoWXtCyL5ufR5CfgSAWFPAeFCBLDwqhe+EXJ8EHxcQHN6ChCbAHVgE7qQQW7rceGpoSlccD DeB5TLABmfeNNPACNKB5OGp5MVqMMtaiefACTvAGPDpoUVAPnZMIZkAInbECslAHhxAEn8ADsiAL PMAIh0AHhUsHEgADXIACXOAECllRBWAAS6BlLdAFZFA4Y/oT75cDRJAAl3ACc2Z9BvUTBhAJNLAe GZkFVuA2VgAGBf8ACE4AG1FQB25DCIbnfpTTO+xxMzs1qD3pu/RnUClWagOACqiACIiwC6ggPCC6 f/+hExTwf8ejArAgPdQDqhMSIQigawhAgQKAA1XJAQ0gA+NbAy5wVsuWCXGwCR4QAbaalrK6vpLw bPI7vx4gBk9AAr6qrPsrrMM6g/sbJQMUJRrwQOMwAVgiWdPiKF1YJmWyd73yQi8XLVnEbzFEJ/a2 QnuSwfqWrqbJKV8XEmHYrhC3KdzaKbSpWzl0KWmCKih3MGiYmnBIKTOscpyZr/qaRdASJ/72r8cZ iEw4cwaMXRYwb8Xyhwn7LNFShPHCiSHUidd5Cg57ifDyc5kIxX//FEjdOUh+Qkhowl8gGxHGsEin CEljJxIoSxIDkBJqXLbfyLJvDMdwPABzTMd0DAkISgT0CQdVALRv+rwPFhWZ8AmgFwOQAAg7wwcx ABOQAAJwYGfsYRRG0QYuMxNfwRLsmaKYx6JhW4zfCKMt6o02aqOaxxfFeAhQoJAmwDWHYAKQ8Qh3 W6RgYAJY6hqAezWN6wS5XAds4AS8HHtGsAI/cQMSEARCux5ZEKZ16x6U4zoe6RM5IAGR4Ah9cwjA DAlRWlFR4AQbcBV58AZvEwPN3Bz4oRM6lbuURh+9Uznl3FMDkgbFizy7YAe7AAtUgAgAUhNpgFRC 63+LwAkGAAvV/yPQs1YLCjBVEEKVvPZrFCgIGSAICBAAYYmqKhIArtAAcRAHg+C+62ur9Du/8mu/ 8dOrvjoGJP2raKCseDmsGkAASbIkSrJLFvBY2rIt2qItwcCDlFVwpyUMMfeHDOCET8jDp7XDqXXB jJJF8tLBZPjBj5RbWaiF4FrCA+FD5HpDOJSvn0kqy4WKFvdaFhdEpygq7equJDxajcJvO/wm/+Zv Sygsv9mH2IUPRVzExhLUOkd0TBx1T7eJDyvFmSh1XmJC92IvA/GsCfHF/uIQXP1DX1cwYqeKZ0xJ 8TnHcWzZlw0JdVzHLIug+ckHnw3aMZCLvbhgroAFmBQDAxB68P+pyGo3AD+boAPgEgMAAnsAAp8N AkAACSsbejnwBVzLedt4toQceuPYxjZKtp9syMVIB5jwBhLJAzTQB4cwfJ5gAlGA3bKANUwWZbJw FnVgGd90ToxAG1BQB8bMoIdwCELbE1Kwy5ZApjXjzDSlUwawBmtABwngBH5gBXyQAFPQBT9xOdws G3UQBhBACOOxHgEFyTdDzosaIJnmHubcaQFYvMdrB5RACWqgBhquIKBQuzqRBlhQlEaFAZwQ0KFw BlRlPa1g0BEyVdgrlQ34vTUeB+gjAx+YvuzLvhEgCe7j0bgq0kpS0iWtAfobrMo6Bk3iJE/i5FGS lwzQWBIkQRP/VA4HQAw57YPIgg8dMG8I29NtPdSp5UJ2osN0QsFTmK0bRMIa1xBMpJ4pHNV+0sFN PZsom4WWUuc9ZIZ3Xpufcq8ghxHH9S9GhCm8wkL8+kKl5a8EByyBGNfFMtdzPQ/zMOlFrF0/PEYL qycY2+mdGMWgHsV/3ZyncF8cC4qBlCpmwl+c5RBijENk7CkGZsYlgdl3DJ8CquttgOtvzOu87uu6 XqCeDdqgTQSER3e7CKGfEBXcuBKMt3apvZ8cugMJgNs7cEw7oAgSMAV7cE3BGAh+lwSHoDgxMHmg tEl+d0mYZEmZBDHvPo6f9wJvsAaR4AkfYAKfsAaeQAdOsO9G/+C3NAAZYJAHkUEDgKE1BR9PSJaR QQBQQ5EGVtClQfECdGAEblDOG8Ool7YxwfcGACCP/o5Pa9AWVxFSWeAENBAfNCABENAFqVQThGof 6+G7EI4eEFU7PflT72y88rzhV0AKpPAHpEAJsaYElJAGQKELu2AGQUUIiwDQWhAAoeogqaAEBb1r raAFl6AADQiBU+mPOIAADZAJDUD2Zd8AHnCCgjAEI5gCcUC/gyAJGp0CIWBXRG7kJo3SdNkBLP0k PHIkR5IkBJSXxsIAwqBAQLgtctKDP3xdXG4B7/YmjLLEaX3UEWxvFJxFan6tn0nnWl2Ft/URIHdc Y7jUXVjVd/+eDA2XwpYi1RskrqDp2GJN1lIEKCOnQx2kDWet+Rasw4xuWr4JsMqCLJZO6ZU+6dil Xe82Rjw3sdUp6tEv/dj5LvR1X1k8SByrsfnS6os9rQGWmZB9sgpj2QGq6+a/67qe6/GZ/gMaCF6g x/3Zn58NCeyteDMRSlEgyA0miwCRQ4oUClJuDBhAJEEtQ7UkKNqx48MOKwqKXMRoZQOkHDQaxbiR w4SKHDfAlDyZQ+VKlVJYrjQJBozJGF1qWlnzxokJI0HwRHrzhlYsK3SCgEmUKIojHjxoPM0TJWmi AhQo3LixosVWERQ+OMnRQsRYEVHq0KkhokUBtonUqk1Kluz/VrpRlgB4wxOnBAkALoAQq7YLF0aW VnSRcKGL2LUttK4ooLUA3caPK1NmC3lyVV0U0nxGhWiXHTuUrvxRouTPH1JU7LhOw3kRvzQrdBHC YiBUqlZxFCAQgKDVGQUKWik506r4cgQ4ZmUAACADDgUBXAQIkClOCkFDMnzPsMXGFkEeFkjyMGTL DBvs248ZM2PGGA0a0NS3X38GCRIhQvTnbwYCOrCAAQbkWEYOOYSRAxgHgTnggHIOCCaYcoQZxwIN N7RgHGeK8SXEB3wZ0QETi6kwGGJUVJEYb4ohphgZZ5xxEhNtnGSSEHfksRced+wlyF9+4aXIZHJB Mpdkihwy/0gfffzRFyendDJKKaXsZcgieUHSH3+S3PKXEaq0skcsoaTShxFGUHNIN90cc80xqcSS xxzvpFHGGFeEEcYVWQSUGGIedMYZYJwRJlFhrGE0Qw7xgdQCSOeBtNINrVk00Qf/TNEdEz914JQR T/GFVFFJ/fEUUEMcxpdWd3yV1WGCnFUZZeSUU0023yTSGF583TJYJItMslhjk/QyWX8gYRYSL54l IhBAiGijWi8CCaSNbKvltltrq80W20DgIJdcPs5F91wQ+LjBrbUKioKgKDLBIgqVsIphgBsMysEq gxLawwpDBBCgiCn2mEIBNn3w4ReGiTwAkBu6yCQGMGJww/8Ek1DaOIeUVLIGxgq9IXmScWJAGYwu Vo7hBTowoeMDE4JgBA9BMIHiDlrWWMMJMFaI4pOzjJLlqZ/lUiswsRI54Y0TlGZMFigqSaSFqpEm a6qql6YLjDdicQKQu5x44YQwAHhBriiakGADI5bw44Ib4NKMLcq2SsQyyybDW+8VbLNKlzRQCY00 NUhZLfHEKQGiCkQQSYOCFQhZhBBdVkiCEyF2U+43go27RAnlECiullaAy8AG1W2QTjoUKrhuAQ82 4Q681VXPYAjvtvBvC/Hkmw8++OSDTwMC+mPBP/9IEFCDDgyUgxoEl1mGGuuXifAAYiI8dBlEMxyH gfATpYb/GGlk/LQYB2isUNAV3W/RffkFDcabYGjMccccb4xSSCK5zIWXlLQkXvwCGr14RpnOdCYq NRBKQPKfkQIoQCUx6Rd0+tGUrvTADG7QgU+6Eo9A9SlfFGMSJsTRnRyQIxmdME8z4lP83te+QREK UYti1KPwMQ8e9jBSl8KUoh7koAq5w4gjPNUDUDUMJe4IVTyKlati1apezKqKQcJVFsXUsF79Klhf 3FIuAHgsMirLH896FraiRYQjHIFa3/IWt9IoLjq24VrYMle69AgCELSBAmPJm1UoEK9MLMIl90LZ vgQyEKsMYAeG8IMfABBJCQgBBoLgxTE0uclj5EIZCeiC/x4yYRMwqEAFIEGZxbASEo+ZZASc5GQv UtmFF0DCJi9wglESEIQ61AEPazAEFIbCsyB0pA6RiEQfgFKHDQTBBEjBGl1EkAMJOKEASNtKFJxg gygEJhEFKYkUvLk1yohgBQlYQywigZMwGKALH5hk2saylhdI4GxrkGQa1mK3yPCNMpChi1ak6ZjJ QOZvFOgMaOxAitQ0tBa1+MMVTrOD0yiBFJSgBCgokQTBJcFygsOCCnaTiuIAJzjGaUUtFCCA4qBA AbO4gA3wsLrUhScDHshEAFwRhwh4IAW7u51MxxOC7/iuPcADHu/WQx/8aGA/AZqB8zpQggkYiAHS E4b0qP8HjOphihrCsKqBhDFECK1IGjaC4BWD9KMU+sJGNzqhC/N0v/u9EH0OCJGTfEAsY4XpgkFK YP/WysH+MZBMGRSSBJU1rAL+lbA9cqAC81onyYbIRL5YIQnxCsFnDFaDVsrsCNUHqkmkSFCHwqE1 dFgpSlXKUhqagAUYFURDbSpFwRghqEYUoidCsVXDiKKrrghcK2ZRTg5zkxd9BSww8pWMZUxWLrxA BDTOcVzY8kIcrUVHPGJLW3e8Y7n0yId18TEBILgBY6riLyk0ggcDGUgOUnmDGDCSAjEABRT8coFJ AgAFCdgDBzIJS02OwAp7+MAqEmAAI7CBEYCAMCBeMID/VM5EJTHoBYE12YuTXEwlURjkB5ZgBCN8 QAJvsEVOhIKHMEBhA12ggRHq8AZMrAEKnqDDIR7BgyjMhTFiKcAGoAAIpE1lBV+IhQEgE4MPvAEK YZiFALKQg6rFRZorAATNDrGG6ITBClbwSxEA4c9EdCECEIjFFAzghwFYraBcSVretmYZuuRNoAbt jOAGR4k/1IJgAnioRa+gBjUMutBKeOgf1ECJS1xiFx6N3AoskYRdCEELnasFAmYBgCgvRwEqRYAf xoAHCIwBd99JQaorsYBMuEJ2m8BB7VJ3O/EcdXjs4d0ThvCEEDC1PmgAdglK0AHjOU/YExD2VA8E 1uhR/8NAG5qAMJwhIfq9aIUP0JGUsrGrL+YCGWIMU2Pf1DCGMWxODWTrCtOapf81101OCqyVQAjC ytY7rVrixZEWC+4mfXbdHkS3YT84Wck+6YMHR/daJZs+FAXDQYVK7YZcCylVqKK1lLL4ay0wAUYp StoPum2FVrXbUrmKVU5cInGBOyXjrolXym2usJ4L3S/lgrtqhMMRcg6H7N4xWngsV9DJVUdxiRdd fCQvHwCcADhQQL2CpEAAFlEQ+JYklTEQSAz2IIDodH2SChBCAiQwYAKPIJIA6MQawmAIAIQBCR/I QhYMAOEXvGBlNunCLzR8DF+grCVRiMLfjMATRrwhEv+YSDEZ6EALWliBJ0Z4QYxxUoQPcAEHVnAm DVbgrnmq5QVv2MM152LlFZBBAktYAhRisV+/ACASPPibP9XC5A90IQo0mAIU/LB2K3wA7l8w6Aqy AAAIcMAIIABADO4GNaoQVDKY2Uw/1zs4O6gB0cGphUUvagdEAOE1hmsoov8AiitcAhSoSMPlWuAZ TsCCcwrggCAEsWk/zEI4xeE6BEo9nidUQgwp8ABRcIVMaIRGIMBWiwOfSoGiWh3xEJ4HnIEn+L8n 2ILi8TX76AA0mCph40AORLaqYpBl4CoG2BAGOABp8IazwrYRUYZeKLeGYYbkKpJvqwYy8itewcE3 2ZL/ZrAgHCygmGusc3sswZKSzjJCfys4DDITLNISZKEgfnMsedugKUQsg5tCz5qSzpqSCxq3LsyV XNGVXogTDBpCyzqRFDkURJkt1ZKUHdqhHoLDONQ4DZmtTHGQP8mtUjmFPTQ5B1CiJiIuKbEiLNKi h0kufAPCMZq55xqXNtI5oWsjOOCuawk6PhC6obu5PFIX8uIjEEgAAAMBSBA9qpAcCqiBqaM6gbC6 fHGWBCiCC+AvrwMAKGgCITgDsoOlEfALCOgEP4CCIhAEKMiC8zoBQAiEWrKJq8swDeuFlbE7lrkY HjCCBHACJ6iDLIgFKHgDK9gZWQADI3CCQ1gCezIE/yTYAAmAgp3Igmdyi3kSixUwsRxwR7zhihZw gxdYgntqvUi6gFj4AJmgMrJYgRewAkwwgqQ4gSIwhCkABAoogC5AvS7QijQgAzSDAisIAwjogrfw sbx5M4Gqs8fYDMfwjNBQgz57KIgihUUjjZZ8DTWIiB3oM9SohUtQA1AABQyInK0ogNvYhVC4NJOa hfmLDvszDgXIAFNTnSfYBEmQBB3QAVGQSlcwwFZDQFhbwPCwgQccgzvwyjuYgQx4gve4j6Zqqg6Y qrREyw5EtmErAQaoHrGiBuxJwf3Jtlt5GGZorBgcEmDxtlyowW9DEmTghYfRleNCrpfjwUS8wSER Qv8FWhV5e5IjpKyCu0IFcpIRwDcbZBIfQEIICqElFE0rTBMfZJIfxEFoyME3wRU6QTiFOxEUOS2I m63VekMeuk1KgUPX2pBxwBRDCbncIpVhUJUfAS5WCZJbiRNccRgu+sEiYS4wEqNFnLmfe8Ry0TlL lMTsCoQ7GpdLBE+hS5fyKi+lA7AdQK9r2ierqIEvKAj2cgn6eoFAWAhJ6rpIkiRBUIAp2AFc5CRl MIQi4AA82IFh5AKGtCUKWwmCGCSrWEYCkyVIoAFIqLu6kwUQMIEMlYUciIJXoANPeAM8OATAC4JI SKcLWAMJYBsooAO3CYKdcDq5aAFcAoTAmMd6NIP/FoCENwCA1ds0v8hGR1iKF2jHrkAnsHkBHgAz PwiCP+qKIIACE4CMPMhIPJAk/UsCqNkKkCQoyvBIx6ALzggNSiAFxOkzi8Ko01CD0qCE6jNT1EA0 0wm01LgEKiAErRCBAkiDHwCFS4M/AYikWRBUTuOAVhCCVJgFUwsBXYNKHcCFOcAFXGhUHQjATFgA nuIArRw1+PDKrrwPNLgD+wC2Tx3V/AC2tdxADkzLt5wAZcOeEzwraZDV8zkrdcsGMXxBQ3ROwSQj MZETMRTD4+IiGQTCdzust8qty7K3HYm3vDI4JVxWKQwS58y3JDkSC/LMw6o3eltClmO3X1jM5uLB /9XMweckkiE5zF8N1hFowcgyw/VpH2AgBtqsTQ2ZuDiEQwLAV3zYuI4botvCq4D9lOEMxFmZlTHU Is08RMYkFkWkTi/5ue+sxEfMxPC0WE1MOvI0r/PcAT6Qgnlar1MUJBCDL5fwAj7IAoERgDCwz7Nr OwlIgHPYOwfYgT3Qggw4LxDQgh6gMKxjUMk5qEF6UFiSpYuxmC6wpS6Qxgy1vSiIgEMIx1h4hNs7 hFhYgxpbJzIIg0j4ABILAqNQvqRxjCz4gBVwx6QR2xYwgzw9gUjgr91rO7KJAjAIghdQmi4oArz4 gC3rL0MgUhFIBB54Ay6QSEtwAlKDAMQdALHl0v/IaIx/CtMtFRxUYFMyTY2VLI2TVA3SMA3WQJw4 rYWLSMmU4gABuIQ0GAs9RQUDAAWSWilAnQU/mL/6EwAVSIJUUJ1FHYJG1QSojFQd+D9KFYUEpJ3v UB3huYMxGFU0KAPmJdVSzY/6WMtkO7Zhe54DgR5YvbYRWcG3OiFl5ZFbXVeGkTkwEUIq2ZVhbbdg MVaFc6tkjUzMPLgymbfQpN+Bu192C6O+YhJolVb5FUNiZcxxJVcfXF/2baxhbbk1waBPcaEWebgb yiF7nZQeIoALngd95SENbq0OCaKPk1eRMyJPMZHeUrleaFfjwkFfOWDppE5j8RI1+jnwvDmgu9j/ SxyvTTy684SIQFBPtjDFqSNZgijZlgEBhFEECSgCQMXP6IBZvdOwBxhGJBCETwSBJcgCm2ClkuXi V9KwviOllLGYFxi8IPiEJF2DPvjQWCiFPKABE3iEOgiCDaiDQ3iDQ9iAT5iZIEA9R7iasZCCXhI9 G73RtWXbN+CZSKAD2EuEHJiCJXDSPIWnMOALfIIBCViDC1gCgYqCDWCDTwg8iKwxLrsAfaIKLr2z erSau4mMyeW+zCWFK2hTSjiciGrTWm6o1Uip38i0h0KAIvhlQKMEp6sK3NgFUBCdTOMAQ4gyQfAD G4AABEiCJAgFBNCd3p0DqGSB3W1UMXDURqWd/yeYteMVnuVtXmArgw4ENqeKKjRwyw1Uy+uFnlcN Bml4gBEZBlvR51fBthtBwftRVvF9oM5qEreCLPSFBnLjIh+AhnOzLLu8KxsZrVXZLMwUuM+M1tG0 X8nUXy5JhuhiLMfUVsmkXy0UYCPhkkRshnbTkgJ+uZbGQXMbQw0iLIYzrUGBuERhQ4rDVwvmYNzk V9mqw7EaIk4ZoR5p13XNIkM8TSCczhcOoFywo26prmfRrp4Dlxqu2PHMWPI8T75IgPTKU/Z0T6gD sSHOAUgAgSzYgx1QBIyMDknyAytIACgmsGGYgg+g4nUJhB7YgEQqCVYK7FTyYgilgbtDmS5QGf8e MIFe4oksGCYaewQayAOgoYGi0WNZcEga4KUgyAJnAgPGyNMsAAsfM221FUhA+IAgOAGkaAEpOMfF JQspMIQL+EUAWIMP8IIs8IM0o7K14Owg0DxJ6wJHEJsL0AO7CajHwFOOVOW/GRzCGVNC4z5EcFM1 AAIgoAREK4KUzL6H+g3gMKngALRMa4VhZovJpQJQCIXkeN35O5tSSwXDMAAdCIEU8F1RwAVN4Oaf GoIAFAUdEGf/CKqu9MpRPed0dufmjY/iced4pl6qCiuxCkEKkQY/dBVbWRNbQeFs2JHdeoDMyrZi cAZrKJTacp8aySxmJTg7wZEZqasZEfH8eav/H4lfIJms+s3og95xJ8G3I0GSIyGgIKySMszxdesF 1RyScGXY5hryL3qT18RVl3NMMWnomfZfM5QRGjqUNFTDCabgebC4nt7NH+rX1NIUTplovKIVb225 hWXYp17EZqHzOrdzSPCW7JKjOPJOjM3hr7YCRQCBP3qXU2SkeHlPkr2KQFjriFAA++y6ItiDB4g5 adiBT4yAF0CZDVABk6AvVLq6VAoGDsKiA7g7vOsC+poxJ3AmE2AEW6CFMDCBetgARjCCzYuCFzAB mekxEZCCxg6CBNgAmTFbssgBJzCCyThbGTUDdymAF/hEIwAEGkgAOsiCj5ULCpiCrosFQxhG/wXg LzI4AalwjOA2gqj4mxxIgFjI0jBNZdF2bufzjM8YAMpt08fh3Hvns9Dt7u4G708DtD8LDpNCAF9G gEtABIcsyV2ggvYGNdiVDgiwAVjInBrQHajUBFyogRrQARbw+Cfo3ai07/HgnfB4wFBFZ1K9NeIx tvugj1TtwAkPK0WZSwix8AsfERQuNzcZVnNTE18olHKAH/nZchUqk2wLER1ZoTth+tBC+h2H+vx1 TSN3Vib8HyBnLCJ3XxyXXwZa8iZv8icvEgIWaX9roBFIaJf2VWDVVmRtOBZxH3mNYAlmwza81311 QwqGrd+sLbpSnwwaxMxETNOMuWGZ8wG48//EV3w653M7ArocVhdP3ANFUAAJ2IGwpQqpgy+rGGIp INkbgASlkwCui8XoEIBLn4IiCIMwuAgrsPwEOAEjaAAtNqWZAAlPp6/cD/WrWxlb8n2khYSamDE6 sMavYAVaoAMwcINSAAoeqBowcIIweAN5SoQXeARG2AA69hm5SARqjIEbVZpEcIM6y4ESG0c1i4Ei lYsYWIJ0slpDyGRKdoIlAD6qyIMZi4SdaApGqG2AiNFCRIsVKwoeHChiIcMWiQ6uKEBhYpo0qC4i skNJDSk1Gq8oqSXyz5+QtRAUqSVgJcuVImulfImgFaoCNnWlwbALVioFCATMCipolg0bGeL/ZGqk YwhTFo3qKWURIsSWEE9w4UoRouiWLUWLjgk75k7YGTOq2jA7RgPbtgQ0dCghVy4DBhNK1GUgLO9e YXKWLaN24AC1ZYOJBZNWzMEDX457QR7hw8evyj4ceCsWbPGkYpMm9fIBzQdkX59NOzY9ycFqx5NU e4792YG219pS486tezfv3r599QIuvDfkXpV58cqlfDlyXr9IBw+Ou3jx3dSNH2+ebHuy5t6/f+++ HTzyyr9GXAd+vfiI7OS9Wz6f3rGD+qwdLC6mX/PmYMGIEQOMgMIQaI2BFiBoAT4LztPgPAziowo+ DuKToIEEOgMMYv7Zp1svw/SCnog+jNCe/3nOoQheLsklt5yLuQwQo4wDQFIjjTXiiGMbkOy4o441 thGkkG14EUggcMDBh5JJKqlkAgnsoUgRRVgBAgULFVDDIhRI0aUUE3XJZZg5QEKFBH4AkKaafkiw xx5TFKHAGVN8sEcCIARyQiYx3JCDCkbc0KeggRLKZwyHInrjC5C88IIXjjIKSCAvnPDBG2/QEYYc eGSRwyFrrBHJBzkkEoMVABQRA0NRGBGEq04cckIiDIkQgwQbrEDrQg495EYiiThk0wpfUqCQCAW0 YOyxNCQgwRqxrMEIDTl8UccHPDgiSxCRgOrJBxsw8sYFFxCSbLI2mbtrQwWx24JNFFWUxv8AiGyk BiX1kvQHKVeQooRJRbTkkgAwIVAwTArU0korqSCCrE1pEIKFCqGk0kocCHAAVAZEQWBUIxWIkgJT mjwFlQ4hzDDVELiIIgZVW2TwxBMZePVVVTN3NUNYGoxhls5soTHXXBMUklddfwEmx1/UCEMNMAcI +PRgg/knjX9V+6fZhsAIMw6BwjiTITHFqEedL8UACKB/iHkTTGb7dRb3ap/d5kvduj3zzHpllzZd 378BThx10PyC3IvKNSff3x4KJ11uxR3XjHfJuDhed++FR14zlq2X3nomercic9+ZV6LZqTmwm331 7Xd12gMKY03sFhyI4IIV3s5ggwsieKH/7GBrePXqqadGXYnnmXdc4Sm+J/qLMcYgIyQ0Up+j9Tn6 COSQQhbpBZLfg48kCE9GCTAUigwwUCJaUpCDFO6/734O8LcPSQIK+DGumhcAEIYEO+xAEXR6EghA AAhK7SkHNzCACnLAJzAgClFdOFQXBrCoRr0AEBoERJOUdIICniAGOXhBHd6wBjx0og9G+AImoLWG N2wgB7KAwgXYcKWFrIAGQXACD+uwATCYqwUUyIIVXhDEYBkkCr7iFbB0dSxI7KBNJ8gBsnaVgyzQ IQhRcEgOTbCBIJQQVGsgAxuy8IEzXSB9QXTirs6FrHOtgAISocgAUIEIeqnhCvbKox6v/6AIkYQE YC5RCcBUMjAEvCQlSghFKHahi2RRAGKo4MROKNYKBKRAADjAgQBSUBRBuIAJNcDFEDShAx00wg1u EMUQZMaCFLBMFJvIQAgywJRbDkEMTKGKz8SyFg2gIWhyKUTRGIA0w0xtatIYzAOa+YBhPEAa0mCM Lx5QH9cBCGrOiN04FHQ7C4zDGhkS0GaGdx/TEGOcaQNQZj7zGdl4pjW/6Rw96xmdwOGTb+45XOJ+ cbp8+u1EmMvc5bTDnfeYh3D2XGiIBMqiF5GuMqZj6OJ8YR/9rA1AwMjQNr8WuwmE0xognUCCJsQ7 Cxnod2ATWzCG9xjjHe94J3Jo8w4nvf/r2WhGM7pej4bkhZ/+lAhHCl/4+DC+PUSxCIYoQgKu1AIs 1KMC9YjqVKtaAalGVQYN8MMdOuHVTrCCFV5lxR2MEgYccAABESADGVCAgkxUYH43+EIAZFAKGbjA rnoNABsC4FcucMGtKFAAChrAVrZGoAgFQwAUOEAGwK4CD7awxRpOwIMEsAEHsaAFLaAVC1aUoQ9u MANpzVCPE8YiFqtYQyVGW1ou4KG1pTWDKmvLD1r9ClgKacEPBDAu/kXCCSZ4ARVXAIgNfIIGYDAI c3NAAxPUgQzcKoIEUGAIAJArXQ3R1RHdaJN3WQQjGdnIvfJIij/AxBC1CEnABFBIlyD/EiWA/MMl roCKNFBgBbrAiS4IgYqdVOxiBcvkLDJwgaJsogY1EAUuNOFgHaiyHriQmRhw0QhXLEVmTxjCJjyQ gidQJS1qAeZciFk0pf1lMNKUZjSjORjAHKCZw1CGMoZh4xmPgMY0dsAymSYMkCKoAxJCkNfUpp9r Aogz7nwNOje6TmJ4Y2ydic1+4Haf1bjUN3qj6JarA1APQW55LVIO5RKHnn/i8zqVkRwvKDe6NiPH ci2CM3eWc1DkbK4yFF3oiAon5oe6CDzLk+h5SmTo6vwNy565WjAExNGwbfRrsktpSk2aoN6JNKUE itp/NrMY4jUuRDFNHqkxdzjlUK96/9PLKU5bjT0iEclIRiJqUY+a1JVIwAuzSsREeu2licSRSzHw wv3ylyY0qal/VtiDAQq4pEDUiE+EKlQEqz2AGNRI1kzqIAiMWsACJmAHS1gCHd4ABUaAIQo82MAL opADE0jAE1BYgyCcAIhcEaQgJjhEHR4Bxjp0wVgraNUNc9tEESTiu7pFuEJyYIULQCEBgEgAGQAQ CwAENws7rMMhShEEWeQhCrktQBReEAQyGCIMJ4TABQTCRu4miyAPGQgkIxleO94REXY0rxJ+EhNB BiwlhxzYwF6iBIVRoSL7/e4K0pAEM0zMkq1IQYEzsLEMpCAOTOCHGVg5lRA0grRucP9FK5miAw94 eGY40xlZejaGoJm4ECiWAwPkPvdloJgBQivBBIwJGGMqk8XNXObTgOHjcXTTa8AoJ2v+QwyoJdnx p2FyZ8LmjCcn2TP1Oc3jQl3PLzcu1HyrqG+M556ClkfPpXHcS0lfvMgQTsy5cDPl5NxmN9v51LNH XD/9ued6Vib2flbRigAtOoQ6R6JnZr1F8dO610Ut+o8Om0etUdJLT4DSGBJb2q62n/q0XtQmIrXy VGR8GKl61TdyNft5tL02HOkIcDiC/OUPPm8jVQJFCEMYOJAAKSQLrxHLr4GJFMQAESSAIghAsjEg APhBEeyAAXgQH0jKolxbtd1AtSX/yvq9gLZ1kFEpSbeNDx8kgBUsVSRgAh0YgUE4AiOYAEQYgQmt gQoCQhdUkUPQwCHwGxjRwQsSBEHkwAbQgPoUwKwcyw2AwA7w0AmsgMEdiwn4gR8YwKwUABi8QAI4 wbz1DxRgSh14YR0EwSeEXBMmQhR8ASNAgcWNSxr8IBtpF0LsFiTFi3ghwgBUBCpQgkmwREoA3R6u hMEIDEysVy2EAiroghwlRAHsl9NhwS5MTCoImAKEkgpgwSIkQRIQQhK4AS6EAAvggmupQA1swlRs mA6IgivMkg2Ihc64XTCVQRns3VygQVwITQe0BVvERQfo4i72nQUwQGC8GDVkiDBK/5/TFEM2SMfc OEA6XZ6nTVk6YV7YPNlmuFPZ0BTvHZ/zsAh8WMbyMR9vrB49lR5k0BQ3+p7egGPoPQ51uEebVc7u kRl3yOPu4V7uFVTpIJrn1ZOhUUb5kU7zGI7z8B55PMfy0cd9VBl/qM2TRZ/0fQ1JYd+FYAiGCEj3 dZpmfB/xRIaokV87fodAoppOieRNrd/0xMiq/QiO/FQbCNVQ0VogGNWTJFXK+UEtHEEBYImvARuX 5MAAVIEB7EARIFsDpkkYFMEU3Akf2J+R+Aj0RNAF3sgAdEGOFMmsbdsHiiAJFkGoRAIUqGAe5IER OAEdAMKvQAIdQEEdSEEi6JAN0v/cCgQBv9UBG9DBEnSBER7LCdQBqTgEJAmBIPwW/2jRQ/wKGJBB LCyB+1RKFpxAo3QBIHzAdQGABHRBHHXBZTECGCZXFERBHpiAE9RBEwDAALxcG5qLsOBkvkVSJF3E ReDXRKCCHZDCSQwSUBSdIb3ESxySSCDSev3BLqSBw+hCATBXHOFEEkySGWABJuqCJTQnIUBnEvCD dJpBBdSACpCWCrhBPdSAB8iMKWYCKrZSzaSFWPAMMKEBLO5dMM3iLtIiXtRF3+WFBeiiBZRAkHVA goyDXlCD0xxAS/mCZEwGetAH2kjZOxFDOUijMygoNK6T5r0GZFCG5Oiei/jDhWL/6D9o6IZqKIZe 6OhI1Hz4DUCFWZwFWuoZJOjp05+9oz3C4+zN46nVHp6p3kKNHnuMH4uWGZ4ln56R30DBR/KRiJfR R/M5X+sw2jppSIA8GjBkGqVJpDA4GqSR04Z42qfJ03UYWqn92UeOGYw8pYxEz0iSqfSsX095AUsS wZoGwpq6aZvCAbgl1f75QRgoAiS8EXH2Why9jwWRoAKmCf80oB+41w4kJR8giZFYj5heW4xM5VQy ihdAwk9p21V6m7fdSQK8gcUFVxCYgAnw4BvUgRGcQBaAJg0sBBg4QVPFXAvo0BfqYAJsEc3FwCG8 IM0VAAjkj/7wTxasQBSk28CF/0oCnIATYFcs+AEUcIHEncAUpAkoHARBrMAJmFAk0EEdmAC2ZMv8 hIEeuGGruovDUIQcgVevkasi4iEpnJceAsUs1EK/BEVuygRLzBco2MF9TcRNRMRNUMB+7RewEWdz WoIlQGfBZqJ08gMW0JYKaGcALIUHLIAoLIAHbMITbIHPsOIdaABZpGeJFUIJzCIaaEAJnNjR/AWK wdjfMQB9umd9ghPYHIA3gFo2OAYyZoPNukZmYN7OrlOUecZLUUZzHI6HXug1gAOHIm3SbuiH8l6I ut48lejtVQ6Kotk4rsc1tiiZ0ePWam3t0WNz5JnvIdrvNVQ78lM/nZmInFk5Iv9fj/qTN67eQbIO fzBao2nURm3Uk2rf72wURy2pRV7p6oTjRsqURxLfcpRp4p7kSNrIqxGJF7ypmxbJmnqbGgQQwEQh oe4AJBxEwuXXHEnBDXhBCCqCIQzloIaBAhhqtyEqU2YPJDxq40JqjTiKo1glknCbs43P+MjkvKng ZTpBJFzK8HIhHXxADMxKFMRlwDHECvAADy3BFIDmC+DlCpQQ87ZADjhrYLIJGJQhIMgCDThBGCxB CWLXb+EBHrDJEhQB/1TBWwLCqcRCGAzvDiYXIAgCaa5LHAYReLVmvobrd0USInCEGhhwv4jELAiA EmxELcQrAvPmbY4EJezCfUH/zHAGMHEGLHPpgn7p18CCMCFATCZO5yIoLNSpknVW7BCcnciAmCqa RXmuBXuip8iWgcjCHckazdEABt7lBUnd56URGQP0JzAsw9M8XjBMQmMoQz9aBmn4wpMVw9skpIFO o+ZZo+zlAtF66DUo7T+AQxgnbRhjaPH1aD4CDmQQjol66OxR7dMKTpj9Ge19bXLQsdd67TtyIzRA g9lExx/zWfIIrR733tumLXaw7TYC6aAZmjc+xuYdaX8oqYBAqUqtVNRIo5Uy2vdhWeuph9rmqOEa X6OOqeKa8klaT5oGFZu6qVARQRvE6fhcrumGAZrYKREgi+faxPvEwAuEYFCe/y4DEqoVRCDrwkGa BsmisN8F2S4cDNUHehu48a4aJMAHfAAjWAEUBAEV0QAdcCX/gUoYHMIHmID3FgAPqCBetgAYkJsT SK9w4RtByMIbGIFu2cr5AoAhLMENDMS7GYEJXIoZGdv5XgAerIFSxcIFtAIAussJGAIezO8bWIEn DC+mHMKp3ACt8G++uQu82BElkAJwiitO4KG92MEdaUS/rIQSnLQa2OYfqIFJ5KZJwHQF3+F9OUye Cssh7pdzNudPW0IaEOzBLoIJQ512usFViSIpMsXM0BJXeMXPkAXQiOzIfizJDlMxzV1dlEB9ykWC yGfTSA3UGB4wlMMBQNkDSP/on5kHaWReOy3ZO+0H5v2HfpxG1LqjcnCxPxjtFyMtOFwD0/aTiFpH iVJOGV/O5kDHcJCoHBtU7lVoHg/tm+UZdMTtH4fePmZHd5xaIXuj8BUOm4UONiIONiLfc5DIRPWN oiFpRnGNRP7ONlGpOqlN1gRufiyGevCN6RTaj36k6EClBh4KmZZy4qokULWyKgOV9xhV/tFpLaeJ AOyBFOT0HDmQFwCC/CVALZguUfqBIAgAMSfAswUJU07Ko/xUo8RaBm2QpYbgt/HukySAGiDVBygC GYRBJHxCE+aBpRgvI0hAGAAAFGRBqzBhGQbBB0RBQ0TBBki0EyxBHTgB8y7/BAV8wBIAkQgE4bxF AqDg2wpUs6nWKcoRNATgwQWEgRUEOIqfAM1FwQ5cHBtkEIBPCRkUARSk3AVkdLq84bn0a0XUER62 Qi1cAX7pwkXYwUnf15LH5h8ggLsigkUogR/Mwh9sREkoAZbrC315RJRXBHISAiImS0RwsL+C8EQI 7AgTNRacsHZKVQ1kggdQxROkgMjUeQrQUs74kljgsDANkw4bjVy0rMvCZ4qN9dX8Z9VQkzKERpd6 Ry+4UzxtHpPlhlxjVBVvXvjBHtbudRm/2Rn3zTeWTT8GZKBJjuqpqOmJmWTLo2R/qV5zsdbSqNiG Y2bfEyCz4y+w2YuMBy+c//pzdM74hU49DtTxzRlBhmiKFuiR4UeSStrXyDak+W1t90dC4gf4+U2I iB/ycOl7IEoGQk+jBvcFRo+1lTJKas/jBhVQPS4sy6n+CUAtR2H/7MANFKFEWDe2BQLkJmEtBPOx JWstrG7rmjf8mbeszRoHNckJ8AHDw/e3yfeT0DcA7cAUBHgsRIIJWAKwBsEbjEoBxMASvEEWgEEO VLP3JsLz0kBqIhwgXDQMMMIhRIKv/mAiGIEVyIq7gIERJAD1Ni8fLMFFP0ugBib/HOUHcIEfxIIE 5MBAFAAgQEEsWAEgREEXwMkaLJVSFQEHtJxGK4uPw0saIAIoUEIo1EIc/P/mfdnha0rEHdqBAwsA JQg1ItTCBdRCS2f5FVwBSeyLHp10lFMEKiRBB7uLuxiEv67AwP50c1bEUF9iEhQ1FnACCruAgjVC JkgCiKVAh21CnYMYeYqYWswwe2a1iQk6XMCFe9qnfAqGEQsI1UxTYtwH8TC6ZJCHGaMGONoTY5sG JPu+fchT64kGTUnOr7f13oBZL/Tx6UFUeVh2qpPjqm/xhYKDp8doPVqoPyTDhbpZ7/3TZes2rssx m2F/78FtcTjxrkOUGftZIg+U8qn2QWLZ3NJto3XUSo3TOOFtgGwIQBALVoygA4LFDDrwtbBXQ4cj ekEcMeJXxYq8fvHCqJH/I68YNwbECCmSpMiQA06mRKkSJaQBkGC2geSFZs2abXB6gcMHRIIdtYoI 8DN0KJQEUgoUoLBUipQcIGHOBLGjiB8AV7H6CWNIwgcDfPjACRSozVgvYwMBQgsI0BGwJ0DElTu3 Z88Ed9Xs2LNjhyK/itaseRPkBSEjVSWAEZFIVhAaiQq8cGIiUYscThjlaCGiRYsoWaxMYVTHUx0w mzlfdgImUaIcNLpEKdD6xgkjJz4AuHAh1m7fu/1MSbAkUqw1PCp7/oAp0qEPS8is0Q1AqyEFAi6k 4dxZRPfunZVS0JUmDSpUiECFInVJCQIEpAZQSJpU/tI0SmZd+JOmQBpS/7NqseO8P0ihRA1S/lDi CkoosWMXRFBJQ7zxyFuhgBYKWEFDDcUTzxJdLLEkDUIISSKJRRYxcREszFDBjQrqqUHGGgJwJYUh NpFkkxSeyCCELYAE0oYZhpxhhjGQ1AANNEoooYMO0NBAyimnfLKECRjIkgE5lgHmgC/BlEbMYKRB yIFJHmBoIh+Y0aiaXHjJRc5fHKpzoUkmWYihOiPywSIfoPGhzmf01LMXX57hk08/obHI0WYqahQa hxIltNBEe2k0I43k7DSXZDSqCKKGCi3VVEMdqqgZjZLp1J9WP01G1llB5TROT3FttVaMfhG0IUsL JfXQYYl1yM9N44TVH/85O6pI0YYoUpVVXT+FsyNeRR3h2IuQvRZbQJ89dCEHziSX3EkMKgaYdZ1x Zt134QWGmHkHqvcgc8011Jc6JYoo2os22rRbXlACKQaSRkrYpJMOZqmll2KCpA2bKMZpYjji8qmV oMIgiqsj5AuvKaeeOlgkL6aqirqVAQijCEX2iCsstNZqiy22jnALLroSqOsuu+5KQI29+OpLkT8U wWSwBIzIoog1/IDChCgSicIEHlbwLIg6ouDMCDpOKMC7AgBhQ4I6tnbiE7E3S+QEK4xoDQwT6DaC bhMAyQGMLHTj7arefANANCvWwIMNCjhbwYg3DCmiCEF6661v6gwJ44L/G1Dz7jsM6aOAvPIQoWS9 BJWoRQAlEAl5qQsp+O8CJVBJChUEZqHEc0r+aJASJZQo0A4HISRPlwlH1GW+4zOkQETySDwRRROd b9FFJl6swHoXashkkyeGuLHHDIS0ocgjj0wyySipTF8DK5ucAMsshaFmGWrABDMYb8TE30w00yxV W4Eh4othNCQbpNITnhCIp2BBS1OOAhhHVsWLVU3QWxWEIKR6NalfHYpQmNIUq3BlLYz4al+nMuGe UvWLCPKCWrSi1bRkJSdYhbBazfrFqBJ1Qn0JK4XIypUIRRWuiEhrWtXaFbYoMpH/OdCCoeIVNCYi RGGVUE/kCga8iLGu/ywKZF5cJMZBBoIvM/lCIeNSVL9uOJGMdGtgBEPYSha2EjnOcY5RicnEakKz sRCBLF4ggk4y1hcFVG4oLtvDACw0MkU65QaNBMkR9lCLjmGFOgKwAsxAABY4iGUtYPGkJ0+ws4zV ZZRAC9oeiNaXP/RFAm/gQRS+4AQBCAIAhngDHZBTgCA4IQ+VoYETeLAZMEhgCZrxzmes4IQ61IEO j5BC5ihggiDkYDFRoIERgpAAQEShBYkwguUu0DIokKEIfQuDBBhBODyEARCVSUQaFCGIMAjlN7uZ 3Cx0EwPOaI474LFPecyDCCpc4RLs4Z3paqGGCC1lKXZAgBKAIKEWrP8AEbUghYRQcQU1IGIXV6iF EhrkoF2YhzyeS4MuxqMLC2noQvShkIlQgQEsoCJFKGKR9NwgPRfBiEYL2MQQMjCEHoXgR+IrX/mQ lFQjLXWpYyAAAaTUgStpiQETKAQDhCEHaggjfsuYX5cOUI4vCSQY9xsTmYpRpoIopH/7aogylOgn H/ggigZEF54OUgwEonCIjmqiRiaIQUdBQ4MbNFWdHniraznLsDo8Fb8eOEN/vKpTLqQVDXG12Bs6 xLGHdWtfOSKnyS7rU6GikxD/FVpPycq0dOqXGv16LU/ZUFRQVKJEKHKsUdlpIcUo62/J+tuy5jWv CTEXug57RiXekLn/a2wiHaHbEpi8hLp2tK7F/MjHQGySk3ukGU96sgdFWMEQQtGKFRJwg85RYJGM vIFIIGmFMFCyklbYQRZkxgc9fpIPbPEkXeTys54NGGio3MEHjOYXCUytADx4mh/eQIZIRGIJVJMF HUyQtSgEIQhSWIwJ2PCCRIztBHRQZh2c8IguiO07XZiCEVjcGg2NOBExkADgwkAGOtDhDZEoghNO EAMT9CEwxewMBUBQlaFcpZ6/6Zt2vMOd7ayXPAHdBSWu8AeD1qIWCPiogJZSUUqwmDMFQEQoYpcG LD+IElwmBSI4CmfzRAilnzuphcCjIZV6rkSoSIKfT4SFm6qA0C0y/0OLXoS9Gi3AAzvikY+2YNSk TtpIJCDBFoia6RBYegYEGENUpdqkJlngfVmSHzWA8VVnhHWsYX1XOYAhVrKqta3Qiuu2HNgrzvoC gcSdhF4VqKcOVkpRxEZUZ/maqQdWS4Sh2i2yk/sQi3QkhrOSYawsSy3MWqsivto1tDfYi2OpNrPY kmK0OrJaEWJwt9Dqa7dmSC3a5tq5a3TgXNudLoJMYiDEvdda8eXYYtUVttN2bgWjK92oVJfhLrGj xfCoXe5uUo9o2Ul4xyuAMHTMEGc4AVJW0BT2tlcK70UZVaxCST8Ywr4906RYyhIIT/r3LZmcS88A 7DNKCG0ve0EwK/938Jgo1EEQa0BAFjbwBsGIeMNO0EwiPuGEF2zmBkvIwgqiXHUTL3MJJnimdyiQ ACck4AWymU1rXPOBNexGEEWwAhSUVgdHyGYFNJCmEWJwoUR8gQzTCZw97YmV3dwgypsDj1IoBFAI 2eEK67lEK7iMAAFwmRLmKR3hNUeBXexiKahg0IOuoIBaQCjOcybESZl3UuNNdEPJE095OLELThhg F2bghBkMUGhDq4B6PA1AJlyxAEY7OgOQjnSkhyQ+TGf6CU9ggaY3bWlOPxWqoH5SBywwDi1Rg/vL YHU5wL8uWLvLXbGm1xgXMkB/zXXaTez2qE6VpxM+g9iYUlRhxc3/xArCidmaPa24oA1VoCWxQKiy DBDbXGjbSsu0ni0ABTD/NoWGGFCKeqH9bmW1IIix/OW2LPACZ0uC6C22NuKv6OrZxIi4zMVM8qWM TIgCowgimKiNOGIlFs6OIMa6HA4HowK72kDiJq7itgsswmsHFIBjDAkSKMBCRm6RbqApQIIPEkAC hIK+/MCSdgDnZsbiAOGTthCUcg7nSGnA1CAB9uAK+GIJ/kIRgi4KZEHpAMAKaAAMNmAVwuAENMQR nIAGhKkOru7DnECfvGMFEsDEHqEO2IARAAHrvoMCjuADDmEJgsAE4jAKcsAEoEA3/OAMTCABOIwH cmAF0G5DQPHI/6ZgOiaHyQJP8LJjnzajFQ8vPD5nAMzDDrAMQUqHy3ARpDzqDzwsypIAFPiDAlBh F+yAo0qn8oZx84aRpBJPeDSEc5KnzghhEThBBWDhGlXAADjh9nKP95igBypA0X4vE4RPEjygElIg HYGq+XpEqNhxCOCRHZ8v04BE+khgBu7RSKiv+qREFVShA/6xBCxgIMehILWvIBnAGhLSGhiSGtpF XuZlrfZkiQzur1bl3oSIsEKwGVYIhjolWQwwTirIIuqKswAQ3OqkgWRL3WBlV7Kt2kLIhnjLAT+r AlUIhOQNBP/PJD/LAiXQtLyNX2zyWmaIWTjiT2JwJW1Fs5KIVP/w5SnLRSEUYlhQiCFq8tz8JQSf q+FwsLqmSwd3EOJohruAMBD4aCegcC8kwBAqRwAkAARiQD5IrilyoORioA1SZr6oEAok4Arzayz5 6y14YjABDLxMaQxRycCMpi92wAiuKRLWAAqWgDWiYArCIAE0LJvEpgBMwAm6oDtioA5gLMq6YJnq YDScIAhOQ3MSgQJiABBMAMU4LAjoACsMIQFiIwqoBu14E+0mChCgIBWbjDr8QBCGYjfSwBVdsczC 459k8TxosfEuARdx8Q/+oBYUYMw2Jw2o4AcooAWEkRgRQQ0Q4A8ihKNGChWwABGSAKXGw0ROqqUy xD1FJAmwoBr/VWAXVIAKYMEar1EImMAFsEcGZCAAxjH4JGEQGg0dvaf54FEdbwQe47H5WOAJ6NEe pW+p9nEf04cfVUED/vEf8WFECXIcrCF+2sVdykEgCmIi52pb9s8o/6ojOpIoZ/Qi763d+ISKaPKx HEJTOrIotY21WIWFXjIBbaiwepRP0I1TZGhXLMJOigW0nDQkj3KzmBS2yM1KdTIECZD/ZPQoR2gE NOiE5I8Fk01KKdDdbqvgCLAj6oi6HsYl5HROwTInsIuPKOYmvKAN0LIndkACriMMoGAKAEEKVoCh SK6RYgAS+GAPpDDlKKntusLlNGksNikwP8nmbI4wDTMBdg4v/8pwDxBMDdWwMWUhNk2gC2Shl1wj CJbAErqJBhxjM3LgETJMBDizDjBnbL4AxergA5aJB8gsyrrJmniANiPhKqKm61o1CkCxNzcEMmig FH/DKuqpkAhpNwZgO7y1Mw4PPP8pDWQREX7nQG7xo0ghyz4KFVyRAkCBCr6zAHQBFWhxd2ohQoaR Eh7kPCLkc/yMPzpDz4ZHRAgBC2ChFeIgDlpBBkIBFkIhFX7PQMcxEzKhAYQvDhTUAxoNB9Sxe24k ZCV0Qt3R+ehx0+oxQzuNQzUAqlzWZVtWA+ZhHv6xA/ChRBuyXVb0AFhUr85EAKGoV/Qvs6wlJr2F I1WI3sCFUv96IYeoskeh9gGVLbHizYiOCFSsjYaI9Ep38iQDELGWzYgASwOpclEiCwNNK1CEyCJW yGhb6/3+pY2Idt4qUEetMlx2aE3DRY34lt54BeEcZk4TjgZvUCZiYk9pAo8St0/L4uJ8QlArpwj2 AAkVtb0YdQBOTmXoCwAEAQHUEAu7K1M1NTA7lVN1jucUcwemgC/UUBZSVcQYwwi6ZgV4YAqmTmtG kzHqABKEaQlAgG06Awyc4BAeYWtEUxENbzuqBg8hc+WsgA76AMPyIFrPLhFWQDdXoBIN4Sqko2Uq JzCKEwqsgAygIBLm6wIGQDnBdX2h8Z/mzFwN5A8g76PU4Ar/eIfzuMMSNCo5OwN0QkcJdqHK+HXO 0nN4RkRC5nN4QEREMEAFWgEHxEd8ZiEDNmFhF9Y9NmETEKDRIiCDPdbR0jFkITRCJZQdTRj6iGoL 7JGp9HFDXbhlZ1ZEs0/7UNT8vMFn5U9PsuEqH8JP0u0jyc0DWyUDM4hpo/aIaXLgOtCynpS1agVr W4jZZKi1ZnKBvs2KqfQCh9i0fiXaKvCHn3RsfwH/niW1qrSyuHazJEJou2Xb5m2z0qiMbU1H17RN 7VhU0kgEZ7SOFk6OSsJkGoaPJUZxKSYQ+vSQD7kHL44KxAsoLCkLIAHkllCR3qtR4SABFKGcNpc6 ikAC9sBS/8Ni4kZ3lEs3Y6Bw54YGlT7g5xiTVb1uxLpAEiEjB7LABCgAMniAEbpgM4YuCzYzCKbA mLpjBUzgEE7sERIgBlCjM3qzaozgEi/AD6wgCOzmE/IAWs+um6w3CsDA7g4hDGIhnAWDEegmAe6G bnaJDiIBOVtxO9bXnZuTAm6AXAOKFklBCSDvD7KMFOzgOznDP5RgAC4EQ4QRFdSgFigB9ebMPP4s QpKiPO5sQ14vCQzABTggAy7gDjT6DtDgDiDABjIABzwAATx2glNAAFKg+FRapYFKEEZ2ZE04plEY SKJPZfVxZV2YZf0R+wYy+xKyhmWNGLzBG36tqM8k2PZl3P+8BUxdZbSc+gOxpWuPzYv1tqqxWIiU uoKK8toU8IcWEFvwj4ermiK2FIh5hYTCJWyhGoPIGLIGRkibzVHalFtW8iedSCvhdk3yOCLG+gX5 NoqaSwRl0FsA+Y9H4mAcKbErOY5y0I5o4gVqYiZ08Cx4wgB84gysoJMTID7ieWQudwCIAAQgVQA2 GQAEQAEwKZPC4gi4KzBzBi01FQj4QLYNEwRCdWiu4ApWmS/ESxF0M8hGjHZNAAxA8QU+gAYu5Faz QD5WIAgkYMX2zgp+1zsSAQyC4BC4zgmyIAcGGlwhw3pfwApiAQ+i+Qx4gLir950hw5o6ExPWQJzf YLh1kxL/wUBvaMAReMAJMIG8lfmdNcdYCdo+5hklzkMNDLx+1zV1WpECDgQVvjPA1eyjJMRz/tXO UMGAUYEQ5lUJV8AS9IAJGmAWbABJ7mAMNlqjl+QOxCcDBEGlI/jFQVqlv6f4NC1IhISFjeTTPi19 0OD6fJx9BPJK3oeruMRLDkAayuopH6CtBGiAlAGubkuu3jSEnHqycKXKsRzLr2HLuXzL/+HLwTzM xXzMybzMzfzM0TzN1XzN2bzN3fzN4TzO1xzLFXBG7dxLuaUD7dxJOyKxPwKx/5xRFfsjGEaOwFIH DT0qiIAIeIIMFUECamEHQOAGErWznbCRBuAIfOI6KCmc/64iDDz3k2WGtScODl574lj7tY8ACHIG CGRbtm/utnsuMa9ADXVTFg61NYw7CUDRaqZ7BTZAAni9AE7gDEBAQ1wsATQDNSjgBAxxCZZgChRh CrIAENC7NTLkBZYAnPxAAnATWn0zOZg5EaSgMd5gOqImC7rAQjIkB7pAb2IgCmJA7ZDTnffpvw2P cxhqwFEBCMz1d6hgo9LgBoRxPUAmZB7aDmqhFWJHKSb84ZlRFzQ8KVZqBdIAAyzaBk5841mho8sg xVUcxvEAxleaxn3kR2zcBm58fHJcA3Rcfarkx4PcfbREGObHS8hETPDlARxgyftngIbhyaM8yiOQ hqp82/+yPOm9/Br+gemdnunlPOqlfuqpvuqt/uqxPsvdeM+5vuu9XhGU4NGVANIVoRYgXQLKXsH+ Yuz/wuwl4O3f3u1rAQUkwAqsAO7xPu/N3gpqge8dpwgaB7VZd9rTcOxboRUgvQgQoLyMs2OMU54E oHGKoAjtnu/vvu8rv+4xv/Itn+/7nss8/++B4u9J/+8FoAim4AOm4O6D1Qo4QAFSP52K4Az2IJ0E AAGmQAvIQAA4QAKQQAI4AArOYJVRaQms4A2gAAocp3K2QgFCYwqgXxHIgJCq0O3e3gnYYAmQYAm0 QAuQoAmQAAmmQFChwBCKUwDQHwEkAPqnwAkkgA5QgO7/x1/J/EABdiD8m6AJeiD/mwAgYDUJdekS qT8IlShUUqtVrVooFCAoMrGIIYoIBAjw40dBw1YgaymYRVLBmVYNRCKQKICkIA4IYsaZOVMiB0EA 8EAYc2EnhDtAgwodMwYoUTxEk9rYkqFpiAxPo2bYEiLElqs2bMzQOqPrmBlENYgdI7as2A5oO5RQ W8LCBAZwhclZdqCutGDS8jrYu/eBL1/DAA9T1kuZshG9Rij2watxrseQI0ueDNmf5cuYM/u79o+z 586g/4keTbq06dOoU6tezbq169ewY8ueTbv2aMuUc+dqzLu379/AHUf2Dfl3lePHiShfrtwL8+Zt nhNB/079+JHqyZFLn15le3Mvzp0zx159efLt4sV7z959ufgq1+EfOQKkPpDu4LmD30/kyA8gP/wQ 33zx/QDCgQgiaCAIR3DHXXvUESjhhBICMZ+FFM6H3HUTYkihhQDSF+CIARIIn3wcYuCffSQGmGCC doAQowE0UmEAFVQIQQUoOCagQgI4UqECKKCEYmQPTfQAihBEgtIDLEiG0sRAWlSpRSpYytBKRHE0 0IACcUQQQUwReMABBzjgIIggKXCwiQebxJnCnHMOMcQTT2SQZ1VWbbFVV4ASQJSgBGhQaFlppVXC om8xINcydNWFF155SdOXAw/45ZcvygwzTGKL/RLcbv/B8bIbZZqlihlon7V6DWe2xSrrrLTWauut tl6m267DmfobqcINd6qpwhIb2XTIaiddeESkN16y5FHn3XPtTbtdtNEi6x1/03bnbbXKRUjheeHt B4lzBI44YIQGLniguz9866C4GdZrr4T0Xnivfy2SaCKKH/ab4Igv0miwASDcCGSPON5oY4579IDk HkwKYXHFSu4x5ZShIIFElVimAsMZZ6CAQgNcKqCAlzOJ6QEOKeDgwcxwxrkJzHUOoefOfGLFFaBA g3WoWYkuWsIEjTIgR11M20WppZby5cBfgBV22Ag+/KL11lzzIiovzPzqa26qZvZqq6ymjevabLft 9tv/cIumGa+UGWtsccI+RuzYeg/rt6nkOTiteuE+iG121hb+3H75SXe4tIk3K7njiJ9nnrgeNlgu 4/lJKOCGoFtH8IIChvttvvum69+9qNsroIj9vq7hvv8RDEK78L6YMMIP33iwwTleLEQCOqog/JIW O7lxEx6DjCUM0J8RQAAobJkJCtdjz3LLYYY5s81y0mlnnnlCVdVVWAXdFQGFkkU0W4zCBddckDZ9 V6V4ORD11FUrthjW/vNB1romKmOI7VS6KVtm0oY2z8AqbhCMoAQn+LZUTUZXdMugBvvGwWxFznEP wtfhPuieZuWncdB6HLjQMzlqPShZ1NrQuEzIuQE4/wdFJcIWd8aFuOnExzqp69C+ZBhEz/GLRJkb l+dq5yISKShBv/OdjWi0uyARb2FBogKQLrYkIkkMSRvr2MeuJDKRBYBk05NeK6jXikxkYnveK1OZ vicnnNmpKXvqGfpIQAL1EcosGkCL0ZI2P2HUr2nACIYiKcUXvwyGMFbznyQFOMCt8cKAYfMNMnil QLMx8JMPpKAoR0nKUramk7jZoCo1CDjsGG6F1yLPv1zpLdO5cnHlGo8KIbetFuoycNiaj+ySYy7O 4fBzuyzP44IooNoRKIn/GiLAnjk62WnIOkSk5uhup7tuUmF3CQunFBOARSAZAEjGGx7ykqcxMIqx Y/9Wet7IYCAD6U0vAG002RtpEoEwuexN4ZuTIOx0JzztCSpUwQoJfgaWGWjAfWeB39EKIb/5yYEa kJKDMOyil7xk6i+bEsynCIOYAFKykgb8FTKChSpUbgaUoDzbq0xJ05raNIIu9ccqI5PKnebica+0 XFDzJR9gnk47K2TWL5P5rMQlU5bC9FB7OMef1f1ndtd8arTs5aHXYag+zczQNIvYzH5NqDocmlAT 18rNglWRijFCUI0UZkUpavGKyeviF5eHBDGOMWRlnOc9p4e9kzWAJnHchJtuRqc6DZR8eDIf+rbQ R6CNoX1lQYMgjQYXQspvLhh1mjQyJTVMTc2RnbL/2tUWI8CulcoxptqkZHK6mQbC1FU3za1ud0sr y5DGgrlQVXCDi8oNDrVyMITQcXlIy1o6d1k0JNxxpWU5oV5ruod7poS+Q1V0qe6HOrzcLotoRHuN 9axAFCbs1HXN9qY3Xdu8He5c5NZwFgxhUfwdw3RUMSFkYUkRW96U+qqFMVqJjPSs52Ct56XD8tMD EQAfzhqrs8hG1ip9WiigLgtRsWjWaCAeZEUPeQD8VcpSpMUUYAQTSZNWUlS/MEYmf7PSatyNp7S9 zG1hytse+/jHssmxkDGTmxTWslvsQatYs2XdwTWOcExV3AdHaMtsXpO7nPMhepu7wqNulbzmxWaY /7FzoQCFaJZkVisT+TDfdrX1QJzo5oEMBk78ztVh6MwR8ZLHpB5EDIwc45jHmnelKsng0IOdnhtZ 5uB+lgl8NqPw+PCkxy3YoLJeIQtENavZojHqLXOZS9NEq0ioXWpTnmoxaymptawZ49WlWmkCh1zb HX8GyLjOta5/S+shT0ZeztWqlUWowya7B4XS9bIHjR3DEX5ZhNGlahWSyOQmqxDMqTvvlqdpZmI/ +0Jg/QGbnShf+soZinKdUZ3nmmf+JgB5XQRFgPmKBOaJ0UouEFk9ZZDoNr7RwTSZ2RwjLb4UTHpP kw0ahzuMqE6zpVFyiPgy6DfqAzwtaiFlsapN+v+L1hrjF8woII0dI9vZ0tq2KA/lrlfOcpv22h// 0LFLIyPsZG4ZvFFmjnTnpULzOLXm74V2tPMjH2sWNXDNhip5X2dNbANRhiM6c1aVrOYWlfvqL3Kz u8C57nBOsWE4+tEW381nJ31RYwIeSF/H6IIrHRrR0/O39rbXTwjTLKAGN3iFndInrfyMww8NPKI2 W4LPVpR+dIlUiZ92KV9oylOGIenGKznASwZH1rMeMspj2vLOe36UQ2YNzGM+t8cAvXJUx5e3lelz WCa957ys8umHrZ0sv0dfzKXuUoOeOtkxHdtFDPcwX3kv4Zc7vgPD+pzlunxx3jnsVgQF8Zb0XyHq ROzPaW9CBTxWgVC0ve1agPuC3/jvBTwYoODLe4UN2ieFqu8rYfGwRAsxgcJXVH6GhJTiT6yXB5g2 pJ6SaoXRC4nhA1hzUh+XUsQBGdWQCw14Qb3mGb6Vcqyicp93gRhYKzkWZERmerOHXUBHQs/yVDBk LbOHXiXkS+cVXpSTXcBnXtL0Q+lCbS5YdUwEIPPVVlZ3bgizfMDjMHRFTj8iPEziJNgHaPSGBC7w V+KnaNfTYI0GYZC2CY1VPk9QaVlhWfGXWZt1fxYVaorHeHxBNVTzKQQIKqGiNcChQZ2UgW74hm5I W7MxNwEBADs= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/Images/Repeating.jpg /9j/4AAQSkZJRgABAQEAvwC/AAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAGQAAgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDU0231 b7RdeY07fuHxufvxRWXplwPPu/8Ar3f+lFeweePsJg01xi2iXEBPy556UVcsNSlaa4U+XxAW/wBW PairAr2VxYrcXBSWU/uDncB04orjrLxBZ+ZNiJl/dHP7z6UVQHktt4iMZlPnxNmMr8r0V5nDcN8+ 2X+A9jRXH7Q6OQ+iLH9mHVWaYPp8y4iJG6M8miv1Mj+F8Ks+VLcY60VxcxvY9E2r/dop396iszQN zYoo4+brRQAbhhuKKNvy9RRQAcbW5oo5w3ymigB207Wopq/dNFADt3DcUU0McNzRQADGGooVvlbi igAVflbmigY2tzRQQAU7WopyqdrUUANX7pooVuGooLAMdrc0UDG1uKKCAVvlbiihejc0UAAxhqKA p2tRQA4LwelFNX7pooLHbvlaimhjtaigAGNrcUUqtweBRQAgUbW5ooGNrdaKCACna1FKq8HkUUFi L900U4Z2tRQA0Z2tzRQMbW4ooA//2Q== ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-Location: file:///D:/InternetDev/Vertebrae/Images/Vertibrea+Main+Back+web+copy640.jpg /9j/4AAQSkZJRgABAQEAvwC/AAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCAGQAoADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDftNNc afeL9qtTu2dJhgfNSHS3/sry/tFt/r87vOGPu+tV7KQHTb3/AIB/6FTmlA0X/t4/9lrv1OYV9Kk/ szYLq1/1+f8AXDH3abNpUhs7ZftFsNu/kzDB57VC0w/srP8A03/9lplzcAWFp/wP+dGoy/Ppr/YL RftNt8ofrMMdaTUbGRjB+/t12wqOZQM1TubgHT7Pns//AKFUt/uc2+Of3CUtQLc2nvI1v/pFvxCo /wBaOa1722trPfd3kuE44RWdug7AHH41R0/Trm+vrK2t490jxIoz0HXk+1eteFtHjtrJo9bt12ag ghuUznyTn5CCPfv6kHoDWU52RcY3PIm8W6PLq/8Ax6TJDvGJXYZH1UZ4/X2q7dW9s7peKwETtvV1 O5SM9iK1vHPg9dG1EwXlrHcW8mTBOUxuHoSOhFczFeW3h+K5e1ZpYYI2uJ7ZzujAHc/3SeBx7dax VSRbgisLG8lvZrmxsL28ijLFmhhOOc+uKq6Ro/iF1a9l0a5igjyGYsvAIIBIzmvVfhb458M+JrBr GznFlfOrE2UxAbkfwno34c+1acWmMNLv4CvLRHH4VftWTyI8PtI1Qzobu23eWVIEoyp46jtUtpbO FlPnwHMR5Eg9q9Ai0WIl5GtYmkx98xgn86r+PvCGl6Zo41zToJIJboKksSsfLBKkkhegyRzVqpdi cbHDw27i2mXzoTuK8hxxyafHbuLaUGaHkr/y0HvVFGeO2myO6/1qE3e23lGe6/1rXUg0zE32UL5s X3yc7+OlT2mj6pfWheytJ7lFcgtChcA4HGQOtYK3g+zgZ/jP8q7X4OeOz4e8UR6VOy/ZNTcR/N0E o+7+fI+pFEm4q4JJswLq1uIGEE48mWPIZJPlIOfQ1BJG+xPnTjP8VekftD6V9l1Sx8R26f6Ner5M zAcCQDKk/Vf/AECvLJLpdq8+tEJcyuDVmW2DHb868KB1qe0sr69lMdlbTXTqu4rChcgeuB2rM+0g 457CvY/BlxF4C+E974uuwi3d+N0Afsgzs/A/M30IonPkVwjG7PL762vLOfyryCa3kI3BJUKNj1wa iDtuzn9ayU8WX3irUp9Uv5mlmlPLN6DgD2GKuxuzOFUFmJwABkmqjqhPRlk59aaWPrVo6RrnleYN G1LZjO77K+MfXFZkkjK5R1KsOCCMEU9xDnLetM+b1NHmA0bhTAcN1BZhSBhims1AEgc+tOEh9a9Q /ZxgtbrUNbS5toZ9kUJUSIGxkv61w/xFmz8RNZtmgjgaOZR5cYwqjYpHT2qFO8uUrl0uZIlPrQZW 9aiIx3ozVkkhlb1pBM1Pt7a4upPLtoJZnP8ADGhY/kKnutF1i2jMtxpV/Cg6tJbuo/MikBCs59ae J+OtUxmm3DFIWYHoKdgOy1jwV4l0vQm1u9tI0slVHLidScOQF4Bz1YVy/mE969e+O93c2/wfspYm fyvJtjIB05aMDP5141pEN5foq2lrPcvjJWKMufyFZUpuS1KnG2xOxJ71E4PrVm8sdQsQDe2F1ag9 DNCyZ/MVUaUVsiSNs005pWkFN3g0CEIakDEHrSlxUbMKAHO59aj3NnrU1raXt4cWlpcXBzj91GW/ kKtyeH9fjQvJoepoo6lrRwB+lF0OxnbyO9PDk96gkDI5V1KsOoIwRSo1AicFvU07LepqIMKsWltd 3snl2drPcuOqxRlz+QpMZHubHU/nS739T+dWLzStWs4/NvNLvrdP70tu6D8yKzmkFG4FrzJMDBb8 6lSSXj5m/Os4yjFHnjjmiwGwZZsLhn6etK0k+7hn/Osnz8457U4y/N1pWHc2GmuDLkM+OO9OMtz5 vDSY3f3qyHl/eflSecfN6/xUrDubIlujck5k27j/ABcYpkEt2sylmlxnnLVmrLm5zn+I0ts2Zl+t Kw7l+B70s2Wl+6cfNU1u16N+5peUIHzd6zbY/M3+4f5VNbt9/wD3DRYC4hvvJlyZc4GPm96bG96I pQWl3EDHz+9UlbEMv0H86jjc+TNz2H86LCNMNffZSN0u7f8A3ucYoD3v2fbul3b8/e7YrM3n7If9 8fyNHmEWn/bT+lFgNd2vfs8WGl3c5+bmmyPfGCJQ0u4Zz81ZUkp+zxDP96nSS/6NDz03UWA07gXx Ee0y/cGcN3plwL4lNrTcIAfm71nzzf6r/rmP6065kz5fP/LMUWA0boXvntsMoXthvallS9a8BVpS mV/i47Vm3cn+kP8Ah/KpZZv9OBz/ABL/AEosBd2Xy3RO6bbv/vcYzTokvjeZJmKbj1bjvWaZ/wDT ev8Ay0/rU1vL/px/3m/rQBcs479bhWdptvOcsfSktotQxLuMx/dnGW71VspcXSc+v8jTbST/AF3/ AFyagCxZx6j5s28zH902Mt34os49R82beZj+6bGW78VTspB5s/8A1xb+lFlIPNn/AOuLf0oEb1pd 3/2C6ZohuXZt/cj19Mc02S9vv7JJ8td3n4/1I6bfTFQW+oXp068Y3UxI2YO88fNUEuoXn9kF/tMu /wA/G7cc429KdguPe+vv7O3+Wu7zsf6kdMemKhu9QvhZ25Ea5O7P7kev0qs+oXp0zd9qmz5+M7z/ AHagu728+x2zC5lBbdk7uvNOwjRW8vTbWpCLlt2f3Q9fTHFdFazS+ZCrRFyIULbYl4znHX6GuSF9 dLaWhNxJkh8/Meea7Lw5eOrhhFHcSSIh+dirDjHB6fmO/Ws6jaWhUEm9TorTxFJoBUrY3y+Yi7gs URDYzx973qXUvitaNG0Mmg3e0jB3sEz+HNZ2oa3pEJ+x6yGtC4zsnXGfcH+orJl8naZdNv4dQsyQ N6MH2E9Fcdj/ADrjbbN0rG7f/FbTNV8NvouqaJd3O4FVmW4UOv8AdbOPvD1714uPGWky6NeaBGks F/PdkXbzY2vEn3EU+7fMfoKXx945ttPv/sOl6Rp926rmWclgEfJBXAxyK8xuJra9vZbq8T95M5dv KbABPoKQzvZbfS4NlxPdR2hB3K0auzj3wo4/OvXfC3jPxBZ/Dm51uPUZdRtbe7jtA19ZhZGDDnB3 ZYDjrzzXgWi31rZwmSXUJGtV4CyfMc+g716H4MttR8ReEbzXdGhnnsbC5MNxEuS0ZKht+z+6c9fa gDv9P+JmrSlSrWckYOTEsXl/gcGrmp+ObPWLeO1v7ee1SMZ2oRIm717Hp7GvLiUYhiq57MOD+lWI J2ZsNl8DjPWmm0Kx20mnW9/bSvp88U2MEqFww+qkZrk9Y0+6t0kynII/hqS2vGjdXjkZGU5BBwR9 COla/wDbH2m2aK/zIMf60feX6+o/X61vCr3IcOxwE888Scj+L+7WZq8072yzRMyTxOHjdRgqw5BH vmuk8TWrQM2GP3jzmuccsYypY8n1rpVpIyeh9OeGLyD4q/BRoCVW9kgwM/8ALK5T+Q3D8VPvXzjJ cTxs0M6NHNGxSRGHKsDgg12X7MnilvD3jibw9dShbTUwZYcngTKOQPqoz/wAetXv2jfDJ0Px1/a1 qm2x1lTMCB8qzDG8fjw3uWPpWNL3ZuJpPWNznPAWk3Hijxbp+iRZC3Eg85h1SMcu34KDj3xW7+19 4tja7svBWlsEhgUI6J0UDGR/Jfzrq/gbZQ+FfAusfEDUQFeWNoLLd3VTyR9XGP8AgBr5svdQn8Ve M73W52LrJKfLJ/ug8fn1/GlP36luwR92Nz0L4OeFbrxFrFrotmfL3KZJ5cZEUYxlsd+oA9yK9C+J nxH0n4W3p8L+DNLt49QiQfadQuEEkrH0Hr368egq5+yUsC3niWZsGaGG3VBkZ2kyFsfiq1ynxF8W /CSX4hat/wAJL8O7291lZVW4n/tGaINhF2kKHwBt29AKVSV5cvQIrS5zCfHr4hLdfaBrEjjOdjQp s/LbXtPwx8Q6P8bvDN9a69psMWrWAVXuYVCum4HawPpweOnHSvKh4w+CKjA+Gdzj/sLTf/FU23+M fgrwT9ruPAfgh9KuryMRzSyX0k2QDkYVmIFTJdUil5lfWLaXSdZvNLuGUy2kzRMV6Ng9R7Ec/jXv 3wO1W2sPhO2o3blYILmYuR16ivlf/hJ5fEutXerSgq1yVYjGOQoB/lX0T8IlWf4B3ayDKm6mB/76 FaVnemmRBWlY4H/hZ/gPwpB5Xhrw/HrN6h+a/wBTIIJ/2UGcfhj6ms/UP2i/EWo2k+nSWOlpbTxt EyxwtwCMcZJrxrw9pazWyvKxIxW2uk2i4IUZoVK+rDntofTvwI+Jus+NBqOnyWlrHHpVrGVdc5bO QOP+A15z4r/aC8a6V4r1HSIxZRpay7But9xIwCO49a3f2R4Y4tS8VBB1tYP5yV4749toZvibr5kX J+0j/wBAWs1TvUcSub3bnU6v8Z/EniyzOmarLbtblw22KAJyOldp8HvCEXip7nV9VZ49Gsf9bs4M zgZKAjkADBJ68gDrkeJxWkEL7kUA19U/Be9g0z4C22oxWxumY3DzRJyzMJXXHHOdqj9K1n+7hoTH 3panlfjH473Wn3s2j+CrK00bT4HMa+XCrSPjjJJ4B/M+9Yek/H7xzYXSzT35vYs/NHPEpBH1ABFQ WHi/4EEeZF8Mb3J/ibV5+fwMhq5J40+CBUhvhndEf9hab/4usklbYq77nr+safonxE+GKeOdIso7 LUPJaU+WMCYoSHRgOpyCAeuRjOK8PurpGtWIIwRVm4+PGk6Joy+GPCHhptI0gyM5ja4edssfm5ck /hXD6ffvNpmWJztrWi3qmTO259Y/FjX/AA9ovwjsV8S6fJf2E8FsXhSQpuKGN1BI5ALKorxLUP2h 9dtoEtfDGm6VollGMJDBbBuPfPGfwr0P9pmJZvgTYAjk29pg+nzxV84adpVsturOASRWVKHMVOVj 3L4T/H+91/xBB4c8XW1pcxXzeUj+SFBJ6KR0OfQjmp/jt4StPC+p2upaUvl6df5HlZyIpBzgZ/hI 5A7YPbFeH22nrDrOn3VmpFxFdRPFtHO4OCMY96+jP2t76G18PWFvuAfz42UZ6H5h/LNXZ05rzFfm icP8Gbn/AIuloSZ+9M4/8hvXpHx38T+A9O16wPiZby+uLONxHYwsEWUsVOWbrgY7eteQfA+bzPi1 4b56zv8A+inqX9r6yE3xH04pkFopNx9eVp1f4isKHwl64/aKudMYweHPDGiaZbDhVSMliPcjAJ/C ub1r4i3njHWIdZ1OKETRRrGyxJtUhWLf1rjLbRLYIN4BNdR4B8G3XiXX4ND0lUEsuWeR/uxIOrH2 H6kgVUafK+YTlfQ6XxR+0Z4ve8eHSBZ6bajhEjtwzAfVs/pWNZ/H74hwTCVtWMwzyskEZU/pXa+L ND+DHwynWz1uyvPFOthcyRmYxRofopAH0O6ucf4u+BrclbD4U+GdnQfaYllOPxWsbReyNLvqz2Pw PquifGj4b3Wpa1p9vBfWrtbvcRriSKQKGDA9cYYHHQ8jtXgMzGG4lgcjfFI0bY6ZBwa97+DfjK28 Y+A9budL8NaboVvbTeU6WSKiu2xTnAA7ECvmx7h21fU9x6Xk3/oZq6Dd3EmotEz2T4R+CrDU9Luv FviUSHRrPdsgXg3DL1zjnaOnue4ANcl4p/aE1oTvYeEbaz0TTIyVijt4FLEDuSRgfgK9r03UdN0X 9nOzubmwe/sG0lmuoImIZ1ZWaQAqQQeW5BBB75rwWx8VfAfYHi+F94PdtYn/AKuahy5pO47WQ7w9 +0T42028R9SuF1K0LfvIpolyV74IAr1T4qeGtD8RfDmD4i+HbWOzme3S6ljjG1Jomxk4HAYdc8ZA OcnFeZS+LPgc6EN8Mbkj0/teb/4uqWv/ABxtT4bXwX4e0E6VoaQPBHD5rTEK27gsxJPLHvR8LTig 3VmYf2gkAg05ZSTWfphaS2Rj1xWlDETjiu0wJ0k6ZxT5JDjKgbh096aIyMYp2GBosO46O5WQ5CgH jIqQSfP90dapyo8cwdeM+1W4XLnsDnkYoC5YicGbGwdasWrL5q/u161WRnEuOOvpUkEz+YAcflSa C5agZcn92o+U9KcjowceWgOw81VjuZAW6fdPYU2O7kJbOPuntS5QuTQXKNHIrxIHXGR681LE6GKT 90nQevrWbNPKY3lUjIx296msr6R4nDbQwAxwOeaLDuXcr9mJ8pPv9PwpCV+zZ8mP7/Tn0pVuZPsx Py53/wB0elBuJPs+75c78fdHpRYLkchAijPkxnOePSiUj7PH+5jIOfWpGuZPKj+73/hFSmZ/IjPy 5Of4RSsFzOkk8uRI5IkPyAqTnpVmZwNn7mM/IPWpdQ3MkZG3IQH7oqE3jqERtvKDkqKWoXC6kAmY eTGfc5pZpB9rA8lOo559qkuZpBOwG3/vkelSSSOLoL8uMj+Ee1MCsrj7VjyY/v8AXn1qxbyA3ePJ jHzHnmkMri6K/Ljfj7o9antp5PtePlxk/wAIpWC4y0cG4X9xGOvPPpTbdwfM/cRjEZPGeas2txI0 6qduOf4R6UlvcSHzfucRk/cFAFS1cGSXEEYxETxnnpRauDJLiCMYiJ4zz0qe1uZDJKDs4iJ+4Pai 1uZDJKDs4iJ+4PagCWC9042V1ttZAnybgZeTzx2pj3emHSz/AKLLt8/p5vfb9K56DWYzZ3P+h24x t4weefrSjV4jp+77JBt83G3Bx061ehNma8lxp39nZFrJs87p5vOcVXurvTfslvm0lI+bH73pz9Ko vq8J07P2O3/13Tn0qB79JIYMWkBB3YGDxzSugsbBms3tbbFtJtO7aPM5HP0rrvDUO+4t9kL/AHFx 81Yvh2z+2RWv+hxc54weOa9t8BeFYZIo7y8gVbVVAVMczEf+yD9fp1wqzSNYROY8TTWE0CWGqWyf ZjGGBmi3NIMdY88Af7XPsO9Zum/DS6twuv8Ahi5TT3lAxp93l4riL0c9RnqPTrxXsvi5tGFpANat oJE8wGAOmcMOc8dq4fxD8SPDNm729tq9nNcjhju+VD/U+1chsfOXx18G6npPxJ1s22lzmzuWW4iM S7lG9ASAR6HIrhNN8OXJ2y6hDNEnaMqQT9fSvoa61vVfGXxIsNO068tby1j0x5JnUYYMr4G4+nzC u40fw54fhvPK1rU4ZJF+9H91M/3dx4z7EigD5cGmTXyizsbGSYKOEjjJA+tez/s6XNz8PrK/FzZG 6ttUkSSRInGYSoI47HIPI9q2vHl19ktp4LO0S1mum8qOGJAu1e/T27+9edarNdeHbOJoLlo7yduF U5VVHXI70AS/ESWO18capOlrJHpF1P5trMI9qoGAJUjtg5FZc8yWkQuOZEPA2nrmtTTvHe5PJ1jT I7iNuGaE4J+qng1LNF4F1S32WuqzaYzNu8lk4B9geB+BoAxLXU7W7mSGFnEzsFVCvJJ7V0ulaHqN zdCKWPyY9rs7FhwqqSePXAqPw54It/7Xt9St9VWW3gfcWePG444xg812d9a/YdPOoecxQsyZIwGw ATj6ErQB5142lhicxDLBflyT6CuMMyEE44z61a8XasJLt+h+Y1iQXSFM4HWu2nLQwkia9uJ7O4td TsWMd1aSrNE3oynI/lX1LqcmjfFf4Q2giv7W2v2VLi1M7geXIvDKc+29T+favliSdHj2kDkVzmq3 +uWcQtdPv54rYMXEaHABPWpqrVNDg+jPoT9qTxdpul+E9M8BeGrpJIYo1hYxsDwBg5I4Jx39Wrx3 wzZrbWS/LyRXKaQl7e3qT6hK8pXoWrtY7iNIwoxwKKKtqwm7nSeAvHUvgLxWNSYE2Nynk3IHOBnI bHfB/QmvRfiR4H8P/GF4PFvgvUbJNb8lY7qyeQKLhR91lP8AeHT0IxyMc+G6l5V3AyNjkVzEL6vo d0ZdLvbiAZyPLciipF83Mgi9LM9Huvgx45t5jE/hfUmYd44/MX81yK19G/Z68VXuJ9ZWz0KyGC89 9OowPZVJOfY4+tcRafF74i2sAgj8T6qqgYAE5rE1jxf4o1yXdqOqX10Sf+Ws7N/M1PNJjsjqtT0e x0HXb/TNPuxeW9tO0UdwBjzQDgNjtmvoD4PX1pbfASdbi5iiZ7yYKrMAT8wr5i0maURZmYlj6mq2 s65r0UMNlZ6hNHaxOXWNQMAk8npzV1FzQshRdmXvDhP9np9K0txrK0NhFZKjdcVdadfWtYvQho9W /Zs8WaZ4d8W6nZ6pKsSajbII2J6sjHj8mJ/CnfFf4X+IJvHF74i8MWMms6PqQSVJLUh2jfaqspUc 9RnOOh9jXiWtq08QaJykinKspwQfUGm6F8QPHegMY7HxBqEK/wCxKRWErqfMi1Zxsz0HWPBHivR9 IbVtV0O6srNXCGSfCHceANpOf0rpPgb8VrbwjNJ4b10j+z5ZjJA79AW+8v58j6n2rym78feK/EB8 nWdXvb2MkErNIWGR9aqavax3tvz97FU7zjZgvdeh7H48+Bi6tqd14i+HU9tqml3jmc2aSqstszHL KAcArnoOo6YOMnil+DPjh5xCvhbVN2cZMWF/76PH61wWka54o8Oyg6bqt7AF+7slIxXRy/F/4jyQ eS/ifVtuMECcioTktBtJnbJ+z9qGn6Tc6v4s1Ow0VILeSWO3aVZJ5mVSVUAHaMnAzkkelcLHCsNo UXpiueudb13VLvzry8up2J5aWQsf1railItNrfexWtNvW5Mj6z+KmgN4y+D1roWkXVo+sG0tWt7d 51TftaJmGSeDtU4968Kb4ZeP7MCCbwpqRdeD5SCRf++lJH615NrfiHxTcams51a7/d4CFG24A6Yx iuisfjB8RtPtVtofEupKijAHmk4/OsoOUNipWke1eAPhlc6HfQeK/iA0GjaVp7i4WGaVTJO6nKja CcDIzg8nGMYOa8t+N/xFb4geOcWWRp1u+Yx64GB+hP51wniXxd4o8Ty7tV1S9vGPeaUtS6BZLbfv H+8aaTnK8g0Ssj1n4FMsfxZ8NF2CqJnyScAfunrW/alvLa7+IunPazxzKsUoJQ5AOVryxtTvLF0v NOnaC5iB2SKASuQQevsTWJYXuqXl+JdSuZJypJUvjIz1/lVyV6iZKfu2OwVuBXoPwB8XaZ4V8dyv qpVI7yza3jkJxh96MBn3Cn8QK8xW6THJqhrQS6tyoOD2rSfvRaJjo7ntPx5+EuteKfFKeMPCA/tn TbuEefHC4MsMgJz8uckEEdOc5yOmeO0f4IeNL2ZYv+Edu4B/FJc4hRR6ksR+lee6H478b+GpNuna 7fQqOAVkOcf1rR1T4n+ONbh8jUNf1K4Q/wADTnb+Qrmi5RVjV2Z9UfC3QNI+HHgDVtHuvEml3l7d ymeWO3lBETFFXbnqemckD6V80Lh9V1Qqcg3cxBH++a42S/16PP2e7liV23MB3NdH4fkkEBedsyOS zE9yetXSTUm2TPVHs/wR+K+m6XYjwZ4pCG0UskJkGVeNiSV57gk8eh9qxfFXwBu1updR8DzRa5ok rb4VimXzoVPO1gSM46ZHJ7gV5Z4g0+O9Tcv3h0NUdI8T+LPDkg/s/V76AL02TMKUouMroaaaszv7 f4MeNZ5vKTwzqQb1ePYv5tgVr6j8DJfD3h+71nxNqun2FxDEXgsEkEk0rdgcHAHuM9O1cJdfF74i XMBgl8T6syEYIE7DP5Vzy6trOoXnnXVzPKzHlpHLE/iaLybFZHb2kSRxhFxitG3C1ztpebYlDHmr sWoKO9dNzOxvYShlQmshdQU96cb9fWi4rGq6Rt8pquoVJOpDA1SOoLnk/rUc18hbcPx5pNjsb0DR SP1IbPSnxrEJFOW61z8OoIJAcnIPrViLVImIHRvrQpBY1B5IJwW+6aZGIct8zfdPassalDk8Hoe9 JHqMPzYB+6e9O4rGvEsBjcFmwQM8VEscCCQb3xxzj3rOTU4BG/ynHH8VDalA0LkKeMfxdeaGwN62 ktmt9rM/3uuOvFSsLb7P998b/T2rmF1S38jhWxu/ve1WItYgaDayt97+97UrjsbjG3EceXfHOOKl MlqLePLvjnHArCk1G38mP5Gxzj5qjl1KDyk+Q45x81O4rHQzz23ybncfIMcVS1A2quh3vgoMcVjz 6lB8mUb7g/iqO51GFlVWQ/dGPm6UtBm6tzbecVldx74FXpZLX7UPnfORxge1cXPqMQmYFGz/AL1W o9WiFyFdWJyOd1F0FjqBJa/acl5M7/Qdc1LFJai64eQtk8YFc3/aUH2g/u2zv67vepYtSg+0/cbO TzuouhWN+1ktPtC4kkJ57D0otpLX95teQ/uzngdKwLbUrfz12xsDzyW9qW21G1xJhGHyHPzUAbdt JaCWUrJIf3RzkDpxRbSWgllKySH90c5A6cVhW2oW2+TEbD92c/P9KLbULbfJiNh+7Ofn+lAzjk1G 3FvMouwQ23J2Hjmganbiy2/bBjzM52H0rjFuE8qQAy44zwPWmidTDjMu3f6d8Vz85pynbxX8UlsI xdceZnOw+ldZ4ZsBe/ZwJtwBP8B55rzvw1ElwUX97jf3Fe3+Brjw7o91Yw6vdtbpI2HkC58tffHT Pr2zn6zKZSier/DbwnCbWO7vRiyhyDnjzW/uj2Hc/h647u+1F2xBb/u0AxwMYA7Adqz7nULC20uK 4SaFbJUAg8psoV7bcda4/wAQ+JLeK3kjnl8lW4lwfmx/c/x9OnXOMG7miVjmf2hvGV1d6vZ6Fpl5 HFALJZZZo23Fy/VQR06V4y2lCTiW8uSD2QhP5DNdN4tfStT1ea+XVNhfhYzFwo9Mg+9YjX+n2XzX F0k6r/CuQW9jSA3vAFl/wj8l3qFrcy2MdzF5E04cmWRc5KoT93kcsP8A9XaaN4w01pI7CKNEhQBF APQfj1rxHW/FVxqU2EcrEvCKvAFV9Mvrq21O3lIl8piNzAEhcHvQB9UR6TJ4iuLC0sLdAtvb/vZ2 GFTc7NyfoRgV89/G7Uzp3xK1LTbLcbOwK2yGVfvsqjew9ixNeqfDj4mmza20+5Ed5ZRciMjYfqSO pHuDXP8AxDWLVvFWqajFatJZ3UxlTzIwwAIGc4yBzQB49H4hTpLAfqh/xq5bX9tef6t/m/uNwa2d R8LaRcI7JAYHAJ3QtgZ+nSuSOgzu+LWUu3YbTn9KAPZ/CifZfDdmvRmQvjPqa6b4jTNpfg/S7N2I IshMwJ/jkYsT+WwfhXLeBNM1268PWQuY8Sqvl7dwO7BwDWd8afFK30r4IG2NI8Bsj5EC8e3HFCA8 h8RaiDct8/8AFVO21MJtYkMAc4PQ+xrD1a5MlwTk9agik+ZQ7MqFhuYLkgeuO9bxlYzaPd/iK2ky 6b4IttK8P6TpNxr1pFdzT2/nEq7SvHsG+Rhs6HGCcjrjiq938PbY67rPhq38XWF34g0yKeU2aWso SUQgs6CQgAPtBOMEdt3XGH448U+DLmLwPJour6vdy+HY4bSZLjTFgEsSyvI0oIlbDchdmPU7u1O0 34haJB8c/EHjN0vTpeof2h5AEQ8wefG6plc4HLDPNLmaHZHW+G4fC2i/BaHxLLNo8mqX1/PAWv8A T5bjHlxgiBAOFJznf/tAZ4rPi8AZ1W38M3Himxg8W3ECyppTQSbQ7IHWFpvurIVI4xjJAzXA3/ii xn+D+leFEW4/tG11m4vZCUHlmN40VcHOc5U8YruX8d+Br34iW3xUvrrWE1mIRXM2hx2a7JLyONVB WffhYiyhjlSw5GORRzNCsiloHhP7f4PfxRqniTTtDsYtUfTZvtaSM4dY1c7URWZj82MAdiSRRb+F dObwyviXUvFlnaaU+pTWEcgtZZJJTGAQ6IB0IbPzFcD3wK5vU/GVtf8Awmfw9Ms39ry+J5tWkZYw IvLeBU4Oc53A8Y6d6g1DxTYz/CDS/CqLcf2ja6xPeyEoPL8t40VcHOc5U8Yqudhyo7x/hjYR+KrT w1c+M9MXUdTWOTS1S1mdZ0kUNEztgeXuzjHzEd+2eY8NaPo13c3Fpq+uS6ZewzmEW0OnSXTsQcE/ KQAAeOpPtV26+IWiy/F3wd4pRL3+z9HtdOiugYh5haBFD7RnBGRxyM1b0H4gaMnhTWdJg8Q634Tv rrW5dQa+0608yS9t2GFhZlkRlKnJA3bTuOfWlzMLI6Hwd4CsLT4q3HhXxVeQT266VLe2zxrKqzqY C6PgYZSo+Yq3dSOeM85p+j6XNoniy60zUNP1uDTdPhnN09vNE8bNMEIjUkfNyMlgRg8c1buPij4e f4y6Z4nK6tPpCaKul3UkqKbnJtmhaTG7DEFt3Xnmua0vXfDPhrw/4y0Ow1W91cazpsENrcGx8gCV Zw7BlLkgbV6+pxjvRzMLI6LTvBVsI9GtNY8WWOkavrcMc9hZSW8jjZJxEZZFGI956cNgEE4qrpnh C5k0zxBf61rFrosegXyWV6s8byNvYuMKEBycoRjoc9QMmkPirwN4gvvDXiXxFqGsWGo6LZ21td6f bWSyrffZ+EaOTeBHuAAYMODkjNZer/ES21nwp45gvIJodT8Ra1BqMKRrmONFaQspbOeN4A45xRzs OVDvHOiL4ftNH1Oz1aLVdJ1mB5rO6WJoidjlJEZG5DKwx1I96g8IeI9Ns5Es7zwtomr+fcL+9vRP vQHAwvlyoMd+QetZvi7xRY6r8OfBGgWq3AvNEivUuy6AITNcGRNpzz8p56c1y2nXJt7+3nk3bI5V ZsDnAINPm01Cx794x03Tbz4jeIPAugeF/DmkWums8s2qu1x5lpbxbWeRiZSp44wEOd2AAeRyes+H bdPDP/CReG9ej12wiu0s7lVtXglgkcEplGzlWwQCD14xVi1+K2m2fxu8T+K7ddWj0bX4J7R5bUiK 9t45AhEsfzYEisikc9utZXi3xewsIfsvxO8XeKbiO8jnittQikS2QISwZw8z5fOMADA5+akpNA0j U8S+FNH0BrvTNY8YWMWv2kBkmsFtZXjWQLu8nzgMeZ26bc8Fq6TxR4O8LXuo+DLJdb07QrvVvD+n eXAtnI5luJU/1khUBVDMQN2SeCSAOa4nx9qfgHxTrGreLotY1qxvtQR7g6T/AGesm26Zenn+YB5R fnO3dg421H4i8caVfeMvAmrQLdi20LTNLtbwNGAxe3I8zYM8jjjpn2o5mFkaOkeCpJbfxVPqer2W kp4YuorW+MqPIC7ySJhdgJJ3RkDjnI6DJqa/8FXkt54Yj8OalDrNr4meSLT5vKaAiSNwkiyIcldp IOcnjmsvWPH2j3Wm/FK3iS83+KNYgvNOzGMCNLmaQ+Zz8p2yLwM85qfw58T7Tw/pnw1e1tbi4vPD F7fzX0bKFSSOd0wEbPXYG5I4OOtPnYcqJtV8Iac+k6ve+HfFNnrs+ip5uoW8dtJERFuCmWItxIgY jJ445xWn4q8Ix63rngPRtCtbKyl1Hwpb313Ow2RrhpjJPIQOypyepwBWBHr/AII8JaJ4nPhTU9W1 W+1+xbToIrqxEC2VtI6PJvbe3mPhAo2gDqfardv8T9HtvFHhC8NpfXGnWXhNfD+rxhVSQ7hMsjRE kg4EikZxnBHHWlzMLIz9Z8LadF4XvPEnhjxFb69Y6dPHDqAFrJbyQeYSI32v95GIIzkHOAQK6DTv h1C/iTTvCOoeL7Ox8T3wjJ0/7JLIsBdQ6pJIOA+0gkAEDI5rl7/XfCvhv4e694Z8L6pqOuXXiGa3 +03NxYi1jtoIJDIqhd7FpGbGT0AHFer+ChZeJvjFofxI1Xw14y0q9miiv76Sa0SPSkCQgG5Fyxz5 TKobbt5JwG6Uc7DlR5tbadI/w21XVBb2c0ltrcNiJMP5+WRztXB27Tt7jOcYNa8Xw7jfWpPCsXim wbxgkTOdJWBynmKhdoBOPlMoUHjG3PG6uSsPG1pY/DzVtHgWc6nN4kt9VtmMeY/LjV/vHOc5YcY9 a7XxN8TbHX9XuPEVt8UPiF4fS5/ey6HbeY4ikwNywyCdUEZOcZUEDsaOdhZGJpvhqzTwjpnibxJ4 lTRbPVpJksAtlJcl/Kba7PtwEG7jHJOCcYrj9UvY7XUbm1gvIryKGZ40uIgQkygkB1BAOCBkZAPN dj8K/Gdh4c0eyWX4ga/p0CzGTUdE/slLu2uBvPEe6Tb8yBQdyjBzyRivOPFuo2mq+KNU1PTNOXTb G6u5Zre0TpBGzEqg7cA4449KpTYOKPQfiBY6XYeCfAuoWtokVxqenTzXUgJJldZ3UE5OBwAOKZaa dEPhJJ4jFtZfLryWXnfP5/Nuz7euzZxnpnOOcUmoaz4F8SeBvCOl6t4h1rSb7Q7KW2mWDRluUkLz NICGM6Y4IHSs/UPEuh23wovPBem3V9eTf8JKmowXEtqIQ9uLZoySodtrbmHy5PHep5mFj0L/AIVl APF7eDB4t09vELxLJa2gtpdkhMIlCvJjCMVPH3h05GcVj3XhyxHhLU9d0TxNaasNIeJdRijt5Iwi ytsR42cDeu7jop56UJ8TdAH7SVr8QCl//YsXk7l8ked8lmsJ+Xdj74PfpXIeE/Fdlpfw68a6DdC4 N5rUVkloUQFAYrgSPuOePlHHXmhTYWR7DofhfQ7nxnLpmu/YbaIeFRqMaW4n2ljBvEpw2dy/eI6H oBXA2XhnTtUm1O9h8TWn/CP6XFG95qjW0igPISEiSIjczkg46DgkkVcg+Jvh4/Eex1WdNQXSpPC6 aHdusIMsTm28ppFXdhgG56jIql4F8a6J4St/EHha18U6/Dp2rJBJDrmmW7W9xazxlv8Aln5gLxkM Qw3A8cCjmYWRK/w+ubvUPDkfhrULbWrPxFJJFZXIjaHY8Z/erKrZKbQdx65HIzXRaNoXhG38E+OL ix1uz1+6sLGIo4snjEL+eql42b7ynJGeCR2rnLH4jQaB478Na3L4y8U+NobCWf7YNQVkRIpY/LYQ CSVzv2s+SdoyFHvUFpr3gTw14Q8Y6Ro2ta1q1zrdpFDatLpqwRxBZlfDnzCS2B1AA4754OZhZHLP qOOjUi6oQfvVzJmkPrSCaT3qucXKdamq/wC1Uv8Aauf4q48TSeppwnk9TRzhynWtqnP3qT+1Mnlx +dcoZ5PU0nnvnqfyo5w5Tqf7SKycN39aQamwYEOPzrlzM5OcnP0pomfP3jRzhynUpqpOcuM49adH qR5/eDp61yQlfJ+Y9PSp7eUHO5znHpRzhynTrqJ2MPMHPvSpqLbHHmLzjvXOBsqfmP5Um47W+Y/l RzhynQm9YJjzFwWz1pwvz5WPNX73rXNlj5WN569cUwysI8bj164o5w5TrRqbGNFMi8Z5zUj6jmJB 5icZ/irjTMdiguR17U/7QdqgyHAzg4o5w5TrZr/cF/eJwuOtI96Tt/ep90D71cq8xO394Rx6GnGU kLmQ9PSjnCx09zdbpS/mJz/tUj3v7/d5idR3rmpJiXOZCP8AgJpjzMJuZCOR2o5w5TrI9RKzZMqY 3Z+971IupYn3eYnU9GrjGnPmf6w9fShJ2Ev+s7njFHOHKdlBqRWZT5qd/wCL2p0OpFd/71DlSPvV xsUrBwQ5P4U6GVvmxIfunsafOHKdfDqJUufNjOUI4aiHUSpc+bGcoRw1cjHIfmxJ/CexojkPzYk/ hPY0c4cp6nH8JNXFvMGsyG+XaNw55570D4S6uLLJs23eb03L0x9a+vh4StFidAifNj9Khfwpa+Rs 2L97dXPzGlj5j8P/AA61GyjUvakMH6bh0x9ata1oN1YTM91aFY2YlZCuVOTnr074xX0LfeG7eO3I VVGDmuE8VQNbwmNQCuCCPWk3cZzPh28Gk+Gox5pyHZ0QtxDn0HYn9OvpXm/j7xJeXM5SNmAxwAa6 HVo55sQRKEjHAVRgCshPCzz3g81M7gDzSA4B01WYK0W9y3UA5Ip76RqrNmbCg+rZJ/AV7DZeBbeV VLR4O3txWxpfwwgut84dVCtgBl60AeO6TpssTIv9nyyEEfMWUA1qnS/FF9IyaZYi2jiXfIVYM2Af 88AV71onw0t4Xaa5MbZH7sAdD61R8J6FbQR6vc3LrGY49jMzY+bd0+vFO4HjtvB4gs1MuoaSY1AO ZwAhI+nf8KhfxHfWUokhlcqeo7g16d4j0ye7kjQiS6kY7UXHJH09a5678FCNyJ4hG390nkGkBlWn ij7VApvrSKXcOrL8359akfWNFhjAS0MGeyOf61qW/wAN5ZLJJ4riWMuCcDkVkaz4DuraMM9xJIxO ApwKAEvPHt1Dp/2Kynlji2bMKQpIPXJGM1wOqC+1iZjtZs9K7K08FTu/zKa7Tw14GRcb4x+VAHid t4FvLhQxhbrV5fh3d7R+5b8q+oNK8IWyRqDEta8XhW0xjyl/KquKx8lj4dXZA/cn8qePhzdf88WH 4V9dp4TtMD90v5VZj8JWeMGJfyo5gsfHy/Dm7P8AyxJ/Cnj4c3X/ADyb8q+xE8I2Y/5Yr+VTJ4Rs +P3S/lRzBY+N/wDhW93/AM8W/Kmn4b3f/PFvyr7PHg+z/wCeK/lS/wDCH2f/ADxX8qOYLHxePhvd /wDPFvyp3/Ct7v8A54t+VfZ3/CH2f/PJfyo/4Q+z/wCeS/lRzBY+MP8AhW93/wA8W/Kj/hW11/zx b8q+z/8AhD7P/nkv5Uf8IfZ/88l/KjmDlPjA/De7/wCeLflSf8K3uv8Ani35V9of8IfZ/wDPJfyo /wCEPs/+eS/lRzBY+MP+FbXX/PFvyo/4Vtd/88W/Kvs//hD7P/nkv5Uf8IfZ/wDPJfyo5gsfF/8A wre7/wCeLflSj4cXn/PFvyr7P/4Q+z/55L+VH/CH2f8AzxT8qOYLHxh/wrq8/wCeB/KkPw5uz/yx P5V9n/8ACH2X/PJfyo/4Q+z/AOeS/lRzBY+Lx8NrvP8AqW/Knf8ACtrr/ni35V9n/wDCH2f/ADxX 8qP+EPs/+eS/lRzBY+MP+FbXX/PFvyo/4Vrdf88W/Kvs/wD4Q+z/AOeS/lR/wh9n/wA8l/KjmDlP i/8A4Vrdf88W/KrUngfW5LEWL3N41ouMQGVjGMdPl6V9jf8ACH2f/PJfyo/4Q+z/AOeS/lRzBynx d/wrS6/54t+VH/Ctbr/ni35V9o/8IfZ/88l/Kj/hD7P/AJ4r+VHMFj4u/wCFbXf/ADxb8qT/AIVr df8APFvyr7S/4Q+z/wCeK/lR/wAIfZ/88l/KjmCx8W/8K1uv+eL/AJUo+Gt1/wA8m/KvtH/hD7P/ AJ5L+VH/AAh9n/zyX8qOYOU+L/8AhWt1/wA8m/Kj/hW11/zyb8q+0P8AhD7P/nkv5Uf8IfZ/88l/ KjmDlPi//hWt1/zxb8qP+FbXX/PFq+0P+EPs/wDnkv5Uf8IfZ/8APJfyo5g5T4v/AOFa3X/PJvyp f+FbXf8Azyb8q+z/APhD7P8A55L+VH/CH2f/ADyX8qOYOU+MP+FbXX/PJvyo/wCFbXX/ADyb8q+z /wDhD7P/AJ5L+VH/AAh9n/zyX8qOYOU+Mf8AhW13/wA8m/Kl/wCFbXf/ADxb8q+zf+EQs/8Ankv5 Uf8ACIWn/PJfyo5gsfGR+G13n/Ut+VH/AAra73f6lvyr7O/4RCzz/ql/Kj/hELT/AJ5D8qOYLHxm Phrd7/8AUN19Khb4bXiyj9w+D/s19pjwjaZ/1S/lVO78L2m8Isa8dfrRzBY+NU+HF4ScwP0P8NLF 8N707v8AR3+6f4a+wR4Vtv8AnmKVfCtuM/IOlHMFj5Et/h1elHHkODxj5evNTx/Da/8AKkJtpOAP 4T619eWng6B/mZML296vDwpAFYbetHMFj42Hw0vTbk/ZpM7+mw+lMm+Gd+ttv+zSffx9w+lfZn/C KQbcbec1XvfDUKQ+UoySc/hRzBY+NZPhte+TGRbSEnOfkNEnw1vvIjItZMnOflNfXjeGodoAXkde aY3hqPaBzxnvRzBY+R3+HF6PLH2aQ5QfwnirMvwxvx5eLWU/IDwhr6zh8JxzMAFIAHJrRHheH5VU EYAHWjmCx8dXfwy1AXDBbWQj1Cmm3fwy1BbrAtZMAjnYfavsmTwvDvJAI/Go7vw5Ao345PQZo5gs fGJ+G199qx9llxvxnYcdafD8NL43RU20gXJ52nFfXX/CMxb8gHGfWnJ4ZiD5IyM+tHMFj5Fsvhrf m4UPayheedh9KtWfwwv2EhNrJjyyRlDzX1pa+F1aYAKT+NaVv4UhiQrgng9T3o5gsfHVt8MNQJkD WcoxGSMoeTRbfDDUCZA1nKMRkjKHk19jp4Yi5yCcjA5oTwvGC2QTxjrRzBY6Mgc8VA4GDU5Jwahk JqSzPvYw6EYrjPEGjC43fLXdS1TmiVuooEzyj/hFE87JT9KvafpmjNcGFzbvNGdpBOCK7XVLbFpJ 5R2uRhSO2a8/SyVQWMbAHvjv9aBHVpY2kcYVIIsY/uihR9n4hAVc52/wn8K5ZrOYANFcOp9Ca0Yd L1qJAzNNJkZAWXOP1oA6u01SB5FjmgZGJAUpyD/Wqd1FosN5Jb3GlQmORvMd8Zyx7kUeH7QWdzCN QdhdXAJhR2OAB1/Gr2tzQ2V0JZLOKfK9wNw9OvbNADxZ2KWz3un20TS+UREVHt0HpXmF6hnk2sMy SNt+lb99rd5LqheKcwtEoChDgfTHeo7S2a51yC6eISs8gYxL8oJ/pQB0eh6DCkIdk/hAUegrI8Sa PC+plQo+RAD+p/qK7S3mkxhrSdG9MA4/HOKwNWLtqtwWXbyuB3+6KAOfg0SJTnYK2LGwSPHygVNE KtxCgdia3jCjGKuwqOlV4hjrVuIYFAMnjHNWYgCRxUEYxVmIcUAiVAKsIBnpUMdTx96BkigelLge lC0tACYHpRgelLRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelLRQAmB6UYHpS0UAJgelGB6UtFACYH pRgelLRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelLRQAmB6UYHpS0UAJgelGB6UtFACYHpRgelO60 lACYHpRgelO6UUANwPSjHtTjSc0AJgelGB6U6kFACYHpRj2pxpOaAAAelG0elKDzQaAIrhxFEWxz 2rLPJyepqe8l82TA+6vAqHtQA3HtVq0td/zuML2HrTrS2LYeTp2HrV4UCEAAGABSgDFFKDxQAxyq oWPQVlTMXYuw6mrWoTf8sweB1qkWx1oC41gGGcYp8Fq0xz/COpp0MRm68L61qJsRABgAdqBEUcQR QqqAAKXZhs4qUvkbh0qNm70DQOPmJxxWZdv5kpI+6OBVu9nKJsyMt/KqPBPDYoBjO9TWsTTPgD6n 0pYIXlfaBx3NakUaxrtUYFABBCkShVH1PrT8cHilHFGc8UAIAPSjA9KcD60nrQBXJ4qKXpUrGonI weKBlaTlarSGrMnFVpfpQIq3ADoVbkEYNZF5aqEIA3J9ORWxKfaqs2D2oA5mWBY2BKgr2I71vaTq dtuL3ZCFem0Zz+FVLuJHV2RATtLcnAYjsD61j6ik0SqyMYwV3AkdR6UCO4u7rSmhW4lkjYDOxgMt 7471Qn0y11e2Wa1vPMX+Fgc49jWPZajpjaCi6nIodWZMD759xisuxWa01syWVzLDFk5zlTgDOCvQ 0AXtV0ew0SBXk/0i+nYncw4UD0H9ap+H5JTq4dGyY1LdO54FXtW1UatYLHcQAXURzG6dG9QfSrHg KzRTPcTlBKXwqEjPHfFAHVwtIlp5lwRuClmwOBXIBnkcySMWduST3NddqzCPSrkjBPlMMfhXKxr7 UDRJGDVuFe9RRAelWY/pQBNEKtRDvUMS8VbjWgGSoKsJUKCp4xmgCaMcVMnSo0GcVKOlAx4paQUt ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABS0lFAAaKKK AFzSfjRRQAvFIOtFFACmkoooABUF7KEj2g/M38qnYhQWPAFZU0hkkLHv0oAZVy0t84eQcdhS2ttj DyD6CrY60ALRnvScUoxQIZkk5z+FMnm8qEsTz2qRyoUlulZF1debMVAOwcCgGIzFiWY5NS21sZTv bO3+dLaQiU5bIX09avsyIn07UBYYVCqOAAKfGF25OKhkmDLjBFNU46GgZZ3jO0CormTy+TwAOaQP gggnNVdSm3YQfjQK5Umm82Qs3Bp9vGZXwDx3NJDb+c3QhR1NX1RUAVBwKBFi3VY49q8Cnj71MiOV 79akQDdQO44HNC9zmgY96FxjvQIAaMnFAx70cc9aBlZjwaic8VI3Q1E+MUDIZORVV9zHaqFz3A7f j0q0/Sq0oGdwyG9RwaCTO1SWe1i3rZTzn+6gFUo1nvdjBXAYZ2sNoX659K2jcyKMPiQe/B/OmNLb SfK52buMNxn2zQBz06STShhPuMZ+UNytWRPI9tLbX4hkhkGNiIcqMY+UdvWtK8srVUM0jCJVHL7s YFc3qOoWttfCGCRZ4ioJdTnB9OKAJNQ8P2NtFbRtM74O4EKM49TTru3j1K5a4gmjmZwNyAbHBAxk DvU2olbjw8JLK4ie5ZlUhm+ZB3/l+tc0Jb2GZVubY4H8a0Aai6dPHdJH5bgsdo3DHWut8OaeLSF4 7hY3lZ8ggZ4xWV4YvHuWkY3DOqAYVjkgmun05C26Ru3AoAr640dvpcqrtVpBsUAdc9f0zXMxitPx G5k1Mx5IWJQoH15J/UflVKJB60DsOiWrkS+1RRKKsRigGTxgY6VPHUKVYjWgRLGM1YQYFRIMdKsR j1oKJEGKkFMWnjrQA8dKKB0ooAKKKKACiiigAooooAKKKKACiiigAoooNABRmm0UALmjNJRQAuaM 0lGaAFzRmkyKM0ALmjNJmigBc0ZpKKAHdaKbRQA6ikzRmgBaKKKACiiigAoopsrhELHn0HrQBWv5 ekS9+TS2lttxJJ17D0p1vAd3my8uecelWKAClpO9LQJh+FH4UYpDgAkkYAoAr38gEBQfeaqVpZsS Gdfl7e9XI4jNIZpB8v8ACtWuAD0oAZsXZgjAFQyjkHkj1qZwGHJxTXP3QMHJoAqNyelPVRt6VYEY bqBigqoHbigCsHWIFm9MD61TiiaZyT90Hk1YdTcS84ES9/WrOxcDYQMCgQxQqDaowBTtwB6UMpzz Rty+MigZNHyM4p6gZ6UwBgMBhTgrHq35UCFLLkClBHpTVUAgDHvTgPcUAAx6UZGDxQB7ijHHUUDK jYwaifGDUjVE/SgZC+MVBJ0qZ6rynAyaCSvKARVWXGMEZq48c5XJgkH5Z/KoigWNpZIXkKj5YsY3 H39qBmZf2txeWgRW/do2FSQ43ZHQZ6jpWBp3hy/NyWmt5AvPKnj6ZrekudRa4je6t1lRX3KpO05w QOce9bdtPd3FkxnWzgJB8hIZCx9DnPWgRyum2ElrpF4HSQztKuGXDfIOo/PmosSKRuIkQ8069vha ak8EU+x4TtY9ie9W4Lu3utoubUb3OBJE2M/h0oA0fCkEM8k5S3SIgDc2etdVCiW8JBIwMt1rKsYI 444rSMFscZOOaseI5/stgIY8Bpfl+i45/wAPxoA5lneaVppGLO5ySaliWo0FTxigZLGoFWIlqKMV aiU0ASRqMVYjFMjTpmp0HFAiSNcVMtRqKlWgoetPFNWnLQA6iiigAooooAKKKKACiiigAooooAKK KKACkNLTWPFAhpNGajLc0m6gZJmjNR7vejd70ASZozUW6jfQBLmjdUW6l3UAS5ozUW6l3UASZpc+ 9RbqXdQBKDRmow1LmgB9FNzRmgB1Lmm596XNAC5peKbRQA6kKgkEjOOlJS5oAWikpaAClGPWjvSU CQcetBAIweRTcsTwMCjLe35UAP4x1phYd6Q7jTcHByKAI3Yt06ZpFyDnipAnHQ1CHwxDDjNAiYea +PnCj6U+QArtLVGzqyYAI9KSEgfeOM0DGy7UIQHGB6UmRnOaWaPLk5qJkcdqAJw5HU5p67Sd3eq2 7nGDVhPujGaAH8FsA1IAM9f0qOMEuTUhzzxQALjrmgY9aFB4oA68UDAY9aOMHmgA+lHODwaBFJu9 Qv061K3Q1C54oBkUnTrVeUAjBwRUz1Xk6UCMy61W8tb5IIYg8S43726g+npWjLqEUSP9rhaJlTeA DncPb3xzg1WnRHKllyQeD3pZ44I9z3soZyjEwM2Dn6+tAzlNf12a7K2zQCFVfepRyW9ql0fUL77d BBCDJcRhnj3L0G3J/StqLwxa3QF4wlgyoO0sCTx0FRvHbadqguYzIGiXBcEcZ7Y+lAjO1eGyu7uR pVQs+HLJxgkZIpml2E0V3A0BDRq4yrHqM1cayEoZrZluE6jb99fYiptFtJTfqzR4EJDFXyA3tQB1 emQgXW5j2OKzvFMscl5HCpJaIHd6c4OK1rVrqdCY1gt1zjcMsfy4rmtRMb6jM0cjSKW++f4jgAmg CKNB61PGoqOMVPGKBk8QwKsRjioIxxVmMcUATIKmQVEg4qZBQBIlSqKYtSLQCHDpTxTRThQMWiii gAooooAKKKKACiiigAooooAKQ0tNoAKRzhaWmTHCUCKzv81NL1BK/wAxphkoGWd9G+qvme9Hme9A FrfRvqr5lHme9AFoPS7/AHqp5lL5lAFrfS76qiSlD+9AFoPTg1VQ9O30AWQ1KGqsH96eHoAsBqUN UAelDUATg04GoA1OBoAlzSg1HupQaAJM0UzNLmgB/NHOabmlzzQIXnNKMk80negdaAF2+1RyMUbG CQRTwaOCMEUARiUdwRTiwVd3UUqxqoY9qjZQytsBoAheSTk54zUfOOae6Nt6d6QKR1FAB90CpACy bscUjISo4qRBthKEUBYQ/cHc0nNNxnHY0EY/KgBShJqWNSAByagb73FWIyoA3HmgCRAQTStkfTOK ZvGflGeaCrE5Y9+goAkAINAzSL1oHf6UAKM0YODSDv8ASgdDQBQYmoXJxUrHrUEh4oBkMrYHQk9A AMk1FJHcY/493/Nf8akk6VUurm9gAa3IkXncr5P0xQIfHvizIUYSDO3I6Vz+rweShu76Rm3OASGP U1stq1zHbu01um/blCudufQg81xGsXt9cz+XLO8qsd4TsKAOktbmzt4zqCKLy4RgFMkzZAPdRSeK xcG3tZbTypDJl5dhBGfSubRLiBYnSNf3pwcHpzW/eQHT5rizAEhUqUcdAOufxFAGNaXzpN+8R4XX uMiux0meVrBHMhcvk59a5393KcTISB6V1Xh2z3adH5CHygTt3fWgDYud1tospAO7yjn6muTQGui8 Q3ObBooZNzBlEu3svue3OK56PrQNEseasR5qGMVYjFAiaPNWEzUMdTx0ATIKmQfWok7VMnSgaJFH SpBTF7VIvSgBwpw6U0U6gEFFFFAwooooAKKKKACiiigAooooAQ0lKetIaBCZqK6OI6lqC9OIaAMi aT5zURk96guH/eN9aiMnvQFy35tHm+9U/Mo8ygLlzzPejzPeqm/3o30BcuCT3pRJVPf70u80BcuC T3pwkqmJKUSe9AF0Se9OEnvVMSe9OElAy4Hp4eqaye9PV6ALgenK9VA9PV6ALYenq1VQ9PVqALQa nBqrq1PDUATA04GoQ1PBoFclBpc81GGpwPNADweaUHmmA80oNAIcDQD9KRSaCxORmgGKW4JwMCm7 1wcYqKZ2Pyg1EM4PNAieLcyZPXNSYAXtmoAXKhQxx7U9FWPkscnvQOwshO0DHWmFyoFPzv5FV3k5 oCxMWVuowaCpPIINQl+nNOJPGDQBIisH5AxUpPPQUxScdacMlxQIkBI4xRklunAoyd1Ck5P1oAAT mgHrxQCc0AnmgYoJ9KM8HikBP6UAnB5oAzmI9Kgc8VM561XlYAEngUAQyHioHySFVSSTwB3qZxKU 3CFse5A/rUUUxiJcwMX6D0AoAZPcafp8oFyQ1woOSOQMjpVCBNIkihl1SS1RpQPlQfM2TwABzVO/ tvKgmupQJCoLkFetR6Lqen+buJMTlGG7YCVODjH6UCNbU7eG2EccECRgEtnGcAVlm7tZ3BniaJxw JI/T3FW4Z3v9Iv1luHa5CcErwq8DjtXNyW1/AflcSJ/ntQBvRWSTzr5NzFICwJHIOO9dHY21sZ0h RTsXnaGOK5Lw5Pv1DZIhV9hxnvXbaIp3ySMPQCgCv4kmWGOOyhRURvmbAx0PH6/yrFjHNX/EbK2p /K24qgBHoeeP1qlH16CgaJY/pViP6VDH9KsR0CJoxx0qdKijqeOgCVKmWo0qVelAx69KkFMHanjt QA4UtAoNAIKKKKBhRRRQAUUUUAFFFFABRRSGgBKQ9aWm0CA+lV9ROLep6q6qcW1Ajl7mT963PeoD JTLl/wB831qEvQMseZS7+etVd9KHNAWLXmUvmH1qqHpQ9AWLQk96USe9VQ9OD0CLYenB6qB6eHoA tBuacGqqrVIrUAWQ9PV6rBqeG9KB3LQenq1VVapEagZbV6kVqqK1Sq1AFpWp6tVdWqRWoEWAaeDU CmpAfagLEwPNOB5qJTzTwRQBIWA5pFZu2KTAJzS4wMjmgBd7dqQMajWZO6mnJIjHigQEAkkg02XC xkgUSyYBCD5qgLls5NAyaGcKOVqR5FdMAHrVZSMY207eAMBaALMDgjZg5qJ0U9iKfkxkHHUUwnpx QDGMmMc5pCSvrTy3tSnbxmgNyRCGQdalQDfUabcYAqUff6UAO4z+NC9fxpGxyKUHnpQADGe9Axz9 KB16UDvxQADHPWgYwaB34oB4PFAGW54NQS4Iweamc8VA54oEVbprhEzbSYYHkNyCKprd3q/NPChU 5B2jBU/Tv+FXpOlEhtLOFJ74cvzGvce9AHC61Pczzl5JHyzY8sE7Rj0FRx28/wBnaQFd69BtzXWr PY3L3F3dzQR2/mkJlRuIwM8dTzVmRbU6c01jbFI3XClo9p9M80AYixvb6Vav5xWW4jMdwp9Qcj9M VXbevysevY1anvHikMJCTIBhg470m+wlHzCaEjsMMKAJdFdRfRh0SNcHLkHjiuv04oQXgJkB4ztI H61j2AW2s0hTLDrnp1rcdzBpzP0ZIyfxxQBzupbTqc5U5G/9e/60yMVGg5qaMc0DJYhViMVFGKnj FAMmQcVOgqKMVOlAEiDipVHFRoOBUq9KBjxTxTV6CnCgB1FFFAgPWig0UAFFFFAwooooAKKKKACk NLSGgQhpppT1pp60AFVNXOLWrRqnrRxZ0IRxN2379/rUG+i7b9+/1qHdQUTBqXdUG6l3UAThqcGq ANTgeOtAEwanBqgDU4NQBOGp4aq6mnhqBE6txUgaq4apFagCcNT1aoAaeGoEWA1PVqgU4p6mgCyr VKjcVWVqlQ0FFlTUqmq6mpVNAidTUgNQKalBoGTqeaep5qJTzUikZoEiVetOX60xetOXGRzQAhiV uRgGlaOMDJOD6inrjB5o+U9T2oEVnjIORyD3qLYcmrUzYUBTnnFOVM5yeKAK0a8YFPMZJqxhQMAi o5OTjPSgYsuWjXHUVHwQO1BfbwDkUu5CBu4PrQIa2KApY8elPKIcEPTo12nOe1ACpvQY2ipV3E5Y gUxiM1LjmgBCAOB3NOA560nG+gY3UAAHPUUAdeaBjPWgY557UAAHXmgDg80DFAxg80AZL9KrykKu TU796qXfmiJnhP71QdvfmgBFZFk3TI+0c42nk/4Vl6tFJe3zTNgpgBQ3arNpe3kwkjlWEMgz8wIz 7VBe308Vq5a3CyDoc5UigDMvGh04RtLHuDkgbRjFaGm6tYvFtlkl271IVeR3zn9K5lo7ue4I8ySU qMlmOQBV/SbbzrrY7lFC5JCdaAI9RsHkvJpoZ873LDIwDVYfa4cq6+Zj3rXukaOU2okyqncvbOe4 qKMhXO4jP05oA6Cz/epC+MIQp59K2dVlWLT5nYbgV24+vH9ayLGVlhjQ2k7ydOyirl/G5tZJbx12 gYSFeme2T3NAGKg5qeMc1Gg5qaMc0DJoxViMVDGKsRigRLGKmQVEgqdBxQBIgqRRxTFHFSL0FA2P A4pw7U0dBTxQMDRRRQIDRQaKACiiigYUUUUAFFFFABSGlpDQIaTTaU0hoEJVLW/+POrhqlrv/HlQ gOAuz/pD/WoM0+7P+kP9aizQUPzS5pmaXNADwacDUQPNPBoAkBpwNRinA0ASKakU1CKepoAlU1Ip qIU9TQBMDTwaiBpymgkmU1KpqBTUi0ATqalU1CtSJ1oGiwp4qVagWpU+tAide1SrUK1KtAyZetSL 1qJc1Kuc0ASr1p6jnpUQIB5PWlEg96BEqnqccCq0kjOxwDipPM9AelRKhz1oGIm4HJFS/vZSV3ED 0FIE9TSJceWxUqOO9AFiKIRpjn3pGHysw6DmkFyhA60u9HjZBxn1oEVdxI5FLkEClMYI64/GmNGw A5zQA8/0qwoOxfpVM7hVqIlo1I9KAJVGX6VMQd1RIDv5qXBzQAgB3njvSgHdTV5JOe9Ox81ACKDm gA88UoBzQAaAEAPpQAcGlANABwaAMZ6gk6VO9VrmVIojJI21R3oAif6c065ksLCArd4a4dT8uM4z 2ptpcW0kIuRICc8KTjaawrhXnuZHdd+WOGPPFAGvYT6fZ6Yj3bK1xcoP3USbmwfQCqlzbSRsCwKp jcG9qoWV7aKdwkxKp7jpitF7q2muLi3iaaUTLtjYDoSKAM0Xztw6xzJ2DD+tSwfZLidE8l0Ynruy Kz5NOx/q5CCOxqTTRcxXkTY3qGwfagDrLVmku41zgZzUuu5NtGP+mg/kajsFKXIJ5zxRrUjHZEvI B3Pjt2H86AM9BzU0Y5qNAc1PGKBksYqeMVFGDU6A0CJUHFSp0piA4qVM4oGiRRxTx0pq5qQZoAUd qeOgpozTucUAFFLzSc0ABooPWjpQAUUUUDCiiigAooooAKa1OprUEjTSGlNNNACE1R17/jxq9VDx B/x40Aed3Z/0h/rUYNPu/wDXv9aiFBQ8GlBpooFADwacKYKcKAHing1GKeKAHinqajFPFAEgp61G tSLQBIKeKjXmnrQJki1KpqFfrUi0CLCVItRJ0qRaAJlNSpUK1KhoGTr2qVTUKmpUNAydetSL1qJe tSoeaAELhHy/BNPR0bGCKbNGZQAMZFRRRsJQGXA+lBJZG31BpQAOTxR5CMDxg+1MkRljK7gwx6c0 DI5JyGIUcetRZBJJobOw8U9Im2bmX6CgLiDaFzz1qZOUzgio8Nj7tXEYbMEA/hQFyIsPLAA5zTSf lAoYlThhx2NDHgHANAgAHFTxDIwtV92McVYQSqOCoyKBk23DZxQ8gD7VG5qjCuzfM/HtUwVVOAAK BDYlKkgnJzmnj71IDzn1NOB+btQAi9aB3+lCnmgHrQADv9KB0NAPXpQDwaBmPJwDgZPpVaRInjxL EznOf881aeoX6UAZVy1nCwDI4BOMtGQPzrL1a72yrDagIP4nwDke1dHsLuEQZZjgCqms2Fks1tHG iSzu2wgHB570COauYgIBKI0Us3XaCf1q9oMcksNwZpDlQDCw4GR2rXks7BCsEzJJcHkRjkD61Vvg YTIw/dhQAoHFAFEgNlvmVupB60Qb5J1jSQgk8ZFPF1Ifv+XIP9oVPZyK9wP3MakDIIFAGzAzvKqK EjB7jlv1p18qQ2wijX77ZYnqcc1FYHNzk84BqfUhlEOejUAUoxzU0Y5piDmpoxQMkjFToKjSpkFA EidKlQcVGnSpl6dKAQ5elSL0pg6VIOlACjpTqQdqWgAooNFAAaKDRQAUUUUDCiiigAooooAKaadT W7UEjTTDTj1ppoATNUPEH/HlV+s/xEwWx5pged3f/Hw/1qIVJdHM7/Wo6RQ4UtNp1AC04U2nCgB4 py0wU8daAH05aYKeKAJFp4qMVIpoAkWnioxT1oEyRakXrUa09aBEyGpVzUKVMOlAEqngVKlRJ0qR KBk6mpkPvUC1MtAydOtSITmolPNSr1oESqTnrT0Jpi43U9SODQIeCeeaVVGdzdcVGJFUFj2qrJOz EhQ2KBkynfKyKvTvVspmIrVC2l8sOxXLHpmpEEtwcu5VfQUCFbIHWkDMELZqV/LK45zUFywRF460 AOExwAwzS5jYDkrVbzFwMg0u9SBQBYKAkYcmpy2AB7VVhI8wfSrLEUASRkkk1I5PPNNjxt5pzY5o AATmgE7qBil4z0oAQE5oBPNAxnpSjHPFACAn9KATg80DH6UDGDxQBkv3qF89uSTxgVM1Z93BdzTZ hkCqnTBwc0ASX850+0aQY+0SDCj+6O9c6m4zCUOxkzndnnNbEsd4ZvNmYF8bQSuQKo3oW3i3yOWP QKOpoAdD9ngX/WJvPXByc1NeGK8tioLNI+CeOuP85rLeGNYmu9mXJGc8gE+lX9MxNbMXcmVWyrig Cg9oNp2kjilsoZo51YPhc4INWSqg7TuUimgBnAJfk+tAGvaDZKCGz2OBU1zmYZUnCck9vpUakl1V mO3OMDgGrE/EJC8dP50AVkHNTRimIOalQUD3JEqZBUaCpkoEPWpV6VGg4qUCgY4U8dKaKd2oGPFF AooAKM0UUCA0UHrRQAUUUUDCiiigAooooAKa1ONMbtQSNPWmmnNTTQAlRXFvHcgJN90VJRQBm3Hh vS5zkKQTVKXwdbH/AFcrD8a6AU7J9TTsByE/hCYf6qUGqE/hrUIicJu+legBm9aXee9IDzKXS76L gwOfoKga3mT70TD8K9U3A9VH5VHJBbSffhU/hQM8uAYdjThXo76Vp0g5gUVUm8N2Mn3eKAucKKcK 6yXwpGeY5cVSufDN1HzG28UBcwxUi1ck0a/T/liTUDWtxH96Jh+FAxF609aaFYdVI/CnCgB61ItR rUi0Eki1MtQrUqdKAJkNSqahWpVoAmQ+1TKagXtUy/WgonXrUqnnpUK9akDYbA5oETGRUGWIAoRw +CMY7YqpKjyPljx2FLEjJ91sA0CJ7hsxnioUOf4acFbJy1KdqfeZQMUDCMpu2sQPrV+N4hGQrL69 aypEEp3KwxTQNnBlFAGjO8SSg5GOpxTJzHMocDIHFVomRmCg5YnirAO2JkI70CImiGOKjZCOwqbP rSMVOCTQA2F2SVcjir+OnFVAyjFXVUsA3ABFAEkZ4xjpSTvsXOAeaQsEyM7m9BQI2Zw0hHsvpQBI rA4IHWlH3ulNQcDnvTsc9aAEHXpQD14oA560AdeaAAfSgHg8UoHvSDoeaAMthxUDIuD1xnPWrDDr UTCgCnPbxyLhmk/BzVK80rzrcyrK2Iv7xzx3rVYE8AZJPFUdVuXXFnA2An+sb1NACQWKTaSqvjCn cpPGT6mqscOxsKNoxk4qSPzblEjkb91GAAo4Bq2TGY1UlflJ6UAZvnP/AHgR7inJIxkAIXGecClN uAe/1pv2b5ycke9AGhGf3y/Wrj42NnpiqlvGCoPUjqc1ZHzDaOnc0AMQc1KgpFXDEDoKkQUAPQVI gpqCpEFAx6VItMUcVIo4oAUdKeKaopwoGOHSijsKKBBRRRQAUUUUDCiiigAooooAKKKKAA0xuopx pj9RQSNNNJpzdTTDQAlLSUCmA4UtJRSAdSUZ4ozigBaXNJRQAtFJS5oAXJHelDtTTRQA/eehFMZI m+9GDRRQBG1paP8AehWq0mj2D/w4+lXc0lAGbJoFq33GIqu+gMPuP+dbWT2NKGPvQBzsmj3KfdGa iNjcp1jNdQHNLvz1AoA5bypF6o35U4AjqD+VdMfLPVR+VMe3t5OqCgDATpUyVqNp8B+7xTDpwH3W oGVF609F9x+VTmxkB4OaPs8oPSgBgDZ4waYzFT/qm+oqwI3DdDTkByOKBFWOZWGBkNjvVWRvNfLd RxWm6A8bAfwqrNa7HJzgGgCOIZ+gpJsBz6VYjiwNoyTT2tOdzk/SgZVt0BmVl7HJq9eFWw6fiKY6 hAAgxTWdk4IzQAgZSKaxA7U/zEIG5OfalIhIB5oAbGFdwp4q2V4ALscCoIlTeGXtUrEnpQInhVQD gYNSPimQqdn1p7g+npQAYANKMZ60mDupcHd0oAQYzQMc0AHNAB54oGAx69qBjBoANABwaBGcw4qJ 8AEk4FTEdahYZyDGCM9zxQMrJewornaxk/hwM1lyRM7GRgQTySTWrNEcfJCoP+//APWqldxXJgI2 bfXBzkUCKixFwZBMRH6DvirNntk3K3ygDK45p9jAz2zxsCrlcD2FNjhMLcZDdKAFcANtbPFIwTP3 T+dSOSGwQDxS5OegH4UAPiRQoxwD2q3GPlFQJyBU8f3QKBgB85+tSIKQfep6DmgQ5RUij3piipEF A2PWnj601RxTh0oBDgOKUdKQdKcOlAxe1FHaigQUUUUAgooooGFFFFABRRRQAUUUUCYhpj9RTqa/ WgQxutNzTjTTQAlLSZpM0ALn3pc000ZpgPzQTTaKAHA0uab0pc0gFFFJS/nQAvNFJmkzQA40lJmi gBaKSigBaAaKTNADhQKbmlzQAtFJmlzQAopefWkFFAD8nPWlyc9qZ3pe9AD+M9BSYXrikzg5NNB5 3HgCgAISNSzke9Ubp0nKgcc8U24lMshGcKOgqNVAOcUDL0jxW6kKdze1MhaaUFnAVewqO2iMjEnp WioGzaBx0oApyx7XweTVOZsSMD2OK02ADbj2rPniXzG9zmgLEW4UblOBkUrRccGoXjb1FAi7bdTy OlTt9az7cSJIMcg8GtDYaALUY+QdOlOfjJOKjjJAIY9OlFxjGM8noPWgCQDGORS/xVHCGA2seQae PvUDBRzSgdelIvWgd/pQAAfSlA4PSkHf6UDoaAKJBxTGBxUpFMI4oGREHFNCbuvQdakbHGSB71Xm Ck7VnyPTNAmQCZYhK0aklm4J6AUisGjy7bnJyeKbIcNtXBHrTl4xhQDigQSR/Pn2pDHk1ZKjaCPS m7RQA2JMHBqwq4PApiD5ulSqPmoAUDuaeoNAHNKooKHKKeopFFOWgQ4ZxTgDSL3pw4FAC804Zpop w6UDF596OaSigQtJRRQCCiiigYUUUUAFFFFABRRQaBMbTXp1I9AMjNMIp5FNNAhtHvSmkFMANFHe jpQAuKDSZozQAtGaSigB2aKQUuaAFoppNGaAHUU0GikApoFJRTsAufalFIDRmkAtANJ3opgLS0lL mkAtLmm0tADu9BOOTwBSZqO5VnQBTjmgAW4RpMHgZ49KZdSniNe/Wo/IYH72aQRkHkmgBPI5y0ir kZppAU4Dbvwp4TnkmklIjQtjPtmgY2a7lijHlgAfSmx3FzLnOQPXpTYpC4LOBjsKLksNoPGRnAoD cnQ7920lyOtK7DyenzA1Fp7bJSQeCKs3AyhdRyOtAiuW46U0lOpp3mAgU2RsY4oAXzFGMVeQFkV2 cAEZrO3/ADAFRzV7AAAHPFAEoYZxGNx9T2qRE2tkncx71HASHIqfPNADVPzE4707nNNQ9s96cDz1 oGAJzQCaQE560AnmgBQTzRng0gPX6UAnBoAqmmnpUh6U09KBkLoGXDKCPQiojBF/zzAqyRxTGxxk 4oApPbhXB7E8U6SLkH2qeZjkBcYHNIu5m59KAIwCBjtS8+1SstJtOaAGr96njrSheaeooAF605fp QBmnr1oEC/SnD6Ui04ZoAVfpS59qB0pRQAo6Uvak5p3NAxKKWkoEwoooNAIKKKKBhRRRQAUUUUAF FFFAhDTH6ZqSmsMrigRDuFJuFMcFSRzUZagCckUlQb6XzKaAlxRUYenq6t1ODQAtJS49KSi4C0Ul LQAUZpKDQAtFJmkNADs0ZpB2ooAWl+lIKgnkkjbgZFFgLFAqOGTzFyRin0ALRRRSAWmxvuYj0pR0 NQW7ZmYY6UAWqXvTc0uaAHcZpCCWzQKUdaAE2nPDfpTWST+HafrUgPPSlU80AU9lyDnYp+hqtdK2 7cyFcjoa1gfYUworqdwFAGbZqrMQwwo5NSXkLNMXPCkcVNbDe5G0AKeas3BjEZ3kD0oGZsaBCGBO am835SSOlDIduVAIpJcLDjA60CELwkcrSHyCBnNREjHamsyhQTigZOPJLAAVZZhwMdqz1ddykYq8 zDjp0oETW5G81Y4z0qrbMBIenSrWcnpQA0YDkY75pwxuqMODMV79qkH3ulAAuM9KQY54pR16CgHr wKBgMc8dqQYweKAevFKDweBQBX4pCBjvT+MdKTt0oGRkDFRyRk9DUxAx0pCBQBXZMKCRSKPTipmB /D0pAPagBoA75pxApcc9KUj2oAbgZpwAp2BnpQBz0oAAOaUClHWlHJoEA/GlGKB7ClH0oBijGDSj pSD6Uo+lAIUYxSnFHGOlHHpQAlHFKaSgANFHFFAIKKKKBhRRRQAUUUUAFFFFABRRRQIayqeoqN4F apqKBWKb2p/hqF4JFHStKigdjKIZeCDSZ/CtRkVuoFRNbIegp3EUlkdeh4qVJlPDcU97Q9jULwOP egCcYI4IoqqPMQ8VIs/ZhQBMcUhzQHVhkGg0AJRQaQ9aAFopBS0AHtUM0co5U5FTUKTQBFA0mdpT AqbNG40goAGkRfvHFKrK33SKa8ccg+Yc1GtuVbKHFICxTUCAnHXvSSsUUbeT3pvER3Zzu7UATUtM LgAHFCyK3tQBJ3paTIJ4NKMZoAUdetKPrTSQKEYH1oAfwePzqvdTHOxG+pqWQ7Y2OeSKpDHvQA+C Uxq+Op70sMRmk3Oxb60wAdzgVZSaGNMAk8dqBku1VRhnqKrTxg24575NSeeWHyrgetMLZB60CKvl j1pk0RKDmrTqiopyTmmNsIwc0AUjCT3q9aoTGN7cimExrwFJNPgkzKFIKqetAFkRqDknFWGZVGSc CoWkjU4QEn1p6puYNJknsOwoAaE3OZTxjoKnGM5zSPjBH4UoxnvQAigZ60oA55pBjPelGOevSgBA B60ADB5oGPegYwetAEeOKTHFO/GkxxQUNxxSEcU/HHWkI4FADSPekI9xTsDHWjHvQA0ilI560pHv QR70AJjmjHNOwM0Y5oAQDmlApQOetKAKBCAUoFAFKAPWgAA4pQOKAKOPWgAxRijj1o49aBi0lH40 UCA0UUUAFFFFAwooooAKKKKACiiigAooooAKKKKACiiigQUUUUCGmmkU8imkUDImA7ionRT2qdhT GWgRWMYHQ4pAXU8HNSuKjYGgBwfPWlGKrtkUnmOKYFqjNVvtGOtPW4QjnigCbvSmo1dT0an/AI0A LRSA0tABS80maBQAoOKaiAMWPOad2NRQtlyM0gJxjHTIpDGp6cUtLQAoULwDmlwc0neigBSGHJHF MSQBvmGPSnNluMimCMZ7GgAlbceOlRhc/wANShR7UhIUcnrQBEyHaRjr0pFhCDLjPtSxj5ic5NSS riDJ6k0DI1Zt68YUHpVmSIYJU/hVQAgYqyrDYORmgCIYOKH2hfu0rxqTnIB+tHl8ffFAiNnHZO1S w/vFyR0phiUfecVJCqqpINADyPQcVZUEgGqrck8irMfKg5FAwYHB/OnAc0Ec9qRByeRwaBCgHNIA aUDnqKAOvIoGAB/SkAODQB7ilA4PIoAZjikwcU7BpOcUDG9qMcU7HFIQaAEI4pCKdzRzQAhFBXml 5oOaAExz0o70vOaMHNAB3oApQOaBmgQAUAUoBpRmgGHakpeaOaAQlFLzRzQAlFLzSUBcKKKKACii igYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFIRS0UCGEU0ipCKQigCFlqJkq0VphWgRTZKi ZKvMlRtH7UAUWWmFautH7UxovagCn8w6Gnx3Dr15qRo6jaM0ATpdKfvcVKsiN0YVQaP2pBG/Y4oA 0xzS1nxsynlzU4uDnpTAtdqjhj2uznvTVuE71IsiN0NAD6WmjFO5pMBe9HejmlGc0AAHNKBk9TRz mlXOaAGeWSfvGkaI7TzmpQTSgmgCsiGp9u9CD+FDA8EU8tsU0AQFSByO9IFzUqEvkkcDpSlSvQda AKsg5pOwFSyBtx69abg8UDImHP4VJCeoqKUNu4zQvmKwIzQIsv1qeJhtFQhGPNTIoVqAH9+ajjc+ aVPQnipGYg4xyegpApAJPU0DHL1oHf6UozmgZoAQd/pQOhpRmgZwaAG9qO1L60Z4oGNxxQelO7UZ 4oAb2pDTz9KQ/SgBppT1pePSg4z0FACd6O9O79KO9ACAc0Cl70ZoAQUClH4UCgQg70UoNGeKAEoo zRmgAoozRQAUUUUDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigTExSEU6 igQzFIVp4pGKgZJxQBGUppjzRLcxJ3zVOa7dshRigCw6KvUgVXkkjHHWq7s7/eJNM2mmBI8oPQYp hbPWk2mlC0gEBpeaULzTttADcZp60YpwFAD1Zh3qQSP61GBThQBIJmB5p4mGeRioxinYB7UASrIp PWnKQT1zUGxc8ChVOeDQBYB96cD61XG6lDN6UASEknr0pDnk5zSB+OlAcEHigBVYgYB705WY8k0g K46UqsCRkcUDEcZwRmmHipmAAz/WmnaRkigCJgTjntSHA71Kdoxwaa2wfwZoAdE24kZxipC2GwtM TaQTtpxxnpQIkUYbJOTQc/rSgjjig4OeKAAE560AnmhSOOKAR6UDAE80DODzQCPT9aBjB4oA/9k= ------=_NextPart_000_0010_01C268B3.2EF184D0 Content-Type: text/css; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: file:///D:/InternetDev/Vertebrae/Vertebrae.css BODY { FONT-SIZE: smaller; BACKGROUND: url(Images/Repeating.jpg) #ffffff = repeat-x left top; MARGIN: 0px; FONT-FAMILY: Verdana, Geneva, Arial, = helvetica, sans-serif } TD { FONT-SIZE: smaller; FONT-FAMILY: Verdana, Geneva, Arial, helvetica, = sans-serif } TH { FONT-FAMILY: Verdana, Geneva, Arial, helvetica, sans-serif } .topics { FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif } A:link { FONT-SIZE: 12px; COLOR: #666666; FONT-FAMILY: Verdana, Arial, = Helvetica, sans-serif; TEXT-DECORATION: none } A:visited { FONT-SIZE: 12px; COLOR: #666666; FONT-FAMILY: Verdana, Arial, = Helvetica, sans-serif; TEXT-DECORATION: none } A:hover { FONT-SIZE: 12px; COLOR: #000000; FONT-FAMILY: Verdana, Arial, = Helvetica, sans-serif; TEXT-DECORATION: underline } .vertebraefont { FONT-WEIGHT: bold; FONT-FAMILY: Verdana, Arial, Helvetica, sans-serif } .tableimage { BACKGROUND-POSITION: left top; BACKGROUND-ATTACHMENT: scroll; = BACKGROUND-REPEAT: no-repeat } .leftmenu:link { COLOR: #333333 } .leftmenu:hover { COLOR: #333333; BACKGROUND-COLOR: #cccccc; TEXT-DECORATION: underline } .leftmenu:visited { COLOR: #666666 } .tdbigbone { BACKGROUND-POSITION: right center; BACKGROUND-ATTACHMENT: scroll; = BACKGROUND-REPEAT: no-repeat } .tableimagelogo { BACKGROUND-POSITION: left top; BACKGROUND-ATTACHMENT: scroll; = BACKGROUND-IMAGE: = url(Images/Vertibrea%2BMain%2BBack%2Bweb%2Bcopy640.jpg); = BACKGROUND-REPEAT: no-repeat } ------=_NextPart_000_0010_01C268B3.2EF184D0-- From mbp@samba.org Sat Oct 5 00:53:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 00:53:42 -0700 (PDT) Received: from sngrel4.hp.com (sngrel4.hp.com [192.6.86.110]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g957rUtG023024 for ; Sat, 5 Oct 2002 00:53:34 -0700 Received: from ctss11.sgp.hp.com (ctss11.sgp.hp.com [15.85.49.5]) by sngrel4.hp.com (Postfix) with ESMTP id 4E600DE for ; Sat, 5 Oct 2002 15:53:28 +0800 (SST) Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by ctss11.sgp.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail BPI enabled) with SMTP id PAA11321 for ; Sat, 5 Oct 2002 15:53:26 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Sat, 05 Oct 2002 17:53:16 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id TWW7DW1Y; Sat, 5 Oct 2002 17:53:16 +1000 Received: from 16.176.68.120 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Sat, 05 Oct 2002 17:53:15 +1000 Received: from mbp by vexed.aus.hp.com with local (Exim 3.36 #1 (Debian)) id 17xjjD-0003kE-00; Sat, 05 Oct 2002 17:51:59 +1000 Date: Sat, 5 Oct 2002 17:51:59 +1000 From: Martin Pool To: James Morris Cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Message-ID: <20021005075157.GC2531@samba.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B X-archive-position: 525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mbp@samba.org Precedence: bulk X-list: netdev --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 5 Oct 2002, James Morris wrote: > Martin, > > I'm not able to reproduce the bug exactly as described. What kind of > network connection were you using between the boxes, and what was the > kernel version at the server end? (I've been testing between two boxes on > a 10Mbps lan, with 2.2.22 at the client side and both 2.2.20 and 2.4.19 > kernels at the server side). The machine inside VMware is as shown below. This was originally reported by a distcc user who was apparently experiencing the problem on diverse hardware on a 100Mbps switched network. Did you see the example code that I posted at the start of the thread? I can't reproduce it locally, but I can reproduce it going to a 2.4.18 machine across a 100Mbps switched network. A tcpdump (complete?) is attached. mbp@maudlin:~$ lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disabled) (rev 01) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 08) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 08) 00:0f.0 VGA compatible controller: Unknown device 15ad:0405 00:10.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10] (rev 01) 00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 10) mbp@maudlin:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 1 model name : Intel(R) Pentium(R) 4 CPU 1.70GHz stepping : 2 cpu MHz : 1696.308 cache size : 256 KB fdiv_bug : no hlt_bug : no sep_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 cflush dtrace acpi mmx fxsr sse xmm2 ssnp 28 acc bogomips : 2929.45 -- Martin --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcpdump_1050.txt" 17:50:58.870451 192.168.1.173.1050 > 192.168.1.1.9: S 1182351029:1182351029(0) win 16060 (DF) 17:50:58.870499 192.168.1.1.9 > 192.168.1.173.1050: S 1288275163:1288275163(0) ack 1182351030 win 5792 (DF) 17:50:58.870730 192.168.1.173.1050 > 192.168.1.1.9: . ack 1 win 16060 (DF) 17:50:58.875597 192.168.1.173.1050 > 192.168.1.1.9: P 1:1449(1448) ack 1 win 16060 (DF) 17:50:58.875690 192.168.1.1.9 > 192.168.1.173.1050: . ack 1449 win 8688 (DF) 17:50:58.875879 192.168.1.173.1050 > 192.168.1.1.9: P 1449:2897(1448) ack 1 win 16060 (DF) 17:50:58.875940 192.168.1.1.9 > 192.168.1.173.1050: . ack 2897 win 11584 (DF) 17:50:58.876271 192.168.1.173.1050 > 192.168.1.1.9: . 2897:4345(1448) ack 1 win 16060 (DF) 17:50:58.876348 192.168.1.1.9 > 192.168.1.173.1050: . ack 4345 win 14480 (DF) 17:50:58.876527 192.168.1.173.1050 > 192.168.1.1.9: . 4345:5793(1448) ack 1 win 16060 (DF) 17:50:58.876585 192.168.1.1.9 > 192.168.1.173.1050: . ack 5793 win 17376 (DF) 17:50:58.876748 192.168.1.173.1050 > 192.168.1.1.9: . 5793:7241(1448) ack 1 win 16060 (DF) 17:50:58.876804 192.168.1.1.9 > 192.168.1.173.1050: . ack 7241 win 20272 (DF) 17:50:58.876994 192.168.1.173.1050 > 192.168.1.1.9: . 7241:8689(1448) ack 1 win 16060 (DF) 17:50:58.877056 192.168.1.1.9 > 192.168.1.173.1050: . ack 8689 win 23168 (DF) 17:50:58.877283 192.168.1.173.1050 > 192.168.1.1.9: . 8689:10137(1448) ack 1 win 16060 (DF) 17:50:58.877354 192.168.1.1.9 > 192.168.1.173.1050: . ack 10137 win 26064 (DF) 17:50:58.877524 192.168.1.173.1050 > 192.168.1.1.9: . 10137:11585(1448) ack 1 win 16060 (DF) 17:50:58.877579 192.168.1.1.9 > 192.168.1.173.1050: . ack 11585 win 28960 (DF) 17:50:58.877794 192.168.1.173.1050 > 192.168.1.1.9: . 11585:13033(1448) ack 1 win 16060 (DF) 17:50:58.877856 192.168.1.1.9 > 192.168.1.173.1050: . ack 13033 win 31856 (DF) 17:50:58.878020 192.168.1.173.1050 > 192.168.1.1.9: . 13033:14481(1448) ack 1 win 16060 (DF) 17:50:58.878074 192.168.1.1.9 > 192.168.1.173.1050: . ack 14481 win 34752 (DF) 17:50:58.878235 192.168.1.173.1050 > 192.168.1.1.9: . 14481:15929(1448) ack 1 win 16060 (DF) 17:50:58.878290 192.168.1.1.9 > 192.168.1.173.1050: . ack 15929 win 37648 (DF) 17:50:58.878445 192.168.1.173.1050 > 192.168.1.1.9: . 15929:17377(1448) ack 1 win 16060 (DF) 17:50:58.878498 192.168.1.1.9 > 192.168.1.173.1050: . ack 17377 win 40544 (DF) 17:50:58.878656 192.168.1.173.1050 > 192.168.1.1.9: . 17377:18825(1448) ack 1 win 16060 (DF) 17:50:58.878712 192.168.1.1.9 > 192.168.1.173.1050: . ack 18825 win 43440 (DF) 17:50:58.878865 192.168.1.173.1050 > 192.168.1.1.9: . 18825:20273(1448) ack 1 win 16060 (DF) 17:50:58.878920 192.168.1.1.9 > 192.168.1.173.1050: . ack 20273 win 46336 (DF) 17:50:58.879151 192.168.1.173.1050 > 192.168.1.1.9: . 20273:21721(1448) ack 1 win 16060 (DF) 17:50:58.879222 192.168.1.1.9 > 192.168.1.173.1050: . ack 21721 win 49232 (DF) 17:50:58.879424 192.168.1.173.1050 > 192.168.1.1.9: . 21721:23169(1448) ack 1 win 16060 (DF) 17:50:58.879486 192.168.1.1.9 > 192.168.1.173.1050: . ack 23169 win 52128 (DF) 17:50:58.879662 192.168.1.173.1050 > 192.168.1.1.9: . 23169:24617(1448) ack 1 win 16060 (DF) 17:50:58.879720 192.168.1.1.9 > 192.168.1.173.1050: . ack 24617 win 55024 (DF) 17:50:58.879877 192.168.1.173.1050 > 192.168.1.1.9: . 24617:26065(1448) ack 1 win 16060 (DF) 17:50:58.879931 192.168.1.1.9 > 192.168.1.173.1050: . ack 26065 win 57920 (DF) 17:50:58.880091 192.168.1.173.1050 > 192.168.1.1.9: . 26065:27513(1448) ack 1 win 16060 (DF) 17:50:58.880146 192.168.1.1.9 > 192.168.1.173.1050: . ack 27513 win 60816 (DF) 17:50:58.880352 192.168.1.173.1050 > 192.168.1.1.9: . 27513:28961(1448) ack 1 win 16060 (DF) 17:50:58.880414 192.168.1.1.9 > 192.168.1.173.1050: . ack 28961 win 63712 (DF) 17:50:58.880581 192.168.1.173.1050 > 192.168.1.1.9: . 28961:30409(1448) ack 1 win 16060 (DF) 17:50:58.880639 192.168.1.1.9 > 192.168.1.173.1050: . ack 30409 win 63712 (DF) 17:50:58.880792 192.168.1.173.1050 > 192.168.1.1.9: . 30409:31857(1448) ack 1 win 16060 (DF) 17:50:58.880844 192.168.1.1.9 > 192.168.1.173.1050: . ack 31857 win 63712 (DF) 17:50:58.881037 192.168.1.173.1050 > 192.168.1.1.9: . 31857:33305(1448) ack 1 win 16060 (DF) 17:50:58.881099 192.168.1.1.9 > 192.168.1.173.1050: . ack 33305 win 63712 (DF) 17:50:58.881255 192.168.1.173.1050 > 192.168.1.1.9: . 33305:34753(1448) ack 1 win 16060 (DF) 17:50:58.881381 192.168.1.173.1050 > 192.168.1.1.9: . 34753:36201(1448) ack 1 win 16060 (DF) 17:50:58.881430 192.168.1.1.9 > 192.168.1.173.1050: . ack 36201 win 63712 (DF) 17:50:58.881727 192.168.1.173.1050 > 192.168.1.1.9: P 36201:37649(1448) ack 1 win 16060 (DF) 17:50:58.881806 192.168.1.1.9 > 192.168.1.173.1050: . ack 37649 win 63712 (DF) 17:50:58.881989 192.168.1.173.1050 > 192.168.1.1.9: P 37649:39097(1448) ack 1 win 16060 (DF) 17:50:58.882050 192.168.1.1.9 > 192.168.1.173.1050: . ack 39097 win 63712 (DF) 17:50:58.882210 192.168.1.173.1050 > 192.168.1.1.9: P 39097:40545(1448) ack 1 win 16060 (DF) 17:50:58.882266 192.168.1.1.9 > 192.168.1.173.1050: . ack 40545 win 63712 (DF) 17:50:58.882469 192.168.1.173.1050 > 192.168.1.1.9: P 40545:41993(1448) ack 1 win 16060 (DF) 17:50:58.882536 192.168.1.1.9 > 192.168.1.173.1050: . ack 41993 win 63712 (DF) 17:50:58.883067 192.168.1.173.1050 > 192.168.1.1.9: P 41993:43441(1448) ack 1 win 16060 (DF) 17:50:58.883154 192.168.1.1.9 > 192.168.1.173.1050: . ack 43441 win 63712 (DF) 17:50:58.883400 192.168.1.173.1050 > 192.168.1.1.9: . 43441:44889(1448) ack 1 win 16060 (DF) 17:50:58.883545 192.168.1.173.1050 > 192.168.1.1.9: . 44889:46337(1448) ack 1 win 16060 (DF) 17:50:58.883597 192.168.1.1.9 > 192.168.1.173.1050: . ack 46337 win 63712 (DF) 17:50:58.883767 192.168.1.173.1050 > 192.168.1.1.9: . 46337:47785(1448) ack 1 win 16060 (DF) 17:50:58.883934 192.168.1.173.1050 > 192.168.1.1.9: P 47785:49233(1448) ack 1 win 16060 (DF) 17:50:58.883990 192.168.1.1.9 > 192.168.1.173.1050: . ack 49233 win 63712 (DF) 17:50:58.884201 192.168.1.173.1050 > 192.168.1.1.9: P 49233:50681(1448) ack 1 win 16060 (DF) 17:50:58.884271 192.168.1.1.9 > 192.168.1.173.1050: . ack 50681 win 63712 (DF) 17:50:58.884441 192.168.1.173.1050 > 192.168.1.1.9: P 50681:52129(1448) ack 1 win 16060 (DF) 17:50:58.884499 192.168.1.1.9 > 192.168.1.173.1050: . ack 52129 win 63712 (DF) 17:50:58.884655 192.168.1.173.1050 > 192.168.1.1.9: P 52129:53577(1448) ack 1 win 16060 (DF) 17:50:58.884711 192.168.1.1.9 > 192.168.1.173.1050: . ack 53577 win 63712 (DF) 17:50:58.884913 192.168.1.173.1050 > 192.168.1.1.9: P 53577:55025(1448) ack 1 win 16060 (DF) 17:50:58.884982 192.168.1.1.9 > 192.168.1.173.1050: . ack 55025 win 63712 (DF) 17:50:58.885151 192.168.1.173.1050 > 192.168.1.1.9: P 55025:56473(1448) ack 1 win 16060 (DF) 17:50:58.885209 192.168.1.1.9 > 192.168.1.173.1050: . ack 56473 win 63712 (DF) 17:50:58.885408 192.168.1.173.1050 > 192.168.1.1.9: P 56473:57921(1448) ack 1 win 16060 (DF) 17:50:58.885652 192.168.1.1.9 > 192.168.1.173.1050: . ack 57921 win 63712 (DF) 17:50:58.885850 192.168.1.173.1050 > 192.168.1.1.9: P 57921:59369(1448) ack 1 win 16060 (DF) 17:50:58.885914 192.168.1.1.9 > 192.168.1.173.1050: . ack 59369 win 63712 (DF) 17:50:58.886077 192.168.1.173.1050 > 192.168.1.1.9: P 59369:60817(1448) ack 1 win 16060 (DF) 17:50:58.886134 192.168.1.1.9 > 192.168.1.173.1050: . ack 60817 win 63712 (DF) 17:50:58.886346 192.168.1.173.1050 > 192.168.1.1.9: P 60817:62265(1448) ack 1 win 16060 (DF) 17:50:58.886417 192.168.1.1.9 > 192.168.1.173.1050: . ack 62265 win 63712 (DF) 17:50:58.886589 192.168.1.173.1050 > 192.168.1.1.9: P 62265:63713(1448) ack 1 win 16060 (DF) 17:50:58.886645 192.168.1.1.9 > 192.168.1.173.1050: . ack 63713 win 63712 (DF) 17:50:58.886801 192.168.1.173.1050 > 192.168.1.1.9: P 63713:65161(1448) ack 1 win 16060 (DF) 17:50:58.886856 192.168.1.1.9 > 192.168.1.173.1050: . ack 65161 win 63712 (DF) 17:50:58.887054 192.168.1.173.1050 > 192.168.1.1.9: P 65161:66609(1448) ack 1 win 16060 (DF) 17:50:58.887123 192.168.1.1.9 > 192.168.1.173.1050: . ack 66609 win 63712 (DF) 17:50:58.887293 192.168.1.173.1050 > 192.168.1.1.9: P 66609:68057(1448) ack 1 win 16060 (DF) 17:50:58.887348 192.168.1.1.9 > 192.168.1.173.1050: . ack 68057 win 63712 (DF) 17:50:58.887502 192.168.1.173.1050 > 192.168.1.1.9: P 68057:69505(1448) ack 1 win 16060 (DF) 17:50:58.887558 192.168.1.1.9 > 192.168.1.173.1050: . ack 69505 win 63712 (DF) 17:50:58.887758 192.168.1.173.1050 > 192.168.1.1.9: P 69505:70953(1448) ack 1 win 16060 (DF) 17:50:58.887826 192.168.1.1.9 > 192.168.1.173.1050: . ack 70953 win 63712 (DF) 17:50:58.888073 192.168.1.173.1050 > 192.168.1.1.9: P 70953:72401(1448) ack 1 win 16060 (DF) 17:50:58.888142 192.168.1.1.9 > 192.168.1.173.1050: . ack 72401 win 63712 (DF) 17:50:58.888307 192.168.1.173.1050 > 192.168.1.1.9: P 72401:73849(1448) ack 1 win 16060 (DF) 17:50:58.888364 192.168.1.1.9 > 192.168.1.173.1050: . ack 73849 win 63712 (DF) 17:50:58.888574 192.168.1.173.1050 > 192.168.1.1.9: P 73849:75297(1448) ack 1 win 16060 (DF) 17:50:58.888642 192.168.1.1.9 > 192.168.1.173.1050: . ack 75297 win 63712 (DF) 17:50:58.888811 192.168.1.173.1050 > 192.168.1.1.9: P 75297:76745(1448) ack 1 win 16060 (DF) 17:50:58.888867 192.168.1.1.9 > 192.168.1.173.1050: . ack 76745 win 63712 (DF) 17:50:58.889023 192.168.1.173.1050 > 192.168.1.1.9: P 76745:78193(1448) ack 1 win 16060 (DF) 17:50:58.889080 192.168.1.1.9 > 192.168.1.173.1050: . ack 78193 win 63712 (DF) 17:50:58.889283 192.168.1.173.1050 > 192.168.1.1.9: P 78193:79641(1448) ack 1 win 16060 (DF) 17:50:58.889365 192.168.1.1.9 > 192.168.1.173.1050: . ack 79641 win 63712 (DF) 17:50:58.889550 192.168.1.173.1050 > 192.168.1.1.9: P 79641:81089(1448) ack 1 win 16060 (DF) 17:50:58.889611 192.168.1.1.9 > 192.168.1.173.1050: . ack 81089 win 63712 (DF) 17:50:58.889819 192.168.1.173.1050 > 192.168.1.1.9: P 81089:82537(1448) ack 1 win 16060 (DF) 17:50:58.889890 192.168.1.1.9 > 192.168.1.173.1050: . ack 82537 win 63712 (DF) 17:50:58.890089 192.168.1.173.1050 > 192.168.1.1.9: P 82537:83985(1448) ack 1 win 16060 (DF) 17:50:58.890152 192.168.1.1.9 > 192.168.1.173.1050: . ack 83985 win 63712 (DF) 17:50:58.890414 192.168.1.173.1050 > 192.168.1.1.9: P 83985:85433(1448) ack 1 win 16060 (DF) 17:50:58.890482 192.168.1.1.9 > 192.168.1.173.1050: . ack 85433 win 63712 (DF) 17:50:58.890732 192.168.1.173.1050 > 192.168.1.1.9: P 85433:86881(1448) ack 1 win 16060 (DF) 17:50:58.890803 192.168.1.1.9 > 192.168.1.173.1050: . ack 86881 win 63712 (DF) 17:50:58.890974 192.168.1.173.1050 > 192.168.1.1.9: P 86881:88329(1448) ack 1 win 16060 (DF) 17:50:58.891032 192.168.1.1.9 > 192.168.1.173.1050: . ack 88329 win 63712 (DF) 17:50:58.891188 192.168.1.173.1050 > 192.168.1.1.9: P 88329:89777(1448) ack 1 win 16060 (DF) 17:50:58.891244 192.168.1.1.9 > 192.168.1.173.1050: . ack 89777 win 63712 (DF) 17:50:58.891448 192.168.1.173.1050 > 192.168.1.1.9: P 89777:91225(1448) ack 1 win 16060 (DF) 17:50:58.891516 192.168.1.1.9 > 192.168.1.173.1050: . ack 91225 win 63712 (DF) 17:50:58.891684 192.168.1.173.1050 > 192.168.1.1.9: P 91225:92673(1448) ack 1 win 16060 (DF) 17:50:58.891744 192.168.1.1.9 > 192.168.1.173.1050: . ack 92673 win 63712 (DF) 17:50:58.891902 192.168.1.173.1050 > 192.168.1.1.9: P 92673:94121(1448) ack 1 win 16060 (DF) 17:50:58.891957 192.168.1.1.9 > 192.168.1.173.1050: . ack 94121 win 63712 (DF) 17:50:58.892157 192.168.1.173.1050 > 192.168.1.1.9: P 94121:95569(1448) ack 1 win 16060 (DF) 17:50:58.892225 192.168.1.1.9 > 192.168.1.173.1050: . ack 95569 win 63712 (DF) 17:50:58.892392 192.168.1.173.1050 > 192.168.1.1.9: P 95569:97017(1448) ack 1 win 16060 (DF) 17:50:58.892451 192.168.1.1.9 > 192.168.1.173.1050: . ack 97017 win 63712 (DF) 17:50:58.893400 192.168.1.173.1050 > 192.168.1.1.9: P 97017:98465(1448) ack 1 win 16060 (DF) 17:50:58.893493 192.168.1.1.9 > 192.168.1.173.1050: . ack 98465 win 63712 (DF) 17:50:58.893684 192.168.1.173.1050 > 192.168.1.1.9: P 98465:99913(1448) ack 1 win 16060 (DF) 17:50:58.893744 192.168.1.1.9 > 192.168.1.173.1050: . ack 99913 win 63712 (DF) --mojUlQ0s9EVzWg2t-- From jmorris@intercode.com.au Sat Oct 5 04:53:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 04:53:57 -0700 (PDT) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95BrmtG025031 for ; Sat, 5 Oct 2002 04:53:50 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id VAA25155; Sat, 5 Oct 2002 21:53:41 +1000 Date: Sat, 5 Oct 2002 21:53:40 +1000 (EST) From: James Morris To: Martin Pool cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case In-Reply-To: <20021005075157.GC2531@samba.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 526 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 Sat, 5 Oct 2002, Martin Pool wrote: > The machine inside VMware is as shown below. This was originally > reported by a distcc user who was apparently experiencing the problem > on diverse hardware on a 100Mbps switched network. > > Did you see the example code that I posted at the start of the thread? Yep. > I can't reproduce it locally, but I can reproduce it going to a 2.4.18 > machine across a 100Mbps switched network. A tcpdump (complete?) is > attached. Thanks for the extra info. - James -- James Morris From anonymous@anonymous.com Sat Oct 5 06:37:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 06:37:35 -0700 (PDT) Received: from 10.0.0.1 (CacheFlowServer@[211.138.91.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95Db8tG026153; Sat, 5 Oct 2002 06:37:14 -0700 Message-Id: <200210051337.g95Db8tG026153@oss.sgi.com> From: "" To: Date: Sat, 05 Oct 02 06:37:19 Pacific Daylight Time X-Priority: 3 X-MSMail-Priority: Normal Subject: Cartridge Recycling DwNNvOFOYp X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=WC_MAIL_PaRt_BoUnDaRy_05151998 X-archive-position: 527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anonymous@anonymous.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --WC_MAIL_PaRt_BoUnDaRy_05151998 Content-Type: text/plain Content-Transfer-Encoding: 7Bit This message is brought to you by:ENVIRONMENTAL ACTIVISTS GROUPS Helping to save our world! Please Recycle Your Cartridges! Our Top Pick! - Company refills and then returns your cartridges! Laser/Jet Recycling Services : Inkjet Laser Toner And Copier Cartridges Recycling Service. Refills apple, brother, canon, hp, epson, lexmark, Xerox and more. Also sells refilled cartridges Cheap! www.eklaserjet.com National Toner Recycling & Supply Produces recycled toner and ink cartridges for laser and deskjet printers and copiers, including those made by Hewlett Packard and Xerox. www.nationaltoner.com HP Environment: LaserJet Supplies Return & Recycling The return and recycling pages for inkjet supplies, laserjet supplies and hardware. www.hp.com/hpinfo/community/environment/re_laser.htm HP Planet Partners LaserJet toner cartridge recycling program This site's purpose is to provide customers with details regarding HP's Planet Partners (LaserJet Toner Cartridge) - Canada Recycling Program www.hewlett-packard.ca/products/plus/planetpartner/program.html Mother Earch Recycling - Laserjet Cartridges For Your Computer Distributor Of Laser, Fax And Copier Cartridges With www.motherearthrecycling.com/laser.cfm MTCR Framed Website Buys empty inkjet cartridges.Recycler of empty inkjet and laserjet cartridges. Buys bulk loads of empty cartridges. www.mtcr.freeuk.com HP Environment: Hardware Return & Recycling The return and recycling pages for inkjet supplies, laserjet supplies and hardware. www.hp.com/hpinfo/community/environment/re_computer.htm Discount Office Supplies - Mother Earth Distributer of recyled office supplies, laser toner cartridges, inkjet cartridges, fax machine and photocopier supplies. Canon HP, Lexmark, Panafax, Xerox and more. www.motherearthrecycling.com Toner Cartridge Recycling, Victoria, BC - Quality Cartridge Recycling Quality Cartridge Recycling offers free delivery within Victoria, BC for all inkjet and laser printer cartridges, photocopier cartridges, and fax machine cartridges. www.inkandtoners.com Boulder Labs Recycling Recycling at Boulder Laboratories www.boulder.nist.gov/recycle Our Top Pick - Pays highest price for selling your cartrdges! JG Recycling, Cash paid for empty toner cartridges we buy empty inkjet, and empty toner cartridges members.aol.com/jgray0000 Toner Cartridge Recycling Toner Cartridge Recycling 1) 2) 3) 4) 1)HP IIP, IIP Plus, IIIP 2)HP 4V, 4MV toner cartridge 3)HP 5L, 5ML toner cartridge 4)HP 3si, 4si 5) 6) 7) 8) 5)LaserJet, LaserJet +, LaserJet 500+ 6)HP 4L, 4P 7)HP II, IID, III, IIID 8)HP LaserJet 4, 4 plus, 5 www.magiclink.com/web/dougbcs/tng070.htm Environmental Organization WebDirectory - Recycling:Recycled Computer Products Recycling:Recycled Computer Products Recycled Printer Cartridges 90 Earth - Environmental company with high tech solutions for the environment, we specialize in the Sick Building Syndrome Ashmor MicroComputer Recyclers - Buy, sell, recycle new and www.webdirectory.com/Recycling/Recycled_Computer_Products IRC - International Recycling Centre - welcome! IRC International Recycling Centre, gespecialiseerd in het verzamelen en recyclen van toner- en inkjetcartridges. www.i-r-c.nl YigZeGTgmzdYIMZ --WC_MAIL_PaRt_BoUnDaRy_05151998-- From yoshfuji@linux-ipv6.org Sat Oct 5 11:33:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 11:33:59 -0700 (PDT) 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 g95IXqtG031245 for ; Sat, 5 Oct 2002 11:33:53 -0700 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 g95IXp1o009258; Sun, 6 Oct 2002 03:33:52 +0900 Date: Sun, 06 Oct 2002 03:33:51 +0900 (JST) Message-Id: <20021006.033351.33728380.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Improvement of Source Address Selection From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021004.015045.96199793.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-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: 528 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 Thank you for your comments. In article (at Fri, 4 Oct 2002 09:32:33 +0300 (EEST)), Pekka Savola says: > Are IPv4 addresses represented as mapped addresses (as they should by the > spec at least)? see below. > There seem to be some points at section 4 of the draft (e.g. for multicast > destinations, MUST only pick addresses on the outgoing interface) that may > be missing? fixed. > > +#ifndef IPV6_ADDR_MC_SCOPE > > +#define IPV6_ADDR_MC_SCOPE(a) \ > > + ((a)->s6_addr[1] & 0x0f) /* XXX nonstandard */ : > Aren't these definitions header file material, perhaps (I'd guess they > might be useful in other .c files too). I thought that we would do it later, but anyway, moved to include/net/ipv6.h. > > +int ipv6_addrselect_scope(const struct in6_addr *addr) : > Something similar to this is done in addrconf.c:ipv6_addr_type, could > there be more reuse? integrated core of the code to ipv6_addr_type(). > > + if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) > > + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.4 */ > > + > > + return IPV6_ADDR_SCOPE_GLOBAL; /* section 2.3 */ > > + } > > You're referring to sections 3.4 and 3.3, I think (similar in other > comments) fixed. > > + if (addr->s6_addr32[2] == __constant_htonl(0x0000FFFF)) { > > + if (addr->s6_addr32[3] == __constant_htonl(0xA9FF0000)) > > + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */ > > Shouldn't that be 0xA9FE0000 if you mean IPv4 zeroconf 169.254.0.0/16 ? > (that could be spelt out in a comment.) > > > + if (addr->s6_addr32[3] == __constant_htonl(0xAC000000)) { > > + if (addr->s6_addr32[3] == __constant_htonl(0xAC100000)) > > + return IPV6_ADDR_SCOPE_SITELOCAL; /* section 2.2 */ > > 172.16.00 -- 172.31.255.255, not just 172.16.*.* > > > + return IPV6_ADDR_SCOPE_LINKLOCAL; /* section 2.2 */ > > + } > > I don't understand this, this was possibly supposed to be the case for > 127.0.0.0/8 which should be treated as link-local? How stupid code I wrote... And,.. I reread the spec and found that ipv4-mapped addresses are global scope for source address selection. So..., I removed above codes. Well, Following patch is against linux-2.4.19. BTW, "IPv6: Miscellaneous clean-ups" (FIX_2_4_19_MISC_CLEANUPS-20020912) and this patch conflics. What kind of patch do you prefer? 1. patch on top of plain kernel 2. patch on top of other-patched kernel 3. patch with other patch (which conflicts) on top of plain kernel Thank you in advance. Index: include/net/addrconf.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/addrconf.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.6.1 diff -u -r1.1.1.1 -r1.1.1.1.6.1 --- include/net/addrconf.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/addrconf.h 2002/09/26 19:15:15 1.1.1.1.6.1 @@ -55,6 +55,9 @@ struct net_device *dev); extern struct inet6_ifaddr * ipv6_get_ifaddr(struct in6_addr *addr, struct net_device *dev); +extern int ipv6_dev_get_saddr(struct net_device *ddev, + struct in6_addr *daddr, + struct in6_addr *saddr); extern int ipv6_get_saddr(struct dst_entry *dst, struct in6_addr *daddr, struct in6_addr *saddr); Index: include/net/ipv6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ipv6.h --- include/net/ipv6.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/ipv6.h 2002/10/05 17:43:48 @@ -74,6 +74,20 @@ #define IPV6_ADDR_RESERVED 0x2000U /* reserved address space */ /* + * Addr scopes + */ +#ifdef __KERNEL__ +#define IPV6_ADDR_MC_SCOPE(a) \ + ((a)->s6_addr[1] & 0x0f) /* XXX nonstandard */ +#define __IPV6_ADDR_SCOPE_INVALID -1 +#endif +#define IPV6_ADDR_SCOPE_NODELOCAL 0x01 +#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 +#define IPV6_ADDR_SCOPE_SITELOCAL 0x05 +#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 +#define IPV6_ADDR_SCOPE_GLOBAL 0x0e + +/* * fragmentation header */ @@ -203,12 +217,28 @@ char *, unsigned int, unsigned int); - -extern int ipv6_addr_type(struct in6_addr *addr); +/* + * Address manipulation functions + */ +extern int __ipv6_addr_type(struct in6_addr *addr); +static inline int ipv6_addr_type(struct in6_addr *addr) +{ + return __ipv6_addr_type(addr) & 0xffff; +} static inline int ipv6_addr_scope(struct in6_addr *addr) +{ + return __ipv6_addr_type(addr) & IPV6_ADDR_SCOPE_MASK; +} + +static inline int __ipv6_addr_src_scope(int type) +{ + return type == IPV6_ADDR_ANY ? __IPV6_ADDR_SCOPE_INVALID : type>>16; +} + +static inline int ipv6_addr_src_scope(struct in6_addr *addr) { - return ipv6_addr_type(addr) & IPV6_ADDR_SCOPE_MASK; + return __ipv6_addr_src_scope(__ipv6_addr_type(addr)); } static inline int ipv6_addr_cmp(struct in6_addr *a1, struct in6_addr *a2) Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.6.16 diff -u -r1.1.1.1 -r1.1.1.1.6.16 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/10/05 17:26:27 1.1.1.1.6.16 @@ -26,6 +26,10 @@ * packets. * yoshfuji@USAGI : Fixed interval between DAD * packets. + * YOSHIFUJI Hideaki @USAGI : improved source address + * selection; consider scope, + * status etc. + * */ #include @@ -104,6 +108,8 @@ static struct notifier_block *inet6addr_chain; +static u32 ipv6_addrselect_label_lookup(const struct in6_addr *addr, int ifindex); + struct ipv6_devconf ipv6_devconf = { 0, /* forwarding */ @@ -132,7 +138,7 @@ MAX_RTR_SOLICITATION_DELAY, /* rtr solicit delay */ }; -int ipv6_addr_type(struct in6_addr *addr) +int __ipv6_addr_type(struct in6_addr *addr) { u32 st; @@ -143,32 +149,38 @@ */ if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) - return IPV6_ADDR_UNICAST; + return (IPV6_ADDR_UNICAST | + IPV6_ADDR_SCOPE_GLOBAL<<16); if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) { - int type = IPV6_ADDR_MULTICAST; + /* multicast */ + /* addr-select 3.1 */ + int type = IPV6_ADDR_MC_SCOPE(addr)<<16; - switch((st & __constant_htonl(0x00FF0000))) { - case __constant_htonl(0x00010000): + switch(type) { + case IPV6_ADDR_SCOPE_NODELOCAL<<16: type |= IPV6_ADDR_LOOPBACK; break; - case __constant_htonl(0x00020000): + case IPV6_ADDR_SCOPE_LINKLOCAL<<16: type |= IPV6_ADDR_LINKLOCAL; break; - case __constant_htonl(0x00050000): + case IPV6_ADDR_SCOPE_SITELOCAL<<16: type |= IPV6_ADDR_SITELOCAL; break; }; + type |= IPV6_ADDR_MULTICAST; return type; } if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) - return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST); + return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST | + IPV6_ADDR_SCOPE_LINKLOCAL<<16); /* addr-select 3.1 */ if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) - return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST); + return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST | + IPV6_ADDR_SCOPE_SITELOCAL<<16); /* addr-select 3.1 */ if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { @@ -176,18 +188,52 @@ return IPV6_ADDR_ANY; if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) - return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST); + return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST | + IPV6_ADDR_SCOPE_LINKLOCAL<<16); /* addr-select 3.4 */ - return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST); + return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST | + IPV6_ADDR_SCOPE_GLOBAL<<16); /* addr-select 3.3 */ } if (addr->s6_addr32[2] == __constant_htonl(0x0000ffff)) - return IPV6_ADDR_MAPPED; + return (IPV6_ADDR_MAPPED | + IPV6_ADDR_SCOPE_GLOBAL<<16); /* addr-select 3.3 */ } - return IPV6_ADDR_RESERVED; + return (IPV6_ADDR_RESERVED | + IPV6_ADDR_SCOPE_GLOBAL<<16); /* addr-select 3.4 */ } +/* find 1st bit in difference between the 2 addrs */ +static inline int addr_diff(const void *__a1, const void *__a2, int addrlen) +{ + /* find 1st bit in difference between the 2 addrs. + * bit may be an invalid value, + * but if it is >= plen, the value is ignored in any case. + */ + const u32 *a1 = __a1; + const u32 *a2 = __a2; + int i; + + addrlen >>= 2; + for (i = 0; i < addrlen; i++) { + u32 xb = a1[i] ^ a2[i]; + if (xb) { + int j = 31; + xb = ntohl(xb); + while ((xb & (1 << j)) == 0) + j--; + return (i * 32 + 31 - j); + } + } + return addrlen<<5; +} + +static inline int ipv6_addr_diff(const struct in6_addr *a1, const struct in6_addr *a2) +{ + return addr_diff(a1->s6_addr, a2->s6_addr, sizeof(struct in6_addr)); +} + static void addrconf_del_timer(struct inet6_ifaddr *ifp) { if (del_timer(&ifp->timer)) @@ -449,122 +495,189 @@ /* * Choose an apropriate source address - * should do: - * i) get an address with an apropriate scope - * ii) see if there is a specific route for the destination and use - * an address of the attached interface - * iii) don't use deprecated addresses + * draft-ietf-ipv6-default-addr-select-09.txt */ -int ipv6_get_saddr(struct dst_entry *dst, - struct in6_addr *daddr, struct in6_addr *saddr) +#define IPV6_SADDRSELECT_SELF 0x01 +#define IPV6_SADDRSELECT_PREFERRED 0x02 +#define IPV6_SADDRSELECT_HOME 0x04 +#define IPV6_SADDRSELECT_PUBLIC 0x08 +#define IPV6_SADDRSELECT_INTERFACE 0x10 +#define IPV6_SADDRSELECT_LABEL 0x20 + +struct addrselect_attrs { + struct inet6_ifaddr *ifp; + u16 flags; + s16 matchlen; + u8 scope; +}; + +int ipv6_dev_get_saddr(struct net_device *daddr_dev, + struct in6_addr *daddr, struct in6_addr *saddr) { - int scope; - struct inet6_ifaddr *ifp = NULL; - struct inet6_ifaddr *match = NULL; - struct net_device *dev = NULL; + int daddr_type, daddr_scope; + u32 daddr_label; + struct inet6_ifaddr *ifp0, *ifp = NULL; + struct net_device *dev; struct inet6_dev *idev; - struct rt6_info *rt; + int err; + int update; + struct addrselect_attrs candidate = {NULL,0,0}; - rt = (struct rt6_info *) dst; - if (rt) - dev = rt->rt6i_dev; - - scope = ipv6_addr_scope(daddr); - if (rt && (rt->rt6i_flags & RTF_ALLONLINK)) { - /* - * route for the "all destinations on link" rule - * when no routers are present - */ - scope = IFA_LINK; - } + daddr_type = __ipv6_addr_type(daddr); + daddr_scope = __ipv6_addr_src_scope(daddr_type); + daddr_label = ipv6_addrselect_label_lookup(daddr, + daddr_dev?daddr_dev->ifindex:0); - /* - * known dev - * search dev and walk through dev addresses - */ + read_lock(&dev_base_lock); + read_lock(&addrconf_lock); + for (dev = dev_base; dev; dev=dev->next) { + idev = __in6_dev_get(dev); - if (dev) { - if (dev->flags & IFF_LOOPBACK) - scope = IFA_HOST; + if (!idev) + continue; - read_lock(&addrconf_lock); - idev = __in6_dev_get(dev); - if (idev) { - 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); - read_unlock_bh(&idev->lock); - read_unlock(&addrconf_lock); - goto out; - } - - if (!match && !(ifp->flags & IFA_F_TENTATIVE)) { - match = ifp; - in6_ifa_hold(ifp); - } + /* Rule 0: Candidate Source Address (section 4) + * - multicast and link-local destination address, + * the set of candidate source address MUST only + * include addresses assigned to interfaces + * belonging to the same link as the outgoing + * interface. + * (- For site-local destination addresses, the + * set of candidate source addresses MUST only + * include addresses assigned to interfaces + * belonging to the same site as the outgoing + * interface.) + */ + if ((daddr_type&IPV6_ADDR_MULTICAST || + daddr_scope <= IPV6_ADDR_SCOPE_LINKLOCAL) && + daddr_dev && dev != daddr_dev) + continue; + + read_lock_bh(&idev->lock); + ifp0 = idev->addr_list; + for (ifp=ifp0; ifp; ifp=ifp->if_next) { + struct addrselect_attrs temp = {NULL,0,0}; + int addr_type; + update = 0; + + /* Rule 0: Candidate Source Address (section 4) + * - In any case, anycast addresses, multicast + * addresses, and the unspecified address MUST + * NOT be included in a candidate set. + */ + addr_type = __ipv6_addr_type(&ifp->addr); + if (addr_type == IPV6_ADDR_ANY || + addr_type&IPV6_ADDR_MULTICAST) + continue; + + /* Rule 1: Prefer same address */ + if (ipv6_addr_cmp(&ifp->addr, daddr) == 0) + temp.flags |= IPV6_SADDRSELECT_SELF; + else + temp.flags &= ~IPV6_SADDRSELECT_SELF; + update = (temp.flags&IPV6_SADDRSELECT_SELF) - + (candidate.flags&IPV6_SADDRSELECT_SELF); + if (update < 0) { + continue; + } + + /* Rule 2: Prefer appropriate scope */ + temp.scope = __ipv6_addr_src_scope(addr_type); + if (!update) { + update = temp.scope - candidate.scope; + if (update > 0) { + update = candidate.scope < daddr_scope ? 1 : -1; + } else if (update < 0) { + update = temp.scope < daddr_scope ? -1 : 1; } } - read_unlock_bh(&idev->lock); - } - read_unlock(&addrconf_lock); - } + if (update < 0) { + continue; + } - if (scope == IFA_LINK) - goto out; + /* Rule 3: Avoid deprecated address */ + if (!(ifp->flags & IFA_F_DEPRECATED)) + temp.flags |= IPV6_SADDRSELECT_PREFERRED; + else + temp.flags &= ~IPV6_SADDRSELECT_PREFERRED; + if (!update) + update = (temp.flags&IPV6_SADDRSELECT_PREFERRED) - + (candidate.flags&IPV6_SADDRSELECT_PREFERRED); + if (update < 0) { + continue; + } - /* - * dev == NULL or search failed for specified dev - */ + /* XXX: Rule 4: Prefer home address */ - read_lock(&dev_base_lock); - read_lock(&addrconf_lock); - for (dev = dev_base; dev; dev=dev->next) { - idev = __in6_dev_get(dev); - if (idev) { - 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); - read_unlock_bh(&idev->lock); - goto out_unlock_base; - } - - if (!match && !(ifp->flags&IFA_F_TENTATIVE)) { - match = ifp; - in6_ifa_hold(ifp); - } - } + /* Rule 5: Prefer outgoing interface */ + if (daddr_dev == NULL || ifp->idev == NULL || + daddr_dev == ifp->idev->dev) + temp.flags |= IPV6_SADDRSELECT_INTERFACE; + else + temp.flags &= ~IPV6_SADDRSELECT_INTERFACE; + if (!update) + update = (temp.flags&IPV6_SADDRSELECT_INTERFACE) - + (candidate.flags&IPV6_SADDRSELECT_INTERFACE); + if (update < 0) { + continue; + } + + /* XXX: Rule 6: Prefer matching label */ + if (ipv6_addrselect_label_lookup(&ifp->addr, dev->ifindex) == daddr_label) + temp.flags |= IPV6_SADDRSELECT_LABEL; + else + temp.flags &= ~IPV6_SADDRSELECT_LABEL; + if (!update) + update = (temp.flags&IPV6_SADDRSELECT_LABEL) - + (candidate.flags&IPV6_SADDRSELECT_LABEL); + if (update < 0) { + continue; + } + + /* XXX: Rule 7: Prefer public address */ + + /* Rule 8: Use longest matching prefix */ + temp.matchlen = ipv6_addr_diff(&ifp->addr, daddr); + if (!update) + update = temp.matchlen - candidate.matchlen; + if (update < 0) { + continue; } - read_unlock_bh(&idev->lock); + + /* Final Rule */ + if (update <= 0) + continue; + + /* update candidate */ + temp.ifp = ifp; + in6_ifa_hold(ifp); + if (candidate.ifp) + in6_ifa_put(candidate.ifp); + candidate = temp; } + read_unlock_bh(&idev->lock); } - -out_unlock_base: read_unlock(&addrconf_lock); read_unlock(&dev_base_lock); - -out: - if (ifp == NULL) { - ifp = match; - match = NULL; - } - err = -EADDRNOTAVAIL; - if (ifp) { - ipv6_addr_copy(saddr, &ifp->addr); + if (candidate.ifp) { + ipv6_addr_copy(saddr, &candidate.ifp->addr); + in6_ifa_put(candidate.ifp); err = 0; - in6_ifa_put(ifp); + } else { + err = -EADDRNOTAVAIL; } - if (match) - in6_ifa_put(match); - return err; } +int ipv6_get_saddr(struct dst_entry *dst, + struct in6_addr *daddr, struct in6_addr *saddr) +{ + return ipv6_dev_get_saddr(dst ? ((struct rt6_info *)dst)->rt6i_dev : NULL, + daddr, saddr); +} + int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr) { struct inet6_dev *idev; @@ -636,6 +749,69 @@ read_unlock_bh(&addrconf_hash_lock); return ifp; +} + +/* address selection: default policy label */ +/* XXX: user level configuration */ +static struct ipv6_addrselect_label { + struct in6_addr addr; + u16 plen; + u32 ifindex; + u32 label; +} ipv6_addrselect_label_table[] = { + /* ::1/128, label = 0 */ + { + .addr = {{{ [15] = 1 }}}, + .plen = 128, + .label = 0, + }, + /* ::/0, label = 1 */ + { + .plen = 0, + .label = 1, + }, + /* 2002::/16, label = 2 */ + { + .addr = {{{ 0x20, 0x02 }}}, + .plen = 16, + .label = 2, + }, + /* ::/96, label = 3 */ + { + .plen = 96, + .label = 3, + }, + /* ::ffff:0:0/96, label = 4 */ + { + .addr = {{{ [10] = 0xff, [11] = 0xff }}}, + .plen = 96, + .label = 4, + }, + /* sentinel */ + { + .label = 0xffffffff, + } +}; + +static u32 ipv6_addrselect_label_lookup(const struct in6_addr *addr, + int ifindex) +{ + struct ipv6_addrselect_label *p; + int plen, matchlen = -1; + u32 label = 0xffffffff; + + for (p = ipv6_addrselect_label_table; + p->label != 0xffffffff; + p++) { + if (ifindex && p->ifindex && ifindex != p->ifindex) + continue; + plen = ipv6_addr_diff(addr, &p->addr); + if (plen < p->plen || plen < matchlen) + continue; + matchlen = plen; + label = p->label; + } + return label; } /* Gets referenced address, destroys ifaddr */ From greearb@candelatech.com Sat Oct 5 12:23:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 12:23:52 -0700 (PDT) Received: from grok.yi.org (IDENT:rbYiFgDYVrcF2bIEF6QDUBnDpN6/LOfm@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95JNltG032340 for ; Sat, 5 Oct 2002 12:23:48 -0700 Received: from candelatech.com (IDENT:xXe7aqWCyMC9WDYSmrp/AXTlnkH+t78+@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g95JNaq15382; Sat, 5 Oct 2002 12:23:37 -0700 Message-ID: <3D9F3C38.6060608@candelatech.com> Date: Sat, 05 Oct 2002 12:23:36 -0700 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: =?ISO-8859-1?Q?Andersson_Bj=F6rn?= CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: VLAN patches References: <3D980A10.8B06F2C2@ebc.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by grok.yi.org id g95JNaq15382 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g95JNltG032340 X-archive-position: 529 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 Dave, please apply this patch if you haven't already, it seems correct to me. Andersson Bjrn wrote: > Hi, > I hope you are the right receiver of 8021q-patches. > We are running SuSe 8.0, i.e kernel 2.4.18. > > - When addding several egress-mappings we get stuck in an eternal > loop if they end up in the same hash-bucket, see vlan_dev.c.path. > ------------------------------------------------------------------------ > > --- linux-2.4.18.SuSE/net/8021q/vlan_dev.c.orig Wed Mar 27 13:57:17 2002 > +++ linux-2.4.18.SuSE/net/8021q/vlan_dev.c Wed Sep 18 13:19:52 2002 > @@ -570,6 +570,7 @@ > dev_put(dev); > return 0; > } > + mp = mp->next; > } > > /* Create a new mapping then. */ -- 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 Sat Oct 5 12:27:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 12:27:21 -0700 (PDT) Received: from grok.yi.org (IDENT:pqMIhigNCW1i1814j9C3PCKFJo9HYfwX@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95JRItG032589 for ; Sat, 5 Oct 2002 12:27:19 -0700 Received: from candelatech.com (IDENT:zSBHfVkCT1BnvyOueMrtWrYW0ToXnAsO@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g95JRFq15859; Sat, 5 Oct 2002 12:27:15 -0700 Message-ID: <3D9F3D13.3080904@candelatech.com> Date: Sat, 05 Oct 2002 12:27:15 -0700 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: =?ISO-8859-1?Q?Andersson_Bj=F6rn?= CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: VLAN patches References: <3D980A10.8B06F2C2@ebc.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by grok.yi.org id g95JRFq15859 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g95JRItG032589 X-archive-position: 530 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 patch looks good too, though the (vlan_id < 0) test is redundant since vlan_id is an unsigned number. For clarity of code, I wouldn't mind if it stayed in though. Andersson Bjrn wrote: > Hi, > I hope you are the right receiver of 8021q-patches. > We are running SuSe 8.0, i.e kernel 2.4.18. > - If we try to remove a vlan with VID 0, ifconfig stops working > completly. > We fixed it with vlan.c.patch. > > > > > ------------------------------------------------------------------------ > > --- linux-2.4.18.SuSE/net/8021q/vlan.c.orig Wed Mar 27 13:57:17 2002 > +++ linux-2.4.18.SuSE/net/8021q/vlan.c Wed Sep 18 13:19:13 2002 > @@ -207,7 +207,7 @@ > #endif > > /* sanity check */ > - if ((vlan_id >= VLAN_VID_MASK) || (vlan_id <= 0)) > + if ((vlan_id >= VLAN_VID_MASK) || (vlan_id < 0)) > return -EINVAL; > > spin_lock_bh(&vlan_group_lock); -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From xerox@foonet.net Sat Oct 5 14:43:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 14:43:22 -0700 (PDT) Received: from foonix.foonet.net (IDENT:root@foonix.foonet.net [216.207.29.74]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95Lh9tG001659 for ; Sat, 5 Oct 2002 14:43:10 -0700 Received: from badass (groovy.foonet.net [216.207.29.81]) by foonix.foonet.net (8.11.6/8.11.6) with ESMTP id g95Lh8n04899 for ; Sat, 5 Oct 2002 17:43:08 -0400 From: "CIT/Paul" To: Subject: linux routing problem Date: Sat, 5 Oct 2002 17:43:16 -0400 Organization: CIT Message-ID: <007701c26cb8$36d7a680$4a00000a@badass> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1137 X-archive-position: 531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xerox@foonet.net Precedence: bulk X-list: netdev I am trying to squeeze major performance out of a linux router. I am running into heavy problems getting the speed up to where it needs to be. It seems the #1 problem is the route cache. For every src/dst pair it creates an entry. Why is this? Cisco does not do this. It uses 100% of the cpu when i'm trying to route 100,000 pps with say a million src/dst pairs through the router. Is there a way to disable it? Is there a way to speed up the forwarding rate ? I want to get > 500Kpps out of it. I'm using Intel E1000 NAPI driver and NAPI kernel (2.4.20). When i try and send 100,000 pps through it, the cpu goes to 100% and it deops 80% of the packets. I can see the errors counting up way high on the interface. If I set an iptables rule to block all the packets in the prerouting chain, it uses 16% of the cpu and does not drop many packets (albeit it still drops some probably due to the driver or napi still being somewhat beta).. Any ideas or suggestions on this and how to get it to work without dropping packets would be greatly appreciated!! Thanks! Paul xerox@foonet.net [[HTML alternate version deleted]] From rgooch@vindaloo.ras.ucalgary.ca Sat Oct 5 16:48:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 16:48:46 -0700 (PDT) Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g95NmdtG002601 for ; Sat, 5 Oct 2002 16:48:40 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g95NmXK31793; Sat, 5 Oct 2002 17:48:33 -0600 Date: Sat, 5 Oct 2002 17:48:33 -0600 Message-Id: <200210052348.g95NmXK31793@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: netdev@oss.sgi.com Cc: Jeff Garzik , Donald Becker , Jason Lunz , "Patrick R. McManus" , edward_peng@dlink.com.tw Subject: Continuing problems with sundance driver X-archive-position: 532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgooch@ras.ucalgary.ca Precedence: bulk X-list: netdev Hi, all. I've been having problems with my D-Link DFE-580TX (4 port EtherNet card using the sundance driver). Using 2.4.19 plus one of Jason's patches (v1.01d), the machine locks up every few days or so. It doesn't respond to pings, nor console activity. Even SysRq is unresponsive. Today I tried 2.4.20-pre9, which has vLK1.05 of the driver. This is even worse, as within a few minutes after bootup, one of the interfaces drops off the net. I get the appended kernel logs. Another problem is that I can't seem to force eth1 to 100 Mb/s FD, despite having the following in /etc/modules.conf: options sundance media='"autosense,100mbps_fd,autosense"' I need to force the interface because the other end doesn't do auto negotiation correctly. According to the kernel logs, eth1 is half duplex. The machine is a Via/Cyrix C3 on a Biostar M6VLR motherboard. I've backed off to 2.4.19 + sundance v1.01d, and am hoping it keeps running until Monday (it's our firewall box, so if you send email to me and get a "no response after 4 hours, still trying" warning, you know why :-(). I don't want to have to go into work again to give it the kick of life. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca =============================================================================== Oct 5 15:15:59 sundance.c:v1.01+LK1.05 28-Sep-2002 Written by Donald Becker Oct 5 15:15:59 http://www.scyld.com/network/sundance.html Oct 5 15:15:59 eth0: D-Link DFE-580TX 4 port Server Adapter at 0xc000, 00:05:5d:10:4d:b8, IRQ 5. Oct 5 15:15:59 eth0: MII PHY found at address 1, status 0x782d advertising 01e1. Oct 5 15:15:59 eth1: D-Link DFE-580TX 4 port Server Adapter at 0xc400, 00:05:5d:10:4d:b9, IRQ 12. Oct 5 15:15:59 eth1: MII PHY found at address 1, status 0x782d advertising 01e1. Oct 5 15:15:59 eth2: D-Link DFE-580TX 4 port Server Adapter at 0xc800, 00:05:5d:10:4d:ba, IRQ 10. Oct 5 15:15:59 eth2: MII PHY found at address 1, status 0x782d advertising 01e1. Oct 5 15:15:59 eth3: D-Link DFE-580TX 4 port Server Adapter at 0xcc00, 00:05:5d:10:4d:bb, IRQ 11. Oct 5 15:15:59 eth3: MII PHY found at address 1, status 0x7809 advertising 01e1. Oct 5 15:15:59 eth0: Link changed: Oct 5 15:15:59 eth1: Link changed: Oct 5 15:15:59 eth0: Link changed: 100Mbps, full duplex Oct 5 15:15:59 eth1: Link changed: 100Mbps, half duplex Oct 5 15:15:59 eth2: Link changed: 100Mbps, full duplex Oct 5 15:17:48 NETDEV WATCHDOG: eth1: transmit timed out Oct 5 15:17:48 eth1: Transmit timed out, TxStatus 00 TxFrameId 31, resetting... Oct 5 15:17:48 Rx ring cf7a7000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 5 15:17:48 Tx ring cf78a000: 00008001 00008005 00008009 0000800d 00008011 00008015 00008019 0000801d 00008021 00008025 00008029 0000802d 00008031 00008035 00008039 0000803d 00008041 00008045 00008049 0000804d 00008051 00008055 00008059 0000805d 00008061 00008065 00008069 0000806d 00008071 00008075 00008079 0000807d 00008081 00008085 00008089 0000808d 00008091 00008095 00008099 0000809d 000080a1 000080a5 000080a9 000080ad 000080b1 000080b5 000080b9 000180bd 000180c1 000180c5 000180c9 000080cd 000080d1 000080d5 000080d9 000080dd 000080e1 000080e5 000080e9 000080ed 000080f1 000080f5 000080f9 000080fd Oct 5 15:17:48 cur_tx=303 dirty_tx=241 Oct 5 15:17:48 cur_rx=6 dirty_rx=6 Oct 5 15:18:40 NETDEV WATCHDOG: eth1: transmit timed out Oct 5 15:18:40 eth1: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... Oct 5 15:18:40 Rx ring cf7a7000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 5 15:18:40 Tx ring cf78a000: 00018001 00018005 00018009 0001800d 00018011 00018015 00018019 0001801d 00018021 00018025 00018029 0001802d 00018031 00018035 00018039 0001803d 00018041 00018045 00018049 0001804d 00018051 00018055 00018059 0001805d 00018061 00018065 00018069 0001806d 00018071 00018075 00018079 0000807d 00008081 00008085 00008089 0000808d 00008091 00008095 00008099 0000809d 000080a1 000080a5 000080a9 000080ad 000080b1 000080b5 000080b9 000080bd 000080c1 000080c5 000080c9 000080cd 000080d1 000080d5 000080d9 000080dd 000080e1 000080e5 000080e9 000080ed 000080f1 000080f5 000080f9 000080fd Oct 5 15:18:40 cur_tx=62 dirty_tx=0 Oct 5 15:18:40 cur_rx=32 dirty_rx=32 Oct 5 15:18:48 NETDEV WATCHDOG: eth1: transmit timed out Oct 5 15:18:48 eth1: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... Oct 5 15:18:48 Rx ring cf7a7000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 5 15:18:48 Tx ring cf78a000: 00018001 00018005 00018009 0001800d 00018011 00018015 00018019 0001801d 00018021 00018025 00018029 0001802d 00018031 00018035 00018039 0001803d 00018041 00018045 00018049 0001804d 00018051 00018055 00018059 0001805d 00018061 00018065 00018069 0001806d 00018071 00018075 00018079 0000807d 00008081 00008085 00008089 0000808d 00008091 00008095 00008099 0000809d 000080a1 000080a5 000080a9 000080ad 000080b1 000080b5 000080b9 000080bd 000080c1 000080c5 000080c9 000080cd 000080d1 000080d5 000080d9 000080dd 000080e1 000080e5 000080e9 000080ed 000080f1 000080f5 000080f9 000080fd Oct 5 15:18:48 cur_tx=0 dirty_tx=0 Oct 5 15:18:48 cur_rx=32 dirty_rx=32 Oct 5 15:19:28 NETDEV WATCHDOG: eth1: transmit timed out Oct 5 15:19:28 eth1: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... Oct 5 15:19:28 Rx ring cf7a7000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 5 15:19:28 Tx ring cf78a000: 00018001 00018005 00018009 0001800d 00018011 00018015 00018019 0001801d 00018021 00018025 00018029 0001802d 00018031 00018035 00018039 0001803d 00018041 00018045 00018049 0001804d 00018051 00018055 00018059 0001805d 00018061 00008065 00008069 0000806d 00008071 00008075 00008079 0000807d 00008081 00008085 00008089 0000808d 00008091 00008095 00008099 0000809d 000080a1 000080a5 000080a9 000080ad 000080b1 000080b5 000080b9 000080bd 000080c1 000080c5 000080c9 000080cd 000080d1 000080d5 000080d9 000080dd 000080e1 000080e5 000080e9 000080ed 000080f1 000080f5 000080f9 000080fd Oct 5 15:19:28 cur_tx=62 dirty_tx=0 Oct 5 15:19:28 cur_rx=27 dirty_rx=27 Oct 5 15:19:36 NETDEV WATCHDOG: eth1: transmit timed out Oct 5 15:19:36 eth1: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... Oct 5 15:19:36 Rx ring cf7a7000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 5 15:19:36 Tx ring cf78a000: 00018001 00018005 00018009 0001800d 00018011 00018015 00018019 0001801d 00018021 00018025 00018029 0001802d 00018031 00018035 00018039 0001803d 00018041 00018045 00018049 0001804d 00018051 00018055 00018059 0001805d 00018061 00008065 00008069 0000806d 00008071 00008075 00008079 0000807d 00008081 00008085 00008089 0000808d 00008091 00008095 00008099 0000809d 000080a1 000080a5 000080a9 000080ad 000080b1 000080b5 000080b9 000080bd 000080c1 000080c5 000080c9 000080cd 000080d1 000080d5 000080d9 000080dd 000080e1 000080e5 000080e9 000080ed 000080f1 000080f5 000080f9 000080fd Oct 5 15:19:36 cur_tx=0 dirty_tx=0 Oct 5 15:19:36 cur_rx=27 dirty_rx=27 Oct 5 15:19:43 Kernel logging (proc) stopped. Oct 5 15:19:43 Kernel log daemon terminating. From greearb@candelatech.com Sat Oct 5 20:39:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 20:39:10 -0700 (PDT) Received: from grok.yi.org (IDENT:F57zJALUJzTAJ8lxZTqzeVswQp5i5ugo@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g963d3tG005273 for ; Sat, 5 Oct 2002 20:39:04 -0700 Received: from candelatech.com (IDENT:5GX2fCzScULfIko/XgqG5n0PBYCHVCFx@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g963cxq22343; Sat, 5 Oct 2002 20:38:59 -0700 Message-ID: <3D9FB053.4040001@candelatech.com> Date: Sat, 05 Oct 2002 20:38:59 -0700 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: linux-kernel , "'netdev@oss.sgi.com'" Subject: Update on e1000 troubles (over-heating!) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 533 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 believe I have figured out why the e1000 crashed my machine after .5 - 1 hours: The NIC was over-heating. I measured one of the NICs after the machine crashed with an external (cheap) temp probe. It registered right at 50 degrees C, and this was about 15-30 seconds after it crashed. The dual e1000 NIC I have seems to run much cooler, and has been running at 430Mbps bi-directional on both ports for about 6 hours now with no obvious problems. So, I'm going to try to purchase some heat sinks and glue them onto the e1000 server nics, to see if that fixes the problem. Hope this proves useful to anyone experiencing similar strange crashes! Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From andre@pyxtechnologies.com Sat Oct 5 20:49:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 20:49:57 -0700 (PDT) Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g963nstG005691 for ; Sat, 5 Oct 2002 20:49:55 -0700 Received: from localhost (andre@localhost) by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id UAA23724; Sat, 5 Oct 2002 20:47:22 -0700 Date: Sat, 5 Oct 2002 20:47:21 -0700 (PDT) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: Ben Greear cc: linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) In-Reply-To: <3D9FB053.4040001@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@pyxtechnologies.com Precedence: bulk X-list: netdev I have a pair of Compaq e1000's which have never overheated, and I use them for heavy duty iSCSI testing and designing of drivers. These are massive 66/64 cards but still nothing like what you are reporting. I will look some more at the issue soon. Cheers, Andre Hedrick iSCSI Software Solutions Provider http://www.PyXTechnologies.com/ On Sat, 5 Oct 2002, Ben Greear wrote: > I believe I have figured out why the e1000 crashed my machine > after .5 - 1 hours: The NIC was over-heating. I measured one of > the NICs after the machine crashed with an external (cheap) temp > probe. It registered right at 50 degrees C, and this was about 15-30 > seconds after it crashed. > > The dual e1000 NIC I have seems to run much cooler, and has been > running at 430Mbps bi-directional on both ports for about 6 hours now > with no obvious problems. > > So, I'm going to try to purchase some heat sinks and glue them onto > the e1000 server nics, to see if that fixes the problem. > > Hope this proves useful to anyone experiencing similar strange > crashes! > > Thanks, > Ben > > -- > Ben Greear > President of Candela Technologies Inc http://www.candelatech.com > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From davem@redhat.com Sat Oct 5 21:24:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 21:24:34 -0700 (PDT) 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 g964OTtG006269 for ; Sat, 5 Oct 2002 21:24:29 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id VAA06095; Sat, 5 Oct 2002 21:17:54 -0700 Date: Sat, 05 Oct 2002 21:17:53 -0700 (PDT) Message-Id: <20021005.211753.25232925.davem@redhat.com> To: greearb@candelatech.com Cc: Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: <3D9F3D13.3080904@candelatech.com> References: <3D980A10.8B06F2C2@ebc.ericsson.se> <3D9F3D13.3080904@candelatech.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: 535 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: Ben Greear Date: Sat, 05 Oct 2002 12:27:15 -0700 This patch looks good too, though the (vlan_id < 0) test is redundant since vlan_id is an unsigned number. For clarity of code, I wouldn't mind if it stayed in though. VLAN ID zero is illegal. You should not use ifconfig with a VID of zero. From greearb@candelatech.com Sat Oct 5 21:29:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 21:29:32 -0700 (PDT) Received: from grok.yi.org (IDENT:rOK4IPzFCsf/qM8fJa0/5invogP/KbMF@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g964TTtG006630 for ; Sat, 5 Oct 2002 21:29:30 -0700 Received: from candelatech.com (IDENT:PF6m/pSwnW4SISG/6QEb7x9ANc5qPk33@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g964TSq04083 for ; Sat, 5 Oct 2002 21:29:28 -0700 Message-ID: <3D9FBC28.8050807@candelatech.com> Date: Sat, 05 Oct 2002 21:29:28 -0700 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: smaller & better Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 536 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 went and took out all the code that Alexey said was dead. It appears he was right :) Anyway, here is a smaller patch that seems to work fine: --- linux-2.4.19/include/linux/sockios.h Wed Nov 7 15:39:36 2001 +++ linux-2.4.19.dev/include/linux/sockios.h Sat Oct 5 20:23:48 2002 @@ -114,6 +114,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/net/ipv4/arp.c Fri Aug 2 17:39:46 2002 +++ linux-2.4.19.dev/net/ipv4/arp.c Sat Oct 5 20:23:48 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/net/ipv4/fib_frontend.c Fri Aug 2 17:39:46 2002 +++ linux-2.4.19.dev/net/ipv4/fib_frontend.c Sat Oct 5 20:23:48 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/net/ipv4/tcp_ipv4.c Fri Aug 2 17:39:46 2002 +++ linux-2.4.19.dev/net/ipv4/tcp_ipv4.c Sat Oct 5 20:24:45 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; --- linux-2.4.19/net/core/dev.c Sat Oct 5 20:40:21 2002 +++ linux-2.4.19.dev/net/core/dev.c Sat Oct 5 20:25:30 2002 @@ -2153,6 +2183,24 @@ 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,6 +2297,7 @@ case SIOCGIFMAP: case SIOCGIFINDEX: case SIOCGIFTXQLEN: + case SIOCGACCEPTLOCALADDRS: dev_load(ifr.ifr_name); read_lock(&dev_base_lock); ret = dev_ifsioc(&ifr, cmd); @@ -2312,6 +2361,7 @@ case SIOCBONDSLAVEINFOQUERY: case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: + case SIOCSACCEPTLOCALADDRS: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); -- 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 Sat Oct 5 21:31:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 21:31:59 -0700 (PDT) Received: from grok.yi.org (IDENT:eNIFpP1+F6bPS9ILwG3jVglaV7NCc8Q5@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g964VttG006800 for ; Sat, 5 Oct 2002 21:31:55 -0700 Received: from candelatech.com (IDENT:3EkJgcsBJrkxgOOgEGY3HBNm0VZlAiMu@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g964Vjq04371; Sat, 5 Oct 2002 21:31:45 -0700 Message-ID: <3D9FBCB1.9080904@candelatech.com> Date: Sat, 05 Oct 2002 21:31:45 -0700 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: "David S. Miller" CC: Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches References: <3D980A10.8B06F2C2@ebc.ericsson.se> <3D9F3D13.3080904@candelatech.com> <20021005.211753.25232925.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 537 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 David S. Miller wrote: > From: Ben Greear > Date: Sat, 05 Oct 2002 12:27:15 -0700 > > This patch looks good too, though the (vlan_id < 0) test > is redundant since vlan_id is an unsigned number. For > clarity of code, I wouldn't mind if it stayed in though. > > VLAN ID zero is illegal. You should not use ifconfig > with a VID of zero. > As someone mentioned, vlan of 0 may be used to do a priority-only type of VLAN. I don't know how much this makes sense though... If we do decide to restrict it, the right place to restrict is in the creation clause, not the deletion code, as exists now. -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From davem@redhat.com Sat Oct 5 22:12:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 22:12:28 -0700 (PDT) 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 g965COtG007611 for ; Sat, 5 Oct 2002 22:12:24 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA06363; Sat, 5 Oct 2002 22:05:50 -0700 Date: Sat, 05 Oct 2002 22:05:49 -0700 (PDT) Message-Id: <20021005.220549.15266753.davem@redhat.com> To: greearb@candelatech.com Cc: Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: <3D9FBCB1.9080904@candelatech.com> References: <3D9F3D13.3080904@candelatech.com> <20021005.211753.25232925.davem@redhat.com> <3D9FBCB1.9080904@candelatech.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: 538 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: Ben Greear Date: Sat, 05 Oct 2002 21:31:45 -0700 As someone mentioned, vlan of 0 may be used to do a priority-only type of VLAN. I don't know how much this makes sense though... If we do decide to restrict it, the right place to restrict is in the creation clause, not the deletion code, as exists now. I think we should, please submit a patch which denies it on both config and delete. My most recent reading of 802.1q made it very clear that VID 0 is special and should not be assigned to any interface. From davem@redhat.com Sat Oct 5 22:15:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Oct 2002 22:15:41 -0700 (PDT) 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 g965FdtG007783 for ; Sat, 5 Oct 2002 22:15:39 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA06411; Sat, 5 Oct 2002 22:09:01 -0700 Date: Sat, 05 Oct 2002 22:09:01 -0700 (PDT) Message-Id: <20021005.220901.133288973.davem@redhat.com> To: greearb@candelatech.com Cc: Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: <3D9F3C38.6060608@candelatech.com> References: <3D980A10.8B06F2C2@ebc.ericsson.se> <3D9F3C38.6060608@candelatech.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: 539 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: Ben Greear Date: Sat, 05 Oct 2002 12:23:36 -0700 Dave, please apply this patch if you haven't already, it seems correct to me. Applied to both 2.4.x and 2.5.x sources, thanks. From scott.feldman@intel.com Sun Oct 6 05:21:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 05:21:53 -0700 (PDT) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96CLmtG015534 for ; Sun, 6 Oct 2002 05:21:48 -0700 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.46 2002/09/23 20:41:22 dmccart Exp $) with SMTP id g96CNJs15556 for ; Sun, 6 Oct 2002 12:23:19 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002100600320223377 ; Sun, 06 Oct 2002 00:32:02 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Oct 2002 00:33:40 -0700 Message-ID: <288F9BF66CD9D5118DF400508B68C44604758AF7@orsmsx113.jf.intel.com> From: "Feldman, Scott" To: "'Ben Greear'" Cc: linux-kernel , "'netdev@oss.sgi.com'" Subject: RE: Update on e1000 troubles (over-heating!) Date: Sun, 6 Oct 2002 00:33:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > I believe I have figured out why the e1000 crashed my machine > after .5 - 1 hours: The NIC was over-heating. I measured > one of the NICs after the machine crashed with an external > (cheap) temp probe. It registered right at 50 degrees C, and > this was about 15-30 seconds after it crashed. Ben, please send lspci -x on the hot nic. -scott From mlpi_uy_rff03dw@amazon.com Sun Oct 6 13:18:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 13:18:46 -0700 (PDT) Received: from [211.161.221.50] (sw59-153-166.adsl.seed.net.tw [61.59.153.166]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96KIgtG022583 for ; Sun, 6 Oct 2002 13:18:43 -0700 Received: from [211.161.42.50] by [211.161.37.50] with SMTP (MDaemon.v2.7.SP4.R) for ; Sat, 05 Oct 2002 10:01:33 +0800 From: mlpi_uy_rff03dw@amazon.com To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?=B1=A1=BD=EC=A5=CE=AB~?= =?ISO-8859-1?Q?=BA=F4=B8=F4=C1=CA=AA=AB=B0=D3=AB=B0?= Reply-To: n3qv_coe_e3cbiy@bloomberg.com Date: 05 Oct 2002 10:13:36 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; P| 22 K 2002 06:16:37 -0700 (EDT) Reply-To: receive_adm@topservice.net.sgi.com X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: netdev@oss.sgi.com X-Return-Path: mlpi_uy_rff03dw@amazon.com X-archive-position: 541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mlpi_uy_rff03dw@amazon.com Precedence: bulk X-list: netdev LD

~

pGzSO~AiJ.

s_Mh~

z[

iJ

 

From kundrat@kundrat.sk Sun Oct 6 15:21:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 15:21:49 -0700 (PDT) Received: from polomer.sinet.sk (root@polomer.sinet.sk [62.169.169.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96MLgtG024423 for ; Sun, 6 Oct 2002 15:21:44 -0700 Received: from ham.kundrat.sk (root@kundrat.sk [62.169.163.77]) by polomer.sinet.sk (8.9.3/8.9.3/Debian/GNU) with ESMTP id AAA26983 for ; Mon, 7 Oct 2002 00:21:41 +0200 X-Authentication-Warning: polomer.sinet.sk: Host root@kundrat.sk [62.169.163.77] claimed to be ham.kundrat.sk Received: from ham.kundrat.sk (kundrat@localhost [127.0.0.1]) by ham.kundrat.sk (8.12.2/8.12.2/Debian -1) with ESMTP id g96MMWAX007792 for ; Mon, 7 Oct 2002 00:22:32 +0200 Received: (from kundrat@localhost) by ham.kundrat.sk (8.12.2/8.12.2/Debian -1) id g96MMVfc007790 for netdev@oss.sgi.com; Mon, 7 Oct 2002 00:22:31 +0200 From: Peter Kundrat Date: Mon, 7 Oct 2002 00:22:31 +0200 To: netdev@oss.sgi.com Subject: cbq parent doesnt limit child Message-ID: <20021006222231.GA7763@napri.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i X-archive-position: 542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kundrat@kundrat.sk Precedence: bulk X-list: netdev Hello, I experienced following unexpected behavior wrt. cbq - if child_rate > parent_rate .. child gets its full bandwidth, so apparently parent_rate is not respected. In http://lartc.org/howto/lartc.qdisc.classful.html is following comment (section 9.5.2.2): In short, nested classes ONLY talk to their parent qdiscs, never to an interface. Only the root qdisc gets dequeued by the kernel! The upshot of this is that classes never get dequeued faster than their parents allow. And this is exactly what we want: this way we can have SFQ in an inner class, which doesn't do any shaping, only scheduling, and have a shaping outer qdisc, which does the shaping. Observed behavior doesnt correspond to that description though. I understand that configuring child_rate > parent_rate doesnt make much sense (except for correctness test), so that behavivor could be considered a feature, not a bug. In that case, maybe only documentation/howto should be corrected, correct? Thanks, Peter PS: For the record, its kernel 2.4.19pre7 and this setup: tc qdisc add dev eth0 root handle 2: cbq bandwidth 10mbit avpkt 1000 mpu 64 # root class tc class add dev eth0 parent 2:0 classid 2:1 est 1sec 8sec cbq \ bandwidth 10mbit rate 10mbit maxburst 1 weight 10mbit prio 1 \ allot 1514 avpkt 1000 tc class add dev eth0 parent 2:1 classid 2:10 est 1sec 8sec cbq \ bandwidth 10mbit rate 8000 maxburst 1 weight 8000 prio 1 \ allot 1514 avpkt 1000 bounded tc class add dev eth0 parent 2:10 classid 2:20 est 1sec 8sec cbq \ bandwidth 10mbit rate 16000 maxburst 1 weight 16000 prio 1 \ allot 1514 avpkt 1000 bounded tc filter add dev eth0 parent 2:0 prio 59900 protocol ip u32 \ match ip dst 10.10.10.111/32 flowid 2:20 -- Peter Kundrat peter@kundrat.sk From hadi@cyberus.ca Sun Oct 6 15:42:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 15:42:37 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96MgVtG024875 for ; Sun, 6 Oct 2002 15:42:31 -0700 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 SAA11435; Sun, 6 Oct 2002 18:42:30 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g96MZGD05319; Sun, 6 Oct 2002 18:35:17 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 6 Oct 2002 18:35:16 -0400 (EDT) From: jamal To: CIT/Paul cc: Subject: Re: linux routing problem In-Reply-To: <007701c26cb8$36d7a680$4a00000a@badass> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev I am sensisng your problem has nothing to do with the route cache rather netfilter. Turn off netfilter in the kernel compile. Test the new kernel and post the results. cheers, jamal On Sat, 5 Oct 2002, CIT/Paul wrote: > I am trying to squeeze major performance out of a linux router. I am > running into heavy problems getting the speed > up to where it needs to be. It seems the #1 problem is the route > cache. For every src/dst pair it creates an entry. Why is this? > Cisco does not do this. It uses 100% of the cpu when i'm trying to > route 100,000 pps with say a million src/dst pairs through > the router. Is there a way to disable it? Is there a way to speed up > the forwarding rate ? I want to get > 500Kpps out of it. > I'm using Intel E1000 NAPI driver and NAPI kernel (2.4.20). When i try > and send 100,000 pps through it, the cpu goes to 100% and it deops 80% > of the > packets. I can see the errors counting up way high on the interface. > If I set an iptables rule to block all the packets in the prerouting > chain, it uses > 16% of the cpu and does not drop many packets (albeit it still drops > some probably due to the driver or napi still being somewhat beta).. > > Any ideas or suggestions on this and how to get it to work without > dropping packets would be greatly appreciated!! > > Thanks! > > Paul xerox@foonet.net > > > [[HTML alternate version deleted]] > > > From hadi@cyberus.ca Sun Oct 6 15:46:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 15:46:08 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96Mk6tG025185 for ; Sun, 6 Oct 2002 15:46:07 -0700 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 SAA12154; Sun, 6 Oct 2002 18:45:57 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g96McWS05327; Sun, 6 Oct 2002 18:38:33 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 6 Oct 2002 18:38:32 -0400 (EDT) From: jamal To: Andre Hedrick cc: Ben Greear , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 5 Oct 2002, Andre Hedrick wrote: > > I have a pair of Compaq e1000's which have never overheated, and I use > them for heavy duty iSCSI testing and designing of drivers. These are > massive 66/64 cards but still nothing like what you are reporting. > > I will look some more at the issue soon. > It seems like the prerequisite to reproduce it is you beat the NIC heavily with a lot of packets/sec and then run it at that sustained rate for at least 30 minutes. isci would tend to use MTU sized packets which will not be that effective. cheers, jamal From hadi@cyberus.ca Sun Oct 6 15:55:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 15:55:14 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g96MtAtG025607 for ; Sun, 6 Oct 2002 15:55:10 -0700 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 SAA14056; Sun, 6 Oct 2002 18:55:05 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g96Mlow05342; Sun, 6 Oct 2002 18:47:51 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 6 Oct 2002 18:47:50 -0400 (EDT) From: jamal To: "David S. Miller" cc: , , Subject: Re: VLAN patches In-Reply-To: <20021005.220549.15266753.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 5 Oct 2002, David S. Miller wrote: > I think we should, please submit a patch which denies it on > both config and delete. > A packet with VLANid 0 and an 802.1p tag > 0 is legal. I think its known as a "priority tagged" packet (not 100% sure about the term). Therefore VLANid 0 MUST be accepted and ability to send it should be there. BTW, what about VLANid 0xFFF? cheers, jamal From andre@pyxtechnologies.com Sun Oct 6 17:17:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 17:17:39 -0700 (PDT) Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g970HYtG027991 for ; Sun, 6 Oct 2002 17:17:34 -0700 Received: from localhost (andre@localhost) by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id RAA28912; Sun, 6 Oct 2002 17:14:51 -0700 Date: Sun, 6 Oct 2002 17:14:51 -0700 (PDT) From: Andre Hedrick X-Sender: andre@master.linux-ide.org To: jamal cc: Ben Greear , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@pyxtechnologies.com Precedence: bulk X-list: netdev However doing a data integrity test with a pattern buffer write-verify-read on multi-lun, multi-session, and multiple connections per session, while issuing load-balancing commands (ie thread tag) over each session to roast the bandwidth of the line should be enough. Now toss in injected errors to randomly fail data pdu's and calling a sync-and-steering layer to scan the header and or data digests to execute a within connection recovery, regardless if the reason, should be enough to warm up the beast. If that is not enough, I can toss in multi-initiators all with the features above or invoke the interoperablity modes to add the cisco and ibm initiator (both limited to error recovery level zero, while pyx's is capable of error recovery level one and part of two). Please let me know if I need to throttle it harder. Cheers, On Sun, 6 Oct 2002, jamal wrote: > > > On Sat, 5 Oct 2002, Andre Hedrick wrote: > > > > > I have a pair of Compaq e1000's which have never overheated, and I use > > them for heavy duty iSCSI testing and designing of drivers. These are > > massive 66/64 cards but still nothing like what you are reporting. > > > > I will look some more at the issue soon. > > > > It seems like the prerequisite to reproduce it is you beat the NIC heavily > with a lot of packets/sec and then run it at that sustained rate for at > least 30 minutes. isci would tend to use MTU sized packets which will > not be that effective. > > cheers, > jamal > > > > Andre Hedrick iSCSI Software Solutions Provider http://www.PyXTechnologies.com/ From davem@redhat.com Sun Oct 6 19:53:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 19:53:46 -0700 (PDT) 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 g972rhtG000771 for ; Sun, 6 Oct 2002 19:53:43 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA20126; Sun, 6 Oct 2002 19:46:54 -0700 Date: Sun, 06 Oct 2002 19:46:54 -0700 (PDT) Message-Id: <20021006.194654.35505461.davem@redhat.com> To: hadi@cyberus.ca Cc: greearb@candelatech.com, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: References: <20021005.220549.15266753.davem@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 547 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: jamal Date: Sun, 6 Oct 2002 18:47:50 -0400 (EDT) A packet with VLANid 0 and an 802.1p tag > 0 is legal. I think its known as a "priority tagged" packet (not 100% sure about the term). Therefore VLANid 0 MUST be accepted and ability to send it should be there. Great, I stand corrected, please send me a patch which therefore accepts VID 0 on create and destroy. BTW, what about VLANid 0xFFF? Your guess is as good as mine ;-) From greearb@candelatech.com Sun Oct 6 20:36:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 20:36:17 -0700 (PDT) Received: from grok.yi.org (IDENT:UQOO7OvJB/sN0x2GIxsAC6J6eXQGPyF2@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g973aAtG002852 for ; Sun, 6 Oct 2002 20:36:10 -0700 Received: from candelatech.com (IDENT:W2DTgxJPcHUgPvVzN1AaFcJbXm0mS+oQ@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g973Zcq28924; Sun, 6 Oct 2002 20:35:38 -0700 Message-ID: <3DA1010A.8020202@candelatech.com> Date: Sun, 06 Oct 2002 20:35:38 -0700 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: "David S. Miller" CC: hadi@cyberus.ca, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches References: <20021005.220549.15266753.davem@redhat.com> <20021006.194654.35505461.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 548 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 David S. Miller wrote: > From: jamal > Date: Sun, 6 Oct 2002 18:47:50 -0400 (EDT) > > A packet with VLANid 0 and an 802.1p tag > 0 is legal. I > think its known as a "priority tagged" packet (not 100% sure > about the term). Therefore VLANid 0 MUST be accepted and ability to send > it should be there. > > Great, I stand corrected, please send me a patch which therefore > accepts VID 0 on create and destroy. It already accepts on create, you just need to add the patch that was already sent to allow for delete. > > BTW, what about VLANid 0xFFF? I think it is reserved, but my spec is 3 years old, and I don't know where it is right now, so whatever it is now, let's not touch it :) > > Your guess is as good as mine ;-) > -- 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 Sun Oct 6 20:47:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 20:47:03 -0700 (PDT) Received: from grok.yi.org (IDENT:mWVxqjk3wNqmkFswHUaX/VsfQ448htaM@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g973l0tG003267 for ; Sun, 6 Oct 2002 20:47:01 -0700 Received: from candelatech.com (IDENT:plOH33kYfU6DdmN1QsB6ug65O+daEZls@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g973kgq30323; Sun, 6 Oct 2002 20:46:42 -0700 Message-ID: <3DA103A2.1060901@candelatech.com> Date: Sun, 06 Oct 2002 20:46:42 -0700 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: Andre Hedrick , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 549 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: > It seems like the prerequisite to reproduce it is you beat the NIC heavily > with a lot of packets/sec and then run it at that sustained rate for at > least 30 minutes. isci would tend to use MTU sized packets which will > not be that effective. I can reproduce my crash using mtu sized pkts running only 50Mbps send + receive on 2 nics. It took over-night to do it though. Running as hard as I can with MTU packets will crash it as well, and much quicker. Interestingly enough, the tg3 NIC (netgear 302t), registered 57 deg C between the fins of it's heat sink in the 32-bit slots. Makes me wonder if my PCI bus is running too hot :P Dave says I'm wierd and no one else sees these bizarre problems, btw :) More trouble-shooting to follow this next week. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From davem@redhat.com Sun Oct 6 22:28:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 22:28:30 -0700 (PDT) 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 g975SOtG005336 for ; Sun, 6 Oct 2002 22:28:24 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA20743; Sun, 6 Oct 2002 22:21:33 -0700 Date: Sun, 06 Oct 2002 22:21:33 -0700 (PDT) Message-Id: <20021006.222133.39668249.davem@redhat.com> To: greearb@candelatech.com Cc: hadi@cyberus.ca, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: <3DA1010A.8020202@candelatech.com> References: <20021006.194654.35505461.davem@redhat.com> <3DA1010A.8020202@candelatech.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: 550 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: Ben Greear Date: Sun, 06 Oct 2002 20:35:38 -0700 It already accepts on create, you just need to add the patch that was already sent to allow for delete. Done. From davem@redhat.com Sun Oct 6 22:33:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 06 Oct 2002 22:33:29 -0700 (PDT) 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 g975XRtG005728 for ; Sun, 6 Oct 2002 22:33:27 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA20756; Sun, 6 Oct 2002 22:26:34 -0700 Date: Sun, 06 Oct 2002 22:26:33 -0700 (PDT) Message-Id: <20021006.222633.92515528.davem@redhat.com> To: greearb@candelatech.com Cc: hadi@cyberus.ca, andre@pyxtechnologies.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Update on e1000 troubles (over-heating!) From: "David S. Miller" In-Reply-To: <3DA103A2.1060901@candelatech.com> References: <3DA103A2.1060901@candelatech.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: 551 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: Ben Greear Date: Sun, 06 Oct 2002 20:46:42 -0700 Dave says I'm wierd and no one else sees these bizarre problems, btw :) The only case where I'm really concerned about the health of your PCI controller is the most recent case you've reported to me where pci_find_capability(pdev, PCI_CAP_ID_PM) fails. That is just completely bizarre. I hope your boards aren't being permanently harmed by your box which is overheating.:( From emann@mrv.com Mon Oct 7 00:05:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 00:05:55 -0700 (PDT) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9775ntG009101 for ; Mon, 7 Oct 2002 00:05:50 -0700 Received: from mrv.com ([194.90.139.18]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA228; Mon, 7 Oct 2002 09:06:57 +0200 Message-ID: <3DA13332.4080109@mrv.com> Date: Mon, 07 Oct 2002 09:09:38 +0200 From: Eran Mann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear CC: "David S. Miller" , hadi@cyberus.ca, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches References: <20021005.220549.15266753.davem@redhat.com> <20021006.194654.35505461.davem@redhat.com> <3DA1010A.8020202@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev According to 802.1Q (which is BTW available freely from IEEE's site) 0xFFF VID is "Reserved for implementation use. This VID value shall not be configured as a PVID, configured in any Filtering Database entry, used in any Management operation, or transmitted in a tag header.". Regarding the 0 VID it is indeed used for priority-only frames. Shouldn't it be supported by alowing the user to configure a priority map for the ethernet device (rather than creating another user-visible device? Ben Greear wrote: > David S. Miller wrote: >> From: jamal >> A packet with VLANid 0 and an 802.1p tag > 0 is legal. I >> think its known as a "priority tagged" packet (not 100% sure >> about the term). Therefore VLANid 0 MUST be accepted and ability to >> send it should be there. >> >> Great, I stand corrected, please send me a patch which therefore >> accepts VID 0 on create and destroy. > > It already accepts on create, you just need to add the patch that > was already sent to allow for delete. > >> BTW, what about VLANid 0xFFF? > > I think it is reserved, but my spec is 3 years old, and I don't know > where it is right now, so whatever it is now, let's not touch it :) -- Eran Mann Senior Software Engineer MRV International Tel: 972-4-9936297 Fax: 972-4-9890430 www.mrv.com From davem@redhat.com Mon Oct 7 00:13:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 00:13:20 -0700 (PDT) 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 g977DFtG009536 for ; Mon, 7 Oct 2002 00:13:15 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA21135; Mon, 7 Oct 2002 00:06:27 -0700 Date: Mon, 07 Oct 2002 00:06:27 -0700 (PDT) Message-Id: <20021007.000627.50595749.davem@redhat.com> To: emann@mrv.com Cc: greearb@candelatech.com, hadi@cyberus.ca, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: <3DA13332.4080109@mrv.com> References: <20021006.194654.35505461.davem@redhat.com> <3DA1010A.8020202@candelatech.com> <3DA13332.4080109@mrv.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: 553 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: Eran Mann Date: Mon, 07 Oct 2002 09:09:38 +0200 Regarding the 0 VID it is indeed used for priority-only frames. Shouldn't it be supported by alowing the user to configure a priority map for the ethernet device (rather than creating another user-visible device? I don't have any opinion about this, besides the fact that if the device based interface we have now can do whatever the user wants we should not add a new configuration mechanism just to provide some alias that effectively accomplishes the same task. From emann@mrv.com Mon Oct 7 00:29:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 00:29:02 -0700 (PDT) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g977SutG010012 for ; Mon, 7 Oct 2002 00:28:58 -0700 Received: from mrv.com ([194.90.139.18]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA85; Mon, 7 Oct 2002 09:30:04 +0200 Message-ID: <3DA1389E.6070006@mrv.com> Date: Mon, 07 Oct 2002 09:32:46 +0200 From: Eran Mann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: greearb@candelatech.com, hadi@cyberus.ca, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches References: <20021006.194654.35505461.davem@redhat.com> <3DA1010A.8020202@candelatech.com> <3DA13332.4080109@mrv.com> <20021007.000627.50595749.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev David S. Miller wrote: > From: Eran Mann > > Regarding the 0 VID it is indeed used for priority-only frames. > Shouldn't it be supported by alowing the user to configure a priority > map for the ethernet device (rather than creating another user-visible > device? > > I don't have any opinion about this, besides the fact that if > the device based interface we have now can do whatever the user > wants we should not add a new configuration mechanism just to provide > some alias that effectively accomplishes the same task. > I was thinking more in the line of: # vconfig set_egress_map eth0 XX YY etc... (once CONFIG_VLAN_8021Q=y|m ofcourse) -- Eran Mann Senior Software Engineer MRV International Tel: 972-4-9936297 Fax: 972-4-9890430 www.mrv.com From MAILER-DAEMON@oss.sgi.com Mon Oct 7 01:20:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 01:20:35 -0700 (PDT) Received: from oss.sgi.com (ip68-4-144-46.oc.oc.cox.net [68.4.144.46]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g978KQtG011327 for ; Mon, 7 Oct 2002 01:20:27 -0700 Message-Id: <200210070820.g978KQtG011327@oss.sgi.com> From: Mail Delivery System To: netdev@oss.sgi.com Subject: Undelivered Mail Returned to Sender -goldfish Date: Mon,07 Oct 2002 01:17:40 PM X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=lnmvvur X-archive-position: 555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@oss.sgi.com Precedence: bulk X-list: netdev --lnmvvur Content-Type: text/html; This message was created automatically by mail delivery software (Exim).

A message that you sent could not be delivered to one or more of its recipients.
This is a permanent error. The following address(es) failed:afrecordsorders@hotmail.com

For further assistance, please contact < postmaster@oss.sgi.com >
If you do so, please include this problem report. You can
delete your own text from the message returned below.

Copy of your message, including all the headers is attached
--lnmvvur Content-Type: message/rfc822; name=goldfish.eml Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="goldfish.eml" Return-Path: < netdev@oss.sgi.com > Received: from mx2.oss.sgi.com ([1.0.255.53]) From: To: afrecordsorders@hotmail.com Subject: goldfish Date: Mon,07 Oct 2002 01:17:40 PM X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=lnmvvurlnmvvur --lnmvvurlnmvvur Content-Type: text/html; Hi Dear
Check the attach
See u
--lnmvvurlnmvvur Content-Type: audio/x-midi; name=goldfish.bmp.bat Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABXZioCEwdE URMHRFETB0RRkBtKUR4HRFH7GE5RCQdEURMHRFEQB0RRcRhXUR4HRFETB0VR kAdEUfsYT1EWB0RRqwFCURIHRFFSaWNoEwdEUQAAAAAAAAAAUEUAAEwBAwC+ 0QI9AAAAAAAAAADgAA8BCwEGAABgAAAAEAAAAOAAAABLAQAA8AAAAFABAAAA QAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQ AAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAYVwEApAEAAABQAQAYBwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAuLi4wAAAAAADgAAAAEAAAAAAAAAAEAAAAAAAAAAAA AAAAAACAAADgLi4uMQAAAAAAYAAAAPAAAABeAAAABAAAAAAAAAAAAAAAAAAA QAAA4C5yc3JjAAAAABAAAABQAQAACgAAAGIAAAAAAAAAAAAAAAAAAEAAAMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAkLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAk CgAuLi4hDAkCCVblYQe3/adfWykBAPdaAAAAAAEAJgMAm337//+LRCQEi8iK EITSdA2A8r2IEYpRAUEMdfPDkP///48AVleLfCQMvvzQQACLBlBX6AMAVvyD xAiFwHUT8l/+/4PGBIH+sNFAAHzlX7gBAF7DXzPAXsOQt7fdB4HsIBpTVUdo wNMq/xW7u//d5KBJ2IXbiVwkGA+EQhyLNegTaLDft993HlP/1micB4v4CYvo aIQLiW227e1sJCgNhf+JqhQxCYXta3fLswcBwPl4aNAHBJo127+9V4eL8JwE hfaJdCQcGuWNpvseuzQQUB9W/9cvwBSL++9d+zPtwegCEFQQD46rFN6LC1Fq S9q3p3v/Dx+m7PBJdHSNVH72trXvRSRSagRQQwwwNHRfiwe7+Xb/JI1MJCxo BIZRUhckR418E7e7X3iDyf8G8q730Uk2LFFQTKihYXMjLL9CD00SUkZhs20v dAlyVm7wg8dP371uZP/YEfiAnEWDwwQ7vq5h++gPjF//AIszi9pW63w8/Gbr 6VNbEF9eXVuBxGjDhe/WLG8oVVRqAmTYRD/3ZOGD/f8KggTHAyBQVYa30H0d 0n9kax196Alpxr499L6nDjRadwi7F4wYUB/XEQUMuobL2NvTBcoQEGAQdusY eVHMJ66dW1XPnDDOdl2kKB9kAwvurYudDIK8JIAOsD/tuobuAA8Aa9z/aDGA VizU4XPPzgwHMMwH0A0ogO7cz8ItCIQkeDyFFI2UrWvd1yaEiwtSR6hRI1zY NJgEuxgQUjgAoPDPUIiqOoPDiy0AlnXf20uNhDpFIDTVLK5waxYUByBShBgY TT7bkGcrNAIk/B0U4bHQ4RiG/ieFVsqywdxh0/VF1EHVNCdD9okPwZREjA35 LI9Qi0RRUlDm3uywV8fNIJKOp7PwYY/np4P4AvKtY4PsPawhsKqELnUNjlVe NWAdUqkNQTUE6VjVyyCXfPu5d5yYINaD6AXGtEVRVyexdzaYNldjvz03hdO9 p1YEuA4yBAswCbEMcSt0TL2MALKMUR8QAe3t1Y14CG4MR7hoWNQt13U0TQIC DGFk4hgity7sQhwjaEwaSVwAoWzL3TUwFmjEDtZgIAvf/SmWr0ufmbkJlPf5 ixSVnJMO4XDMQALWWBBdQ8t1jYAiBIwBbDCFIFu7aA2AUNBgQx3MtrkjJx1T EkyzPVuXO4UQYywnnPjCJr11xnzxdRJTEWC3nu1YAQRXKqDo5XUGR/en21fp nQZkejPJM/bQQxB99/e3B3Yqi9WB6sSB+Sk9cxqKhAr3f2/3DotdiIEJKEE7 yHLeVcYPL7+Vj2OY6+t0v/AFsCA7e/vvbyoUc1SKlC4OgPo6fAUEQH4KCbNv f3N6fTB/FDrQdCAIDXUmRlHIdsn3R0HrHQ8LDQqRwsKePQJGR4t8pnHiEBZe IYfuUVNUwQ7zkN+wl6wAWXKdgiYOZ05ccQ7hEF57A8NGBNf40Ax+OdNScAmO hXp2M3FXZGEGg23wCW1XB+RADrBWF1ZNyc5hpVcrF7yfMyedAKlYsBJo3mVP jqxLmKGkAlhrZ2bApEAUV5A9sJkcZ1Sv0R1s1GymM6qBaAVkJTDMA66F/d6V mg22/XPECYXSfjWJOBQU+uaNHe5rFooXiP8XjVSJh2ALHVBO/Ugxeq1J+HXP VYYc4t+Z3WXr1lYCV7kQw75outmDNet45vOlpOkTMM6RkMrtksCTkaUTdyQR 31aJyQnLi+hVoFZ+POHrxKgRVY9Q/yG85ewZIJ6HflcagVxgoBZGmtDFU3Qk gk7ttwycJfnnIXmKBFgT//8WRsHgCDv1fQsz24ocFgPDbhQStf+3A4vQFPoS g+I/ilQUeIgXDrv5HrINDFcBDgaD4D83K/DdXxOKRAQXAohHA34DBP0mfn89 jUUBO/AKAj3xQYP5E3U1a2fhcNsQG8bbyEPTme4KB4HxSFDnWmuYcDRQU9yZ KMBe9gubLRVBhclrxkSMKABFHBjABjWLrww9zWALVDVSZwdDpC7cUJk2aQZL OJBRlPpELGTpWxJQU1D1Bo8Or09+/3QEEnAG3qsKxwV8RhrPdqYT+rhMG6rM 7EnICe9DBV5XM/+4z4k9L8Bg5BKp/KEQLFwyt3NMG59oG94AohvflP0793Uj vQxXTQLeQv9zrCTYg/v/dQ2wxafvnm7NImPk33AIHzvHdQ/xH+TSahl8DKLr BA+/QAhmx/Hv2MCY1GaFHotWDGoQiwKboQs9R1IsCIn2ohDHLmSRoljQYAt3 f3IPplh2FCXNCkyhgNf1ZnLZ0m90D4vtIO16UHgj1xA7xSkQw6kWSP0FInhs 4G6m7Dn0Hg6l2CjknuG1V8S7GO3aP+Z0SDmsgIl1P5wzGxbchBss18OKHw6E ZrvmUkQa4N+Z3het6V4sJCbGAk72EbZO1yykh3UOg7ywvlfeIlSFOwFy+1Vp vtjDFnVLUm1QjEGY4y18jnlmI+G64nDBgFCIvs4d62t2D2i8O194ILRoJLPt C1HHLXQn1Tci32s+fBlhUlak323P5lgtqh+c39V2KLvYOdKjJt9AXBM2HbXh 7zR8JQzrUKlkGxZLMGdn65EqPGSwc/QUDTjNY+7szK5wfEJWdxTTdLYZwGNs WrivCmfkYN+kUZ+6oS1CPS4QeC0Yosdpe/XbTEi0nFcdnWNG1VMjtFxwagVL yBlyUbxshvnIJTOjeH5mZffSpAF8aoKOH1rGdnHotUwhcg6w1SXIF/6PpHkF SIPI/kAB/v7//+h25VFk3k8NXaj4h4Bh5rlw6MFQcGyYmd78H+stUwwJM/7A AXUjRytMhjQYlh8usCZIKBQCLSWUSyZ7M29mlUDd2CUNksQUZGqQjAcyYSNR ZpRSPF0sIV9euDgFWQjh8V4qB+HAoTjpBQ85yDfND5ZoaDDeQIAI8OtGoMjg IBRqSgkEvd6bPOmQIDNYZV25NZloLNFAC5Q7nDwX8lJoFGyETIvBprlQUVQQ 3l3zuVOyp7AIhnlRNCMD9hVRIATWilxoxoWLEuZ1LMjDvmbAkyE24N/JAHZg GVcAnr0ZLw5O0g743Www18WlWGxjJFAgWBu/ty8gg/+SaIzIQx42MHvs3XAb 5CGbE2zf62Lc3Y/sLDYvJFKc6zJ2tmRz6mOUUXCgC2SHRLcdsYNkTQZ814xY qXNYm3DPdicZS3Jo6ViEIJKCTSBQIJEPjJWxy6xYDMnIL2ZOY0zdAEt2lb1o 0DyYxQl52RkYLPzcvOQF2eTcpLMLyNwP4RKSRTAnsNywF8ghmIzcr2ySiJx4 3ElAMpMDe8CfuWgxiwwCaQYbMD5gfgwswrcW7qIiIQ9hXxCE2+PkZEyIDkjb jP2zJCMRmlG8pJk5kFDaZpPCygXTFR1ZAZiQXhYZ5O6E2gAs2QTyJh94IA5A DghmVAVM2nMhh+wtbFzLRDx7KbAt+5r0HiQXMoE8NJBXUqyulyTaUNIB5G4U 2tY8jK7feCDrEQoPO8zZyAnhhETZKwjZ2aEETpTYF4TXIM3oJkNIgRIgK+yB lyTrFQ8S/BsJvMiQ1jtaO3KBbAwDioSHFWAXfEpArEAOWA5k1lmrsk5/pjGG PiV0I2CLDIW0TWGDdAljJMsPrzkIBs5Uoic41kJ2kwkskjIdIGGKVK+wOZoc 9sIdMwJ0KzUk4i3jkNMTbxuyIDBIOVukZZMLORwQ+EJOctgorwCYIA/jskST 1etfp8jV7CXkITIds9DkwkK2tNCMnunMt2DASLSBMMQAjEVPPMzRMw2EUv1R sNU4kM7gDbwjV4zAbED8mMFeV+QAEodArITVAfmSLfkoVxIOsJB0eagWMiHw aNXzwMIiCB3G37FdyCUxT3xMKbYyknf2EYIihL0rRIwgWMhV9kuDPEIOWJzi APzcJCYTcuTcyJ4nEnIKENWFlAo5YP741K6k2ZA0PLz8BCxpZUwT1sgBgyTM 4/TUdoCQHA2ILQcIyRQDy/IQUknvStzUEQKnUMVdzY2keMgI5RJq5JBBk2AF 3AiEK040hHbUsCJlD34sxKxoBHzUMIqVXVaAFDQNrHhaHxjxUpRTBDAHait1 DykO7FFXzFdmFIv4YcGRPddWzFKLNaSn45wwPIQgZbgggQGT0BmSZg8w3+sG UVIumawRvkm8DBGLkELxBECCydMwvLwDkCDSkPO0A7mSATmEUIzCUtgbtFrl WrOZzo0eDxwFIDXBECm9qaQLpHhZcVFWajLJWfspLKLY6RcJ2drJJJNM29zd ZDB3M97GBd8FLtCRSSaZ0dLTVANwkNQnjJtQRiRYclvgL13TdJjuyHhqD7F0 xnA+1U33/wiUXlnDH6wFV1gRoThCLSFHqjwAAUICR/JIKiAEBJSyeciuBcnY 6agF0OkOOesFdEbcA/xDviZ8uNGpdzIjdsSThJTGLgzgCBu5si8Q63JFDFEY EV8OOQf4FIUIybvsIJOGBZDIFBNzgTxPDowMyADwT/XxGGjs/oT4M/+JPeTM Eu2frSZMOT0U6wr4Bg7/x85P9xGNBJKNDICNFE3oC2KBvsE5oRlI0xin41vu K4zBArseU6YkIZRgdhWEkK6JcmQLGZoeNhdNwAQrGAX+HeWg2AEoXje9/ZEv 3EzB3oNTi1UAQFBSYAmnA5LmB91edMAejbSLRLlPdzdM1ExSAnA8BXb8U1JO YFPC86X8UBEKbPvd55aFUDT6jRuDxQSB/cyNCmvRgh9sv29CWyzZa7ZvUzzA DJBNUHoSDEEJeIFAHvb8R6jcfen+2PgrfXaNLIVMDCusBfqNMN0gh8r8kAD4 aHwyBBGAlcoxvSjsDr9+db1/dBQPu4bg/RJAhDvBA3yxweGskBczB/INw7fu 7bwdwzJJHBgiD45E/aB7ix6mBNdoD48gEeMrSICqe8KFfx4IQc9ABTP2V4mT HFiPNYWDLdb2SA6MAdrVmAMemku6EoMo1TwCuZJL1UOQIawX84BvwmpVgtR9 BcCwEHt4LDb69avwEEmFyXenu3xkU2QUDIJp6i4IytgGhsEvBCg1FMxC48El jUOcKB5YoQHyMCxSUEI+OxdGHC6EQIHDWSofL+EDEKR5wxwknhBQQAUBcEKI DQz/FAItZQhmj5BPEQvEAR6uHy4cu4HYIg+A8PQQQQQgl0s03CgBFOCUkaUg iCAcBM+BAOMEVMGBJyeDUvihsYYmAU/tV2eavzOAQph9FR2L2LgB3BqXtzvT CBSjy218+9HGpRNtfWyZfCMHbhJwewV9YRx9PqDCz2J0hRsnTdX9QkJGf/tY A/SJCo0ciYpiE4D5O4iMW9bt3l7nXlZ1vh9AXA0Bt/Z9icaETh0Ae1x8mhfC YWCMLT9EPCN4MDtWuljg4BQMAq8QygWHxqxGP80QritiN6NTDkDsuizKBFVX UyDIeHxUjiAQ9OW/TZxOgYPI/e5kgYgQAyucNxbw8DBSaQyhLHkZH7iudeh7 JFSuDMCd0QRnjDJpWFO52RJPzFCeEKcCMlEhyZ0FMAEekHbLD/7Mc0jg0xSN R5zDY20We5bpFV0qNHSugXh6KmQTMozAGt6L3BDh1mLbYQm5IC9Sa2QCH5t4 ahOBx9dCkB8suMMDJBBH2hPKgSwc6V9diQpbXqJENx4ZpM55D77CMmJ/fHoH sBUUfusyD8gAVpvNnb9ikuAz2yz5fnSLXqTprIygBYhVd7e5izWEPbcldQNT n6wi3Juv4THcVYkdsC6G4sZLjhZq/NTgNr0RipvgFcihPawtXnvbgCcoVtAa b0D7ERzbRrwFuOnlo8AHgyHbHaPEBmioOTwkvoWmYQNOpFV8BT4CF2MnHX7M jBhRudtXKMz7q1NVHczZwLU16w9sTL7gTj4egZiQMCS35D68scxwPYowLAPT dF1XMPc0BzgDPEA128hdRCNIpOBMV7yhvZcO4ITsxHUmobdXa/xrssRTVlNT uwMQeh//2pAFNmoI/9f3g/nGfqUlWjW+L6G8NLhz/NpPK9BVUhdBK9H8PuPE 7ORAUz2j9e8d4aboUKPMsjCgQEu29r1nOaPIVhtRQh40F+vpRRNMKHocuW3H sq2YAMxgU3knBZubJgopJLVqutY7uwVEwKE2f0UssxXACiCzQDKADQZ8KBgG nhJm+mf/M8mK6olJFLmybyCKisrB4QgZRKfge3Yj0XILwrk8JXOwwsO4PMJ8 gS1oAQY7sqYqVBBYT0axXcBO8g6gTBoW6S5l+IP+D3wE7An6DxVQG+jY3BA9 UCZML2ABdQvLHytgvAKI92YDZRxhCdgVaxDd8GNWUIaU4SdUahNokKaP/p+Z EdrAwlKZg+IHA8LB+AM8YQT4yiA+OGEYSMF0ll7c6c3z70uGB4M9grB1L7gm 12A9U0lTKQzMGb+NMXO0HC2s/IjZi3cIWQmDMBfyBA51297IAJCGprvug+xU glzjCDDh7hM+z2JkdgwMGAkHFOifjQx32w+HsQY2g/gg07bw0ndOk4vISTxJ uxBEA9wWDNgM+yUwMN0EpYRFVMIQziW/Zcer1KESItyht3+htkuByy7/dAmD 6QRSvQJrJcshAajEcxVbxXxkJ0Wic/GjvXG7+hquaGxiYBSK4DRRVTALUkN5 13QUwC3pPZZVFD0VbCGLleUqPypTOv0P7lyvaHWgTUN4lDGk6cBKSuxMzDnp pFgMTqFAUCshUwg65BQISe9shBjQT7Kwn5Buu4r6MYraweMIEekxu5Q/C9qF TD8jOZILKDDkQiaSNCgokaaZ5CwsKDwFz9edPA1CBEFHiCGpbGJARVVngKQz J1VHaA7jYZZo1e0njXiL35USEYP5B3dt/2zoQEB8HNzDVnVVpJuVocQv4Hqg j3jIeQL32eueBRw3iKzCD9g+NjLeeAp/HvQKfiGGTJq6kR0IGExkz2CzlXAG hU3iZ9gnt90zG5Blhg4+A8tAsrmE3rJACxd/lDDqeMEogFfBKSOzlPeYxBmQ T0e/oMzhDOLB7JBXNAtRkK8sppQkrEbDIoLFqsHQs6F4uSKhROEQFVulTCPL oUhEF4+Kzs8oPYAczEzdDbXUQCNlJx0UjVCyYJN9SlAWUTMt6WhYRYeLlEHN CSEPGFYjVpJzN4lDzpnk7BAFCfX24uduJvfGBfgFEDEMGH1Ssaz/8A9BO1oR o4UD4uZes4ohG2YYAQjCudB7z9XeHAGQC2v4ziDTAlkcT4C+Q3P7CIxPECgY vc48BBqd2WLlxh3UIUBhFOidUAQ2iy1f91qPOTwqYRAWVHQ0CyoLFhgxng7o nwMMFn8zuZNQig90ajxhfgo8ejANn/t9BgTgiBKvV5kE3S3Q91EnBAEUOQQg iLZDhvMMhMxrIxgPLl1gOJw9AAwOdWfNjZGKJYQZgp5LrpoNlgxWpzEDxWH1 2HQIBwR1U/4IXGjACE5DJnvHiojd/10BOhZ1HITJdBSKUAEMVgH00u2X4sAC g8YCE3XgTusFG42iobhS2P+BV6YrvNmIALo0g8cDgD9flga7fYpHAUd7dfgH iPtfXz1ZgM8DcASInGiHQ+wkeASZ6kqdPNkZvqZs5QccZCBckydPniRUKFAs SOGAx8kwQBR7jugRtnrADuKtOIsxoBPRXcBoLAxSXI2HPLfcQAM0+IOqfTQ1 93RVaBwkK25EWBAwIMOBMjxVcxVMR5f3HIM4/iZmnF2IQAJx2T46RIYvUeMd VKONoiNOwvEHLCY2wsCHVVgTToV5Ev1wBIKZzXzHgWgMBGxopLBgzJpkEMRb FiNpWT6PPzaDR8MIAwxw6qLKPXSHH3L/XwBLHa8OeMPqEoXCHKy0LXKfoLMC rdFA+YZH9FT+8GZPR91I0VBW6OTcQAff2NSrqWZ2zxEkhF4Ivw1++nQLjUb8 7TWs63QGHItO2yALwBBRFjRHKSBmFR38O/hy0uucHqhgDHP1xlTeylDHMHEy X0IIZt61dqBeOCh9K5kWmcmd2xXXWJwtDhVqLtS20SAOkF8ESCHBJRpgo/9e Lys6wDkUBGM4sQwoD8jigcEEHh54ExeS7BERcFnaTQ42BvLA1lIcKLYl8Hq8 mdY8JGXBY+YVNBeZHnilaGVQ1lDOgJ5J8FZ929QOZgOMFLTlog1qVrVEUSgT uDHHiwWnNLLrfAo4A/QYoCQ+N2gTHFFDUjZsdTIZXKgOHiRE8q4NMahvgHT3 0VBJUoLuhhmBVv8cLmi4zzugFHUQgd72dYTLimZQbeosZBJOsEt04QSQPEUT i+hDSkaYKv1BiDZSctLBFK8clHBCTghU42OzSHLkZAIkAoRATiC8lBJnLAMp hJk7KBU0Z0jxTMk4AuhVRq8jDHEoXCIcF3g1MhKICL7hJl10ZBOTMCRAtMGh I0I9GqCLcLoyQsH4NMDPuYQtDOOjVSEarzKEEdxRUgcGagvxUwBE2zYXLMFA OFI4bxjWHbxL1Gg5ajtQPnUQDShWzLQbhIGbgRj/a0UyYuEwfeP5cjJkLCRR MzA1NC+HDCQ4Vf/WJMaA4JYQRFSa2XChITVDSFNRPjTICAYemM6FMdhjGIJF vf6IABoeETiT/6WPjAWHc3RFJqsW6IFwcFSSioV146Spse4Y+wD4qeRDdSYc j7gHR63JGBCfvynfl2A6jKSJKJyTDrNwEnQQAQRqh61Oz8AFUH4fxDwUXTBw 9WyueGOE7p3VvBlKKBMU31WYYNk/jZNwm5tYmYe0LNMkNogGMglQJ6pD9Q2x w3g3uQE4kFGsBG3U/x1ARFIr+YvBi/eL+sHpAkU3qd8/yIPhA/OkRpNE57r/ WLFEg+oDxgQQZPhEsBhQu22xFTJSFghhEdl+073QBEN0HXiAfAR3XHTNTLOI PFAYUe55cuwXwKzjBzCkNJw6TZ48OJQ8jC/Hd0OFfJksiwZuUtiSzS5KfKqI A4TjhPOrwwlOfAMM38KEuxf0gIT/BXy6opoLCBEW4+h0ZkA+BFmQULOokTnW kUPyRS1qzL1XV0YAmCwotihd8kKiT7gHUytql0C/GJpkii2JGlNRLTkhwOlz eFx4AhyCdQLIBtcJU8jnA1jEBngCjAhZbljT5M8FylC940xhGwDcy3wBD4a2 BVy/dFYSAAxvv46P3Ki+D1NPWVx8g8PAMsGFEGoQU4IGeG6Ge2eL+zVpe1Wj BaPNcHNyUXR40DCdGoB7lPoC1uenDFE9clIB2XLwM7czUHqhKlFNYEM7dBlM DTpggm3HsyHIAtWxKNQYa2GQEt4tbn/IUko6VATf2vDSpNNjq+zetcLkEg0g jmADtTiWdErtuPsZlxxga3TVI6pGlqiKAjxHJflAFBx1FFuCkVS9qRaERc6a 5BnqVy3+S1SDIMh+Y4pmYYpeYnUL/wOmD75+ZMHj78mMWAjFY9/hik5gC9jC UgvZxUfyUW8ZnFCMbpDk5CRkAlHRXAIFFnVGWIP+yDjkbAHVg8fB4AQD7Zsb 6AQCQo6KAFBDuPHwAHq0Gv734gPeweoGHxDTFdt3r7pVGPfZEYPBAojoLIAX bwDCRH7xlwcDRttlcLSKLBkATAelFJc0aTpmmMbKV9Mo3R68A9NWEVZESEZ1 JAcStJNWMOBRRlhoUYQSQEjo21JvvwIJYMlYuNk0E0ZPEBhkAnDRkCcg5EDZ +FzCABJpYcPBYEACiB0aehz4ekPlPQqnEmyFW7AcSzXwWS+caPVMPC5FKywU dAVe3EFvBBB1B2RS6zNB3axpqii4yCr+HG9xc9h0Di4LdAaFDtTrDprBRnVY TEVWcq5w2IsGZqzimwc8Im2PtH4CBiZkK1GALnpMPhXj4aIaX2XeYPAeww48 1pj4JgXBIXMKVcMjF79qRCy/yRtksC9SapCBUL34h4xM2W2MUZSzMaAlk0wh Q85mEWptUiggbBDmlnqFseDCv0zvBPOJZ9Vz/h+oV1XmoQ1c4ZyUEid01g/R Ef0UaDDkVQqRKHcaMKrkQhw+Ij4EAQPJlISW8lXNnQsvjngUbJNoB3wP2LIY INhAwtsSsosTS2/kDEgCPYHfLCooi9Fyyk+raM2dK8opsCvDexWf3kJORfzD Do1RfpTkSAy9lFV4Q4i5f8Glku8Fq9JI5q5SH3H4ACGLhGwgUambMAcSvekE JTORcAkFKUzOJdOdpr8UShzGRdNIAHBXlyDIBoAIaNSAUHBfQH4UD4TEfLMQ +yxiX75kD4yqGTmD6GQkH8gWgPooGHUScIEckFYUAxewQ/FaJCY4KziSCxAS HAEcDpALDHokICS5QkYcMCGLZAA+PsXNAk1xALubv0DkwOL7hDeNDC5oElE6 G2xxaWepLgY7Bok86Xb3rSJoiEQMIBABQUYNdfLSHRBo7sYRvsk3UCCZi2Kn PFqBTHUxmWBM5tXcBfmiVClSEOsBRkno5FgkjGkYgZrUWQAGV4uBjIBgq1QP nQAukDXWzXGYsVXCGAfeeyDNswnF/7zvZCqYMCrAKEYUBmQK2QlVUxuBcQbJ whnWDS45ecmUUv+EUC655ECMUZTKSAZNWA2EDLfkjH0NZ6PFaAkH/QmpXzD6 kEiNFC5EElLI0gwYCXkHB+Nv8P8iPCB0Hjw/dBo8J/o8PHQSPD4dhMTkId6N ROdHJyPNNRwoKEWS5yNJPRtEUCaJZjkYV1XkFMahWUkvVBvIJ4AEvyBZPAWR YlXpMDLBoZ3VS3Am1MFFk8meao1gkofLOAHXreBNiAmE6jULJuHrDtMmAtTV oE4ITcLQ1po8AbM3oUnXlkgxQQjGD83TM//B0Jl5MMBXV9jLgBUoJOlqMUzg aELXduYUUL405mF9tHA66lCnU/lGTcGJ6+IxcOrQ3/4z7YH9/FM7fVM7+H0t glS5gqbEVD5+11jUqHwTExdHRoiEDDjHKeCGOzw7i54n3Mp9Q4uVRoPFMokH mDv4mnDMvBQ3BFx8pWeLT0GQHCFI/pqcnZp+fFuNWQFHHEsRPpDo5RbmagR+ zlb3GRoc9H4a5clXnsBTBxcjNsxWx3OtL03GMkt1VERWCy7RzdBJB5SwSHQc AR18f3ducP+D/gF8dgRhopy7ej9wYgq7AiCIjVf0jyzRzlcgCCs73n8ZK/NY 3b5v4UaNeDJ0Tgp19LD/ul+5NLBJTmUYQoPHMkPuBvtjQUP/O8Z+t4UccUE7 zlQHwIeSfoqoQqbBNZsJ3hVgLPfogsCL/hhcLPbenVvSQNMSLBDkTcSER8B1 zeVCR8AIOMS907kxHtbD/6AFQBBoRsAjoE6XkbHNKljoMqBUOz4W+YsN/MLc rOQW1IglOEowHEjZ5ACiM0UdCmYEnn2CC3iAIlBmFF8RcIyAmGoQfwTcyIic VwyGDFJWvQnsPBiXoZbWH6cuoWh0Wo5oUOT2T9CMSLNwMwvgdqzbpIv5qX4g bSh9tR2L16ErKyRA0r8U8CPNSwPYO9985srG0oHeFI08KQRD0SDdN9cfKxNU UgzSfCPOGBcTRFAhIEGPdehWp32PrBpZuX/AAyugfBDY/DGEazDB2Jf8z4ow KRkSIk0cr4qV8xsJ8OAB9yz+60W72P+p9uoDgpB8IcQCA/ns0zQRaPArM5i9 3hQqcxRIrDpLBcccP0EHXi3bpTkkOPBVVJcoUvcmSxF3HCRTfdewjDEWBwsy HOtkv+5jy+IYSQ6KVAwmEsyb62UQiBX+FkQMJ78HdgByLqL4HEwMumEG4CiI DYM5RSlIbpTZOPf1iACBIAtRiIgykCIHRLGrYGxW5YwmNuQJWAbxziiIcTBN Dfzco9lzJheM+VQKz02KyG9OkAF/gvIn6lSGioQEh2xmYJBciBxzFHOy7r+D 6gJRigQQGhWOvuCdNWAKuisAHBLiFcgC5hB1GPNh5Ovu1LmMUJgpXKoX8jDy HOIaamwI5UDMzAT9BHE+EaoAHO4LE9HiBaGI2KzEQCJM/fjxvYRI8kU1xBrW iH3tsxR9AcynS1wRTs/mFgbIQUzksNy7B9/ZfehT0M0cwKBFPARjF7wbo43N rcLGupTGDa7Vx7bAvaERmUQyHXzgNreKYCbIDMjmrZuHZMImEwSFkFDobiG5 kL8FdAjJTsmEfJitCFzLnJILeXEtcMw5JRfySgm0zHNKLuQjAtjMZEom5Pys A/R8bots1SZ0OM2urHlOyYQNLMKH8pySCwbkwmDkOSUXB0zBOdhzSi4gTNAS Jkc7glwrWz/sV+Qhm928CUosOWw8DCInu0ZcC0I8ABqbh5kGJAScBny2yFbk iq/HGLx06uRAZdbvg2oPU9kZ/WzfdD1woI4GCpKMvYCmM3D26pEimHQDUOJS 5mrJyFIQFxxEksvMVW9mQI0s3XV0B1dNcJT3iuboNNMErQgOkhHfVQRXy2Om 6c8GexBowCcJQtSeDEd27zM8Nawzn9AFBwaRUqVRMM02s/30y9T/yHVtG4sC CbAnVufqAkYC3kIe7Ovjv3D5oPVpktRoiLLEGDGI8NQ7CB8vHIA30h0A4gQY jmhWXRl21u4BDgR6vBCb1ymAjMEb0xxqUmLttsgFKeVHCOVNCxDhLN2RiQLg CBSPOnEQboH5ClTwW1WaxchSzP7/KFdej1wZn3hoMHWWnWxmEB8UcvTkL/SE EDPag/vs0I10YTBXddL7cdNd2s++BAfViUAET3XkIYsGf+zgCsRK4Bbv65WQ /yU5MrK54A4F3NiYoRCwZuSUnMwAE4Wj3ygIV1NWihFCBC3+439pinEBhPZ0 T4v3LIoHRjjQUNwIvreEqAuKBgoK7/Ve//82WrQEwxDwdeuNfv+KYQKE5HTd /R2UKFo44HXEikEDMRiKZti1d0s2wRB03+uxLzSKwn2lum85WKKNR/8MwxQF /670LqLJhFrTWcNmDNhEtJsIWxRZDRCjMLHf/m2ew6EFacD9QxkFw54mABXW 0UKJweRqf7bMAOwaqhdRPRyN1XIUH/vdUN5n3i0QhQEXc+wryB1+o9uLxAyL 4UCLQARQw7hLxAXI+SRU51R+Rm/5/g8PtgdqCFCEdusO4gcbEN1Ib4qp4PoV L3T7A0fr0hU3RzQti+4Oa/S+bf4rdQQPSEMMs4cVIlVAC6E8+/dvlnAEDY0E m41cRtAw68+D/ULYqRJxw3Xshci1rr09jUL/Co2kJKvFZAZtmYAG9CtDwZEJ uKN9kAj3wud+1sS/WIoKQjjZdNHdURJ17QvY+Lcl2srD6lYIiwq///7+fhYL /6ZpM8sD8AP5g/GL8ITF7VLwzzPGrYHhpQGBbhHntxolBnTTToHm/A0vnFS9 Xl9b3YtC/DjYdDame8M3x+843HQn3+fB6BASFXvWbprcBtTrli2xQv430jsn nQb9/M/rh9z/9uxXVr5NEOMmi9mLfQiQCcbt3+rZA8u8i3UM86aKRpbJOhLu diH+dwR0BElJ4cFbO8nDN8Nl0xvcaCiioxx2ZKEQW8TW+1BkiSUHRFiaiWH6 z9Zl6JHE0orUiRU4+XIb4FLS4f+UDTQN3c52AecDygowu6MsbLl+2Acz9ppk 4VkHqBybtt1/ea9ZiXX8CGM2TVgdozhjN56IFrhifhQRCV+91Da7twRe/lwg K55FpFAv/D+zKowWpolFnPZF0AEQD7dFoKm3LwNqClgddZxWeGD+W3YGkCNO nKAIXE2LRew9jtA7eQmJTZhkXSLprG7j28d1mB5eQhxyAaIWrYN0ZvAbZymC 1xvCXDlA5S8kWSV+BQ8FQ8NmhfZ+pebXBO5oula7gmjl3FN33UFew0s1ABXV VKMOSObWDw18En6DfOPbwV7gdyJdW0BAWXUWOYrmeA62dBATcMXeK2x9v1s7 OzXCSncLcGwQGhz2t4VGqQ4B1MYPg+bwVnNR4eFcXOFRDmlDtbFiSIP5qncM aaBwqTBGautSyRu99OdYDsH5CC3R9kS9gGz/S/1edA6AZf79TfyIRf1qAusJ Df2eRXy7RfxjWI1NCqpQjRY4AtUQ3HDgexy1NzQa5wJNmgojRQwIg/iBa+/C HAvIRgP0q4GjZvfh3XbpKzUFZB33dRQDCWpy7H7hA9NbGqE0Eb0CgzsbNGE1 wAS9wJCv1QhCDgB2DadoT8EhDBBcb98m5FkMAVcPXzk9aExGhw3DdRFysPA3 UK3BdwyLR4k9ZM4KfHciiB1gKDwEgyJr8O8WJCwJVo1x/DvwchMCl3z/FT6D 7gSAInPtXmgYlBSWfBeGzGggEBwZse8tj1t1EHqJhjNItgvCX8eqcw1XUosI N1fr7atAMLuCzYbaXmMPhLWLWPSrJooI9RXg+wXmoNu9y4NgCOpY6SRgxyQv NNzm9gANbGHvdE0MiTq24WMLi0gEg9OFyB3Y5/b/rgkI3AUD0VY7yn0VjTRJ K9EEGtzB7rVoEoMm2AxKdYvb0tUux+TnKo7AacfA3gW9BQwW63A9kBJ+BuRn gV09kYRKPZMG5GdAhTc9jYLnZ0B+JD2PhhE9kil6p5MKimCIXN+lWKvTNwpO 6wj6UUrE63ARz6PjpWqz0Tad/0nrTFtdXavZmr0E7OA5FgVW/k/3nrh07etg wAw7xnMEORC83/YlX40MSV4DjRU7wRJkuWQqiWX2KBYAqMTLdHYvHadzUKAF FiAlQwEozYZLI5oRLMBQp3IpdPFtu9DmRnWAPiENBwo8IHZ3XXsrsQwgd/o0 KAQP6YvGAu8GC9tTuTkdWlFuv1qwW1r4M/8nOsOtP32Bjz10AUfVdzxZjeUS ptjgAevoxL2dJW7hDSKRWTvzCUgxfwtPA1EJigc9QTgfdN2+Uew5VVc5sFlF gD9JIlVCyxaONDvDPAYuO/btjt82eExZblkD/Td1yV3/hCV+zyIaiR0LiR4n 9QhwC4ckqX4E7pWNQFG9vnArw0jQ4Nt32qEpW9s/tqJYfP44GHSz+CT4G+3v WChTU59gUIsPoPzWqIZt2IjUkdbXhk26oQgvJyRsOxp2hlBWNVIUSFpALQbd zZyjPAZbu0yU2g22GBwUpIMhcmpyxBpLl31UtSBtUCyZnHc3+onhJVi4FIA4 m0SdQID6vrRfaGgpfiW+0vaC4RNH/gY2Sg49AcEGihCIFkZApWNHxgvV684M BIAdFhm7vUZAHOtDHgUE92/J20BE2vaDGRiIHkZlBcpbcyB0CQkICXXMnhuF Yo1Iu0qqgGWyQSwVPThB4GPb97VEKwUnA17xF8iv/QMzvItVFP8Cx9DX3xfa CoUiXAhAQ+v3kiwQ9Ebj9sMBlkE5fRhW4ta+VngBIo3jHYvCHjf9RgnDCAyx GBgPlMKJhX63vwXR64vTS4WTDkOIxgYdtA9Bb7FLdfORSoM/S23zbVUKij90 Og9ndDBhwLouKBniBh82NyCcGw9AAxUBQH1tCLuQYTwwDw4KCTK02scDg52j +SZulFr7oEmhdAIWgtNE1ERJ9oaButHAqHUzegtL9T3XdBYh7evTPDkzC5uh O/sX6hsCs1WgnV5i4bPggd1ssw5DDD8nwmY5Hn32ditz60BACBh1+QbyK8ZG 29gtL0BO0fiOQAJd+tITtQN41zU763QygNYBSzISIxwVrhQ0aA8lh2BS91AO DBAnM0vws3UDVp5Qw+tT+XUqncy1TKWFsXQ8YP+2W5R8DkA4e/sE9ivHQGqF JW1qVc6q+w5GKjW6uvW8szxyfbZXPUjG64mtla+KXyHsRK8AmjQVhjplMhta LphYFSDtGCAWIDZu8D7Nhim0cxptBHfp/Va2xkYFCqEj9QgFG8QJHeDr4uhb Zo0R1NEJQnXFr0TfS5+t6Qu5MI3cuAAISo1l7t/uHC58djk1Y31SvyRMj8d+ 9oEAOIN/iQeNiH7Bc7ZYluYYgGAIQIuZwGeOsY34wXzk1Ul8WyFWgruaCfvR ftb4G+hGiwPLNopNAPbBAX4EFyIL8Ah1C8I40MeLtWBjq8+OBY0fudC9RevP IVwLiQgviBp/BG3rR8D+fLpQlHiBz+w82P/y2HVNO7dvlSoAirRq9ljriMNI 0G4zQOSN9VgwoUYnO0i5F1dmDCXY1ij9MD7QBoBOauoKX2J38wN1CgjrBAWA Q3QDfJv/GJDZYrg2NHvgkIvgRMN5u1uD0oM4diBVJFGDQyOjkDfBIdTxF3xK D6H0alJNPOfDzcPDLNoPaG5Vizx1GQlDHWz6gmRdO4vl3ExD+kEOakEEMsx0 D311Ux09TIkCuJvDm/pH1D6LTv5oRHXN/zXFoZg0AM6EYwfdS4twDIguO9ut Ev0CJTR2iwyz5G5FF24Be3yzsnUS99u/7Ysts31l9v9UCOvDZI8FQ1eic46j jOhkZQ/41tL3gXkEaHUOUadSDDlRwcTdW7IFm4pRu/RYcttWIFgIqWFLAkO/ teBb0WsMWVva71ZDMjBY/GtB7kMwMPdu+vyLXQwOS7ENuvdA5NqCitYctA4y ReEQCD4t8V22IXN7CMFhu3a2UP2ysY90RVZVjbpUC77uhe5dXkELxTN4PCVT wCBAY10LGR1WDGIx2QrNbDZw3o++c922S49VDDsIMBqLNI/rof2OfTX3fRzJ 6xVcav/aEGKTP10WlLyV7PYbO4spi0EcUAMYUCQFXK8MHD+imnfzVg3zKk5E 5UAhaPw+GHUdK0qheMxZ8T+Y1SN2YNiB7NFK1IekhFUI2qhPbdpyoJELQ0E9 /XxVeH+L8ZbxweYDO5YaJjNLw0xBbL3ocGgP3aQNENeo+nVKxaartvGFXKEP dsiIjHUTFwilQImzsygnWRJXk3s7Fm+9B2JAWWU8dikZgbOzOFB1+A2DR7Op rn1qAwP4WUFXqXt8Z0M2N1Vg/+ikEFd+yGBjDFwd5Fz/tgyq1Wzm0xYRC7eD DGYFJ7x68VksXxoi5urrJo3YMOw206TdhDwIavTdgHC3aCrPXitoQO2GNiUE Gpb8FE04m3mhAfIl9BQG+BC4B94co/AUUegFQsBbMjKcoRhu/qhr7KH8B4je FGorUAwKLewWWAAkcgecFLHY2GKYy8wcVaVNtkGp4dISGXdxDPxLv8VawcL8 V8Huss6LevxpyQTRjRIdw0uk1IwBtbTUXSuJXfS78IkTjdr/zfkI+HV/wfkE aj9JXwutUmv94s92AwVME94DXwVfytRI4dggcxy/tvhb30fT741MARXXIXyw RP5EKy7YS+11ITlhg8HgHi10OvdgIbywxBIkBoxtG664Ubh8VYkKBAK/294I A134DQiMi/vB/wRPGgoY2to/e4ZfsnWaqdvol+xqoEIrpxGu1VvEoVj4SVpO pj+3te52BYnzykEb+0A+O/qW2m2DdjX6v3RrLsNRkZEB275RvbrqCxa55NIh VBEevbGWkA/SIZRMUspytm2/Sb5KCwQIcGGL1hGRvezVCTmFwmujM+6J91iy muvesPkpCyaJLw6KL1vZBQiXSmOKTAfdvvu32SCITQ/+wYgLcyWAfQ9GDrsk 293giHjT63YJGQ03Yt9KQbEJGOspJONP4ENwz2IZJVkED51bvOGxhLcJOItU RfCJGjsTEw9z6fz/CLP6AHZw2cI9wN+j7A2haAvYNrrB4Q8yDFKAKdjsgaBA h9cfMh/2HoQcCVAIDjlAEIOd3c3epIhsJA/+SEMKSGyJhhtmeUMTg5L+EQ1M L3GDeJh1bFMQDYQF3WtaEgkQrhCjAY/0M/I4dqNo9UGLyCgryODTt1qSERKN SBRRinx84/12YLEX/w0vOwUiNTr92lYKFJY6iQ1MOD8DNJCyrIk1CliQGjzJ Kmbjk3tXL2hXjTyCLBtIF3Z1R4dp8BdqSTR9DoPHl4gvktPug03CdfTrECbg LtQAAELT6A6NBvB1JqFpi0F/Lb5d+AhzGYtL4TsjKyP+C89Hu13jFhwUO5oY cucHdXnbTMj3i9o72CYVBevmGQVocHd1WSRzEYMRbHfIs3MTN+vtJg0bRRua sy/uDghvGbRfq86BHHSQDspZWxa2DRq3aUOoOGwH697mthvpFEodpRSLFh3e Sm36x0oti4yQttvZwy6AkESIN4sScBFVUKBVK900vu4G1L4ORAvWiwvtkYQc 9N8K5v9F/AS//iM5C9d06YthzSrUl8pKXFiwBt3GTXZMV84PZuoLQXdqIGRf xQXR4Uer67bbRosgVPlDCit/8Xvjpku8wf4ETl4/fvheO/ebtOkkcw0BJGEg fSvb0oWAEaJ8OJzT8+xb4Lj7I1yIRIkD/g916oXsaLGB9CEL6zEXK5UVXLvF oTIhGSk2mJNzFIIshSIKwNem12V6BPgAla96CJBbg+c2hJQ0qflCDMsAUmul IsJkBloq3Sz+C30pxJkLpbHNNRcRYr+wzoyw2y7ZCTsKjwl8rusvKOz7kB4N jU62CXsEsbytItcjXRa+7gk3am7pRgUHdQqJA/yyDb/tXXl18APRIgESMvyf i6HHb7cOIY15Dz51Gjsd8lEGjUhdSzukBmsivZELEbmNQgQILMCDkwINbxD/ LRSAGl2WTVBDeio1clCQGFeXUCgFmXzaiC9YDGacwD0K0Mz0wWjEvwhFMN/i yLbdgTNciUZBKmoEaMj2wVcjaLJXGYgABtI/DHUU/3YQV/z7rbXUtnxOJMWJ fgT/BWKxlakWQc6bX8ZHrVlT6W5xyLOjtcVBpNvFT+BDY+vjRsM3acCBWvsw gtDFdhtF6kAIAgS/Ss9269Ye+4XB5995DIsQgGRy0JAALNFLdNXeJ3DAjZcE R/rQjY4Gl7ZHd0jyg4h+9Azm3VZf/AbHQPzwQudeqt0O7/+l/8eA6BAUwQ1+ 0QWZSPCWdsfdU9V2R08MvmNfJontZWtvrI1KDAiPQWSeREK7bvzDvJ7jikZD isgLhMB6iE5BgTH+Q3UDCXgEuizLaPGEVsB+atirgBJVyEBfIA+ettEkTn38 BL/6O3KBNEulGKGEQLbYgIIw8T695GzVfYFCXlZoJDNWgoTZ3gKcBP8dGxgg JwAsxF4ooM599T5B9lijQ6EkGBx0t64cSQWhoFfG2YIpGosORlAz9vJcgiVy F5Q5XRgZNtsK7qGwKpONUyxBa0A8wCAS4O0O6baZbRg3LB/gVnRjoRda0EI+ PEO5AyQv0J2I/I3Ai2t13Feit+mAU7R/6wv/BBtNUF3Kg9f/ydrstsQpSeBW XxxVMHOtc1IRFNeg7WfBxB3njWXMliYNh0CNCGMg23JbqUGbOg+2Pt4RhIIG 7IKIcnUctNDRDdqhDsNFUuQjDtDxCgdKQAFNEAEmGIpwQ3N9l8BSbzW8+XVO Ij9bM0RKpwlW0rioznJ5U2I5MHRyMELpRjANF4DoUJOAQCS05d4+Q0BjWb/g gqLobhZ4rOFQ86uq0+QPhu/7T1M/MH3uZrtN74oRhNIMfiF+aq55tkH/MjvC D4eTyzYg9iXHXO5SL2VYakiuUnHYBKqNKeqF3Z64kYA7e8t0LCot3WJEsoW2 +q93b9/uHV38ipKgIAiQRkATdvVBbeBg4UGAORjUFJMIEBs5vp38BHLBysTM LPXwnktQo6wLTjGs2v2927/AD6WlWaO7petVQHn/zAymukxIZ0KhsVZfbRM9 l3JwOfbay2YsVOsG+gvCCu63sU2rAOsNOR2ICpuCqev7MIEEqksD1toN76Eo tyUhVf6EB9kaIEuI/yV4aktELmz9FGR5D+3Yshi3GUktpF/fLkFtYCL1dBcE DXQMSDZXRNN0A4i4WgUSLzzPdgsIEVdsWTPAGyHYIKq0F6PFYgT43tzDX4AU jGfgJqBF7FaDIgqrfz8GFjTAvoeIhAXs+YG+/4KCxnL0ikXyxoUNIPeDbmxx N1PIVWC2CijHGrpA0HcdNbwqQbgqNEG7IACL2WWr3i8AvwmPqkJCikL/8tBf WwdBaxDJQ+5QY89eNY16UI1WVtl3xoJvI/0dVh7JyG42VjQjgBT8lkUIWPEn 8P+all5cgo1yZosR9sIBdBZvm7+f+hCKlAVkiJDg6xwaAnQQbZA7JyBb9KDh hkbjHIE8AL/rSRWssd0wJUFyGQRaqktjSzQ6yECYiEkfNycvbx1hchN6dw4g 6SDrIdHdsOBMSr5eyYiDXPj1Emr9CGtZ/CgWzAFYcgBN8mrBh3hDPIv/G1f3 wQMWAP6s4YoBQYE7DnXxiwG6NNQAbKUD0JrCMKlAd+sAkMhB/CYj5RyGC2Aa qROzBnnbStx4AuvNv9wNBP7rCIM5ann96wP8xl8ZHexNS9ZBkGSIF0di7uta rBFb/RfXZ266yQrBaU5r4S809sZeAu8n98JpEgdqtmGINsc4xXNmCC2ZKWAI DAiTwV6wiAff3hQiO8SQQJjj4ZKT5jIkE0E1SSbZHivBwwn+/TAMYJD8zF8B NIAGSGER/H/LXVvRA8Y7/nYIO/gPgnhRd4x1WseMFNWD4gPrwMS/eHIp86X/ JJX3P7oc3uBCwf1yDGYDA8i75lbeF4UgiB6NGJAHnIj6Tdc1MARcA4Aj0YoG iAetue2FcIhHAQUCVghZ2UnGlsbHXMyNSSt5lmVsJQECAqbk684mkCNGIUc/ jJqu6w7/b+wD5Afc1PybpmnMxLyLRI7kiUSP5NM0TdPo6Ozs8E3TNE3w9PT4 +PwBhy0ywY2adN8hbBf4Cf/wIAMsTUCB10ARo4aQwWYDe50L+REwQ0Jwow0K KzIIm/qNdDFYOfx/JO2z214N/eP8d6CK99nvczIJ541Qio/5K+u6X+SoiSyQ uAvYAwAM190Km20DOm8DTlhPVoRhb8m2Sx+jkG8huu6IAimMJeEtG5AnJKtz bbyyLQOuRVqrW6bpugtUBlwDZGyMsGmadHyEl4qXHNM0TdMcGBgUFE3TNE0Q EAwMCAgTFtI0BAQflrDpurAFuAPI3IqXYbYE57e1hw+DCWFgCxO3UPz5VDSM EkJoZKWj6ouCUR1njzUQpjhYLMij/J4t8Cl0oEgQaDQHo5CLet0fetajlAah C7nsD6KRdusOoZQQNKyh9wVTETEYA4Ij0HMyTavr+BtBV79/DFe5eiTZ9So1 QR/3SzYK3tBBJAeLdW/rIXW1uNFpZEdJaTEpzf7Xnh916y0dUYPjA3QNIIGD GtUdLzlofK0ZG0LDedE6D9zZZC2aAAvuOmwYRWBW2y76Ksgn8iEnsGOvKgYW g8YySNMM3iweDM5AfHt1xjnrGIHi9wlihUaaDgAEvlN2v9vW51UKBIkHX3X4 sHWF5BVZw6O/yI3z5MgL4IzYjVyNIZDLZfCMHI1AjSPkAcjIjciN03TdYD+/ BqwDpJzA2jRNlIyEfI2/pvvOI8iN8OAD7EkeQNYAjr9gj82RU8gQj2iOYI94 HEgul46YjsCOYI+NQh6BYI9N03WDWxQGHAMkLDQAa9M0PERXj7/TdSeMH3AF eAOIRYQAa5yPv140ooC/Dg8UidgAQUcrjgoLL4H5g/qBLZnCJeLS9HQIK9Hn SYvIQW0wNN8DwQYQys0qdAYWpusa6zoGI0rSQk6CckQzcOsGEBkc4T24z05w Kbh1RlfVW1MwBB1FjGkPcLbyW4g2Ix0j6yIgIIAnwWcbdDgiAZHgTzo8uDl9 FH4QLpPg31RhOFlZiUUUobhUJYEDth0WHLNOm+cTvEhNgaTTfSAszNohIHMu OSRWjFwSTSCLMq6IAPHkO99f2ME2IcEEG1HEQdzWBgk2OesTSv8mEVuCtzaL OGfcdGas3GFzXbI2IVf0Tewa0aV3FqVwbdR12LZGX6j89PZFDQQmPhyzmwnY eLIj1X8e2sBsbWQySNKPnfpCmozIx0X8cmTkF7KzNtyJXeASexdrkO6yfd90 tFZkanOnrORndJyPs3Urw9klCusGjFatk6orYt/VQL92cQ5HhI5XxnF7+0Kw wR97Vo1K3Q0l3RLwhexAi/FJBvMMXsy98eN1BStLi8Kx/yVsQgBsriiq/29q +P+uAGcDcnVudGltZSBlcnJvchXPfiO2VExPU1MNDQraD9hdc0lORw4ARE9N QRLydvvLEVI2MDI4CC0gR2FibLNv3/50byBpbmlSYWxpeg1oZWFwN/+t/Xwn N25vdD0EdWdoIHNwYWNtwN5tI2Z3bG93aThhBvIUctlvbjc2c3Rk9tvPQDVw dXIrdmlydHUhse23tTOlYyMgYwxsKO02hXxfNF8qZXhcJ3vttS9YBtziXzE5 3c19YfdvcGVYMXNvD2TaZMC2ZXNjKzhGgRDh1iSBZWQZV3Z7SL4jN211bKx0 aL8hjOTbYS9sb2NrF5rbBls0ZLdhLgL2reHWoiFybQBwQGdyYW0geyEUtkpt Ni8wOU+jGVoKEEEqJxTyuUYsLis4PQ/h+2FyZ3Uoc18wMmaLbduuwW5uZ4Jv BXQ6EdAKZ61k5n9NLWAY//C2OWYVVmlzqkMrKyBSnGHuuz1MaWK0cnknCi0W Gmfbw0UOIRFQ1Dq+XBt22QAuADzl4CU+y3jbLGtsd24+/92BOza+W+EDR2V0 TGFGQRZ2ZW1n74VQwnVwABMPV6lkWKD/rTqbZXNzYWdlQm94HXNBzxpfOTMy LmQ+RyiRpNh8rncDC9zgkRmVFYqIHgCQFUV9KvmgM4ZA0NzU0ZFnQP4L0MWP kwCMRka+2Y2PExeMj46zk7H3GyIrjo5LsD/dkowH3MncjJAUgv3lf9TT39LI 09kAzs2Q2sqQiSftftbdF5CNOcVDzdLS0Q7T2G8b+7852dnP2M7OAMrY30HK AJ0jfth/sNhP2MXe1dzT2thv1dLOyfc6s/0L084E2VjIVBv2N2v+ztjPy9jP yQknzcjfInx4w9reBxGXPzDA0zRNtzgDREhQWE3TNE1cYGhsdHw0TdM0hJCY pKzTNE3TuMjc5OymaZZN9ADBDBAUmaZpmhwoNDxEt8Lb/wD+1dje1p3JBZ3c yQjn0NiPDdjP08nu2NgV2Bb409fYbhjZ0sQVKfDSzxLZ3eEwZ0f+GtkPg+iN Avc0/MJv2XbZ/7kEAwD11J2B/++DfvxSsPe9A5OTG4LICC+3B2shZ3qd0tMf +tQNs9a22xjbmUIdh8rwcvn/8uqd/vX4/vad6fX07tXJh5KS67rt3+6TzdzW k9rSywfWJ0ireAOv65qmnLwIswwDzMPHysaHAMfczxHUX8nPu7HRtsht8Tse xHWd3hrR0N5ctRXbz9SZBOqxrfG9LJ3UzhH/YpD7Ft4YsI+dK9YnnV/NzcSh uyV76U0A+dLbylVo2+5Zx9HScMnU8ABEZzPebRnu3gXTnc7cZFjOYbeFbZXN GUrS1qmwhtuyIy/z2CfcfrLta26CPyQP2i7Zu9r2DVixzpv0INAPMbKwHVIL 8V7Y2DMYPuMUNfPSyRWe8shu323KGc/E0Ogh8MT7Ydnadu7cEZpMQtbkMxsD YWGajtIyZ9y3Nee2ziDqJEjKxdEdFJZ9wtET6tLKAG22zxViDiBTWul+ztvW Nvc0M33fyUHIN9RqhWec1rvv0nepbRtLV4sV2/Gymi/5VnLOsRHe0T7O5Ket EGuNC8TvenbL5Pjc/NoNvfFU6CfOtQrt9YNdLCrv1o+FhM5vU/HcyNrVQ3HC zDHyisrV8QyCe807K0H05/xhS/hwMjvRqxrNcNveAPZazTXWziC+wmHdGPvV RMnT29Xe8Xhat9VYMt/c38QdNgnJD13Ok/W2TXYrKRfPzmfyHtp7cySMpTnb JY9uWXtvg8zR2RqMMxPLJoVsLpxryx5LS2zUJ9GvUVZozLrV+dzvG93OaKYF N81UXYLjH7G5QXY0AzP80Suom/Ae034TgKrTNM12BMMDHDBIYE3TNE1shJiw yNh0btM07PwIxDMDMNM0TdNEZICYuKZZNk3M7ATFIDCapmmaQFRwjKCw65qm acTY8ASPHAOmaZqmNEBMXGCapmmaZGhscHR43zCeaXwAoQvVBcfTwsjQJc+r yvdBEAMHCybbs48uDa+h4LX+DePez9D2wCM5OKPZ1NLA80ImNHyE1//I0dF5 yfcMH0sYixjTF/pGYHTw8BT/+tzOK512F75GzaPbyFn30jqwZ2rNU5B6AxsL aZrOPWDHxwN0eISmaZqmjJSgqLCapmmavMDI0NzkNGumaez0GPtjYEyaSEcz oyK1tg0d0bPenJqu696ByNvbB1w7aAN0fMIwBWuIS2/0nN6MWQ/AH2PNeq17 gxfOdB9MrFlrgzvKaA4L4W7MMNgLzmqLqGeapmm6uAPI0Njk8Ae2rGn8zssL ic0NMgM6D5YRW9aBudsOP9ELvS0L9t4HHw8oss0MlyPa0Quw0lhsyS9DicjU WOAYWCzUCy6zQsCKDDM8DHiTBnsLFt7dD3uzYUurMgelE3vLYinzMw4PHQby A9/Uz9kSLQKxkg92m8WjQIFknbCUFk73grEA3+t1x9a9x5vFB4YL3+l32MCG C7pHyAtn47a1FxTJIwDa7NglW/YOBDgPkyEWy5YSEyGPLw4mDttbnSmlIbxh tAuLbDqz0AOLAJ/JA0RpmqZpVGR0fISmaZqmjKCsuMCbpmmayNTg6PgEyjRN 0ywUICg0PNM0TdNIWGh4iE3TNE2UnKiwvMh2TdM03Ojw/E8My9M0TWcDMDxI VJbr/DDj0djJyRu1SiUKjhTFfkNotY4WP9kUxBRSodFyObDNPZlTe4LhVrbZ 21/H2NYghjE7JHcJ89M0ndnHzAMoMDwx2zRNRFBgaMyDa1vtKnD4ksUC1AcP ugJLA8jLzyeoU6/AQZPeYAf3LDgTsQfzBkvM1mKQzifQzSDDNN2HgSE66Bvs 8MZW24PZ0t4nzYrFbdNtt98AX8nFJ9fNRtoz2d9tjlrfHFtm0BPQ2d8AxzSd gx1dBM1vAwwQ0zRN0xQYHCAkP9s0TSgsMDTNa4uLk4+Xpbv9jYWTjI+EA4SJ D46Pj4nftjKXiIiPwYoSjI2Kk7Ytu9+Lii+PjCyIjYwVig/b2LctIIQriomT hQuLGoh128G6iVKNG4+OL4s8jOsmn4cPjI2PAFmPfOz9nptLiY6NSISLgh/s 2eZcZx4djguMiwO/1s1epw+kj0xbxdQaNDoK+CTe95hP/dQQg3je38pK3G1z 8GQT2N+T9yzRFL3QTJvWk9bLNNfOxZMAx3rJB9Lbk9mnz8uCqVCpvGUSscqZ th+/PpPff86Njs6Nor2XhhSeANPPVRQoXEjW8iaXxNbZ/2OxBrCTCX7w9O/8 +/Hy7/hG03v/7pP68v+T7fgnIt3Vuy3HYKXUj9dbG+xRqXNQppDQPz+tMdZV esRh3uPr6RKtSgFNRN7KFlgYtnvF2pMG098bfYSE99JgcKaIioQAD+QNhnfh hTuIjg+AWI+CoXyHi/cPi6aFModzbw8b5hsPDGMPboxD84gPjaGxs4LbE4RW fg+MDJtzzW0HjiALeB5Sikr38QypDxGJH46wQ2fuf4yLiFKMyg/t3Ba5jiuK onaIhePrtu8PzI4MimaND4mgQYLmOIVOCnvHIbynxXLJCOtw403TNF2AA5Cg sLzMlk3TNNzs/AzOGGmapmkoOExgdKZpmqaIoLTI3E3TLJvwBM8cKDBENE3T NFRkdISU0zRN06S0xNTkpmmWTfQE0BQkNNN0hn4AeNOzA2RcTdM0TVBEODAk HLlN0zQUDAD40o/TNE3TA+jc0Mi8TdM0TbSspJyUiDRN0zR8dGxkXNM0TdNU TEA4MG7TNE0oHBQE/NFrw0zTdAPo4NgAME3nCoF7A8zIv+u+q8c6LSkAIQch BFNDQU0zMv6/P3cHSVJDV0lOSzdaT05FQUxBUk3b//buC0FWUBqHT0NLRE9X TjIwAAAWu/1nFy5FWEUAQ0Y0RVQiC01QeQtBSUNN40H72M79RkVXRUIAA2pO WDdOVElWb/33m3sATUMcPgBOT1JULE5WQzk1C5vO3R9GUC2GQ085OG9D3/vP uUMPCBstUFJPVCYLU9a11m43UFcfTGMSTpD58861nHsHUlVOUkxVMzLu71/7 QVBTXDNOSVNV01NZTUjvZrffWFkWUkWaVUW/H1NFUla2gmtvo1RSQe2DHjtQ gmuv7ftVQ40ZAgsZe7HX3kwrGqZ3PWdfK7sXCZtWU0MHSLu1NnO7Ex51M0dS C3OH9zZPTlNPRhttZHvuvW1QzDMIE/NdB98BvcMGZjtNb2R1bBA3oO1lRmkD Tn9FeAPagP5URW51badjSttL2FkfcxMOR1Nj7WNvV0kuRLdcKi5kGQd06Jcg w3h0Cxp3YXJlXB8DOiQoXJ1zXEN1JehL0HJyb1ZlcnPO3P+3t1xwcGxvEHJc U2hlbGwgRm9sZBnxStD/gzxCUj5TZREIqH3tDUtpIERlUw1DK1z7ty1fdAUg YXR0YWNoizP/7RDdTGFs851rdG9wAGtpdI3/N7RrHhdCQ0RFRkdISUpLTE0Y haCNqlChVD22/+0LqFphYmNsZmdoaWprbG1uMnH+/v/fRHR1dnd4eXowMTIz NDU2Nzg5Ky9TbXVuc3cE5GVbSVQlnQPebkFvLgarLS0LLS0AooVnSQ1iYSM2 Qb/bFqhDlHTsLUlEOiA8++0fM+8nPC9CT0RZPgZIVE1MPg/bQtReORdkaYt0 4e9r/z0zRDAgd2lk3Qk+LWlmcpoUcwufCka2VDcGiNowF4k7+d66oFYi/wU7 EQlib/1sC9qvZII9l1N1Ymp2LagQo3E0VG///1voB0aUbZEgKFsxLjAuMjU1 LjUzXeu2rr0pUhMkUi5lS2QjK7T2bmYpIG14MrkTHGPe5rZSLGVoOkMifAqF H+Yv40Rpc3DqdAxREBrVOpdYWbfp+I9mXW49Ii8+N78lTAgbM7M3Ynuv8WtH CS5zPg9EQIgajd/QYXAxVSi01vgML3NCQbVYUITWQByn+62EGf8vcmZjODIy Q225u6W2F1jGNS3laXBpg4xS9BCLKZlT6Ig2Wq2JZHt24batUIUCym4DY3G9 3xW+cCJVbnNKkmliZSIuIFzWXnbrA2suLg0qIFagttBM0XliTBIgko2xZgjS Dl537rZUam1QIiGC+SJzYW8nHHOiIGduZS5KuVZI2FQ/HiWr2+3r/lhhZGRy FiC2AOxlbapltuZKhT+pLJsEpGGNrp3dDnIgjEUxC3kQM1lhawQmYYc7KO+1 5r5MZSwfdiQzS6VzRRP4co1Sa7T3AgZORCwipoUCisYKbnSOD4hkY08FZx0Q topvxXC9s79IhkR3aG+tabDmWmzhWiFJQF7RNbm+r0sYLDpuCScAnDvMEf2J aMeFR6sVFqRyfwhEjNollFxpeHtrVEJob4vN/uJxbCRh2mjvTXrvpQQhLLmO MCnJCWJyifRGzNThdAtorXA6L5u9MMzpWDVqb3lEc9AivAUKcCBTXQaYm/WI XhaHUCQ7zBEsqg5IUxaNDYSZR5qid+OKpLkALgAqACUcuggnZS3cCW7PqjVQ J3t13GmTNPcOBZ19+x4MNsJlPHh1yiwDZirkODSo14uTrZh52lF1Y8lzE1IY z+AKI7SEDZTKNkYs5kc8AD7Lio3KBs+tXmdDcFdEDgC8a6ybuXoXeSINAM9t +20FXS0AIE/VZ8OxIC1QlU07FtmBvWGrBwsAZzg6BiEiZLpvL2nB4CrIkQzR dQ5LlGtCxBQ+bXILNxxzTXJ0VFkuFFqL0YrxIhhoSjQVZl9H1WUIgEvCMIsw OBmGguFEgnZtJtg7XCALcHlbPSsS9Qh2LHrB/3DCRL1Ghx6RrE3g52FJz3O4 5ig6WD4mnEHJCjRH85jFxzbT5kzWMJI8CBptjpTV1RIXAGGkMmD4alj0de1j xWibi3mZYgJemoTh1eNpLR/f2WQv0UW/aW0px0FMbcZrLYY9zol81k7UFkNk RfdFrXvNGId4uG0DhsD2cgcgg3KW7fVik+ij8F6GYeFFvW5PWn5UEp0VYYa3 JNkoEBy4tgMpFa6+4yARjNhIrUZJrJIIe7c1V2qzDNLkH6SNWgyCX1cF3Pw9 mLlEUwZxM3F1bwlVazRNLTafjRp4Gbxu+1RyTWbHodDazS1wIunmBQe3Dzgv i21s9ODiv22uYdSXIv9vLTg4NTktMZwKA2Z2P3kTGUcWw14DWwBtBwkLx2l4 JSP/yaLaQ00gcjvJhloLhU/ySG/OkW/hIgYgEhk0MTP9VmqLMx40nVRNSU1F LbkWLQi2NzYS1j6qhYYAcHW9WvZO0gDDRneeD0l6eEHDpx88u/ZCJQyDkuNI Om0M1tr2tXwfZAAsAqAAfY5C5iB515gnRHGrQ0sEQXxdUFSgo7e9AU86PAw+ D9xM0Oxr5LHaEUAUo0CRjacgAIZ39BY2+/iQSEVMC0Yxzk8gu7MvPLmtNwvF bDfVRGWzrodTeRRtH1fMamGrni1yRTCWVOg1TC0ZCMTBpBnFQxzS93KA6/Nb MTVHXHTs+mgyaECtYXnuLgHpZsPOYyACC3hcjTse1a4zTVRQjBRs0lh3QdkT DXu1fWhsSiCvJ0xgtblzcnZcAHtJa66tc6addEhjiQyzFszVkghndA/rCuVC O1VyFgNCZUlNbUAkzsxo9FDqaAZ4U5PZ72aNFaPWJ+h8k3ZqNVPJnthKjYRY i7l3lyAH+7VXGtrNxCCOO2N1gx1kqoSp7bgjIQEHYjeJF60rurJxaK2LMYdJ r2sUNntuwXSTVDYhiUegWuFJI/NpThDOBQet0GIONaGJsAu3A3EIeUFuLkUg 3NxNH2hBQ2u9LFZ4BY4wbZcbvbUm7DBSa5pJVHVTwI3Wdg5mVSOkOSBH8vZS qRtf7nBBS1hoaXTbZXu/SGJZBWhBZVkSLIDDK2xDQgoStwb4VHv4ZVvrXHPM CoYOgFxiXO0Jugtd+6siIyYi6CUxAyoCcO4Z8zUx2wOCcVbXD1x36ni8wHFT S3MNK9g2oMUZZ/kuAkkmT24P4wdYUE1FfCeY/AtOVNAHOAOMLZhmUxv2cLQX I6YMQhV3jia2Gkw5Q6wkU04gUSDYZB4gH1+hsGCcp2KmU/pW1oIuy1RHQMkm LVUcNG8dU4OLGL9ZE1xQrHxcAbBAhCaLVj2z0ILiDPJji2yYIJE3szdtYUiR HBZV53LJVy7EfzJiB2H8DDLYMQ8xMCoudcMBPxqko0NRB5MOhKZCV45yA3KJ VredDu5cIlxZhxZszUEUdQdzE6O17wFBQgM0BDTT0HiTXKPTZx+9fCyIL1sq aHQqSG9UBQOCdWxMD1DhMmzqy8gAR1hHqTHYKo0OL51V4h7DPbotQWc8GKdN b3qFa7DULLAv29i00liwvHeTO2wCuti0bTc0FDuFLXU/R4Ll9qbYby8yNQEw MQAkwbDgBGVnxdOAr21CChdrWmwKdcUkZYtrheuifdA8n1PDYUUCdfHGRrJF jWM6XNl5bSlgXR9yCxgjOlCDmeM3NzCjjNJAIIa1hmugDyJaLGQBTjxHUKQW 7QOZZMpMQQEoIJlIHgBIABCEQCZkABCBBmQIZAEQgmQIZEACEO6qyty/AAEH N8htkC4FF8ALHQs0AzJIBJaNCAMyIIOOj5AgAzIgkZLQdAMykwMDBwoLb7IR v4wMowD1YyQvBZMZw5SkmqbpGtMHaAk8CjTLpmkYEOyjEbzTNE3TEpgTbBhl 0zRNNBkMGtSimqZpmhucHHR4ZGuapml5VHpE/EeH153l3/8P+MBDDvbd2AIE 0qQPYIJ5giGvpt/z7yfPB6GlgZ/g/C9AfoD89gjjzajBo9qjj4H+BwyBDXJA tS9BIf93g7Zfz6LkohoA5aLoolvf7j5ffqH+UQUD2l7aX1/aatpql7+yMi/T 2N7g+TF+OQUKAAGjkgBFYRuVLSqIA2UzVETgSJCNigbFAWxtHypoVbRBCY6x FSDoBVOMDEScdO9AUA8ZU1DBxzZRw2VyKVRlbXBkVTxXhDfGYK+ILhNDyT5B LFS8LsFDCzZ7M+wNV3JpGRgvhOsqYEZvdChXAdsSPXUOVJDWbWexdQpQMW80 eVZI5g4bIFIFSChATCrAD7Td1ojqLnlORXg0VMBgFSgBh70KmLwHSE1u9s62 dQN4oESuh6IR29aVYQxTUmddT9m/3U48FFVuHHBWaWV3T2Z01rntsuNNGHAr OU0iOtfFFuu+diiJZu0/KxxebipHbG9iYWxGRKDY9rBlC0FsBmP3gR3YBKbM RxVhCVs3RvVOw3SoLBCWvQ9DbGH2NgmamxUxSKA/SNmsFSVNqaIk3JJwQI0X ZXCBb78F8W9vbGRwMzJTbvFzaG9aa8EMH18Si1yg3d7AD58OTG9FxJtNgJvN HyZrD0ZaAU9woaBUm+wMCHBlEUh0hUdHY3CRqW8EJfAOh/ZzZUhh+GEAcPKw P4YBzmNweQlhdBmC0Biu6I1ZsMO7v3lwLHyTSYniGbFaK29nfi/phJgtD3MI QXQXxXN0EWI8Ez1iE14wfKYgQw0Ug803a02fQtqliod5O1fgQ2h0zdywwSRk y10Kzt6kICmQrE9FCJYkCFmSsGRtdsBLVWArx5XNhlfvGEHbiIXC2Gh4ZPFw cBB2cqZfeOoyIma82VfrHGKMIbQxZkwbBsufMFvWG9iCQUNQswgRbAdWZkI6 XBDtUnRsgg8nQ7OEnZlDZlcNO1tWeu9PRU09Yv5kE0s2JHxJbmZvdVdlKNxe ty0dYRFwLVAA7RG6JkBiSmf7oO127EtleQxRdfx5Vjh1MPd4h5MRoR0OEDBD 0I8OyGYkzLotBS/pabpYIXX6IFQZo7D0sU91okJoQnACsBuW6WzbclVCa6M1 JMs/bGdwBnout7JbJERDE0SiewEbArtEZyZQaC1rbPjcyuayi7UCZEiQBAGU kdQw8NpXTiypiIJ7Ed6hM68SGhcO03TvMAoNOQyk3ENFgXlmZjFQvG8/jlVw I3JCdWYPmlVxczFzY2gPUOEOTEb3jrIZM/eCbJEcTSjECkLE9cxsAlsjSlNr d+rLEEFsNg0cjoozlnwVbMhFoniHUgYOYW5JoKMkIGMa6HJQ2Wv20N00Zkl0 owwCBrMdXY5ms441lUlkMxoEWzjMcJWvdpMkitMsHhf0A6cIjhQrbm6zNs3W HIoFIyP8/3NZlmXZAjQXNwkElFiWZRATA3TIZch/+VBFTAEEAL7RAj3i78X4 DwELAQbGAwCYaQDd7BsJ8aANQAsDBEx2s2AzBxswAcDGZkEIDBAHNtjL3gYA iKVSIDe3AiTiGAehVIOJK2woAh4upgJ7IRvsboKQkJiSArK5InhgLnLF+7Dm spkbFLACQN5pNrwuJgc8VsAHWhVtyifAT2yVjb3nC+vzc/BPANB+vxtQqA21 JwkAAAAAAAAASP8AAAAAAAAAAABgvgDwQACNvgAg//9Xg83/6xCQkJCQkJCK BkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D 7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4se g+78EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz //+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP 6Uz///9eife5PAEAAIoHRyzoPAF394A/A3XyiweKXwRmwegIwcAQhsQp+IDr 6AHwiQeDxwWJ2OLZjb4AIAEAiwcJwHRFi18EjYQwGEcBAAHzUIPHCP+WuEcB AJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WvEcBAAnAdAeJA4PDBOvY/5bA RwEAYek7Hf//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAwAAACgA AIAOAAAAaAAAgBAAAACoAACAAAAAAAAAAAAAAAAAAAABAAEAAABAAACAAAAA AAAAAAAAAAAAAAABAAkEAABYAAAA7FABAOgCAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQBsAAAAgAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAmAAAANhTAQAU AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAMAAAIAAAAAAAAAAAAAA AAAAAAEACQQAANgAAADwUwEAKAMAAAAAAAAAAAAAGCQBACgAAAAgAAAAQAAA AAEABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAA gAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD/ //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAP qqAAAAAAAAAAAAAAAAAAD6qgAAAAAAAAAAAAAAAAAPqqqgAAAAAAAAAAAAAA AAD6qqoAAAAAAAAAAAAAAAAPqqqqoAAAAAAAAAAAAAAA+qqqqqoAAAAAAAAA AAAAD6qqqqqqoAAAAAAAAAAAAA+qqqqqqqAAAAAAAAAAAAD6qqqqqqqqAAAA AAAAAAAPqqqqqqqqqqAAAAAAAAAA+qqqqqqqqqqqAAAAAAAAD6qqqqqqqqqq qqAAAAAAAPqqqqqqqqqqqqqqAAAAAAD6qqqqqqqqqqqqqgAAAAAPqqqqqqqq qqqqqqqgAAAAD6qqqqqqqqqqqqqqoAAAAPqqqqqqqqqqqqqqqqoAAAD6qqqq qqqvqqqqqqqqAAAA+qqqqqqqAPqqqqqqqgAAAPqqqqqqqgD6qqqqqqoAAAAP qqqqqqAAD6qqqqqgAAAAD6qqqqqgAA+qqqqqoAAAAAD/qqqqAAAA/6qqqgAA AAAAAP///wAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////H////x////4P/// +D////Af///wH///4A///8AH//+AA///gAP//wAB//4AAP/8AAB/+AAAP/AA AB/wAAAf4AAAD+AAAA/AAAAHwAAAB8ABAAfAAQAH4AOAD+ADgA/wB8Af/A/w P////////////////wAnAQAAAAEAAQAgIBAAAQAEAOgCAAABAPAgAQAoAzQA AABWAFMAXwBWAEUAUgBTAEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAA AAUAAgAAAAAABQACAAAAPwAAAAAAAAAEAAQAAQAAAAAAAAAAAAAAAAAAAIgC AAABAFMAdAByAGkAbgBnAEYAaQBsAGUASQBuAGYAbwAAAGQCAAABADAANAAw ADkAMAA0AGIAMAAAADIADQABAEMAbwBtAG0AZQBuAHQAcwAAAFMAYwByAGUA ZQBuACAAUwBhAHYAZQByAAAAAABIABQAAQBDAG8AbQBwAGEAbgB5AE4AYQBt AGUAAAAAAHcAdwB3AC4AcwBjAHIAZQBlAG4AcwBhAHYAZQByAC4AYwBvAG0A AABCAA0AAQBGAGkAbABlAEQAZQBzAGMAcgBpAHAAdABpAG8AbgAAAAAAUwBj AHIAZQBlAG4AIABTAGEAdgBlAHIAAAAAADYACwABAEYAaQBsAGUAVgBlAHIA cwBpAG8AbgAAAAAANQAsACAAMAAsACAAMAAsACAAMgAAAAAAIAAAAAEASQBu AHQAZQByAG4AYQBsAE4AYQBtAGUAAABGABEAAQBMAGUAZwBhAGwAQwBvAHAA eQByAGkAZwBoAHQAAABDAG8AcAB5AHIAaQBnAGgAdAAgAKkAIAAyADAAMAAy AAAAAAAoAAAAAQBMAGUAZwBhAGwAVAByAGEAZABlAG0AYQByAGsAcwAAAAAA KAAAAAEATwByAGkAZwBpAG4AYQBsAEYAaQBsAGUAbgBhAG0AZQAAACAAAAAB AFAAcgBpAHYAYQB0AGUAQgB1AGkAbABkAAAAIAAAAAEAUAByAG8AZAB1AGMA dABOAGEAbQBlAAAAAAA6AAsAAQBQAHIAbwBkAHUAYwB0AFYAZQByAHMAaQBv AG4AAAA1ACwAIAAwACwAIAAwACwAIAAyAAAAAAAgAAAAAQBTAHAAZQBjAGkA YQBsAEIAdQBpAGwAZAAAAEQAAAABAFYAYQByAEYAaQBsAGUASQBuAGYAbwAA AAAAJAAEAAAAVAByAGEAbgBzAGwAYQB0AGkAbwBuAAAAAAAJBLAEAAAAAAAA AAAAAAAA+FcBALhXAQAAAAAAAAAAAAAAAAAFWAEAyFcBAAAAAAAAAAAAAAAA ABJYAQDQVwEAAAAAAAAAAAAAAAAAHFgBANhXAQAAAAAAAAAAAAAAAAAkWAEA 4FcBAAAAAAAAAAAAAAAAAC9YAQDoVwEAAAAAAAAAAAAAAAAAO1gBAPBXAQAA AAAAAAAAAAAAAAAAAAAAAAAAAEZYAQBUWAEAZFgBAAAAAAByWAEAAAAAAIBY AQAAAAAAiFgBAAAAAACYWAEAAAAAAKBYAQAAAAAAdAAAgAAAAABLRVJORUwz Mi5ETEwAQURWQVBJMzIuZGxsAEdESTMyLmRsbABNUFIuZGxsAFVTRVIzMi5k bGwAV0lOSU5FVC5kbGwAV1MyXzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0 UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABCaXRC bHQAAFdOZXRDbG9zZUVudW0AAABHZXREQwAAAEludGVybmV0R2V0Q29ubmVj dGVkU3RhdGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgd0jJzPSHeIzVDuICYWCCLzf9fQXVhSj8nrs jrsGuLYDNXGxNc+sxrxQQxTZE8HLXta4LqZ7i94YYOSqPJVsYQgSPEDvWhsO X1fJc+bwQM8XzX0djOvi7qCdPxJsX0xkivjQpdQ9AsFNYpuiFDhGQQrzhKrk wmHLXVFpSIZyHkzvvn22yRRZpxG/w5zu0BMBvb4sya/xvOyCDcvfh4cxMLWc cmySL4QqOe0EiNKJ40bcGqd/iWQSkUZpsYk4fx61kAcC+M3zlC3NHjWk5tPN GigbGPfHwjJxS6dzBta2Kx2OzEF9sGTMP/Z8NEvEWR0dpEXHcnqfLdNFV3BN n5POR9U3ZUoPmDp6B63B5QVJx13PkswmhGWnqiMj0zdlZmGNzbqQlZI3EK2T tZ3zxccenBYeOo0+IqZ/JlHm2rMoNzcORucRuwcoBHUCgBnwytIzGZMzLwsg tm+5cclm0LlxnHIeZg1uYdOHtSUa7lVCTyDmt7+cuRjvOW4+tSTI5ps7Fbwh VJ+4xaeBRu5rJa1A5LLT730X47QGLvbUaE5Uua4fHwOnxzxEc0Cm1F2GvdOK ypexu2gpFeQAQTaR0WYXjzWBHcsZ1ObIywhKt0ugy+DGzO0ezD1ePDzp7yp5 V7TD7nRjw6KC5bXakM+b2bk8No/PsKUudYkiSC747CdP7OpT9KVyCurkTqaa 9yqW78xSJk3HYPLt70r5qHp6cVGbR4Jh3x2ljvLngNZTvVg0kOLFGySHjLdd 7ypNU6ueGyqM1zfX0pjynp3maDmN0kMIzfeNg1LAgS8CFFN9XsVnMTXbh2sE 0DAAMLPJLztnsE/qa1K6CmMUD90ZTtKPqJ0lJ3eTVRDEcX6138WGJEbb43UJ cZlHzdIxksVJWW+4J5UJqShVab+nHy+NYrwNJBSYPfcuzHggOnze7IzXHyYv yt+6FzOcxY1T70hAC5WfdxHMjkwRNVVV5veZuxvi2LFwrQvgn3CAyPgKlvfC twft9iRLsRRdzU8tnha2ABt3n6eYVCM3nHG6cyZo70JJO17f8C3jg5UC9GZG 0wEvSUarCaR6+J8Lq8WyetF8rkQGS4FpA4XW8tMONQSEGofzb2yTVKq7ap8k GdPcH4xU08kwNoMjp9RhCxmXaRwvkb2tPOTpMik1d1SS16PKR1IfrHS6hwOo 5vccfgOup4ESeoZX6/ilQJGriiPNz5Iz0omTO0SBQEqm6TGWjJp/zqLyIdNK 5sB/0IfqYokhhi/yavSRpjXLrnKJEoOKkVgs7yqLrrSWi7qiVjDgM6Cye9Ep TzPzoLZE5S6GDBGI2d+BAk6025063lp9qgNrH4qhf3qACsvPTMBPWsQZYT4N v8Wz43VhFS6LdqK77mb5u53m+E5iePU4TiivzEBkriLkdnhUaMmFLmUyTBq1 mEoDnSpwLtRlKxBezqyJ73qpm7LUo3Tj13QLsRM5gUU9d2M2NrM5frAX67t4 NlKiWagV632X1BTBn8vBRiJDZrjBPlvjrHd00LH4mpkbV1pEgoKdy7iw13GT yZYXDWWRH+EKYD6Mcq7b9qttWVuWHQzO61kt0e1AElWeO9jbr0DVNnjQBlZ5 3j04pB8C2Z/e06uq29x8WtU3nPBA0b2wruidc7kQR6O40Vqksrjv6SZH4UBZ VnZFGCyS0GwI14YVqr0uY0PIr6QZCd7Uxq5ip529ajPJnNGBizRSArReLFUA r996ZkEk6N9MlVs7ZeazUT4wT3/z60lg4uebCLhNOi4gSAgiHySviABUe0ed +HyTw7vhxo4lYEy0MOwOdkF4JVQuSy8HofPKb6/H3MnWFuCHgluhnaLBXk8H a9wQE38VYnryT8A6igtuzBUycntqNkQLom09jDkQxn53dxWircahkSsRB1YY 8LOwtCRrajkfIVDcMOF+TE4kyBzPam4de0bFPSm1DxG5RtItxFwxK5oyPLcY Bu1smqZ4iALUr+3c5NTTLdsa+R3O3HYMTL+f7dA59yASE+DbZElN3Thi6ffU pimQgwzWKsCB280TF+sjJ7fiXKmy02fyFItqtUDfmQlfcfLaLeOA5872I8Ge MXrWdCLgm4c5OJwVVHFUmDm80S+e0iZH5lK+Icmvna5Nzi5dg5eiuNVvF6Jy zUeZe+xxypWwwTeUDmvbgFvWKUF27KRfY7t1T/K8StFi7yXLSG3kAtYkQo/P orfl+d7UmTq1rkVU1no5GJTqxw== --lnmvvurlnmvvur-- --lnmvvur-- From sekiya@sfc.wide.ad.jp Mon Oct 7 03:11:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 03:12:00 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97ABqtG016664 for ; Mon, 7 Oct 2002 03:11:53 -0700 Received: from rena.onaka.info ([IPv6:3ffe:516:3b00:ffff:230:65ff:fe1a:e264]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g979AcMa003397; Mon, 7 Oct 2002 18:10:38 +0900 Date: Mon, 07 Oct 2002 18:10:38 +0900 Message-ID: <87it0e1unl.wl@sfc.wide.ad.jp> From: Yuji Sekiya To: netdev@oss.sgi.com Cc: usagi-core@linux-ipv6.org Subject: USAGI STABLE RELEASE 4 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (powerpc-debian-linux-gnu) MULE/5.0 (SAKAKI) Organization: USAGI Project MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-2022-JP X-archive-position: 556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@linux-ipv6.org Precedence: bulk X-list: netdev We are glad to announce the USAGI[1] STABLE RELEASE 4, dated on October 7th, 2002. The release includes IPsec for IPv6, this is a big change from the previous stable release. On this release we provide only usagi-2.4 kernel because we feel linux-2.2 kernel becomes somewhat old and usagi-2.2 kernel is not our main developing target. The new or updated features are: ・ based on the latest kernel, linux-2.4.19 ・ IPsec for IPv6 ・ IPv6 over IPv6 tunnel (HUT implementation) ・ improved restricted double bind ・ anycast address support for kernel ・ based on the latest iputils-ss020124 ・ based on the latest netfilter-1.2.7a We also fixed the following bugs of the previous release: ・ behavior of double bind Currently we are contributing patches of USAGI kernel to the main-line kernel. Some of the improvements and features have already submitted and accepted. We would like to continue submitting patches. Our goal is completely merge of USAGI kernel features into the main-line kernel. You can get our complete kit which includes kernel tree, library and applications from We also provide a patch against the main-line kernel and a tarball of userland tools. We have a plan to provide the binary packages for some distributions. They will appear under within several weeks. When it will be available, we will announce. For the latest information on our web pages, please check our web site . We have a mailing list for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit for further information. Thanks. About USAGI Project The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We are tightly collaborating with WIDE Project[2], KAME Project[3] and TAHI Project[4], and trying to improve Linux kernel, IPv6 related libraries and IPv6 applications. Our snapshots are released every two weeks and stable release is released several times a year. Please check our web site http://www.linux-ipv6.org for the latest information. References: [1] USAGI Project [2] WIDE Project [3] KAME Project [4] TAHI Project -- USAGI Project From hadi@cyberus.ca Mon Oct 7 05:00:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 05:00:55 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97C0qtG019171 for ; Mon, 7 Oct 2002 05:00:53 -0700 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 IAA29397; Mon, 7 Oct 2002 08:00:47 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g97BrQj06563; Mon, 7 Oct 2002 07:53:30 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 7 Oct 2002 07:53:26 -0400 (EDT) From: jamal To: Ben Greear cc: Andre Hedrick , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) In-Reply-To: <3DA103A2.1060901@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 6 Oct 2002, Ben Greear wrote: > I can reproduce my crash using mtu sized pkts running only 50Mbps > send + receive on 2 nics. It took over-night to do it though. Running > as hard as I can with MTU packets will crash it as well, and much >quicker. > So is there a correlation with packet count then? > Interestingly enough, the tg3 NIC (netgear 302t), registered 57 deg C between > the fins of it's heat sink in the 32-bit slots. Makes me wonder if my PCI bus > is running too hot :P Does the problem happen with the tg3? cheers, jamal From hadi@cyberus.ca Mon Oct 7 05:04:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 05:04:17 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97C4FtG019423 for ; Mon, 7 Oct 2002 05:04:15 -0700 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 IAA00593; Mon, 7 Oct 2002 08:04:14 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g97BuxK06572; Mon, 7 Oct 2002 07:56:59 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 7 Oct 2002 07:56:59 -0400 (EDT) From: jamal To: Andre Hedrick cc: Ben Greear , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 558 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 It does seem like you need a lot of packets over a period of time to recreate it. So if what you are trying to do can achieve that, you should reproduce it. How many connections and sessions can you support? BTW, does iscsi call for a zero-copy receive? cheers, jamal From davem@redhat.com Mon Oct 7 05:05:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 05:05:43 -0700 (PDT) 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 g97C5ftG019735 for ; Mon, 7 Oct 2002 05:05:41 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id EAA26764; Mon, 7 Oct 2002 04:58:45 -0700 Date: Mon, 07 Oct 2002 04:58:44 -0700 (PDT) Message-Id: <20021007.045844.12156576.davem@redhat.com> To: hadi@cyberus.ca Cc: greearb@candelatech.com, andre@pyxtechnologies.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Update on e1000 troubles (over-heating!) From: "David S. Miller" In-Reply-To: References: <3DA103A2.1060901@candelatech.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: 559 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: jamal Date: Mon, 7 Oct 2002 07:53:26 -0400 (EDT) Does the problem happen with the tg3? He gets hangs in one box, inoperable PCI config space accesses for the cards in another box. From hadi@cyberus.ca Mon Oct 7 05:12:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 05:12:26 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97CCOtG020380 for ; Mon, 7 Oct 2002 05:12:24 -0700 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 IAA03353; Mon, 7 Oct 2002 08:12:23 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g97C57F06586; Mon, 7 Oct 2002 08:05:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 7 Oct 2002 08:05:07 -0400 (EDT) From: jamal To: Eran Mann cc: Ben Greear , "David S. Miller" , , Subject: Re: VLAN patches In-Reply-To: <3DA13332.4080109@mrv.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 560 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, 7 Oct 2002, Eran Mann wrote: > Regarding the 0 VID it is indeed used for priority-only frames. > Shouldn't it be supported by alowing the user to configure a priority > map for the ethernet device (rather than creating another user-visible > device? > That or you complain and drop the packet when someone sends; btw also VLANid > 0 and p tag 0 is legal - i guess that is the default for linux. On a side not: I never liked Bens patches that much compared to the other VLAN imp. -- would have prefered a marriage of the two. cheers, jamal From davem@redhat.com Mon Oct 7 05:15:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 05:15:58 -0700 (PDT) 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 g97CFutG020721 for ; Mon, 7 Oct 2002 05:15:56 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id FAA26849; Mon, 7 Oct 2002 05:09:07 -0700 Date: Mon, 07 Oct 2002 05:09:06 -0700 (PDT) Message-Id: <20021007.050906.62369710.davem@redhat.com> To: hadi@cyberus.ca Cc: emann@mrv.com, greearb@candelatech.com, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com Subject: Re: VLAN patches From: "David S. Miller" In-Reply-To: References: <3DA13332.4080109@mrv.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: 561 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: jamal Date: Mon, 7 Oct 2002 08:05:07 -0400 (EDT) I never liked Bens patches that much compared to the other VLAN imp. -- would have prefered a marriage of the two. There is a long thread deep in the archives for these lists saying why Ben's code went it. Please, let's not duplicate that conversation ok? From boroking@gmx.net Mon Oct 7 06:01:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 06:01:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97D1LtG032561 for ; Mon, 7 Oct 2002 06:01:22 -0700 Received: (qmail 23573 invoked by uid 0); 7 Oct 2002 13:01:11 -0000 Received: from dialup09.hades.dragon.net.au (HELO MyWorld.gmx.net) (203.56.247.73) by mail.gmx.net (mp007-rz3) with SMTP; 7 Oct 2002 13:01:11 -0000 Message-Id: <5.1.0.14.0.20021007230057.00b5b198@pop.gmx.net> X-Sender: boroking@gmx.net@pop.gmx.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 07 Oct 2002 23:01:16 +1000 To: Eran Mann , Ben Greear From: Boro King Subject: Re: VLAN patches Cc: "David S. Miller" , hadi@cyberus.ca, Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com In-Reply-To: <3DA13332.4080109@mrv.com> References: <20021005.220549.15266753.davem@redhat.com> <20021006.194654.35505461.davem@redhat.com> <3DA1010A.8020202@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: boroking@gmx.net Precedence: bulk X-list: netdev please take me of the mailing list!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From yoshfuji@linux-ipv6.org Mon Oct 7 08:06:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 08:06:11 -0700 (PDT) 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 g97F63tG006005 for ; Mon, 7 Oct 2002 08:06:05 -0700 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 g97F5xlw011028; Tue, 8 Oct 2002 00:05:59 +0900 Date: Tue, 08 Oct 2002 00:05:59 +0900 (JST) Message-Id: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses 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-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: 563 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, Prefix length for link-local address should be 64, not 10. This patch fixes prefix length of link-local address. Following patch is against 2.4.19. Thanks in advance. ------------------------------------------------------------------- Patch-Name: Fix Prefix Length of Link-local Addresses Patch-Id: FIX_2_4_19_LINKLOCAL_PREFIXLEN-20020928 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.20.1 diff -u -r1.1.1.1 -r1.1.1.1.20.1 --- net/ipv6/addrconf.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/addrconf.c 2002/09/27 17:17:06 1.1.1.1.20.1 @@ -783,7 +783,7 @@ struct in6_addr addr; ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0); - addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF); + addrconf_prefix_route(&addr, 64, dev, 0, RTF_ADDRCONF); } static struct inet6_dev *addrconf_add_dev(struct net_device *dev) @@ -1158,7 +1158,7 @@ flag |= IFA_HOST; } if (idev->dev->flags&IFF_POINTOPOINT) - plen = 10; + plen = 64; else plen = 96; @@ -1208,7 +1208,7 @@ { struct inet6_ifaddr * ifp; - ifp = ipv6_add_addr(idev, addr, 10, IFA_LINK, IFA_F_PERMANENT); + ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, IFA_F_PERMANENT); if (ifp) { addrconf_dad_start(ifp); in6_ifa_put(ifp); From greearb@candelatech.com Mon Oct 7 09:40:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 09:40:59 -0700 (PDT) Received: from grok.yi.org (IDENT:tU32dhJjHLOe47SjxW5goEvxxlS1jGKI@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97GertG007860 for ; Mon, 7 Oct 2002 09:40:54 -0700 Received: from candelatech.com (IDENT:ylg/14Ju+yysPzbw1BvVgnp506GmZR+G@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g97GeEq30326; Mon, 7 Oct 2002 09:40:16 -0700 Message-ID: <3DA1B8ED.2000309@candelatech.com> Date: Mon, 07 Oct 2002 09:40:13 -0700 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: Andre Hedrick , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 564 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 Sun, 6 Oct 2002, Ben Greear wrote: > > >>I can reproduce my crash using mtu sized pkts running only 50Mbps >>send + receive on 2 nics. It took over-night to do it though. Running >>as hard as I can with MTU packets will crash it as well, and much >>quicker. >> > > > So is there a correlation with packet count then? No, running at slower speeds (50Mbps), the packet count was well over 4 billion (ie it successfully wrapped 32-bits). At higher speeds, it crashes before the 32-bit wrap, generally. It also does not coorelate to bytes-sent/received, or anything else that I could think of to look at. > > > >>Interestingly enough, the tg3 NIC (netgear 302t), registered 57 deg C between >>the fins of it's heat sink in the 32-bit slots. Makes me wonder if my PCI bus >>is running too hot :P > > > Does the problem happen with the tg3? As Dave mentioned, tg3 locks up almost immediately (like within 30 seconds), and in the meantime, it's spitting out errors that are 'impossible'. The messages I sent a day or two ago. I may have cooked my cards, or something like that, because one of the tg3's do not work in my other machine now. Still trouble-shooting that one. Ben > > cheers, > jamal > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From weixl@caltech.edu Mon Oct 7 11:12:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 11:12:54 -0700 (PDT) Received: from chamber.cco.caltech.edu (chamber.its.caltech.edu [131.215.48.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97ICntG013447 for ; Mon, 7 Oct 2002 11:12:49 -0700 Received: from weixl (sonata.caltech.edu [131.215.220.1]) by chamber.cco.caltech.edu (8.12.3/8.12.3) with ESMTP id g97ICkne002191 for ; Mon, 7 Oct 2002 11:12:47 -0700 (PDT) Message-ID: <03ab01c26e2d$06adeac0$f5f2010a@weixl> From: "Xiaoliang \(David\) Wei" To: References: Subject: How can we bound one CPU to one Gigabit NIC? Date: Mon, 7 Oct 2002 11:11:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weixl@caltech.edu Precedence: bulk X-list: netdev Hi Everyone, I am now doing some experiments on Dual CPU (2.4Ghz) with 2 Gigabit cards. Can anyone tell me how to bound one CPU to each NIC so that we don't need to care about the packet-reordering and the interrupt sharing problems? Thank you very much.:) Xiaoliang (David) Wei Graduate Student in CS@Caltech http://www.cs.caltech.edu/~weixl ==================================================== From greearb@candelatech.com Mon Oct 7 11:24:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 11:24:40 -0700 (PDT) Received: from grok.yi.org (IDENT:9VY/Yrf6+qzm6em06r+1nvMco9LquyiI@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97IObtG013914 for ; Mon, 7 Oct 2002 11:24:38 -0700 Received: from candelatech.com (IDENT:eAisPhZtwcLne0JgSmo9te2Cl1+DvLO2@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g97IOSq12663; Mon, 7 Oct 2002 11:24:28 -0700 Message-ID: <3DA1D15C.1070309@candelatech.com> Date: Mon, 07 Oct 2002 11:24:28 -0700 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: "Xiaoliang (David) Wei" CC: netdev@oss.sgi.com Subject: Re: How can we bound one CPU to one Gigabit NIC? References: <03ab01c26e2d$06adeac0$f5f2010a@weixl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 566 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 Xiaoliang (David) Wei wrote: > Hi Everyone, > I am now doing some experiments on Dual CPU (2.4Ghz) with 2 Gigabit > cards. Can anyone tell me how to bound one CPU to each NIC so that we don't > need to care about the packet-reordering and the interrupt sharing problems? > Thank you very much.:) My experiments show you will still get re-ordered packets occasionally (but then again, I'm having other wierd problems, so maybe you wont). # Bind processor 2 (1<<1) to irq 11 echo 2 > /proc/irq/11/smp_affinity # Bind processor 1 (1<<0) to irq 19 echo 1 > /proc/irq/9/smp_affinity I will be interested to hear of your results, as I have been having heating problems with e1000 and other problems with tg3 based nics! Ben > > > > Xiaoliang (David) Wei Graduate Student in CS@Caltech > http://www.cs.caltech.edu/~weixl > ==================================================== > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From davem@redhat.com Mon Oct 7 12:02:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 12:02:47 -0700 (PDT) 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 g97J2gtG014560 for ; Mon, 7 Oct 2002 12:02:42 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id LAA30959; Mon, 7 Oct 2002 11:55:30 -0700 Date: Mon, 07 Oct 2002 11:55:30 -0700 (PDT) Message-Id: <20021007.115530.00078126.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: "David S. Miller" In-Reply-To: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> References: <20021008.000559.17528416.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: 567 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 / 吉藤英明 Date: Tue, 08 Oct 2002 00:05:59 +0900 (JST) Prefix length for link-local address should be 64, not 10. This patch fixes prefix length of link-local address. Following patch is against 2.4.19. Patch is applied, thank you. BTW, we start to run into conflicts now and most of USAGI patches now I need to apply some parts by hand. Here is one example, with this patch: @@ -783,7 +783,7 @@ struct in6_addr addr; ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0); - addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF); + addrconf_prefix_route(&addr, 64, dev, 0, RTF_ADDRCONF); } static struct inet6_dev *addrconf_add_dev(struct net_device *dev) Note in this hunk the __constant_htonl() which was transformed to plain htonl() by already accepted USAGI patch. It is not such a big deal now, but it may soon become larger as bigger USAGI patches are applied. We will need to synchronize at some point. From weixl@caltech.edu Mon Oct 7 12:13:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 12:13:47 -0700 (PDT) Received: from chamber.cco.caltech.edu (chamber.its.caltech.edu [131.215.48.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97JDjtG015130 for ; Mon, 7 Oct 2002 12:13:45 -0700 Received: from weixl (sonata.caltech.edu [131.215.220.1]) by chamber.cco.caltech.edu (8.12.3/8.12.3) with ESMTP id g97JDfne012358; Mon, 7 Oct 2002 12:13:41 -0700 (PDT) Message-ID: <003401c26e35$890d56b0$f5f2010a@weixl> From: "Xiaoliang \(David\) Wei" To: "Ben Greear" Cc: References: <03ab01c26e2d$06adeac0$f5f2010a@weixl> <3DA1D15C.1070309@candelatech.com> Subject: Re: How can we bound one CPU to one Gigabit NIC? Date: Mon, 7 Oct 2002 12:12:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weixl@caltech.edu Precedence: bulk X-list: netdev Thanks Ben. We are going to use SysKonnect Cards. Are they tg3 based, too? Thank you. Xiaoliang (David) Wei Graduate Student in CS@Caltech http://www.cs.caltech.edu/~weixl ==================================================== ----- Original Message ----- From: "Ben Greear" To: "Xiaoliang (David) Wei" Cc: Sent: Monday, October 07, 2002 11:24 AM Subject: Re: How can we bound one CPU to one Gigabit NIC? > Xiaoliang (David) Wei wrote: > > Hi Everyone, > > I am now doing some experiments on Dual CPU (2.4Ghz) with 2 Gigabit > > cards. Can anyone tell me how to bound one CPU to each NIC so that we don't > > need to care about the packet-reordering and the interrupt sharing problems? > > Thank you very much.:) > > My experiments show you will still get re-ordered packets occasionally > (but then again, I'm having other wierd problems, so maybe you wont). > > # Bind processor 2 (1<<1) to irq 11 > echo 2 > /proc/irq/11/smp_affinity > > # Bind processor 1 (1<<0) to irq 19 > echo 1 > /proc/irq/9/smp_affinity > > > I will be interested to hear of your results, as I have been having > heating problems with e1000 and other problems with tg3 based nics! > > Ben > > > > > > > > > Xiaoliang (David) Wei Graduate Student in CS@Caltech > > http://www.cs.caltech.edu/~weixl > > ==================================================== > > > > > -- > Ben Greear > President of Candela Technologies Inc http://www.candelatech.com > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > > > > From blueflux@koffein.net Mon Oct 7 12:34:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 12:34:18 -0700 (PDT) Received: from laptop1.agatha ([195.163.42.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97JYEtG016885 for ; Mon, 7 Oct 2002 12:34:15 -0700 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id g97HjeT01780 for ; Mon, 7 Oct 2002 19:45:41 +0200 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Mon, 7 Oct 2002 19:45:40 +0200 (CEST) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: netdev@oss.sgi.com Subject: [Almost OT] ipsysctl-tutorial pre-beta version Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 569 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 All, Just wanted to let everyone know that the ipsysctl-tutorial is released in a kind of super-pre-beta version or so. It's far far from complete, it probably contain 500 errors per word that it consists of, but.... I'd just like to see if people would like to read through parts of it and see what they think of it? This is the URL to the current version: http://ipsysctl-tutorial.frozentux.net Is this document worth the effort? Is this anything along the lines what you have wished for? Is there anything missing (yes, tons that I know of=))? Find any bugs or errors on my part? I will be totally honest, this document probably took me several hundreds of hours getting this far, since I had to pretty much read up on every single variable in the source code. Considering that I am a fairly bad coder, this took some considerable part of the time:). I am pretty damn certain that this has led to hundreds of errors, and people will probably want to kill me for some of them. Thanks for any kind of feedback! -- ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net From bcrl@redhat.com Mon Oct 7 14:55:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 14:56:00 -0700 (PDT) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97LtstG018490 for ; Mon, 7 Oct 2002 14:55:55 -0700 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id C74EF8000F2; Mon, 7 Oct 2002 17:55:51 -0400 (EDT) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id g97LtpB25361; Mon, 7 Oct 2002 17:55:51 -0400 Date: Mon, 7 Oct 2002 17:55:51 -0400 From: Benjamin LaHaise To: davem@redhat.com, netdev@oss.sgi.com Subject: [patch] abstract out socket lock.users access Message-ID: <20021007175551.B30693@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev Hello Dave et al, The patch below abstracts out accesses of the socket lock users count access and replaces it with a macro, is_sock_locked(sk). It also changes sk->lock.users into a .owner field that stores a pointer to the current iocb that owns the lock. This is useful for aio as the userland side of a socket lock may need to be held until an operation that would have blocked is retried. Comments? -ben :r ~/patches/v2.5/v2.5.41-net-is_locked.diff diff -urN v2.5.41/include/net/sock.h linux.net-aio.00/include/net/sock.h --- v2.5.41/include/net/sock.h Tue Oct 1 13:25:11 2002 +++ linux.net-aio.00/include/net/sock.h Mon Oct 7 17:27:07 2002 @@ -70,15 +70,16 @@ * between user contexts and software interrupt processing, whereas the * mini-semaphore synchronizes multiple users amongst themselves. */ +struct sock_iocb; typedef struct { spinlock_t slock; - unsigned int users; + struct sock_iocb *owner; wait_queue_head_t wq; } socket_lock_t; #define sock_lock_init(__sk) \ do { spin_lock_init(&((__sk)->lock.slock)); \ - (__sk)->lock.users = 0; \ + (__sk)->lock.owner = NULL; \ init_waitqueue_head(&((__sk)->lock.wq)); \ } while(0) @@ -306,22 +307,35 @@ * Since ~2.3.5 it is also exclusive sleep lock serializing * accesses from user process context. */ +extern int __async_lock_sock(struct sock_iocb *, struct sock *, struct list_head *); extern void __lock_sock(struct sock *sk); extern void __release_sock(struct sock *sk); +#define sock_is_locked(sk) (NULL != (sk)->lock.owner) #define lock_sock(__sk) \ do { might_sleep(); \ spin_lock_bh(&((__sk)->lock.slock)); \ - if ((__sk)->lock.users != 0) \ + if ((__sk)->lock.owner != NULL) \ __lock_sock(__sk); \ - (__sk)->lock.users = 1; \ + (__sk)->lock.owner = (void *)1; \ spin_unlock_bh(&((__sk)->lock.slock)); \ } while(0) +#define async_lock_sock(iocb, __sk, list) \ +({ int ret = 0; \ + spin_lock_bh(&((__sk)->lock.slock)); \ + if ((__sk)->lock.owner != NULL) \ + ret = __async_lock_sock((iocb), (__sk), (list)); \ + else \ + (__sk)->lock.owner = (iocb); \ + spin_unlock_bh(&((__sk)->lock.slock)); \ + ret; \ +}) + #define release_sock(__sk) \ do { spin_lock_bh(&((__sk)->lock.slock)); \ if ((__sk)->backlog.tail != NULL) \ __release_sock(__sk); \ - (__sk)->lock.users = 0; \ + (__sk)->lock.owner = NULL; \ if (waitqueue_active(&((__sk)->lock.wq))) wake_up(&((__sk)->lock.wq)); \ spin_unlock_bh(&((__sk)->lock.slock)); \ } while(0) diff -urN v2.5.41/include/net/tcp.h linux.net-aio.00/include/net/tcp.h --- v2.5.41/include/net/tcp.h Tue Sep 17 18:05:36 2002 +++ linux.net-aio.00/include/net/tcp.h Mon Oct 7 17:20:05 2002 @@ -1348,7 +1348,7 @@ if (tp->ucopy.memory > sk->rcvbuf) { struct sk_buff *skb1; - if (sk->lock.users) BUG(); + if (sock_is_locked(sk)) BUG(); while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) { sk->backlog_rcv(sk, skb1); diff -urN v2.5.41/net/core/sock.c linux.net-aio.00/net/core/sock.c --- v2.5.41/net/core/sock.c Tue Sep 17 18:05:38 2002 +++ linux.net-aio.00/net/core/sock.c Mon Oct 7 17:20:05 2002 @@ -861,7 +861,7 @@ spin_unlock_bh(&sk->lock.slock); schedule(); spin_lock_bh(&sk->lock.slock); - if(!sk->lock.users) + if(!sock_is_locked(sk)) break; } current->state = TASK_RUNNING; diff -urN v2.5.41/net/decnet/dn_nsp_in.c linux.net-aio.00/net/decnet/dn_nsp_in.c --- v2.5.41/net/decnet/dn_nsp_in.c Thu Jun 6 00:35:20 2002 +++ linux.net-aio.00/net/decnet/dn_nsp_in.c Mon Oct 7 17:32:49 2002 @@ -800,8 +800,8 @@ printk(KERN_DEBUG "NSP: 0x%02x 0x%02x 0x%04x 0x%04x %d\n", (int)cb->rt_flags, (int)cb->nsp_flags, (int)cb->src_port, (int)cb->dst_port, - (int)sk->lock.users); - if (sk->lock.users == 0) + (int)is_sock_locked(sk)); + if (!is_sock_locked(sk)) ret = dn_nsp_backlog_rcv(sk, skb); else sk_add_backlog(sk, skb); diff -urN v2.5.41/net/decnet/dn_timer.c linux.net-aio.00/net/decnet/dn_timer.c --- v2.5.41/net/decnet/dn_timer.c Mon Jan 22 16:32:10 2001 +++ linux.net-aio.00/net/decnet/dn_timer.c Mon Oct 7 17:33:38 2002 @@ -57,7 +57,7 @@ sock_hold(sk); bh_lock_sock(sk); - if (sk->lock.users != 0) { + if (is_sock_locked(sk)) { sk->timer.expires = jiffies + HZ / 10; add_timer(&sk->timer); goto out; @@ -115,7 +115,7 @@ struct dn_scp *scp = DN_SK(sk); bh_lock_sock(sk); - if (sk->lock.users != 0) { + if (is_sock_locked(sk)) { scp->delack_timer.expires = jiffies + HZ / 20; add_timer(&scp->delack_timer); goto out; diff -urN v2.5.41/net/ipv4/tcp.c linux.net-aio.00/net/ipv4/tcp.c --- v2.5.41/net/ipv4/tcp.c Tue Sep 3 19:47:24 2002 +++ linux.net-aio.00/net/ipv4/tcp.c Mon Oct 7 17:20:05 2002 @@ -623,7 +623,7 @@ local_bh_disable(); bh_lock_sock(child); - BUG_TRAP(!child->lock.users); + BUG_TRAP(!sock_is_locked(child)); sock_hold(child); tcp_disconnect(child, O_NONBLOCK); @@ -2019,7 +2019,7 @@ */ local_bh_disable(); bh_lock_sock(sk); - BUG_TRAP(!sk->lock.users); + BUG_TRAP(!sock_is_locked(sk)); sock_hold(sk); sock_orphan(sk); diff -urN v2.5.41/net/ipv4/tcp_input.c linux.net-aio.00/net/ipv4/tcp_input.c --- v2.5.41/net/ipv4/tcp_input.c Mon Oct 7 17:19:22 2002 +++ linux.net-aio.00/net/ipv4/tcp_input.c Mon Oct 7 17:20:05 2002 @@ -2570,7 +2570,7 @@ /* Ok. In sequence. In window. */ if (tp->ucopy.task == current && tp->copied_seq == tp->rcv_nxt && tp->ucopy.len && - sk->lock.users && !tp->urg_data) { + sock_is_locked(sk) && !tp->urg_data) { int chunk = min_t(unsigned int, skb->len, tp->ucopy.len); @@ -3190,7 +3190,7 @@ { int result; - if (sk->lock.users) { + if (sock_is_locked(sk)) { local_bh_enable(); result = __tcp_checksum_complete(skb); local_bh_disable(); @@ -3324,7 +3324,7 @@ if (tp->ucopy.task == current && tp->copied_seq == tp->rcv_nxt && len - tcp_header_len <= tp->ucopy.len && - sk->lock.users) { + sock_is_locked(sk)) { __set_current_state(TASK_RUNNING); if (!tcp_copy_to_iovec(sk, skb, tcp_header_len)) { @@ -3864,7 +3864,7 @@ tmo = tcp_fin_time(tp); if (tmo > TCP_TIMEWAIT_LEN) { tcp_reset_keepalive_timer(sk, tmo - TCP_TIMEWAIT_LEN); - } else if (th->fin || sk->lock.users) { + } else if (th->fin || sock_is_locked(sk)) { /* Bad case. We could lose such FIN otherwise. * It is not a big problem, but it looks confusing * and not so rare event. We still can lose it now, diff -urN v2.5.41/net/ipv4/tcp_ipv4.c linux.net-aio.00/net/ipv4/tcp_ipv4.c --- v2.5.41/net/ipv4/tcp_ipv4.c Mon Oct 7 17:19:22 2002 +++ linux.net-aio.00/net/ipv4/tcp_ipv4.c Mon Oct 7 17:20:05 2002 @@ -1003,7 +1003,7 @@ /* If too many ICMPs get dropped on busy * servers this needs to be solved differently. */ - if (sk->lock.users) + if (sock_is_locked(sk)) NET_INC_STATS_BH(LockDroppedIcmps); if (sk->state == TCP_CLOSE) @@ -1022,7 +1022,7 @@ /* This is deprecated, but if someone generated it, * we have no reasons to ignore it. */ - if (!sk->lock.users) + if (!sock_is_locked(sk)) tcp_enter_cwr(tp); goto out; case ICMP_PARAMETERPROB: @@ -1033,7 +1033,7 @@ goto out; if (code == ICMP_FRAG_NEEDED) { /* PMTU discovery (RFC1191) */ - if (!sk->lock.users) + if (!sock_is_locked(sk)) do_pmtu_discovery(sk, iph, info); goto out; } @@ -1050,7 +1050,7 @@ switch (sk->state) { struct open_request *req, **prev; case TCP_LISTEN: - if (sk->lock.users) + if (sock_is_locked(sk)) goto out; req = tcp_v4_search_req(tp, &prev, th->dest, @@ -1081,7 +1081,7 @@ case TCP_SYN_RECV: /* Cannot happen. It can f.e. if SYNs crossed. */ - if (!sk->lock.users) { + if (!sock_is_locked(sk)) { TCP_INC_STATS_BH(TcpAttemptFails); sk->err = err; @@ -1111,7 +1111,7 @@ */ inet = inet_sk(sk); - if (!sk->lock.users && inet->recverr) { + if (!sock_is_locked(sk) && inet->recverr) { sk->err = err; sk->error_report(sk); } else { /* Only an error on timeout */ @@ -1778,7 +1778,7 @@ bh_lock_sock(sk); ret = 0; - if (!sk->lock.users) { + if (!sock_is_locked(sk)) { if (!tcp_prequeue(sk, skb)) ret = tcp_v4_do_rcv(sk, skb); } else diff -urN v2.5.41/net/ipv4/tcp_minisocks.c linux.net-aio.00/net/ipv4/tcp_minisocks.c --- v2.5.41/net/ipv4/tcp_minisocks.c Mon Oct 7 17:19:22 2002 +++ linux.net-aio.00/net/ipv4/tcp_minisocks.c Mon Oct 7 17:20:05 2002 @@ -989,7 +989,7 @@ int ret = 0; int state = child->state; - if (child->lock.users == 0) { + if (!sock_is_locked(child)) { ret = tcp_rcv_state_process(child, skb, skb->h.th, skb->len); /* Wakeup parent, send SIGIO */ diff -urN v2.5.41/net/ipv4/tcp_timer.c linux.net-aio.00/net/ipv4/tcp_timer.c --- v2.5.41/net/ipv4/tcp_timer.c Thu Jun 6 00:35:29 2002 +++ linux.net-aio.00/net/ipv4/tcp_timer.c Mon Oct 7 17:20:05 2002 @@ -213,7 +213,7 @@ struct tcp_opt *tp = tcp_sk(sk); bh_lock_sock(sk); - if (sk->lock.users) { + if (sock_is_locked(sk)) { /* Try again later. */ tp->ack.blocked = 1; NET_INC_STATS_BH(DelayedACKLocked); @@ -421,7 +421,7 @@ int event; bh_lock_sock(sk); - if (sk->lock.users) { + if (sock_is_locked(sk)) { /* Try again later */ if (!mod_timer(&tp->retransmit_timer, jiffies + (HZ/20))) sock_hold(sk); @@ -581,7 +581,7 @@ /* Only process if socket is not in use. */ bh_lock_sock(sk); - if (sk->lock.users) { + if (sock_is_locked(sk)) { /* Try again later. */ tcp_reset_keepalive_timer (sk, HZ/20); goto out; diff -urN v2.5.41/net/ipv6/tcp_ipv6.c linux.net-aio.00/net/ipv6/tcp_ipv6.c --- v2.5.41/net/ipv6/tcp_ipv6.c Tue Sep 3 19:47:24 2002 +++ linux.net-aio.00/net/ipv6/tcp_ipv6.c Mon Oct 7 17:35:17 2002 @@ -731,7 +731,7 @@ } bh_lock_sock(sk); - if (sk->lock.users) + if (is_sock_locked(sk)) NET_INC_STATS_BH(LockDroppedIcmps); if (sk->state == TCP_CLOSE) @@ -749,7 +749,7 @@ if (type == ICMPV6_PKT_TOOBIG) { struct dst_entry *dst = NULL; - if (sk->lock.users) + if (is_sock_locked(sk)) goto out; if ((1<state)&(TCPF_LISTEN|TCPF_CLOSE)) goto out; @@ -792,7 +792,7 @@ switch (sk->state) { struct open_request *req, **prev; case TCP_LISTEN: - if (sk->lock.users) + if (is_sock_locked(sk)) goto out; req = tcp_v6_search_req(tp, &prev, th->dest, &hdr->daddr, @@ -816,7 +816,7 @@ case TCP_SYN_SENT: case TCP_SYN_RECV: /* Cannot happen. It can, it SYNs are crossed. --ANK */ - if (sk->lock.users == 0) { + if (!is_sock_locked(sk)) { TCP_INC_STATS_BH(TcpAttemptFails); sk->err = err; sk->error_report(sk); /* Wake people up to see the error (see connect in sock.c) */ @@ -828,7 +828,7 @@ goto out; } - if (sk->lock.users == 0 && np->recverr) { + if (!is_sock_locked(sk) && np->recverr) { sk->err = err; sk->error_report(sk); } else { @@ -1622,7 +1622,7 @@ bh_lock_sock(sk); ret = 0; - if (!sk->lock.users) { + if (!is_sock_locked(sk)) { if (!tcp_prequeue(sk, skb)) ret = tcp_v6_do_rcv(sk, skb); } else diff -urN v2.5.41/net/llc/llc_c_ac.c linux.net-aio.00/net/llc/llc_c_ac.c --- v2.5.41/net/llc/llc_c_ac.c Mon Oct 7 17:19:22 2002 +++ linux.net-aio.00/net/llc/llc_c_ac.c Mon Oct 7 17:35:35 2002 @@ -1489,7 +1489,7 @@ __FUNCTION__); kfree_skb(skb); } else { - if (!sk->lock.users) + if (!is_sock_locked(sk)) llc_conn_state_process(sk, skb); else { llc_set_backlog_type(skb, LLC_EVENT); diff -urN v2.5.41/net/llc/llc_mac.c linux.net-aio.00/net/llc/llc_mac.c --- v2.5.41/net/llc/llc_mac.c Mon Oct 7 17:19:22 2002 +++ linux.net-aio.00/net/llc/llc_mac.c Mon Oct 7 17:35:55 2002 @@ -140,7 +140,7 @@ } else skb->sk = sk; bh_lock_sock(sk); - if (!sk->lock.users) { + if (!is_sock_locked(sk)) { /* rc = */ llc_conn_rcv(sk, skb); rc = 0; } else { diff -urN v2.5.41/net/llc/llc_proc.c linux.net-aio.00/net/llc/llc_proc.c --- v2.5.41/net/llc/llc_proc.c Mon Oct 7 17:19:22 2002 +++ linux.net-aio.00/net/llc/llc_proc.c Mon Oct 7 17:36:15 2002 @@ -182,7 +182,7 @@ timer_pending(&llc->pf_cycle_timer.timer), timer_pending(&llc->rej_sent_timer.timer), timer_pending(&llc->busy_state_timer.timer), - !!sk->backlog.tail, sk->lock.users); + !!sk->backlog.tail, is_sock_locked(sk)); out: return 0; } diff -urN v2.5.41/net/x25/x25_dev.c linux.net-aio.00/net/x25/x25_dev.c --- v2.5.41/net/x25/x25_dev.c Tue Oct 1 13:25:11 2002 +++ linux.net-aio.00/net/x25/x25_dev.c Mon Oct 7 17:36:32 2002 @@ -70,7 +70,7 @@ skb->h.raw = skb->data; bh_lock_sock(sk); - if (!sk->lock.users) { + if (!is_sock_locked(sk)) { queued = x25_process_rx_frame(sk, skb); } else { sk_add_backlog(sk, skb); diff -urN v2.5.41/net/x25/x25_timer.c linux.net-aio.00/net/x25/x25_timer.c --- v2.5.41/net/x25/x25_timer.c Tue Oct 1 13:25:11 2002 +++ linux.net-aio.00/net/x25/x25_timer.c Mon Oct 7 17:36:55 2002 @@ -131,7 +131,7 @@ struct sock *sk = (struct sock *)param; bh_lock_sock(sk); - if (sk->lock.users) /* can currently only occur in state 3 */ + if (is_sock_locked(sk)) /* can currently only occur in state 3 */ goto restart_heartbeat; switch (x25_sk(sk)->state) { @@ -193,7 +193,7 @@ struct sock *sk = (struct sock *)param; bh_lock_sock(sk); - if (sk->lock.users) { /* can currently only occur in state 3 */ + if (is_sock_locked(sk)) { /* can currently only occur in state 3 */ if (x25_sk(sk)->state == X25_STATE_3) x25_start_t2timer(sk); } else From davem@redhat.com Mon Oct 7 15:21:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 15:21:53 -0700 (PDT) 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 g97MLntG019082 for ; Mon, 7 Oct 2002 15:21:49 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA31856; Mon, 7 Oct 2002 15:14:59 -0700 Date: Mon, 07 Oct 2002 15:14:59 -0700 (PDT) Message-Id: <20021007.151459.09774569.davem@redhat.com> To: bcrl@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [patch] abstract out socket lock.users access From: "David S. Miller" In-Reply-To: <20021007175551.B30693@redhat.com> References: <20021007175551.B30693@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Benjamin LaHaise Date: Mon, 7 Oct 2002 17:55:51 -0400 We define this: +#define sock_is_locked(sk) (NULL != (sk)->lock.owner) But call: + (int)is_sock_locked(sk)); + if (!is_sock_locked(sk)) ... - if (sk->lock.users != 0) { + if (is_sock_locked(sk)) { And it's not a lock, it is a user ownership indication. I'd therefore prefer "sock_owned_by_user" or similar. Next: +#define async_lock_sock(iocb, __sk, list) \ +({ int ret = 0; \ + spin_lock_bh(&((__sk)->lock.slock)); \ + if ((__sk)->lock.owner != NULL) \ + ret = __async_lock_sock((iocb), (__sk), (list)); \ + else \ + (__sk)->lock.owner = (iocb); \ + spin_unlock_bh(&((__sk)->lock.slock)); \ + ret; \ +}) + How does this work? Is there some protocol that treats (void *)1 specially inside of __async_lock_sock()? Where are this semantics defined? Please clean up the {is_sock,sock_is}_locked() stuff and define how async_lock_sock works wrt. the owner pointer. From bcrl@redhat.com Mon Oct 7 15:50:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 15:50:55 -0700 (PDT) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97MoqtG019997 for ; Mon, 7 Oct 2002 15:50:52 -0700 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 5CCF88000E5; Mon, 7 Oct 2002 18:50:51 -0400 (EDT) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id g97Mop025537; Mon, 7 Oct 2002 18:50:51 -0400 Date: Mon, 7 Oct 2002 18:50:51 -0400 From: Benjamin LaHaise To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [patch] abstract out socket lock.users access Message-ID: <20021007185051.A25468@redhat.com> References: <20021007175551.B30693@redhat.com> <20021007.151459.09774569.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021007.151459.09774569.davem@redhat.com>; from davem@redhat.com on Mon, Oct 07, 2002 at 03:14:59PM -0700 X-archive-position: 572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev On Mon, Oct 07, 2002 at 03:14:59PM -0700, David S. Miller wrote: > From: Benjamin LaHaise > Date: Mon, 7 Oct 2002 17:55:51 -0400 > > We define this: > > +#define sock_is_locked(sk) (NULL != (sk)->lock.owner) Whoops. Sorry, but the cases that didn't compile aren't in my .config and the patch was written over a few days. > And it's not a lock, it is a user ownership indication. > I'd therefore prefer "sock_owned_by_user" or similar. Sure. > How does this work? Is there some protocol that treats (void *)1 > specially inside of __async_lock_sock()? Where are this semantics > defined? (void *)1 isn't special, it's just a way of ensuring that code which has yet to be converted still works. __async_lock_sock() treats owner == iocb special and allows that case to fall through succeeding without blocking. __async_lock_sock depends on the sock_iocb being defined which will follow, so I've removed it from this patch and into a later patch. > Please clean up the {is_sock,sock_is}_locked() stuff and define > how async_lock_sock works wrt. the owner pointer. async_lock_sock works by placing the iocb on a list of outstanding iocbs under the spinlock, until the socket is unlocked. The unlocker checks if there are any outstanding iocbs and transfers ownership of the lock to the head of the list and then kicks it off for processing. The read/write is then retried via the same code path it originally took unless the protocol replaced the retry hook. This should make for minimal bloat in the conversion to aio capable networking. Of course, you'll probably want to retweak things... Anyways, this version should be cleaned up, unless my eyes have glossed over and missed something in reading through the patch. -ben :r ~/patches/v2.5/v2.5.41-net-is_locked-B.diff diff -urN v2.5.41/include/net/sock.h v2.5.41-net-is_locked-B/include/net/sock.h --- v2.5.41/include/net/sock.h Tue Oct 1 13:25:11 2002 +++ v2.5.41-net-is_locked-B/include/net/sock.h Mon Oct 7 18:37:51 2002 @@ -70,15 +70,16 @@ * between user contexts and software interrupt processing, whereas the * mini-semaphore synchronizes multiple users amongst themselves. */ +struct sock_iocb; typedef struct { spinlock_t slock; - unsigned int users; + struct sock_iocb *owner; wait_queue_head_t wq; } socket_lock_t; #define sock_lock_init(__sk) \ do { spin_lock_init(&((__sk)->lock.slock)); \ - (__sk)->lock.users = 0; \ + (__sk)->lock.owner = NULL; \ init_waitqueue_head(&((__sk)->lock.wq)); \ } while(0) @@ -306,14 +307,16 @@ * Since ~2.3.5 it is also exclusive sleep lock serializing * accesses from user process context. */ +extern int __async_lock_sock(struct sock_iocb *, struct sock *, struct list_head *); extern void __lock_sock(struct sock *sk); extern void __release_sock(struct sock *sk); +#define sock_owned_by_user(sk) (NULL != (sk)->lock.owner) #define lock_sock(__sk) \ do { might_sleep(); \ spin_lock_bh(&((__sk)->lock.slock)); \ - if ((__sk)->lock.users != 0) \ + if ((__sk)->lock.owner != NULL) \ __lock_sock(__sk); \ - (__sk)->lock.users = 1; \ + (__sk)->lock.owner = (void *)1; \ spin_unlock_bh(&((__sk)->lock.slock)); \ } while(0) @@ -321,7 +324,7 @@ do { spin_lock_bh(&((__sk)->lock.slock)); \ if ((__sk)->backlog.tail != NULL) \ __release_sock(__sk); \ - (__sk)->lock.users = 0; \ + (__sk)->lock.owner = NULL; \ if (waitqueue_active(&((__sk)->lock.wq))) wake_up(&((__sk)->lock.wq)); \ spin_unlock_bh(&((__sk)->lock.slock)); \ } while(0) diff -urN v2.5.41/include/net/tcp.h v2.5.41-net-is_locked-B/include/net/tcp.h --- v2.5.41/include/net/tcp.h Tue Sep 17 18:05:36 2002 +++ v2.5.41-net-is_locked-B/include/net/tcp.h Mon Oct 7 18:36:01 2002 @@ -1348,7 +1348,7 @@ if (tp->ucopy.memory > sk->rcvbuf) { struct sk_buff *skb1; - if (sk->lock.users) BUG(); + if (sock_owned_by_user(sk)) BUG(); while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) { sk->backlog_rcv(sk, skb1); diff -urN v2.5.41/net/core/sock.c v2.5.41-net-is_locked-B/net/core/sock.c --- v2.5.41/net/core/sock.c Tue Sep 17 18:05:38 2002 +++ v2.5.41-net-is_locked-B/net/core/sock.c Mon Oct 7 18:36:01 2002 @@ -861,7 +861,7 @@ spin_unlock_bh(&sk->lock.slock); schedule(); spin_lock_bh(&sk->lock.slock); - if(!sk->lock.users) + if(!sock_owned_by_user(sk)) break; } current->state = TASK_RUNNING; diff -urN v2.5.41/net/decnet/dn_nsp_in.c v2.5.41-net-is_locked-B/net/decnet/dn_nsp_in.c --- v2.5.41/net/decnet/dn_nsp_in.c Thu Jun 6 00:35:20 2002 +++ v2.5.41-net-is_locked-B/net/decnet/dn_nsp_in.c Mon Oct 7 18:36:01 2002 @@ -800,8 +800,8 @@ printk(KERN_DEBUG "NSP: 0x%02x 0x%02x 0x%04x 0x%04x %d\n", (int)cb->rt_flags, (int)cb->nsp_flags, (int)cb->src_port, (int)cb->dst_port, - (int)sk->lock.users); - if (sk->lock.users == 0) + (int)sock_owned_by_user(sk)); + if (!sock_owned_by_user(sk)) ret = dn_nsp_backlog_rcv(sk, skb); else sk_add_backlog(sk, skb); diff -urN v2.5.41/net/decnet/dn_timer.c v2.5.41-net-is_locked-B/net/decnet/dn_timer.c --- v2.5.41/net/decnet/dn_timer.c Mon Jan 22 16:32:10 2001 +++ v2.5.41-net-is_locked-B/net/decnet/dn_timer.c Mon Oct 7 18:36:01 2002 @@ -57,7 +57,7 @@ sock_hold(sk); bh_lock_sock(sk); - if (sk->lock.users != 0) { + if (sock_owned_by_user(sk)) { sk->timer.expires = jiffies + HZ / 10; add_timer(&sk->timer); goto out; @@ -115,7 +115,7 @@ struct dn_scp *scp = DN_SK(sk); bh_lock_sock(sk); - if (sk->lock.users != 0) { + if (sock_owned_by_user(sk)) { scp->delack_timer.expires = jiffies + HZ / 20; add_timer(&scp->delack_timer); goto out; diff -urN v2.5.41/net/ipv4/tcp.c v2.5.41-net-is_locked-B/net/ipv4/tcp.c --- v2.5.41/net/ipv4/tcp.c Tue Sep 3 19:47:24 2002 +++ v2.5.41-net-is_locked-B/net/ipv4/tcp.c Mon Oct 7 18:36:01 2002 @@ -623,7 +623,7 @@ local_bh_disable(); bh_lock_sock(child); - BUG_TRAP(!child->lock.users); + BUG_TRAP(!sock_owned_by_user(child)); sock_hold(child); tcp_disconnect(child, O_NONBLOCK); @@ -2019,7 +2019,7 @@ */ local_bh_disable(); bh_lock_sock(sk); - BUG_TRAP(!sk->lock.users); + BUG_TRAP(!sock_owned_by_user(sk)); sock_hold(sk); sock_orphan(sk); diff -urN v2.5.41/net/ipv4/tcp_input.c v2.5.41-net-is_locked-B/net/ipv4/tcp_input.c --- v2.5.41/net/ipv4/tcp_input.c Mon Oct 7 17:19:22 2002 +++ v2.5.41-net-is_locked-B/net/ipv4/tcp_input.c Mon Oct 7 18:36:01 2002 @@ -2570,7 +2570,7 @@ /* Ok. In sequence. In window. */ if (tp->ucopy.task == current && tp->copied_seq == tp->rcv_nxt && tp->ucopy.len && - sk->lock.users && !tp->urg_data) { + sock_owned_by_user(sk) && !tp->urg_data) { int chunk = min_t(unsigned int, skb->len, tp->ucopy.len); @@ -3190,7 +3190,7 @@ { int result; - if (sk->lock.users) { + if (sock_owned_by_user(sk)) { local_bh_enable(); result = __tcp_checksum_complete(skb); local_bh_disable(); @@ -3324,7 +3324,7 @@ if (tp->ucopy.task == current && tp->copied_seq == tp->rcv_nxt && len - tcp_header_len <= tp->ucopy.len && - sk->lock.users) { + sock_owned_by_user(sk)) { __set_current_state(TASK_RUNNING); if (!tcp_copy_to_iovec(sk, skb, tcp_header_len)) { @@ -3864,7 +3864,7 @@ tmo = tcp_fin_time(tp); if (tmo > TCP_TIMEWAIT_LEN) { tcp_reset_keepalive_timer(sk, tmo - TCP_TIMEWAIT_LEN); - } else if (th->fin || sk->lock.users) { + } else if (th->fin || sock_owned_by_user(sk)) { /* Bad case. We could lose such FIN otherwise. * It is not a big problem, but it looks confusing * and not so rare event. We still can lose it now, diff -urN v2.5.41/net/ipv4/tcp_ipv4.c v2.5.41-net-is_locked-B/net/ipv4/tcp_ipv4.c --- v2.5.41/net/ipv4/tcp_ipv4.c Mon Oct 7 17:19:22 2002 +++ v2.5.41-net-is_locked-B/net/ipv4/tcp_ipv4.c Mon Oct 7 18:36:01 2002 @@ -1003,7 +1003,7 @@ /* If too many ICMPs get dropped on busy * servers this needs to be solved differently. */ - if (sk->lock.users) + if (sock_owned_by_user(sk)) NET_INC_STATS_BH(LockDroppedIcmps); if (sk->state == TCP_CLOSE) @@ -1022,7 +1022,7 @@ /* This is deprecated, but if someone generated it, * we have no reasons to ignore it. */ - if (!sk->lock.users) + if (!sock_owned_by_user(sk)) tcp_enter_cwr(tp); goto out; case ICMP_PARAMETERPROB: @@ -1033,7 +1033,7 @@ goto out; if (code == ICMP_FRAG_NEEDED) { /* PMTU discovery (RFC1191) */ - if (!sk->lock.users) + if (!sock_owned_by_user(sk)) do_pmtu_discovery(sk, iph, info); goto out; } @@ -1050,7 +1050,7 @@ switch (sk->state) { struct open_request *req, **prev; case TCP_LISTEN: - if (sk->lock.users) + if (sock_owned_by_user(sk)) goto out; req = tcp_v4_search_req(tp, &prev, th->dest, @@ -1081,7 +1081,7 @@ case TCP_SYN_RECV: /* Cannot happen. It can f.e. if SYNs crossed. */ - if (!sk->lock.users) { + if (!sock_owned_by_user(sk)) { TCP_INC_STATS_BH(TcpAttemptFails); sk->err = err; @@ -1111,7 +1111,7 @@ */ inet = inet_sk(sk); - if (!sk->lock.users && inet->recverr) { + if (!sock_owned_by_user(sk) && inet->recverr) { sk->err = err; sk->error_report(sk); } else { /* Only an error on timeout */ @@ -1778,7 +1778,7 @@ bh_lock_sock(sk); ret = 0; - if (!sk->lock.users) { + if (!sock_owned_by_user(sk)) { if (!tcp_prequeue(sk, skb)) ret = tcp_v4_do_rcv(sk, skb); } else diff -urN v2.5.41/net/ipv4/tcp_minisocks.c v2.5.41-net-is_locked-B/net/ipv4/tcp_minisocks.c --- v2.5.41/net/ipv4/tcp_minisocks.c Mon Oct 7 17:19:22 2002 +++ v2.5.41-net-is_locked-B/net/ipv4/tcp_minisocks.c Mon Oct 7 18:36:01 2002 @@ -989,7 +989,7 @@ int ret = 0; int state = child->state; - if (child->lock.users == 0) { + if (!sock_owned_by_user(child)) { ret = tcp_rcv_state_process(child, skb, skb->h.th, skb->len); /* Wakeup parent, send SIGIO */ diff -urN v2.5.41/net/ipv4/tcp_timer.c v2.5.41-net-is_locked-B/net/ipv4/tcp_timer.c --- v2.5.41/net/ipv4/tcp_timer.c Thu Jun 6 00:35:29 2002 +++ v2.5.41-net-is_locked-B/net/ipv4/tcp_timer.c Mon Oct 7 18:36:01 2002 @@ -213,7 +213,7 @@ struct tcp_opt *tp = tcp_sk(sk); bh_lock_sock(sk); - if (sk->lock.users) { + if (sock_owned_by_user(sk)) { /* Try again later. */ tp->ack.blocked = 1; NET_INC_STATS_BH(DelayedACKLocked); @@ -421,7 +421,7 @@ int event; bh_lock_sock(sk); - if (sk->lock.users) { + if (sock_owned_by_user(sk)) { /* Try again later */ if (!mod_timer(&tp->retransmit_timer, jiffies + (HZ/20))) sock_hold(sk); @@ -581,7 +581,7 @@ /* Only process if socket is not in use. */ bh_lock_sock(sk); - if (sk->lock.users) { + if (sock_owned_by_user(sk)) { /* Try again later. */ tcp_reset_keepalive_timer (sk, HZ/20); goto out; diff -urN v2.5.41/net/ipv6/tcp_ipv6.c v2.5.41-net-is_locked-B/net/ipv6/tcp_ipv6.c --- v2.5.41/net/ipv6/tcp_ipv6.c Tue Sep 3 19:47:24 2002 +++ v2.5.41-net-is_locked-B/net/ipv6/tcp_ipv6.c Mon Oct 7 18:36:01 2002 @@ -731,7 +731,7 @@ } bh_lock_sock(sk); - if (sk->lock.users) + if (sock_owned_by_user(sk)) NET_INC_STATS_BH(LockDroppedIcmps); if (sk->state == TCP_CLOSE) @@ -749,7 +749,7 @@ if (type == ICMPV6_PKT_TOOBIG) { struct dst_entry *dst = NULL; - if (sk->lock.users) + if (sock_owned_by_user(sk)) goto out; if ((1<state)&(TCPF_LISTEN|TCPF_CLOSE)) goto out; @@ -792,7 +792,7 @@ switch (sk->state) { struct open_request *req, **prev; case TCP_LISTEN: - if (sk->lock.users) + if (sock_owned_by_user(sk)) goto out; req = tcp_v6_search_req(tp, &prev, th->dest, &hdr->daddr, @@ -816,7 +816,7 @@ case TCP_SYN_SENT: case TCP_SYN_RECV: /* Cannot happen. It can, it SYNs are crossed. --ANK */ - if (sk->lock.users == 0) { + if (!sock_owned_by_user(sk)) { TCP_INC_STATS_BH(TcpAttemptFails); sk->err = err; sk->error_report(sk); /* Wake people up to see the error (see connect in sock.c) */ @@ -828,7 +828,7 @@ goto out; } - if (sk->lock.users == 0 && np->recverr) { + if (!sock_owned_by_user(sk) && np->recverr) { sk->err = err; sk->error_report(sk); } else { @@ -1622,7 +1622,7 @@ bh_lock_sock(sk); ret = 0; - if (!sk->lock.users) { + if (!sock_owned_by_user(sk)) { if (!tcp_prequeue(sk, skb)) ret = tcp_v6_do_rcv(sk, skb); } else diff -urN v2.5.41/net/llc/llc_c_ac.c v2.5.41-net-is_locked-B/net/llc/llc_c_ac.c --- v2.5.41/net/llc/llc_c_ac.c Mon Oct 7 17:19:22 2002 +++ v2.5.41-net-is_locked-B/net/llc/llc_c_ac.c Mon Oct 7 18:36:01 2002 @@ -1489,7 +1489,7 @@ __FUNCTION__); kfree_skb(skb); } else { - if (!sk->lock.users) + if (!sock_owned_by_user(sk)) llc_conn_state_process(sk, skb); else { llc_set_backlog_type(skb, LLC_EVENT); diff -urN v2.5.41/net/llc/llc_mac.c v2.5.41-net-is_locked-B/net/llc/llc_mac.c --- v2.5.41/net/llc/llc_mac.c Mon Oct 7 17:19:22 2002 +++ v2.5.41-net-is_locked-B/net/llc/llc_mac.c Mon Oct 7 18:36:01 2002 @@ -140,7 +140,7 @@ } else skb->sk = sk; bh_lock_sock(sk); - if (!sk->lock.users) { + if (!sock_owned_by_user(sk)) { /* rc = */ llc_conn_rcv(sk, skb); rc = 0; } else { diff -urN v2.5.41/net/llc/llc_proc.c v2.5.41-net-is_locked-B/net/llc/llc_proc.c --- v2.5.41/net/llc/llc_proc.c Mon Oct 7 17:19:22 2002 +++ v2.5.41-net-is_locked-B/net/llc/llc_proc.c Mon Oct 7 18:36:01 2002 @@ -182,7 +182,7 @@ timer_pending(&llc->pf_cycle_timer.timer), timer_pending(&llc->rej_sent_timer.timer), timer_pending(&llc->busy_state_timer.timer), - !!sk->backlog.tail, sk->lock.users); + !!sk->backlog.tail, sock_owned_by_user(sk)); out: return 0; } diff -urN v2.5.41/net/x25/x25_dev.c v2.5.41-net-is_locked-B/net/x25/x25_dev.c --- v2.5.41/net/x25/x25_dev.c Tue Oct 1 13:25:11 2002 +++ v2.5.41-net-is_locked-B/net/x25/x25_dev.c Mon Oct 7 18:36:01 2002 @@ -70,7 +70,7 @@ skb->h.raw = skb->data; bh_lock_sock(sk); - if (!sk->lock.users) { + if (!sock_owned_by_user(sk)) { queued = x25_process_rx_frame(sk, skb); } else { sk_add_backlog(sk, skb); diff -urN v2.5.41/net/x25/x25_timer.c v2.5.41-net-is_locked-B/net/x25/x25_timer.c --- v2.5.41/net/x25/x25_timer.c Tue Oct 1 13:25:11 2002 +++ v2.5.41-net-is_locked-B/net/x25/x25_timer.c Mon Oct 7 18:36:01 2002 @@ -131,7 +131,7 @@ struct sock *sk = (struct sock *)param; bh_lock_sock(sk); - if (sk->lock.users) /* can currently only occur in state 3 */ + if (sock_owned_by_user(sk)) /* can currently only occur in state 3 */ goto restart_heartbeat; switch (x25_sk(sk)->state) { @@ -193,7 +193,7 @@ struct sock *sk = (struct sock *)param; bh_lock_sock(sk); - if (sk->lock.users) { /* can currently only occur in state 3 */ + if (sock_owned_by_user(sk)) { /* can currently only occur in state 3 */ if (x25_sk(sk)->state == X25_STATE_3) x25_start_t2timer(sk); } else From davem@redhat.com Mon Oct 7 16:00:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 16:00:25 -0700 (PDT) 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 g97N0MtG020557 for ; Mon, 7 Oct 2002 16:00:23 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA32218; Mon, 7 Oct 2002 15:53:32 -0700 Date: Mon, 07 Oct 2002 15:53:32 -0700 (PDT) Message-Id: <20021007.155332.32735975.davem@redhat.com> To: bcrl@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [patch] abstract out socket lock.users access From: "David S. Miller" In-Reply-To: <20021007185051.A25468@redhat.com> References: <20021007175551.B30693@redhat.com> <20021007.151459.09774569.davem@redhat.com> <20021007185051.A25468@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Benjamin LaHaise Date: Mon, 7 Oct 2002 18:50:51 -0400 Anyways, this version should be cleaned up, unless my eyes have glossed over and missed something in reading through the patch. Looks good, the sock_owned_by_user() is a needed good cleanup in any event. After some sleep I'll think some more about the async machinery and probably just apply this unless someone else finds something terribly wrong. From ahaas@neosoft.com Mon Oct 7 16:49:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 16:49:58 -0700 (PDT) Received: from mx4.airmail.net (mx4.airmail.net [209.196.77.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g97NnrtG021760 for ; Mon, 7 Oct 2002 16:49:53 -0700 Received: from mail3.iadfw.net ([209.196.123.3]) by mx4.airmail.net with smtp (Exim 4.10) id 17yh3S-000MOt-00; Mon, 07 Oct 2002 18:12:50 -0500 Received: from debian from [66.94.136.187] by mail3.iadfw.net (/\##/\ Smail3.1.30.16 #30.61) with esmtp for sender: id ; Mon, 7 Oct 2002 18:14:26 -0500 (CDT) Received: from arth by debian with local (Exim 3.36 #1 (Debian)) id 17ygYo-0003oo-00; Mon, 07 Oct 2002 17:41:10 -0500 Date: Mon, 7 Oct 2002 17:41:10 -0500 From: Art Haas To: netdev@oss.sgi.com, carnil@cs.tut.fi Cc: Linus Torvalds Subject: [PATCH] C99 designated initializer for net/atm/lec.c Message-ID: <20021007224110.GM9856@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahaas@neosoft.com Precedence: bulk X-list: netdev Hi. Here's a trivial patch for net/atm/lec.c to switch it to use C99 designated initializers. The patch is against 2.5.41. Art Haas --- linux-2.5.41/net/atm/lec.c.old 2002-07-05 18:42:03.000000000 -0500 +++ linux-2.5.41/net/atm/lec.c 2002-10-07 15:52:02.000000000 -0500 @@ -553,8 +553,8 @@ } static struct atmdev_ops lecdev_ops = { - close: lec_atm_close, - send: lec_atm_send + .close = lec_atm_close, + .send = lec_atm_send }; static struct atm_dev lecatm_dev = { -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 From ahaas@neosoft.com Mon Oct 7 17:19:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 17:19:34 -0700 (PDT) Received: from mx10.airmail.net (mxall.mxgrp.airmail.net [209.196.77.107]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g980JWtG023070 for ; Mon, 7 Oct 2002 17:19:33 -0700 Received: from mail3.iadfw.net ([209.196.123.3]) by mx10.airmail.net with smtp (Exim 4.10) id 17yh3z-0002ME-00; Mon, 07 Oct 2002 18:13:23 -0500 Received: from debian from [66.94.136.187] by mail3.iadfw.net (/\##/\ Smail3.1.30.16 #30.61) with esmtp for sender: id ; Mon, 7 Oct 2002 18:15:00 -0500 (CDT) Received: from arth by debian with local (Exim 3.36 #1 (Debian)) id 17ygjI-0003ui-00; Mon, 07 Oct 2002 17:52:00 -0500 Date: Mon, 7 Oct 2002 17:52:00 -0500 From: Art Haas To: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: [PATCH] trivial C99 designated initializer patch for net/netlink/af_netlink.c Message-ID: <20021007225200.GP9856@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahaas@neosoft.com Precedence: bulk X-list: netdev Hi. The trivial patch below fixes a structure to use C99 designated initializers. The patch is against 2.5.41. Art Haas --- linux-2.5.41/net/netlink/af_netlink.c.old 2002-08-10 22:04:03.000000000 -0500 +++ linux-2.5.41/net/netlink/af_netlink.c 2002-10-07 15:51:59.000000000 -0500 @@ -280,8 +280,8 @@ skb_queue_purge(&sk->write_queue); if (nlk->pid && !nlk->groups) { - struct netlink_notify n = { protocol:sk->protocol, - pid:nlk->pid }; + struct netlink_notify n = { .protocol = sk->protocol, + .pid = nlk->pid }; notifier_call_chain(&netlink_chain, NETLINK_URELEASE, &n); } -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 From rgooch@vindaloo.ras.ucalgary.ca Mon Oct 7 17:19:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 17:19:18 -0700 (PDT) Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g980JCtG022957 for ; Mon, 7 Oct 2002 17:19:13 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g980Id205154; Mon, 7 Oct 2002 18:18:39 -0600 Date: Mon, 7 Oct 2002 18:18:39 -0600 Message-Id: <200210080018.g980Id205154@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: netdev@oss.sgi.com Cc: Jeff Garzik , Donald Becker , Jason Lunz , "Patrick R. McManus" , edward_peng@dlink.com.tw Subject: Re: Continuing problems with sundance driver In-Reply-To: <200210052348.g95NmXK31793@vindaloo.ras.ucalgary.ca> References: <200210052348.g95NmXK31793@vindaloo.ras.ucalgary.ca> X-archive-position: 575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgooch@ras.ucalgary.ca Precedence: bulk X-list: netdev Hi, all. I've tried out the latest driver from D-Link, which they sent to me after I reported problems this weekend. I keep getting transmit timeouts, but so far the driver seems to recover OK. I've appended my kernel logs. The flood of logs is disturbing, and I wonder if this is supposed to be normal behaviour? I do note that it always seems to be the same interface (eth1) that is timing out. Is this perhaps because the link is auto negotiated to 100 Mb/s half duplex, and the other end (which doesn't do auto negotiation correctly), is set to 100 Mb/s full duplex? I still haven't had a response to how I'm supposed to force the interface. My best guess is that I need the following in /etc/modules.conf: options sundance media='"autosense,100mbps_fd,autosense"' but this doesn't seem to make any difference. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca =============================================================================== Oct 7 18:02:09 sundance.c:v1.01+LK1.05b 3-Oct-2002 Written by Donald Becker Oct 7 18:02:09 http://www.scyld.com/network/sundance.html Oct 7 18:02:09 eth0: D-Link DFE-580TX 4 port Server Adapter at 0xc000, 00:05:5d:10:4d:b8, IRQ 5. Oct 7 18:02:09 eth0: MII PHY found at address 1, status 0x782d advertising 01e1. Oct 7 18:02:09 eth1: D-Link DFE-580TX 4 port Server Adapter at 0xc400, 00:05:5d:10:4d:b9, IRQ 12. Oct 7 18:02:09 eth1: MII PHY found at address 1, status 0x782d advertising 01e1. Oct 7 18:02:09 eth2: D-Link DFE-580TX 4 port Server Adapter at 0xc800, 00:05:5d:10:4d:ba, IRQ 10. Oct 7 18:02:09 eth2: MII PHY found at address 1, status 0x782d advertising 01e1. Oct 7 18:02:09 eth3: D-Link DFE-580TX 4 port Server Adapter at 0xcc00, 00:05:5d:10:4d:bb, IRQ 11. Oct 7 18:02:09 eth3: MII PHY found at address 1, status 0x7809 advertising 01e1. Oct 7 18:02:09 eth0: Link changed: Oct 7 18:02:09 eth1: Link changed: Oct 7 18:02:09 eth0: Link changed: 100Mbps, full duplex Oct 7 18:02:09 eth1: Link changed: 100Mbps, half duplex Oct 7 18:02:09 eth2: Link changed: 100Mbps, full duplex Oct 7 18:03:37 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:03:37 eth1: Transmit timed out, TxStatus 00 TxFrameId 03, resetting... Oct 7 18:03:37 00 0f9d0000 0f9d0010 00008001(00) 0fa76812 8000004a Oct 7 18:03:37 01 0f9d0010 00000000 00008005(01) 0f5f1812 8000004a Oct 7 18:03:37 02 0f9d0020 0f9d0030 00018009(02) 00000000 00000000 Oct 7 18:03:37 03 0f9d0030 0f9d0040 0001800d(03) 00000000 00000000 Oct 7 18:03:37 04 0f9d0040 0f9d0050 00018011(04) 0f9cc812 8000059a Oct 7 18:03:37 05 0f9d0050 0f9d0060 00018015(05) 0fa2f812 80000042 Oct 7 18:03:37 06 0f9d0060 0f9d0070 00008019(06) 01324812 8000059a Oct 7 18:03:37 07 0f9d0070 0f9d0080 0000801d(07) 0fa79012 8000059a Oct 7 18:03:37 08 0f9d0080 0f9d0090 00008021(08) 0f40d812 8000059a Oct 7 18:03:37 09 0f9d0090 0f9d00a0 00008025(09) 013b4812 8000059a Oct 7 18:03:37 0a 0f9d00a0 0f9d00b0 00008029(0a) 0f425812 8000059a Oct 7 18:03:37 0b 0f9d00b0 0f9d00c0 0000802d(0b) 0f65d012 8000059a Oct 7 18:03:37 0c 0f9d00c0 0f9d00d0 00008031(0c) 0f52d012 80000035 Oct 7 18:03:37 0d 0f9d00d0 0f9d00e0 00008035(0d) 0fbbd812 80000035 Oct 7 18:03:37 0e 0f9d00e0 0f9d00f0 00008039(0e) 0fbe7012 80000035 Oct 7 18:03:37 0f 0f9d00f0 0f9d0100 0000803d(0f) 0f9da812 80000035 Oct 7 18:03:37 10 0f9d0100 0f9d0110 00008041(10) 0130e012 8000004e Oct 7 18:03:37 11 0f9d0110 0f9d0120 00008045(11) 0f533012 8000059a Oct 7 18:03:37 12 0f9d0120 0f9d0130 00008049(12) 0fa2e012 8000004e Oct 7 18:03:37 13 0f9d0130 0f9d0140 0000804d(13) 0f8cc812 8000003a Oct 7 18:03:37 14 0f9d0140 0f9d0150 00008051(14) 0f5ef812 8000059a Oct 7 18:03:37 15 0f9d0150 0f9d0160 00008055(15) 0f42e012 8000004e Oct 7 18:03:37 16 0f9d0160 0f9d0170 00008059(16) 0f40f012 8000059a Oct 7 18:03:37 17 0f9d0170 0f9d0180 0000805d(17) 0eccc812 80000062 Oct 7 18:03:37 18 0f9d0180 0f9d0190 00008061(18) 013b5012 8000003a Oct 7 18:03:37 19 0f9d0190 0f9d01a0 00008065(19) 0f5ee012 80000042 Oct 7 18:03:37 1a 0f9d01a0 0f9d01b0 00008069(1a) 0f756012 8000004e Oct 7 18:03:37 1b 0f9d01b0 0f9d01c0 0000806d(1b) 0f426012 80000042 Oct 7 18:03:37 1c 0f9d01c0 0f9d01d0 00008071(1c) 0fbe6812 8000004a Oct 7 18:03:37 1d 0f9d01d0 0f9d01e0 00008075(1d) 013b4012 8000004a Oct 7 18:03:37 1e 0f9d01e0 0f9d01f0 00008079(1e) 01361812 80000042 Oct 7 18:03:37 1f 0f9d01f0 0f9d0000 0000807d(1f) 0fa67812 8000004a Oct 7 18:03:37 TxListPtr=0f9d0060 netif_queue_stopped=1 Oct 7 18:03:37 cur_tx=706(02) dirty_tx=676(04) Oct 7 18:03:37 cur_rx=9 dirty_rx=9 Oct 7 18:05:01 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:05:01 eth1: Transmit timed out, TxStatus 00 TxFrameId 0b, resetting... Oct 7 18:05:01 00 0f9d0000 0f9d0010 00008001(00) 0f9d9812 800005ea Oct 7 18:05:01 01 0f9d0010 0f9d0020 00008005(01) 0f3f2012 800005ea Oct 7 18:05:01 02 0f9d0020 0f9d0030 00008009(02) 0f9d4012 800005ea Oct 7 18:05:01 03 0f9d0030 0f9d0040 0000800d(03) 0f88d012 800005ea Oct 7 18:05:01 04 0f9d0040 0f9d0050 00008011(04) 0f65e812 800005ea Oct 7 18:05:01 05 0f9d0050 0f9d0060 00008015(05) 0ecce812 800005ea Oct 7 18:05:01 06 0f9d0060 0f9d0070 00008019(06) 0f9d6812 800005ea Oct 7 18:05:01 07 0f9d0070 0f9d0080 0000801d(07) 01363812 800005ea Oct 7 18:05:01 08 0f9d0080 0f9d0090 00008021(08) 0f88d812 800005ea Oct 7 18:05:01 09 0f9d0090 00000000 00008025(09) 0f9d9012 800005ea Oct 7 18:05:01 0a 0f9d00a0 0f9d00b0 00018029(0a) 00000000 00000000 Oct 7 18:05:01 0b 0f9d00b0 0f9d00c0 0001802d(0b) 00000000 00000000 Oct 7 18:05:01 0c 0f9d00c0 0f9d00d0 00018031(0c) 0fbe7812 80000042 Oct 7 18:05:01 0d 0f9d00d0 0f9d00e0 00018035(0d) 0f651012 800005ea Oct 7 18:05:01 0e 0f9d00e0 0f9d00f0 00008039(0e) 0ece6012 800005ea Oct 7 18:05:01 0f 0f9d00f0 0f9d0100 0000803d(0f) 0f3fb812 800005ea Oct 7 18:05:01 10 0f9d0100 0f9d0110 00008041(10) 0ece7812 800005ea Oct 7 18:05:01 11 0f9d0110 0f9d0120 00008045(11) 0f531012 800005ea Oct 7 18:05:01 12 0f9d0120 0f9d0130 00008049(12) 0f70b012 800005ea Oct 7 18:05:01 13 0f9d0130 0f9d0140 0000804d(13) 0f9da012 800005ea Oct 7 18:05:01 14 0f9d0140 0f9d0150 00008051(14) 0ece6812 800005ea Oct 7 18:05:01 15 0f9d0150 0f9d0160 00008055(15) 0f9d7812 800005ea Oct 7 18:05:01 16 0f9d0160 0f9d0170 00008059(16) 0f88c012 800005ea Oct 7 18:05:01 17 0f9d0170 0f9d0180 0000805d(17) 0ece0012 800005ea Oct 7 18:05:01 18 0f9d0180 0f9d0190 00008061(18) 0fbfa812 800005ea Oct 7 18:05:01 19 0f9d0190 0f9d01a0 00008065(19) 0f81d012 800005ea Oct 7 18:05:01 1a 0f9d01a0 0f9d01b0 00008069(1a) 0f5a8012 800005ea Oct 7 18:05:01 1b 0f9d01b0 0f9d01c0 0000806d(1b) 013b5012 800005ea Oct 7 18:05:01 1c 0f9d01c0 0f9d01d0 00008071(1c) 0f5ab812 800005ea Oct 7 18:05:01 1d 0f9d01d0 0f9d01e0 00008075(1d) 0f5a8812 800005ea Oct 7 18:05:01 1e 0f9d01e0 0f9d01f0 00008079(1e) 0ece2812 800005ea Oct 7 18:05:01 1f 0f9d01f0 0f9d0000 0000807d(1f) 0f3f9012 800005ea Oct 7 18:05:01 TxListPtr=0f9d00e0 netif_queue_stopped=1 Oct 7 18:05:01 cur_tx=3178(0a) dirty_tx=3148(0c) Oct 7 18:05:01 cur_rx=43 dirty_rx=43 Oct 7 18:05:45 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:05:45 eth1: Transmit timed out, TxStatus 00 TxFrameId 0c, resetting... Oct 7 18:05:45 00 0f9d0000 0f9d0010 00008001(00) 0fbbc812 8000004e Oct 7 18:05:45 01 0f9d0010 0f9d0020 00008005(01) 01360012 8000004e Oct 7 18:05:45 02 0f9d0020 0f9d0030 00008009(02) 0fa79812 8000004e Oct 7 18:05:45 03 0f9d0030 0f9d0040 0000800d(03) 0fa66812 8000004e Oct 7 18:05:45 04 0f9d0040 0f9d0050 00008011(04) 0f65f812 8000004e Oct 7 18:05:45 05 0f9d0050 0f9d0060 00008015(05) 0f3f8812 80000042 Oct 7 18:05:45 06 0f9d0060 0f9d0070 00008019(06) 0f70a012 80000042 Oct 7 18:05:45 07 0f9d0070 0f9d0080 0000801d(07) 01361812 8000004e Oct 7 18:05:45 08 0f9d0080 0f9d0090 00008021(08) 01324812 8000004e Oct 7 18:05:45 09 0f9d0090 0f9d00a0 00008025(09) 0ece3812 8000004e Oct 7 18:05:45 0a 0f9d00a0 00000000 00008029(0a) 0f5ef812 8000004e Oct 7 18:05:45 0b 0f9d00b0 0f9d00c0 0001802d(0b) 00000000 00000000 Oct 7 18:05:45 0c 0f9d00c0 0f9d00d0 00018031(0c) 00000000 00000000 Oct 7 18:05:45 0d 0f9d00d0 0f9d00e0 00018035(0d) 0f3f0812 8000004e Oct 7 18:05:45 0e 0f9d00e0 0f9d00f0 00018039(0e) 0f42f812 800005ea Oct 7 18:05:45 0f 0f9d00f0 0f9d0100 0000803d(0f) 0f42e812 800005ea Oct 7 18:05:45 10 0f9d0100 0f9d0110 00008041(10) 0f81c012 800005ea Oct 7 18:05:45 11 0f9d0110 0f9d0120 00008045(11) 0ec8c812 800005ea Oct 7 18:05:45 12 0f9d0120 0f9d0130 00008049(12) 0f5f1012 800005ea Oct 7 18:05:45 13 0f9d0130 0f9d0140 0000804d(13) 0130f012 8000004e Oct 7 18:05:45 14 0f9d0140 0f9d0150 00008051(14) 0fbdc812 8000004e Oct 7 18:05:45 15 0f9d0150 0f9d0160 00008055(15) 0f9db012 8000004e Oct 7 18:05:45 16 0f9d0160 0f9d0170 00008059(16) 0f52d812 8000004e Oct 7 18:05:45 17 0f9d0170 0f9d0180 0000805d(17) 0f3f9812 8000004e Oct 7 18:05:45 18 0f9d0180 0f9d0190 00008061(18) 0ecf5012 8000004e Oct 7 18:05:45 19 0f9d0190 0f9d01a0 00008065(19) 0fac8012 8000004e Oct 7 18:05:45 1a 0f9d01a0 0f9d01b0 00008069(1a) 0ec8b012 8000004e Oct 7 18:05:45 1b 0f9d01b0 0f9d01c0 0000806d(1b) 0131a012 8000004e Oct 7 18:05:45 1c 0f9d01c0 0f9d01d0 00008071(1c) 0facb012 8000004e Oct 7 18:05:45 1d 0f9d01d0 0f9d01e0 00008075(1d) 0fa76812 8000004e Oct 7 18:05:45 1e 0f9d01e0 0f9d01f0 00008079(1e) 0130f812 8000004e Oct 7 18:05:45 1f 0f9d01f0 0f9d0000 0000807d(1f) 0f586812 8000004e Oct 7 18:05:45 TxListPtr=0f9d00f0 netif_queue_stopped=1 Oct 7 18:05:45 cur_tx=2891(0b) dirty_tx=2861(0d) Oct 7 18:05:45 cur_rx=2 dirty_rx=2 Oct 7 18:05:53 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:05:53 eth1: Transmit timed out, TxStatus 00 TxFrameId 03, resetting... Oct 7 18:05:53 00 0f9d0000 0f9d0010 00008001(00) 0f424812 80000042 Oct 7 18:05:53 01 0f9d0010 00000000 00008005(01) 0fb69812 800005ea Oct 7 18:05:53 02 0f9d0020 0f9d0030 00018009(02) 00000000 00000000 Oct 7 18:05:53 03 0f9d0030 0f9d0040 0001800d(03) 00000000 00000000 Oct 7 18:05:53 04 0f9d0040 0f9d0050 00018011(04) 0f9cc812 800005ea Oct 7 18:05:53 05 0f9d0050 0f9d0060 00008015(05) 0ea74812 800005ea Oct 7 18:05:53 06 0f9d0060 0f9d0070 00008019(06) 0f650012 800005ea Oct 7 18:05:53 07 0f9d0070 0f9d0080 0000801d(07) 0f5a8012 800005ea Oct 7 18:05:53 08 0f9d0080 0f9d0090 00008021(08) 0f757012 800005ea Oct 7 18:05:53 09 0f9d0090 0f9d00a0 00008025(09) 0f659012 80000042 Oct 7 18:05:53 0a 0f9d00a0 0f9d00b0 00008029(0a) 0f9d9812 800005ea Oct 7 18:05:53 0b 0f9d00b0 0f9d00c0 0000802d(0b) 0f533812 800005ea Oct 7 18:05:53 0c 0f9d00c0 0f9d00d0 00008031(0c) 0f531812 80000042 Oct 7 18:05:53 0d 0f9d00d0 0f9d00e0 00008035(0d) 0f5ab012 800005ea Oct 7 18:05:53 0e 0f9d00e0 0f9d00f0 00008039(0e) 0f88d812 800005ea Oct 7 18:05:53 0f 0f9d00f0 0f9d0100 0000803d(0f) 0f5f1012 80000042 Oct 7 18:05:53 10 0f9d0100 0f9d0110 00008041(10) 0f580012 800005ea Oct 7 18:05:53 11 0f9d0110 0f9d0120 00008045(11) 0f9da012 800005ea Oct 7 18:05:53 12 0f9d0120 0f9d0130 00008049(12) 01363812 80000042 Oct 7 18:05:53 13 0f9d0130 0f9d0140 0000804d(13) 0ec75812 800005ea Oct 7 18:05:53 14 0f9d0140 0f9d0150 00008051(14) 0ec77012 800005ea Oct 7 18:05:53 15 0f9d0150 0f9d0160 00008055(15) 0fbbd012 8000024e Oct 7 18:05:53 16 0f9d0160 0f9d0170 00008059(16) 0fbfa012 8000024e Oct 7 18:05:53 17 0f9d0170 0f9d0180 0000805d(17) 0f3fa012 800005ea Oct 7 18:05:53 18 0f9d0180 0f9d0190 00008061(18) 0130e812 800005ea Oct 7 18:05:53 19 0f9d0190 0f9d01a0 00008065(19) 0fa2f812 800005ea Oct 7 18:05:53 1a 0f9d01a0 0f9d01b0 00008069(1a) 0faca812 800005ea Oct 7 18:05:53 1b 0f9d01b0 0f9d01c0 0000806d(1b) 0f5eb012 800005ea Oct 7 18:05:53 1c 0f9d01c0 0f9d01d0 00008071(1c) 0f426812 800005ea Oct 7 18:05:53 1d 0f9d01d0 0f9d01e0 00008075(1d) 0fa2f012 80000042 Oct 7 18:05:53 1e 0f9d01e0 0f9d01f0 00008079(1e) 0f581812 800005ea Oct 7 18:05:53 1f 0f9d01f0 0f9d0000 0000807d(1f) 0ecff012 800005ea Oct 7 18:05:53 TxListPtr=0f9d0050 netif_queue_stopped=1 Oct 7 18:05:53 cur_tx=354(02) dirty_tx=324(04) Oct 7 18:05:53 cur_rx=56 dirty_rx=56 Oct 7 18:06:01 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:06:01 eth1: Transmit timed out, TxStatus 00 TxFrameId 13, resetting... Oct 7 18:06:01 00 0f9d0000 0f9d0010 00008001(00) 0f5ab012 800005ea Oct 7 18:06:01 01 0f9d0010 0f9d0020 00008005(01) 0f709012 800005ea Oct 7 18:06:01 02 0f9d0020 0f9d0030 00008009(02) 0f88d812 800005ea Oct 7 18:06:01 03 0f9d0030 0f9d0040 0000800d(03) 0facb012 800005ea Oct 7 18:06:01 04 0f9d0040 0f9d0050 00008011(04) 0f5f1012 800005ea Oct 7 18:06:01 05 0f9d0050 0f9d0060 00008015(05) 0fbbd012 80000042 Oct 7 18:06:01 06 0f9d0060 0f9d0070 00008019(06) 0f532012 800005ea Oct 7 18:06:01 07 0f9d0070 0f9d0080 0000801d(07) 0faca812 800005ea Oct 7 18:06:01 08 0f9d0080 0f9d0090 00008021(08) 0f9d7812 800005ea Oct 7 18:06:01 09 0f9d0090 0f9d00a0 00008025(09) 0ece3812 8000059a Oct 7 18:06:01 0a 0f9d00a0 0f9d00b0 00008029(0a) 0f587812 8000059a Oct 7 18:06:01 0b 0f9d00b0 0f9d00c0 0000802d(0b) 01325812 8000059a Oct 7 18:06:01 0c 0f9d00c0 0f9d00d0 00008031(0c) 0f5aa012 8000024e Oct 7 18:06:01 0d 0f9d00d0 0f9d00e0 00008035(0d) 0facb812 8000024e Oct 7 18:06:01 0e 0f9d00e0 0f9d00f0 00008039(0e) 0eace812 8000003e Oct 7 18:06:01 0f 0f9d00f0 0f9d0100 0000803d(0f) 0f70b012 8000059a Oct 7 18:06:01 10 0f9d0100 0f9d0110 00008041(10) 0f9d6812 800005ea Oct 7 18:06:01 11 0f9d0110 00000000 00008045(11) 0f8cc012 8000059a Oct 7 18:06:01 12 0f9d0120 0f9d0130 00018049(12) 00000000 00000000 Oct 7 18:06:01 13 0f9d0130 0f9d0140 0001804d(13) 00000000 00000000 Oct 7 18:06:01 14 0f9d0140 0f9d0150 00018051(14) 0ece1012 800005ea Oct 7 18:06:01 15 0f9d0150 0f9d0160 00018055(15) 0fbbc012 80000042 Oct 7 18:06:01 16 0f9d0160 0f9d0170 00008059(16) 0f9cc812 800005ea Oct 7 18:06:01 17 0f9d0170 0f9d0180 0000805d(17) 0f5a9012 800005ea Oct 7 18:06:01 18 0f9d0180 0f9d0190 00008061(18) 0f756812 80000042 Oct 7 18:06:01 19 0f9d0190 0f9d01a0 00008065(19) 0f5ee012 80000042 Oct 7 18:06:01 1a 0f9d01a0 0f9d01b0 00008069(1a) 0f659012 80000042 Oct 7 18:06:01 1b 0f9d01b0 0f9d01c0 0000806d(1b) 0f3fb012 80000042 Oct 7 18:06:01 1c 0f9d01c0 0f9d01d0 00008071(1c) 0fa79012 800005ea Oct 7 18:06:01 1d 0f9d01d0 0f9d01e0 00008075(1d) 01325012 800005ea Oct 7 18:06:01 1e 0f9d01e0 0f9d01f0 00008079(1e) 0f70b812 80000042 Oct 7 18:06:01 1f 0f9d01f0 0f9d0000 0000807d(1f) 0fbe7812 800005ea Oct 7 18:06:01 TxListPtr=0f9d0160 netif_queue_stopped=1 Oct 7 18:06:01 cur_tx=146(12) dirty_tx=116(14) Oct 7 18:06:01 cur_rx=18 dirty_rx=18 Oct 7 18:06:13 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:06:13 eth1: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... Oct 7 18:06:13 00 0f9d0000 0f9d0010 00018001(00) 00000000 00000000 Oct 7 18:06:13 01 0f9d0010 0f9d0020 00018005(01) 0f617012 800005ea Oct 7 18:06:13 02 0f9d0020 0f9d0030 00018009(02) 0f5a9012 8000004e Oct 7 18:06:13 03 0f9d0030 0f9d0040 0001800d(03) 0131a012 8000004e Oct 7 18:06:13 04 0f9d0040 0f9d0050 00008011(04) 0ec8a012 800005ea Oct 7 18:06:13 05 0f9d0050 0f9d0060 00008015(05) 0ece6812 800005ea Oct 7 18:06:13 06 0f9d0060 0f9d0070 00008019(06) 0ec76012 800005ea Oct 7 18:06:13 07 0f9d0070 0f9d0080 0000801d(07) 0ec76812 800005ea Oct 7 18:06:13 08 0f9d0080 0f9d0090 00008021(08) 0ec73012 80000042 Oct 7 18:06:13 09 0f9d0090 0f9d00a0 00008025(09) 0f5f0812 80000042 Oct 7 18:06:13 0a 0f9d00a0 0f9d00b0 00008029(0a) 0ec74812 800005ea Oct 7 18:06:13 0b 0f9d00b0 0f9d00c0 0000802d(0b) 0f659012 800005ea Oct 7 18:06:13 0c 0f9d00c0 0f9d00d0 00008031(0c) 0fa76812 80000042 Oct 7 18:06:13 0d 0f9d00d0 0f9d00e0 00008035(0d) 0ece7812 80000042 Oct 7 18:06:13 0e 0f9d00e0 0f9d00f0 00008039(0e) 0f426012 800005ea Oct 7 18:06:13 0f 0f9d00f0 0f9d0100 0000803d(0f) 0f65f812 800005ea Oct 7 18:06:13 10 0f9d0100 0f9d0110 00008041(10) 0f531012 800005ea Oct 7 18:06:13 11 0f9d0110 0f9d0120 00008045(11) 01324812 800005ea Oct 7 18:06:13 12 0f9d0120 0f9d0130 00008049(12) 0f3fa012 800005ea Oct 7 18:06:13 13 0f9d0130 0f9d0140 0000804d(13) 0ea74812 800005ea Oct 7 18:06:13 14 0f9d0140 0f9d0150 00008051(14) 0fbfa812 80000042 Oct 7 18:06:13 15 0f9d0150 0f9d0160 00008055(15) 013b4012 8000004e Oct 7 18:06:13 16 0f9d0160 0f9d0170 00008059(16) 0f580812 800005ea Oct 7 18:06:13 17 0f9d0170 0f9d0180 0000805d(17) 0f650012 80000036 Oct 7 18:06:13 18 0f9d0180 0f9d0190 00008061(18) 0fac9812 8000024e Oct 7 18:06:13 19 0f9d0190 0f9d01a0 00008065(19) 0f617812 80000087 Oct 7 18:06:13 1a 0f9d01a0 0f9d01b0 00008069(1a) 0f584812 800005ea Oct 7 18:06:13 1b 0f9d01b0 0f9d01c0 0000806d(1b) 0ec8c012 800005ea Oct 7 18:06:13 1c 0f9d01c0 0f9d01d0 00008071(1c) 0f585812 8000024e Oct 7 18:06:13 1d 0f9d01d0 0f9d01e0 00008075(1d) 0eccc812 8000004e Oct 7 18:06:13 1e 0f9d01e0 00000000 00008079(1e) 0f709812 8000003e Oct 7 18:06:13 1f 0f9d01f0 0f9d0000 0001807d(1f) 00000000 00000000 Oct 7 18:06:13 TxListPtr=0f9d0040 netif_queue_stopped=1 Oct 7 18:06:13 cur_tx=223(1f) dirty_tx=193(01) Oct 7 18:06:13 cur_rx=0 dirty_rx=0 Oct 7 18:06:21 NETDEV WATCHDOG: eth1: transmit timed out Oct 7 18:06:21 eth1: Transmit timed out, TxStatus 00 TxFrameId 10, resetting... Oct 7 18:06:21 00 0f9d0000 0f9d0010 00008001(00) 0f5ab012 800005ea Oct 7 18:06:21 01 0f9d0010 0f9d0020 00008005(01) 0ec72012 8000004e Oct 7 18:06:21 02 0f9d0020 0f9d0030 00008009(02) 0f40d812 8000004e Oct 7 18:06:21 03 0f9d0030 0f9d0040 0000800d(03) 0fac8812 800005ea Oct 7 18:06:21 04 0f9d0040 0f9d0050 00008011(04) 0f5ee812 800005ea Oct 7 18:06:21 05 0f9d0050 0f9d0060 00008015(05) 0f424812 800005ea Oct 7 18:06:21 06 0f9d0060 0f9d0070 00008019(06) 0ece1012 800005ea Oct 7 18:06:21 07 0f9d0070 0f9d0080 0000801d(07) 0f9d7812 8000004e Oct 7 18:06:21 08 0f9d0080 0f9d0090 00008021(08) 0fb69812 8000004e Oct 7 18:06:21 09 0f9d0090 0f9d00a0 00008025(09) 0ea7d012 800005ea Oct 7 18:06:21 0a 0f9d00a0 0f9d00b0 00008029(0a) 01325012 800005ea Oct 7 18:06:21 0b 0f9d00b0 0f9d00c0 0000802d(0b) 0fa2e812 8000004e Oct 7 18:06:21 0c 0f9d00c0 0f9d00d0 00008031(0c) 0ece0812 8000004e Oct 7 18:06:21 0d 0f9d00d0 0f9d00e0 00008035(0d) 013b5012 8000024e Oct 7 18:06:21 0e 0f9d00e0 00000000 00008039(0e) 0f40e012 8000024e Oct 7 18:06:21 0f 0f9d00f0 0f9d0100 0001803d(0f) 00000000 00000000 Oct 7 18:06:21 10 0f9d0100 0f9d0110 00018041(10) 00000000 00000000 Oct 7 18:06:21 11 0f9d0110 0f9d0120 00018045(11) 0f425012 800005ea Oct 7 18:06:21 12 0f9d0120 0f9d0130 00018049(12) 0f42f812 8000004e Oct 7 18:06:21 13 0f9d0130 0f9d0140 0001804d(13) 0f427012 80000036 Oct 7 18:06:21 14 0f9d0140 0f9d0150 00008051(14) 0ea7d812 800005ea Oct 7 18:06:21 15 0f9d0150 0f9d0160 00008055(15) 0facb812 800005ea Oct 7 18:06:21 16 0f9d0160 0f9d0170 00008059(16) 0f5a8812 800005ea Oct 7 18:06:21 17 0f9d0170 0f9d0180 0000805d(17) 0f586812 800005ea Oct 7 18:06:21 18 0f9d0180 0f9d0190 00008061(18) 0f651012 8000004e Oct 7 18:06:21 19 0f9d0190 0f9d01a0 00008065(19) 0f9d6812 8000004e Oct 7 18:06:21 1a 0f9d01a0 0f9d01b0 00008069(1a) 0f8cc012 800005ea Oct 7 18:06:21 1b 0f9d01b0 0f9d01c0 0000806d(1b) 0f756812 800005ea Oct 7 18:06:21 1c 0f9d01c0 0f9d01d0 00008071(1c) 0f88d012 800005ea Oct 7 18:06:21 1d 0f9d01d0 0f9d01e0 00008075(1d) 01325812 800005ea Oct 7 18:06:21 1e 0f9d01e0 0f9d01f0 00008079(1e) 0fa76812 800005ea Oct 7 18:06:21 1f 0f9d01f0 0f9d0000 0000807d(1f) 0ece5812 800005ea Oct 7 18:06:21 TxListPtr=0f9d0140 netif_queue_stopped=1 Oct 7 18:06:21 cur_tx=463(0f) dirty_tx=433(11) Oct 7 18:06:21 cur_rx=16 dirty_rx=16 From yoshfuji@linux-ipv6.org Mon Oct 7 17:37:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 17:37:26 -0700 (PDT) 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 g980bMtG024210 for ; Mon, 7 Oct 2002 17:37:23 -0700 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 g980bLlw014085; Tue, 8 Oct 2002 09:37:24 +0900 Date: Tue, 08 Oct 2002 09:37:21 +0900 (JST) Message-Id: <20021008.093721.11469009.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021007.115530.00078126.davem@redhat.com> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> <20021007.115530.00078126.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-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: 577 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 <20021007.115530.00078126.davem@redhat.com> (at Mon, 07 Oct 2002 11:55:30 -0700 (PDT)), "David S. Miller" says: > BTW, we start to run into conflicts now and most of USAGI patches now > I need to apply some parts by hand. Here is one example, with this > patch: : > It is not such a big deal now, but it may soon become larger as > bigger USAGI patches are applied. We will need to synchronize > at some point. Agreed. So,... What kind of patches do you prefer, now? - on top of plain kernel (2.4.19, 2.4.20, 2.4.21-preXX, or whatever) - plain kernel + on top of our whole patch? - ??? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ahaas@neosoft.com Mon Oct 7 18:23:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 07 Oct 2002 18:23:54 -0700 (PDT) Received: from mx1.airmail.net (mx1.airmail.net [209.196.77.98]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g981NptG025056 for ; Mon, 7 Oct 2002 18:23:52 -0700 Received: from mail3.iadfw.net ([209.196.123.3]) by mx1.airmail.net with smtp (Exim 4.10) id 17yh3P-000IG9-00; Mon, 07 Oct 2002 18:12:47 -0500 Received: from debian from [66.94.136.187] by mail3.iadfw.net (/\##/\ Smail3.1.30.16 #30.61) with esmtp for sender: id ; Mon, 7 Oct 2002 18:14:24 -0500 (CDT) Received: from arth by debian with local (Exim 3.36 #1 (Debian)) id 17ygfk-0003uS-00; Mon, 07 Oct 2002 17:48:20 -0500 Date: Mon, 7 Oct 2002 17:48:20 -0500 From: Art Haas To: netdev@oss.sgi.com Cc: Linus Torvalds Subject: [PATCH] trivial C99 designated initializer fix for net/sctp/sm_statetable.c Message-ID: <20021007224820.GO9856@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahaas@neosoft.com Precedence: bulk X-list: netdev Hi. As the subject indicated, the patch is trivial. Patch is against 2.5.41. Art Haas --- linux-2.5.41/net/sctp/sm_statetable.c.old 2002-09-28 10:35:14.000000000 -0500 +++ linux-2.5.41/net/sctp/sm_statetable.c 2002-10-07 15:51:59.000000000 -0500 @@ -555,7 +555,7 @@ .name = "sctp_sf_cookie_wait_prm_shutdown"}, \ /* SCTP_STATE_COOKIE_ECHOED */ \ {.fn = sctp_sf_cookie_echoed_prm_shutdown, \ - name:"sctp_sf_cookie_echoed_prm_shutdown"},\ + .name = "sctp_sf_cookie_echoed_prm_shutdown"},\ /* SCTP_STATE_ESTABLISHED */ \ {.fn = sctp_sf_do_9_2_prm_shutdown, \ .name = "sctp_sf_do_9_2_prm_shutdown"}, \ -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 From weixl@caltech.edu Tue Oct 8 00:28:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 00:28:18 -0700 (PDT) Received: from chamber.cco.caltech.edu (chamber.its.caltech.edu [131.215.48.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g987SDtG000760 for ; Tue, 8 Oct 2002 00:28:13 -0700 Received: from weixl (sonata.caltech.edu [131.215.220.1]) by chamber.cco.caltech.edu (8.12.3/8.12.3) with ESMTP id g987S7ne007807; Tue, 8 Oct 2002 00:28:08 -0700 (PDT) Message-ID: <010001c26e9c$2319c480$f5f2010a@weixl> From: "Xiaoliang \(David\) Wei" To: "Ben Greear" Cc: References: <03ab01c26e2d$06adeac0$f5f2010a@weixl> <3DA1D15C.1070309@candelatech.com> Subject: Re: How can we bound one CPU to one Gigabit NIC? Date: Tue, 8 Oct 2002 00:27:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weixl@caltech.edu Precedence: bulk X-list: netdev Thank you Ben. I did some UDP test with Iperf. Here are the results: Without bounding CPU, I had thousands of pakcets out of order in 1.7GByte* 2 connection transmission, with standard MTU. The throughput is about 550Mbps*2 (connection) with UDP packets. The sender can send 800Mbps for each connection. With CPU bounding, I had no packet out of order. Anyway, the two connections got only 1.3~1.4 throughput totally. The senders seemed to be able to send 1.6Gbps totally. (So, it seems that receiving packets takes more time than sending packets) Anyway, for a single connection on these machines, I could get 950Mbps. Is there any suggestion to improve the Dual CPU-Dual NIC performance? I looked at the "top". The two Iperf processes seemed to be using more than 60% CPU each. That means they are using different CPU. Anyway, I am not sure if they migrated from one CPU to the other very often or not. If they changed very often, it may resulted in the low performance, I guess. Is there anyway to bound a process to a specific CPU? The machines are with Dual Xeon 2.2 G CPU and Dual SysKonnect Gigabit-Ethernet Card. All the tests were done with UDP. (Iperf -s -u / Iperf -c -u -b1.7G.) Thanks. -David Xiaoliang (David) Wei Graduate Student in CS@Caltech http://www.cs.caltech.edu/~weixl ==================================================== ----- Original Message ----- From: "Ben Greear" To: "Xiaoliang (David) Wei" Cc: Sent: Monday, October 07, 2002 11:24 AM Subject: Re: How can we bound one CPU to one Gigabit NIC? > Xiaoliang (David) Wei wrote: > > Hi Everyone, > > I am now doing some experiments on Dual CPU (2.4Ghz) with 2 Gigabit > > cards. Can anyone tell me how to bound one CPU to each NIC so that we don't > > need to care about the packet-reordering and the interrupt sharing problems? > > Thank you very much.:) > > My experiments show you will still get re-ordered packets occasionally > (but then again, I'm having other wierd problems, so maybe you wont). > > # Bind processor 2 (1<<1) to irq 11 > echo 2 > /proc/irq/11/smp_affinity > > # Bind processor 1 (1<<0) to irq 19 > echo 1 > /proc/irq/9/smp_affinity > > > I will be interested to hear of your results, as I have been having > heating problems with e1000 and other problems with tg3 based nics! > > Ben > > > > > > > > > Xiaoliang (David) Wei Graduate Student in CS@Caltech > > http://www.cs.caltech.edu/~weixl > > ==================================================== > > > > > -- > 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 Tue Oct 8 02:04:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 02:04:23 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9894LtG004697 for ; Tue, 8 Oct 2002 02:04:21 -0700 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 FAA14720; Tue, 8 Oct 2002 05:04:20 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g988v4509980; Tue, 8 Oct 2002 04:57:04 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 8 Oct 2002 04:57:03 -0400 (EDT) From: jamal To: "Xiaoliang (David) Wei" cc: Ben Greear , Subject: Re: How can we bound one CPU to one Gigabit NIC? In-Reply-To: <010001c26e9c$2319c480$f5f2010a@weixl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 580 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 Can you repeat these tests with NAPI and no binding and see if you get any reordering? cheers, jamal On Tue, 8 Oct 2002, Xiaoliang (David) Wei wrote: > Thank you Ben. > I did some UDP test with Iperf. Here are the results: > Without bounding CPU, I had thousands of pakcets out of order in > 1.7GByte* 2 connection transmission, with standard MTU. The throughput is > about 550Mbps*2 (connection) with UDP packets. The sender can send 800Mbps > for each connection. > With CPU bounding, I had no packet out of order. Anyway, the two > connections got only 1.3~1.4 throughput totally. The senders seemed to be > able to send 1.6Gbps totally. (So, it seems that receiving packets takes > more time than sending packets) > Anyway, for a single connection on these machines, I could get 950Mbps. > Is there any suggestion to improve the Dual CPU-Dual NIC performance? I > looked at the "top". The two Iperf processes seemed to be using more than > 60% CPU each. That means they are using different CPU. Anyway, I am not sure > if they migrated from one CPU to the other very often or not. If they > changed very often, it may resulted in the low performance, I guess. Is > there anyway to bound a process to a specific CPU? > The machines are with Dual Xeon 2.2 G CPU and Dual SysKonnect > Gigabit-Ethernet Card. All the tests were done with UDP. (Iperf -s -u / > Iperf -c -u -b1.7G.) > Thanks. > > -David > Xiaoliang (David) Wei Graduate Student in CS@Caltech > http://www.cs.caltech.edu/~weixl > ==================================================== > ----- Original Message ----- > From: "Ben Greear" > To: "Xiaoliang (David) Wei" > Cc: > Sent: Monday, October 07, 2002 11:24 AM > Subject: Re: How can we bound one CPU to one Gigabit NIC? > > > > Xiaoliang (David) Wei wrote: > > > Hi Everyone, > > > I am now doing some experiments on Dual CPU (2.4Ghz) with 2 > Gigabit > > > cards. Can anyone tell me how to bound one CPU to each NIC so that we > don't > > > need to care about the packet-reordering and the interrupt sharing > problems? > > > Thank you very much.:) > > > > My experiments show you will still get re-ordered packets occasionally > > (but then again, I'm having other wierd problems, so maybe you wont). > > > > # Bind processor 2 (1<<1) to irq 11 > > echo 2 > /proc/irq/11/smp_affinity > > > > # Bind processor 1 (1<<0) to irq 19 > > echo 1 > /proc/irq/9/smp_affinity > > > > > > I will be interested to hear of your results, as I have been having > > heating problems with e1000 and other problems with tg3 based nics! > > > > Ben > > > > > > > > > > > > > > Xiaoliang (David) Wei Graduate Student in CS@Caltech > > > http://www.cs.caltech.edu/~weixl > > > ==================================================== > > > > > > > > > -- > > Ben Greear > > President of Candela Technologies Inc http://www.candelatech.com > > ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear > > > > > > > > > > > From mbp@samba.org Tue Oct 8 03:23:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 03:23:45 -0700 (PDT) Received: from toey (CPE-203-51-31-169.nsw.bigpond.net.au [203.51.31.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98ANctG015747 for ; Tue, 8 Oct 2002 03:23:39 -0700 Received: by toey (Postfix, from userid 2013) id C7E8B8BA66; Tue, 8 Oct 2002 20:21:38 +1000 (EST) Date: Tue, 8 Oct 2002 20:21:38 +1000 From: Martin Pool To: James Morris Cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Message-ID: <20021008102137.GA10627@toey.sourcefrog.net> References: <20021005075157.GC2531@samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B X-archive-position: 581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mbp@samba.org Precedence: bulk X-list: netdev On 5 Oct 2002, James Morris wrote: > > I can't reproduce it locally, but I can reproduce it going to a 2.4.18 > > machine across a 100Mbps switched network. A tcpdump (complete?) is > > attached. > > Thanks for the extra info. OK, let me know if there's anything else you need. At a stretch I could install 2.2 on a non-VM machine. -- Martin Discontent Provider From jmorris@intercode.com.au Tue Oct 8 03:28:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 03:29:00 -0700 (PDT) Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98ASutG016126 for ; Tue, 8 Oct 2002 03:28:57 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id UAA08866; Tue, 8 Oct 2002 20:28:49 +1000 Date: Tue, 8 Oct 2002 20:28:49 +1000 (EST) From: James Morris To: Martin Pool cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case In-Reply-To: <20021008102137.GA10627@toey.sourcefrog.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 582 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 Tue, 8 Oct 2002, Martin Pool wrote: > OK, let me know if there's anything else you need. At a stretch I > could install 2.2 on a non-VM machine. Thanks, but I can at least partially reproduce the problem with a specific network configuration. At this stage, I'd say the patch supplied is probably fine, but I'm taking some time to make sure I really understand what's happening. - James -- James Morris From emann@mrv.com Tue Oct 8 08:21:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 08:22:01 -0700 (PDT) Received: from apollo.nbase.co.il (apollo.nbase.co.il [194.90.137.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98FLstG022928 for ; Tue, 8 Oct 2002 08:21:55 -0700 Received: from mrv.com ([194.90.139.18]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with ESMTP id AAA248; Tue, 8 Oct 2002 17:23:05 +0200 Message-ID: <3DA2F8F7.905@mrv.com> Date: Tue, 08 Oct 2002 17:25:43 +0200 From: Eran Mann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, Eran Mann Subject: e100 driver oopses on non-cache-coherent archs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: emann@mrv.com Precedence: bulk X-list: netdev The e100 driver in recent 2.4.20pre kernels contains several instances of pci_alloc_consistent and pci_free_consistent called with some _lock_bh() taken, which causes an oops in non cache-coherent systems (currently PPC 8XX/4XX and ARM cpus apparently). In a discussion on linux-kernel a couple of months ago the bottom line seemed to be that calling pci_free_consistent is forbidden in interrupt context, while calling pci_alloc_consistent SHOULD be ok in interrupt context (this is actually documented in Documentation/dma-mapping.txt), but is broken on non coherent CPUs The thread starts here: http://www.van-dijk.net/linuxkernel/200203/1644.html.gz In contrast with the e100 module, the eepro100 module seems to work fine. A sample of decoded oops, occurring on the insmod of e100.o on a Walnut (ppc405) board follows. The kernel is linuxppc_2_4_devel which already has 2.4.20-pre9 merged in: ksymoops 2.4.4 on i686 2.4.20-pre9. Options used -v vmlinux (specified) -k /tmp/k (specified) -L (specified) -o /tmp/lib/modules/2.4.20-pre9/ (specified) -m System.map (specified) Warning (read_ksyms): no kernel symbols in ksyms, is /tmp/k a valid ksyms file? No modules in ksyms, skipping objects kernel BUG at cachemap.c:127! Oops: Exception in kernel mode, sig: 4 NIP: C00105DC XER: 00000000 LR: C00105DC SP: C1B13D70 REGS: c1b13cc0 TRAP: 0700 Using defaults from ksymoops -t elf32-i386 -a i386 MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c1b12000[90] 'insmod' Last syscall: 128 last math 00000000 last altivec 00000000 GPR00: C00105DC C1B13D70 C1B12000 0000001E 00001030 00000001 00000020 C0180000 GPR08: 00000000 00000000 0000001F C1B13C90 82042882 1001F9E0 00000000 00000000 GPR16: 00000000 00000000 00000001 00000000 00009032 01B13F40 C1B13EA8 C02D17C0 GPR24: 00000001 C0180000 00004FC9 C02D1880 C0190000 C02D1880 C1E22960 C301F000 Call backtrace: C00105DC C000BFB8 C300F9FC C300D7FC C300DB50 C300B270 C300B158 C300A384 C00A4508 C00A459C C300A6C4 C001663C C000477C 1004F6A0 10003954 10004B04 10004DB4 0FED5DBC 00000000 Kernel panic: Aiee, killing interrupt handler! Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; c00105dc <===== Trace; c00105dc Trace; c000bfb8 Trace; c300f9fc e100_free_non_tx_cmd Trace; c300d7fc e100_exec_non_cu_cmd Trace; c300db50 e100_load_microcode Trace; c300b270 e100_hw_init Trace; c300b158 e100_init Trace; c300a384 e100_found1 Trace; c00a4508 Trace; c00a459c Trace; c300a6c4 e100_init_module Trace; c001663c Trace; c000477c Trace; 1004f6a0 Before first symbol Trace; 10003954 Before first symbol Trace; 10004b04 Before first symbol Trace; 10004db4 Before first symbol The BUGging code is in arch/ppc/mm/cachemap.c (ARM code is similar): ... /* This function will allocate the requested contiguous pages and * map them into the kernel's vmalloc() space. This is done so we * get unique mapping for these pages, outside of the kernel's 1:1 * virtual:physical mapping. This is necessary so we can cover large * portions of the kernel with single large page TLB entries, and * still get unique uncached pages for consistent DMA. */ void *consistent_alloc(int gfp, size_t size, dma_addr_t *dma_handle) { int order, err, i; unsigned long page, va, flags; phys_addr_t pa; struct vm_struct *area; void *ret; if (in_interrupt()) ----> BUG(); /* Only allocate page size areas. */ size = PAGE_ALIGN(size); order = get_order(size); .... -- Eran Mann Senior Software Engineer MRV International Tel: 972-4-9936297 Fax: 972-4-9890430 www.mrv.com From haveblue@us.ibm.com Tue Oct 8 09:32:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 09:32:14 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98GW7tG005390 for ; Tue, 8 Oct 2002 09:32:09 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98GW1VL017718; Tue, 8 Oct 2002 12:32:01 -0400 Received: from nighthawk.sr71.net (sig-9-65-36-150.mts.ibm.com [9.65.36.150]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98GVwbJ166032; Tue, 8 Oct 2002 12:31:59 -0400 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g98GVuc13856; Tue, 8 Oct 2002 09:31:56 -0700 Message-ID: <3DA3087B.5080704@us.ibm.com> Date: Tue, 08 Oct 2002 09:31:55 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Attempt to release TCP socket errors in 2.5.41 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev I've been running a certain large webserver benchmark on an 8-way Profusion-based PIII Xeon. I'm using Apache2. These errors have cropped up pretty recently, definitely since 2.5.34: Attempt to release TCP socket in state 1 f1e3f440 -- Dave Hansen haveblue@us.ibm.com From linux-netdev@gmane.org Tue Oct 8 10:43:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 10:44:10 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98HhrtG009002 for ; Tue, 8 Oct 2002 10:43:56 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17yyNA-00027m-00 for ; Tue, 08 Oct 2002 19:42:20 +0200 To: netdev@oss.sgi.com X-Injected-Via-Gmane: http://gmane.org/ Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17yyMS-00024E-00 for ; Tue, 08 Oct 2002 19:41:36 +0200 Path: not-for-mail From: Jason Lunz Subject: Re: How can we bound one CPU to one Gigabit NIC? Date: Tue, 8 Oct 2002 17:41:36 +0000 (UTC) Organization: PBR Streetgang Lines: 8 Message-ID: References: <010001c26e9c$2319c480$f5f2010a@weixl> NNTP-Posting-Host: dsl-65-188-226-101.telocity.com X-Trace: main.gmane.org 1034098896 25158 65.188.226.101 (8 Oct 2002 17:41:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2002 17:41:36 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev hadi@cyberus.ca said: > Can you repeat these tests with NAPI and no binding and see if you get > any reordering? Wouldn't he need a NAPIfied SysKonnect driver? I wasn't aware anyone had converted it yet. Or is it enough for him to check the blog_dev path? Jason From greearb@candelatech.com Tue Oct 8 11:44:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 11:44:51 -0700 (PDT) Received: from grok.yi.org (IDENT:qyu9DRthKL1xWtkC78+uACr6kzNhUOfY@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98IietG010311 for ; Tue, 8 Oct 2002 11:44:42 -0700 Received: from candelatech.com (IDENT:evTzt9FzU25Nn1cgKbtzFql7vShAy5rf@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g98IiVq02230; Tue, 8 Oct 2002 11:44:31 -0700 Message-ID: <3DA3278E.9000800@candelatech.com> Date: Tue, 08 Oct 2002 11:44:30 -0700 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: "Feldman, Scott" CC: linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) References: <288F9BF66CD9D5118DF400508B68C44604758AF7@orsmsx113.jf.intel.com> Content-Type: multipart/mixed; boundary="------------060904060906010300070406" X-archive-position: 586 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. --------------060904060906010300070406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Feldman, Scott wrote: >>I believe I have figured out why the e1000 crashed my machine >>after .5 - 1 hours: The NIC was over-heating. I measured >>one of the NICs after the machine crashed with an external >>(cheap) temp probe. It registered right at 50 degrees C, and >>this was about 15-30 seconds after it crashed. > > > Ben, please send lspci -x on the hot nic. Here is the lspci information, both -x and -vv. This is with two of the e1000 single-port NICS side-by-side. I have also strapped a P-IV CPU fan on top of the two cards to blow some air over them....running tests now to see if that actually helps anything. If it does, I'll be sure to send you a picture :) Thanks, Ben > > -scott > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear --------------060904060906010300070406 Content-Type: text/plain; name="lspci.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspci.txt" 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11) 00: 22 10 0c 70 06 00 30 22 11 00 00 06 00 40 00 00 10: 08 00 00 f8 08 00 20 f6 91 10 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge 00: 22 10 0d 70 07 00 20 02 00 00 04 06 00 40 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 44 f1 01 20 22 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 04 00 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 05) 00: 22 10 40 74 0f 00 20 02 05 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 04) 00: 22 10 41 74 05 00 00 02 04 8a 01 01 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 f0 00 00 00 00 00 00 00 00 00 00 22 10 41 74 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03) 00: 22 10 43 74 00 00 80 02 03 00 80 06 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 43 74 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:08.0 Ethernet controller: Intel Corp.: Unknown device 100f (rev 01) 00: 86 80 0f 10 17 00 30 02 01 00 00 02 10 40 00 00 10: 04 00 00 f4 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 10 00 00 00 00 00 00 00 00 00 00 86 80 01 10 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 ff 00 00:09.0 Ethernet controller: Intel Corp.: Unknown device 100f (rev 01) 00: 86 80 0f 10 17 00 30 02 01 00 00 02 10 40 00 00 10: 04 00 02 f4 00 00 00 00 00 00 00 00 00 00 00 00 20: 41 10 00 00 00 00 00 00 00 00 00 00 86 80 01 10 30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 ff 00 00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 05) 00: 22 10 48 74 17 00 20 22 05 00 04 06 00 63 01 00 10: 00 00 00 00 00 00 00 00 00 02 02 a8 20 20 00 22 20: 10 f4 f0 f5 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 0c 00 02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev 07) 00: 22 10 49 74 17 00 80 82 07 10 03 0c 00 40 00 00 10: 00 00 10 f4 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 49 74 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 04 00 50 02:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00: 02 10 52 47 87 00 90 02 27 00 00 03 10 42 00 00 10: 00 00 00 f5 01 20 00 00 00 10 10 f4 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 08 80 30: 00 00 00 00 5c 00 00 00 00 00 00 00 ff 00 08 00 02:08.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) 00: b7 10 05 98 17 00 10 02 78 00 00 02 10 50 00 00 10: 01 24 00 00 00 20 10 f4 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 62 24 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 0a 0a 02:09.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) 00: b7 10 05 98 17 00 10 02 78 00 00 02 10 50 00 00 10: 81 24 00 00 00 24 10 f4 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 10 62 24 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 05) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev 07) (prog-if 10 [OHCI]) Subsystem: Advanced Micro Devices [AMD] AMD-768 [Opus] USB Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [5c] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:08.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) Subsystem: Tyan Computer: Unknown device 2462 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 02:09.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) Subsystem: Tyan Computer: Unknown device 2462 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- --------------060904060906010300070406-- From davem@redhat.com Tue Oct 8 12:47:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 12:47:38 -0700 (PDT) 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 g98JlXtG012084 for ; Tue, 8 Oct 2002 12:47:34 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id MAA11426; Tue, 8 Oct 2002 12:40:03 -0700 Date: Tue, 08 Oct 2002 12:40:02 -0700 (PDT) Message-Id: <20021008.124002.06553598.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: "David S. Miller" In-Reply-To: <20021008.093721.11469009.yoshfuji@linux-ipv6.org> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> <20021007.115530.00078126.davem@redhat.com> <20021008.093721.11469009.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: 587 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 / 吉藤英明 Date: Tue, 08 Oct 2002 09:37:21 +0900 (JST) So,... What kind of patches do you prefer, now? - on top of plain kernel (2.4.19, 2.4.20, 2.4.21-preXX, or whatever) - plain kernel + on top of our whole patch? - ??? If you send patches against 2.4.20-pre9, it would be fine. From miriam@wmcomputadores.com Tue Oct 8 14:05:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 14:05:13 -0700 (PDT) Received: from dns3.telecom.com.co (col3.telecom.com.co [200.21.230.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g98L50tG023817 for ; Tue, 8 Oct 2002 14:05:01 -0700 Received: from gerencia by dns3.telecom.com.co (8.9.3/1.1.2.6/27Apr00-0721PM) id PAA0000002690; Tue, 8 Oct 2002 15:14:59 -0500 (GMT-0500) Date: Tue, 8 Oct 2002 15:14:59 -0500 (GMT-0500) Message-Id: <200210082014.PAA0000002690@dns3.telecom.com.co> From: Miriam Mendoza Subject: CONFIRMACION CAMBIOS FECHA HOTEL PARQUE FUNDIDORA MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------49OP8AW5QHG4B7" X-archive-position: 588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miriam@wmcomputadores.com Precedence: bulk X-list: netdev ------------49OP8AW5QHG4B7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. --Boundary_(ID_25oPtZ7K7KZf4NBGPw5Mgw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dns3.telecom.cop ------------49OP8AW5QHG4B7 Content-Type: application/x-msdownload; name="setupce.exe.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="setupce.exe.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABxdTv8NRRV rzUUVa81FFWvTghZrzEUVa+2CFuvNxRVr90LX68gFFWv3QtRrzcUVa9XC0av PhRVrzUUVK+OFFWv3QterzoUVa+NElOvNBRVr1JpY2g1FFWvAAAAAAAAAABQ RQAATAEDAF1Flz0AAAAAAAAAAOAADwELAQYAAMAAAAAQAAAAQAYAQA0HAABQ BgAAEAcAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAgBwAABAAAAAAA AAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAGQQBwBkAQAA ABAHAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAGAAAQAAAAAAAAAAQA AAAAAAAAAAAAAAAAAIAAAOAAAAAAAAAAAADAAAAAUAYAAMAAAAAEAAAAAAAA AAAAAAAAAABAAADgLnJzcmMAAAAAEAAAABAHAAACAAAAxAAAAAAAAAAAAAAA AAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAHICQKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAhDAkCCWJRunWUCFtVMeoGADu9AAAAoAEAJgwAWJ95uv+LRCQID7dI DFEECggDSLm9df8C/zSNKDBBAAoGA0AEUQ+FEN23f7doqAT/dCQk/xWcEQmD xCTDRAR/+//bi0xIVlcz/yvIg/8CdA5mixACNAFmO9Z3//+//Q9yEkdAQBUI cuUzwF9ew2oBWOv4g8j/6/NVi+z/b7f2i00IUzZfdRoDQQ4D8L/oAwAAi8ax t2//M9KL32o89/MJZolRDg33918Sr5Xd7hiL8CcMAwVFGB4iv8813Yv3JAz2 IxkWH0EK7Ha6IUIKA19XH7plZGQUCPdePgi3299+i1UMtHUSadJtAYQDwg4O a7v97dvSHgdmA0EGA/B0W2oCXx9RAjvutul+wivHdBoDEg6DsnQJCO1/++0F ah/YD2oe6/nmZjkBD5TAg8AcK95e+P/eO8NzHWaD+gx1C2b/EMdBAlzrBUIv 3N7ucwJmK1QG66wKcQYXW13Dv7XdDQ+B7AB7M8lCfQiIgOiJK/yFC2GKFGY7 TQyIlAV2ALfC73ZyAhxAPSRy3Tm1VzL/73fsyYqCJpwVH42yDALYAstCD7b5 3X+/34qfDYH6L42/C4geouqKBge+a5b/csiAJegMAEOJ6ZCBycP+Bejc32/r HFM5DQeKkSCpFekLz+/33BIF6ZhEjYAFiJlbxXbv/YgQisICgQpZKMCKHrfx NfzOg+wM3mh+ajnsHsvlcnvGRfQcA/US9ib3NPjdXS6X3fmx+sP78nHGoo3j G9+9JGoIUAoBiYtdCGIUD74zNrv/739GXzv3diPHRfxH/038igQfiEULJQIL LvbftjIHixCIBDlHO/5y58p3ma3ZaHKjrFAGqGv/f7MFpGoWmVn3+YvyweYD /7ZQNBBAGGf/+FiLPcy7ADVBplPhZbIh29chVBY4+MbMbZEoY+CSAlaLMcf7 7e/5O/CJdfSJffp97HMFiwzp324XNhRyYVX8DPgpn0ZTjUGldmu0BAp2EDPb MB/87dulAiUD8g3oE9+LNAPWE/uDZbvbNi7/iRA3BN74SnXVi0W3W/t/i0Xw W4k8gQP+iTl014sB2Ysywvbt/zvGV3Iqdy2L2MHgRDQIizxIwh2m33j7chcr ygV3FkuTBIXbdhOBG6en24s4EHPtbgd4PcDu9spkuRRvA/AAwV33t+WJTfRz TPCD/gFyUbNTsVet0QxjsPhbR2u0u7V/+4sMASv5Dewb2gPPEV3jeE3wrX93 uwUUddgN9F8+W3YRjQSxg3funfs4AHUJTokRd/KJMbt2UYsR7m9ohVOYIi/T ch9WjXEEanv3/9uNWqcGjTxHiT6DxgTB6B//b/h17F72/jaseZkD+ls6q/wA hdJ2IvBfuhncLpGLojeL3tHrA138l9zbv80fiR+D7wRIrfx16eJwAXZgC9/a B4MjgwFKiRFD/EKt0PjHRZCLALn/kWkVF248bg8Ix53SeAQa86vbBecKh9IV G3UMkIfthdvNM9uDxwSd92Vhw4PSM2/71v4Hi9ri6olf8zyD+wGDegAtZoXm bjMDyEt4EqzWxrqayAjJVW4C8Gult1vsDFt0ZTldWr0E/Kv0/9vuiZ0ABYvz dnI1jXoEjUb/UI2FAPjfGz/exTf/dRD/BOhqEI2VE43v1t29jSwTAzlGkTuf ds6t7Rve/ss5H3IOjUelIABBijsPdvWLRGu/cLr8MLUVjUgB86WYlrZrWiYE U1VW4YvWPv4O/79RroXAdQ0hQwTHAwoqfvpXI5xnwa2qx4UolWvfZngJKXS9 CUFcRLOT3QZfRX4apgRqKbkl7GAc6+IOKn0R+8DuLqV/ieveIfPrz64sOJ45 DKs0hVsaG/4LTHUhg34EAnMbbYvOk+vvGw1v+wFCiTj6Fnbzyos0PLsHu7q5 i8pm+AXZshc79LcVCcvwIszMBiOWFV1zbos2dxAZLe3nOfj92GNCdwmDQAB0 bYSdCHQs2C3pTrVQBvzFBVJlrgFbxxQO6corgRzYsgYr+JhwkIUh9OuC1RBA mGDy2NZYwoXQJhS2VrfLQbbmUeiaBMaoDA7Z2yfB7gILCIm1vAaY24J1zXFh UDcmGDovZ2AWGAUbk7pBiVlOG9tTZmq6XWdUCASLCFcM9AaBrsRWMgURPQ74 vpuDUnfsCI1ftOAVBvt9bfdSUAP3Uwk7Gw4BPQQ+BnOttVr3dhkBEwQtOlds UCFdQDMxLMthYxNRFPjw/Gona40DjhfwMVFrc21blDNJMSIfrSBW5na5duyJ FqDrdYDzXK2E2wKbAw3mS7qzm2sReg5DAg/8CgRDZ5pdRgInjxAGeBVKuMLC cvjakSU2sG1kCm8MXyvBxaK1t3QQDAgNgA4dfzPkb2EdD6/Bi8glNgDF4Bvt wekQJ/F/AUBdpdst0Go1yLeL6hwBWwIXWGgYK070jUL3b7+99c+D4cH5BnWF i0gO6wkKB3UR7tsPNf5bweEJA+oH6xAQdPvldwNQDmbB6QfiCTPKR0NIHA9N Aj9wNHK862ibOTl462+YdmqLx4PgEwxFBOpYgdj2Cxc9FAyyBpMj3fdmARF5 DxZNDE3isLO/EC0HjTQliy0B30oYTlaLlvrlM8FmMcbYW4kGhWlylr4+VUax W9nEztQJfAnWUAyHlbvNCEK/CG1Qi9cRuYZkspEM0Q8QFLJl20I7UDxb9tKF x5FVGVkEv5CNMLfCQo31MbhNCIkNby0UuvQOXx3/CC4IPYTvodl2DXzxFfjD Hj0fiwuF93YkVr42/KJ0CDrHOvimtFmDJgBHCjsicuM1eLbvXoMlCAAG+F8Z 96mLjxgZVnM/IQgktEA7+33/Q8AZ8FmF9ll0JhhWGa5WGH1vvGa4oTJPDP8F CIlGsPhKXnZeVUTU3X7qEAAZhHYCX778GVaZrbXPwT7ATgIXXoB0ZrskFAAJ VBwUdobdzUGLHWBkaGwzOf/TtNlsJVEb/x0DNeBZ6Dc4CpcAV//WVyXcJtc+ 01xCuhQWJbatUXoZCccE/CHUKCNfZyjQUmgU3LYCmx7EPJIr7KfOAdpSe9dk GYld9FYDkv8EBZbuxpK0kXYtau/Hra230EJ58cqfJR97a/GNysMD0+OL0CYz 2EcsS0vfDjulctP3wycHQxd9TrbuxgWM+AMGjY7rGVu6xbsziB0YKQjBAaIc 4f722hAbYDlV+A+GUopdNtow8aoCIgIXiiw29tcCDR/SwDJKKlcZ/xH69kI7 MogGcs9p/IA8BiAPg+kH26FdoSt1CUzR87ctg/B+AVfM2Nvs1xQwxKgjXlOt wh9qqNBq4m5N2gPKXqj0UrEBiBTHo3L1U8woCxHqqGUiMN0xbkp2el//Nhtc u3K3fbF0VTjwRNJ2EoQKCly/1Ur1Pzh3A0p17veTZtvaGjvEcxt9Ofz4x5cM QevpoX+JFMXw3wzFLv5eeub5+DKjFndF/5mnG/loArcFi3K04t0edexGrePr BAhQKLzQTTaC+v51XCZlmrDY7OY/SLPQYsEzaqsRs9wP2u5w//FXx11bufh3 Onj7BeE5Ufh3MwT8ci4AOdHSWzUgBPxzGpeN1rrBtjNVh1i3eAjdB/uxb/wM iVgESgx17YvGpusGg8EIqW6H79okVUo71nK1Lml2TciGazbCyL/Vx1wXDP/N 7Hf8WVlGOzdzHa/gBjwMw+7qDXTxdFBoWCGQnuVgLUz7xwj4vh9+4+zYizXX gX34YOqKIGggyMKkVB6KYM3aXUS5Rg4aUCj02g+/ig1MdBIBdC9WIiNdOJfb eBIFdBHVtBbp7Qt2Ill9BQUCfwWvIZN4S89wxtG4DqZ4dwOGrC3yBr6Ud1mN fbhuwGuUw5oeM6WksrW73w/piE3oqwBmq6oRDtXdVmLI1PHuVwBQc+fmbgJo kD2OUBC8ApZtN9Z0rqoQVOn8nM5dLmG2VP9ojC3MurYzE70QUEnonPBSwzP3 IQm9xBxxPZ0DXGjwRD3oqjhqGibeoWs4Dr8u1FxDDusG6wpQa8Y7RzwYwjAX l7dyw1EboXBNFoZFGiDJ5MjN3Srw5EMG9ND4vOTWMHL8sOAXgAbkAYWWOXLo AuwDYwZs7gkb3TdjUFZgufRlasMXeBCKEEML/60ZL4cEfN2tTfPB5gL/dDXw QvcOIpWNRAgBsgweiPDROotE+B3UjIc3CxE4RmD/NdyJzhdEmgsxrP744AxF crMReKyUDevtG3FUM/ZqRP6sVlAAAW4z1SX9JRJEyDX3YezvMRBh8FAqDtfN 2uwATDYuYVghme9gOihULJUMAQsFsx/06rqHDzde+H4QXf5ZO8ecBbgajQU2 blsMUQP8UQg//25kc7QABUAyjVFUsL050ggQqIWa9gXYfQ0gbU3bz2+UdAdR hXIFBoO2RoTz2vQZiyFZUQL395hFvoyG/4XBGSOwa1b9DGkfBmfBvnD0AXUZ NytQdmtwwE50I1C0Wf8OHQZrBAlFEGjhhNn3CBTuX++FV3hLwhcE/fY7FHbk YdhPNP5kEhrCZe0dv82kgmxigXDsDVcmtHRSqvPhJLwdp1Ch9FBQwVGSTf0E Niy3kRCeI/1Xsd4ZpJvfwgAADBkvsp0jp2wUgJtdOiGOAR51URnc5hdLLgCL 5n2wJnvwJr7qfSodXKX//s3iEo4lct8ywIqwAev4mR6XY45gB4oVFHcbsLZ/ RrmIVbgClFiVCzLXtwGBGoCIlUQYFGYzF/a9RQ5ZI1i65zfYaj8WWRel+6QF 8yCbkcMqbWwz2+0jnYVgtBZTiF3/ArJsLpb9/iQC5OjawH/C4O9qBGoHv+A3 7dQ3btE+fDm4Vx4PZxU+vsw2khz5F8SUVsm47/lDxhKABmoGaLCFrfYMhWAV z2DhR9uwWKluXFkPC84ivdhoqC6xSRmh3+qlHqhqWyVP/9QNTwHHFni33QXa ENABw2ajGkocs7XNdhbe8FXZCebHcB9nDQBXcglzZoF+t7XdpTwq//lNNCwI U1BmiZ0ous1PZwYmx4UkFwAPIqRzg2VUQOgoOM6+Ce82bUg+NDcyB8cnbWMA wb6KfhxloPtpQ109kGzXaKTbVsAOm02uOwxYT1Y280DErkF/QF4LgWw6llA+ IUizzXUNgIQ0W+ju0zwlwPxmPYDDEy7IPxupvqVWpVnrQWY7w702T+91DhlN jOsMm5kbWMyzFH1wCRqkmYHzMTRWBOkOwwu7hoZhyOZaLDyjh6oXDK4QfSGX NQWK+SaMdb0ZG6iRG7wMNruYEgQQ9BJ6FTAgu979HlA3NAPSDIISPZh0bG63 hA1TomhANSSI/5RbwpKEBS34dBpoKKENamNN1g43AWKyzWZq0GkmgGgYMe16 8l8r9HRdaARo7KCj1OTTFXoQsQ7U4InNPeQ7vB2wOR0oDyuba5vQdBsMJgcT H65SqfZ0C1hLeIf0bKlGSTjk9zc4j2CFgaWFDQQhjBCQUOtQjd0/loQF4Pg7 +3VtaLSHas50I9tnUxN8Vwl49hGawGBBsGdwn9vVb4lZowCOQcWtA3YsdHOJ rw5Qdfia+BHFJku8IH7QgMPruodwaKxLV/yoBy04aU46CqT4oNxsZmtlDpRi Sgj41swyskHcOIIH8D81wDATjaXB6QqD4QFR2cS3u5C/mDy+VEFW5bsug53V gU06R1AUWZ5srgO5/tVMXBIztlksmhTFUNPEaCsGi6l9FR3S4VgU7L5ngIlv YRJPdARkkp0TmyGecyIVXXkdbBOavSQQN+WNNLdhI4ig+ETWPmys+4RFzDho b8wl6AnmSfOy9z4qOLT9PGZzvYy/OmaxG/77dL7MrIkmqCqL/Br2Znc7pQBQ pSwAeUWoaJwpYW12Wq0pFyZoCHUtdmFTPIyPhtodaPVTMhKLrc1md5jJBMXQ uv6Bw844mq25WBkhcsRTnnDdy13fhHIBgb3IERMJGDfotu9TBThddErJN2DD T1X09oU9sgJZp1mITG8t3pwFG8Qo/nQUfrDWhu2NoPrvHhX/70eWOlnmaDt1 4HR5WxNoE7YDT9w9KhEPltD0Ez1ZhPdbbT+p8y3EJlD42ATWNbKFS0JybWsc CnahBhD+AaSiAQP2P4//nOxuL1SKdvAPiYF2ChQ5TFm0aE0364aeS0B4+/YE dEwe5EZ2Q539dT7y96+H96hQDXNBmX0NoeIvp9mOQTuwdg8f/ah2e7bGRpXG VOTkS+gUZ7WEZzsRihLo6HZa1Nx3XRqzi4XMDBlTlWPxKQUQAHSAAMQvNhOe A/h2ahRuK/Wz0hwQWDnkbYge7ZGpFRKiVqaBlh6W3Db/BsSDcv+S4FvgdGlq JGN0Wok7i0b+bdluL0MYBQwcCxCNewSNddzT5jZUmvilAAkUJG5skCMtClY8 cASXOluFpxecGjvGGFBooYn1gCW86I1VIfAQANBV/wuX3vxIEHw7jXgBjXSF gKnNZqhXYjqUPQIl/9tW7hoh0H1xTgQrx4sRiVH8Sv8W/YPBBEh19ZeD7gRP S3XO2YPWtoWjXn3A6OkFN/wYEBkfgX3ERQl1FmhUm0WJcM6WejRbZTP+Xph9 feH2YGYwPgr//aG8olAhSzxT+43WAE1WS3N0M4oAhFO1+797LYrIEgyEyXQW i9Yr0IoICQw4++3tbyV1B0CAPAJq7oA4sQyKTgFGGK434nZ11URew2kMgCZq XUMDmqQDgI4uFBDtjDgLX/wItaACS00HlKhH+1FH+we8K2AKoaBQ8h7LaDgV l321DSyd1zAPjZ7shzwsdHpoJAtuaCBJnuRJW2gcT2gY5Eme5ENoFDdoECto DJ7kSZ4faAgTaAQHoZg1P3/voesToZQGDKGQBaGcX1sAeYTrHwEWGFzIAzPl CAH4XPJc9lgP6FTUXPJc8lDETLSX8FzySKREVZRyIZc8QIR0AzIgA2hYTCAD MiBANDIgAzIoHBB1qRsDBNLrDk7rCqDUSy2E60MC6wIabrtelcDfvhCD+bmA LMv25itiSHQ2AiwiGO+G/7IOBIvR6y+6jDCEKLqQBufn5+chupQaupgTupwM uqD9f3PmBbqkUjmD+At3W/8khQwxQAB+/v5anhxPuIQGSLiAQbh8fn5+fjq4 eDO4dCy4cCW4bH5+fn4euGgXuGQQuGAJuFy6Qol+AovBdxwEFvqBwnkUB40S UFJJHMA1Is2lsabptvYkXcOCh48Dlp2apmmapKuyucDHx1imac7V9hBYpd9y t1a4kAf2O8hXf3cA2LTF7YPAnAl/QyyBRyIp6b8VWn9JgwIOSUl1d7vIUl0y yWQfIhq7vAm0sNke20yc635Az3QVPQv7+fu7ObuMFWi7eAZhu2Rau1gq/e32 51MjXnRGJ3Q7AjGD6WB0JS+8uo13EQIHu9imu0RSPz8/P7s4UrsoUrsQUrsE UogFPz+7+FG76FG7xALNXCCsEOh78PeoA/Lz8CAdsxLCDeiqsFPlaIRXlJNR FzCiJAocZAJHxA1koC44g9CWqyg0ZMnt5gBAIbjAoaMMsRAJDDX0X+/Ae4GS PVA5F1ly1ZA9sN3bcP3D4PVTix30fYtHCICl5DYa5taeAAbc/cfCfDa3ZVtw AnYJVgwL63HL03zbJwQRDEh1aA5fFHIh54JAwTxSVFO/f5sNDBAL00h4FoC8 BQxcjbn9QrGMB6zGAS/r5zLc/ddVG6RMZabyEFdsDnBPDAcIIl4QbtQrDmsZ v+sIi1085gQMi1cUpoXSaGJHgX+JVeyLTxiF7MiDf4eyu11ldRsVdReS3PVp s+f7sCSVEOspFv3wszbIAXuOKuRSIBMUwVxhe8IfUavBg88M9kdUZmfPNmh4 WmIaaNw3WdtKYGcOWTYrVwrJYYM9ImM11G0URwQQAtWk7A4IDgHZhTPKW1ch xDNJxPyKd250DOB0CBwQVyDkEOMYBQM0HIVJOUnqpBv0YxDgRBcO5gJn+wdu ItT7270fNDVDaMgoYSE4TvvNDGakWR/A11AL/WZM2MDgc1tqBgpbcpse/AhY OwLQmVuVEEPwGJrBDhksPAAMMOsoPRvG4MjN5t4rrdfNoEm0BsYNYsf6v2wC KhpqB0lbdAq5+Fc+JpOfdT/YufAJmGoIuegLWwwJueBnoNslB7jYW90DaqFh TfzwpvncRjBSNBM+W399gxzAul0V/MHoCr7Rt66LCNgDTdQ7wrcXS3YHF2B7 5xQITTvKswwGP4DDuZXY/gIPvlUXUlAFwxvZjPe3qzaywFeLWUCNjRO/23mB vbm4V4i5rJXrDTbY4HQJmBoBwFErfVAQnOBTUUEoA8nDWBj/98xGI4w3qRp5 BcLZSRhZDlnLb1jJsyr4ViosDWj0DGWcjFZYpwA7NbHDupT2CHJTcDkIPxpg OWoK92xWtbBl59c0MZCzSU2sU2UzUA18A+QUthhL2LQwtX2L+OcDiP5s5ehu NZ8DvQRBZszTPdPRVmHUDVNMY19QgmquzBdMU+5vVrUeUDPbyq8DnTm2R7kR HEMV1UxjQMid7Yj4AL8FXQP4QQSbweAG2VyuJgWA4jeBZXNtmE5MmRX87rgU mGtNfiRsjbBAfjGo+55DGRA3XIHGS/W98BXbEHXrE9eFjndny5WKMEb8Ljld /AG/W8B9ZRGNmCwrTSW46zbo9gD1iw72AxC9Pk20xEssnCwkqH4lCMoLuz1q UPG9jPluS8Fb8H0NkqUGjbWf3dz2Ewz7FluBw4D0da3721y5i91FXgUSSTvL esoYhbF8gxO6hzGjREoV9hSMRDbhaNhV4je7ygbyHHxV1yqWzW1VRtirAvwU ANsjFz8OAY1YLAX4jd3h9pngMUPosa32QxhzG3KGU7DEMupTUQfDep6v6ATg 5uL2aIPssACqKOJ1gmkz7Jcq/IpYcaJkoUtCq+Z7DPN6vtuFZPgwKSY9Hs5T U1CDPEj+iP9z9JBUMAANDiSLQ3nEUkBo4NXX/taLGYw18GvXfaXDGl38LVUY A5BXCGcYU4q8U6fkQJYp+FbrfUOr3QVUHeJZaPN7xG+hVAiHegEJgFa8MVlq ytG8c/h1EoG7wYhtlMjrI2iq2JJ50nI7wy9CJGPGzBz0bJhakT3AJXouqA5k o69H8gfg4IqugXzQ+oVTXIo3e7G4Qx0ZjPchnA25ZFMRUFqLpFvS3CKJIO4w 29oz9oZkUOCVbeteOoO0oxz4FHQXgBQYeLt2Fi8DDRZ1yhL1UN2wPzKwuFvP QRoIuboA/qB2tmEhITP/G1eZDEK5YMevVuV+AWZOIPgOD4fsNVxzW3bQQj5X SCBDJASXbHYbQy40EKRCqEI4yeaAPDwURBhE8A3Id5xDoBCdFNdsdh3xfA3o OOw4bhvzPM1m3D7gPmA3N2bTPV9SjEtLN0SQP9NsNs2UPzYIRQxFKPM0zWbQ OtQ6GuzwaOaa3QwNGEccBPc0Tbd9iFk97GoDe4yd0zRN0668ytjmpmmWTfQC PhAeLA3iOULETANX2BTqFxrm4dBeagRQo3qW2kAo/zfn0B6v/ReXRtQAp2h+ ZgSAFhPLsg2pGOMX4H9ApTraIIsPEuG8ViOWEU3KcIizY/W+BQB04FMpEs1t IxaDCMXpNTS7aEtB29WYWUCAJI9JHa0ruJGPfDQpGFBIMGMGZhYoGWI2+IkT 11MVT3hf8B9OxnCblWiILZ3kLpA8ZAWbESVocKtv5eIcT7bwfcLrGSrTPN1z +AoQCAkHC9vXBTQem16unaUfcdgrBdqvlPCR4tdLBVloBc1wHLChP0sS2wzW ipQFwxcv3H7sjAaA+i90BQRcdVEhAEgb2ee/uTkryI2EBVFTO/37trpwM8lH fhn0DREvKOJGLl4HV4ZcQdBKt1oBfPdD/ifJ8mxlVwuOKCg9JaEXBc49X3Tf TgLOVg1ZwgxM9rouMyMhy2S09Ha0fQPB+VgrxwN0/7cxb+bIDlZGaFg+Hsa+ 7J3NIT+D6wk5iv1/7NsVxfOUBjxBfA88Rn8LisjA4S+k2b726RCITRJhZjB8 s65A/wo8OX8GwOAEfEHGOnTnVpoMCDdBCA9ma2/GnmEINAkFLDAIM4tbtLOn x1KMihEz7O7DhrOIoEcpO/gnjNgOmmIDRxqNHMM5hyQciaW8/QvOo9lDfe3w P+Qbi7DSyRhQonQb0S0tkYQ3JPorHLbQtUZjOW13KI0ZwIPmIvwVUbJHNig8 TewCdBM3WmyIQCo7L6yOfjTGhyRoVKvo/XVvo70RtPvydSeLUL74ZjOHLa07 JDMiuzI7DiS1YjSbZqOWjGMKYFm9M3BSRyB6Q4PGBlZkOZm5dAASQCz3EJ1i W3ZoRHwy7a4aTiOMEfQAu5kZUyn2WhMP4F4KkHjPjHRTV69XXzTlRg1rB9g6 PBhZO2Y6ZzgUvA1qXDNNMcbTnfxmRB5A7ylgT9oMe3NZ+VlAegl5tPx0DJwb G9LWWA9RVRNawYAZNyozuwi2lIk94VBDRJJ4ne2/6vabc0tf8RPBPNHgK/iL x77dXugrfbh8B/YJ6CuHiX3YA1p8d7fAO8ejdgWLBo3SgsEstOvA6PC0almU hUPsHMfouUmPkVZNAHQ3gW7WXEQ2JjMwJpajtwd+HzscfgOLIqVcOgrYalA3 KXXJmmeJC7zoUzmQyVe2yVZD/FcGM2yxQAwxY1gMV/GSxZ5ZWR4bVFuJySGo 7PMU6DeBDiYfWbc/+aIxiMXGgATBCWEYqGf+VtAabW+RGP/TBBxeBofC8a8F 8I1EBhZ5jYvSmeJ0Fmi3DfgfBuIgkYNq/vlzn0rANo4dvWgBJHF9hS3gPFUB ngo2UaXtWbJ1BStbeOCwgtby6MUGZhCdEa+71zBKvK3CXfPqI7ewBjgLvSqN IAwxavBC3cv/VkRxi5VohtYL0k+BLzAPMVghJCf4uw9mM/0X5vzkiQY1L9sN sYlGBAUUCI1GDNtvr+34Hh149DAV/3YMFBAY3LUIDQoHoSCOcuyjW/8qiwg7 TRB0fYAMOe2SBhsSNo8SXuvYJr7E44cE4JlWaEUs7tRAhHIBae+HogW5TTN0 wnKEHEpCO2ucWe4X36/FbgSJB3IpZ4k9C//kjiy8tzXj/GgIEnQh9Cxa+Mab oIjQJTqZ0n+Ib3xG8CNzAf5tv/xZCAy5AKLMWQ8YKZjQZJrwrjCANimUF7Vj QyhYKsATvnkAlrmsHjbsKHcYJWwZE4mu0xfPxgv5cpBVu/HQHUA9zLuKfpta Y7vPeBBnWb0w2XRfFGgUXjMEXBijK3QQ7AQEEc7QAtNVnOtv0Nq46VjtzpXg VmoyfFX291jlKitmgT1UAiB0eBfLXrAsTHMkbLRYQf+fOJpVUoRnlwU3aFJt AftA5LJa+HE3YnnByTakABncOyzVsB/8fihxVgABFraseEkkrnphW0ZTRVaj fdBwN2Y/3WgyhCqQpwtCchBSrBg05BlCzBtVuL+Kn4k1cBot3I/ta1RoWR1s BSpVLGcRyEAlq/gll2+v5TPdR2efz0kO23SOdY52js885CF0jnWOG28ErEtW JBAdDF1bgSTgFZ3EY+c6ge/hBAo9mQC9U06D8WFZJ1cOfmRaaxgNhBqLDa8q 9NCxbPpsubDhEJjQmpk6T/5eIgLvqkI5FVV2OqGObS/+/IoEEKQCAsQyBbq3 +/ymig3SyBmLDSUfiE4+jt2QQjs5csZeV1cKL0LQlGUZw+HIttcHLolTEFfh YhjQ42hCMW8EQ6ROcNpXNBBMsV0xgyXzxwgDaqVT1y38//g2vge0AwUhWVRw jAXfs9kD1BmsUKEfViJyFuEDyFH6NAF2RMvqWF4dZA+3HqBViJr4kf/zf8GI 2xQPt04EgKQFDMj3gQcIUSH+BHQ9dxIYLFcoDgAVmwWLSRkRkHzLYhoPIf6p MCTkHFoVAY442WBenQikgS3zpeAF2X10dDeAPRjgwH3gLricEoVcTFSLWAQy 6okQHUzEt+d9OxIbwPfY4Djjx94DuBgHYccMuKhIf9yFaA+J62o/LU4imk3E TfmsTPnzYi7STaoV+gUTYneRwyv4BYNN8BmYgN0l4sSqVn9SzZ50Ty4yTPo2 kwv5vbjQI2AU5uXWr0YyXmnVwEYQzQKTUx3cU/FgvP09g+gy6Oh1Gd3HBCQg EzuWI+RGbu93ZuiwhFPZQlMWvdO5AhIO1D22bxJ4flbWb1Av3KULdENsPJWu CibJTtaCHGdtVDUxkFb2ulktWRuJaS1aUOs8U1Lb7mBB7XY1i4lO74oCi3TS SV/AbSp5GazNFjRO6OsCj3BFLXo7YIRu8vkwAmQ9eoBBAtY1VMliV1N0/8WS rQSMKcLQgD3ybVTgdS0TTi60pLvmdRQP+caKCNGFSmxADKGz6wYgntF1jwRp 0OpmoTiJZ+HvncwCBjAwklm6l87MXkjIhux17W1UeB1oudSq5CHH3Ac9hPto u2RXXvJWz+Q283QSYb8cjhdIxAazAB4WWmMUdGYbI5sb9wY7+4LkPUIQUDOg 1GJmTpwRZ+LMDAbpEBRXehvwJKcrxj81EWwz8j3bjAwyA/ArJVvO4FA48MO3 kiuZ7Cy5BZw57BE84QYWpYgDIScAjAZf5EKukgY7eA6EnADmBbkF5o5kSnSV IxuQTegMbPCgQcgVyAxFsGdgyRgAlKY28mxkaNai8gT6UHTvJRhqWXZwESlk BmSwl3RcE2BIaLNAT2pAPQhwAWiE+oxq6ANQfFbkMt6Exw37UJDuFrDZ6xwd 9wS3EIYML3YtgQTyCBcEO4qPYDsIH6j7Wq9g+xCs2DvfFJNG/UQ8UiIVhBBZ 93R6sxNN05i3HKNBD/JCZ0GYWS+1SkBJuHDA/1hkZGSzk7WwrztXEq7lhUXo oSzGrmgDKk7WZie0rcVTqySHcXRFHPj/Ag2iArj5MItV5IoMEJP9l+KA+Q0s +Qp1GopMEP4NDF6gtv+AfBD/LnUFxkQGf5ToctMSyCkST8cC3BJ80EmAJedX OTt2ZA6H2I83O3V7AyWlbNvGDDiQQVpgjm8ogkHyANUBq+SF9YW6pAEBIIO5 gCOkIAQsFsgw/levYln41IhYyFYN1f5XLH4vubsBg+syQcxT4ixOFm1XIuBW U97xBU0GVgG02QEdQs60pDKO0UAONg+ciZOmYtKQfH0UgEjF2aWlFqV/AaeS zXqu//6OW/1ZO13og3YUaYtN5CvYV1PqEWylgJRRYLQEGED8V89XFZAy2Oto N4oxd+R0Cc7sWb3/dD91EIoIgaF4xk38/1rUb0dngCCrf2Lh0RTsIv5kiRoA ugkgCNL1xgYB39cFsR7lNTmjyaGNNHysKAE7xnQHHrAMo2i9FKlosUsoBfOL /gajJF5dw2QgBL6pS7WaekSVg4l9/HUN28zW2QtYG+mzCAjValZm4BVYfcFd Uk7JFgIgagNXiBRuUokenZ1to2rT++jsI6VXQIt01bjMDkdXivZ0FlAA1xcQ GUZd29HJ/DvB1g+w8VtUqH1K71EARKwMZ7YuOqvwTUeA7GDuf1OGjU7/hckP hisPrnUSw7u2M923FUNJIxEsiV4auCNAAqE0HZ0XW9gI9jvOCkUkv59bIXg2 6ZSFkABM6pShKhA8N0VB9/v/fxs8CnQXPCB8BDx+fg+NR//GBeseoxhKwIHd Ng4Bs3JeEutFf6kocSFzSYA8Hw3dAhe49nUlCB8BDx4GArYbweYNdRcDCtVP BDXqs223cNkUNoA4FBYpZHuDdWQCG6ManOsTfL/mkaFjKwUXPffutg10c3o9 IHZzJSQTAHVq7mHFJQoCVsijHBSQwgELDQcRjKLXTG+hPOhjMd8F95a9IAZE gzsFXnMd+1JvqzwYCtQYdQb/HIoWVbv/KwlIiBQOQUDr2kVLHLHRRSgnP+Y6 0UdwlPrBNbLIg2UFkTUzXCgRxFsfBmAHjYobbeaHV9pWeyRZK/tTMkQ2BLZl 0QW1+Fe15jUt4F/qIUNx/HMPgH//H1GvW1NsNCKGAwrkvvkwJTNbceDPIpYz QKXxXEAX1cK//1H+O8JzKI29Iyv4OXWKG+aDDVp9qAiaEKBAt/90C/9F+IgM B0AncuCm2xbAaTbgrQmft4l6q54ACKv4WkCT7mW/mW1qUb0LXBtsH8jOffGu IhtSD1nrUhEve2AO60QNWJoe7BPW5TZYUj7rzUaf6xjy+9DLF1k2FHMJVFLO xsM4wh5x6xehDkt5ALAdDokdt9YIDA/1rgbGCg+CeD/wpazcNh2aKjv5FNX8 QrQVWWBTeQjPNVe0puptAewEYM2AdN0F9igDP01v4w/SNHmbUVMz2zgdQmQF CeBVjDWEz3DRacAyXCQX/rTK0OM1kq8QDCbZbgj7WSREV4m190lHBbi9MFyc F9z9l0TVDYPFBIH9TBh85euVZtBdVSQTAew1UjVkt2IBT/QBENhgnCwLX/JZ 0iHgUvReixUKaIvIC/wBUNtZCzvIN401vfCFeCzPdQNJEY15Bckrt38rvWAK AUbKHiGAeAJydRsFA2/2S+XLdRUEbXUPIXUJiFgBTOQWKXZSWJKRgmL/+vAp LosNVLE1KEUMiYkECwWG0I2QpxQhXdbAc9ED/R4kOlAhDphpcoDBOwSAk2yH mWsZrt0s+MmQHGBDhCxshRoyhNVGBCRDdpGIigTJRXLJiByM1iWTDByMOIEx Gn+/HYM9BTF2E/BiNrfibAZbY05pWcNvnKIrQly0DhBoVGCPcYpldTlBaEwN sBCzODNX1IcB+AVwA7dYdgw4AUDwrXYBq3L0gEF8QwdXWwSXEaB1/uvtkC2A WtNW0hF9bbVvOXZEi0xqWApTB5ahBW5QMEIbLT1oCzV++3ww/w1QSMYEMDyo JWK/2Wx2BAJyAz4EDQUKg8AGQuhECwXnvNbgLL0eHFHCQllQfOAj39DvPJWS VU2Ol8MAVQBmhNkUrmIJivSerTUtYdpm4gjvj0BzNX2c8JCJ5qj9AnXqRYli jp2jcjFgN/1cZT3Y8Q6PaCNmVLN4PvTHDl88vh//dvygURk57GAFuAd2BAgI j8hBMExHYSOO8IPGFDu7cslzWbG9gkVnWcM9yLbEs+taV9b87MC+A2R5O8Oz nhRsMWtCy+aiTDqbiwOLgt38KNZAPCua/PehzxBgpfiLdq9vz6B3iB11QutM bnY5VpVoP2LcGFAzjb65yGGDCAYQBEbZI99GSEPXHc5eV0YcgkW63FrbydvQ hx5OV3QzEYsdkPwC38N6AZ7TpviB9xebEGzRQT73Lgq0Vjiaj5fq60GjAmNw QrNhE/EChuLe8QvgDcPTmzKZan+Cb3VdYorIcFz/+oEDgMJEsOHCPWbzdgl4 MBBMmAS3JvoIa1Fpn1AIbsB0QdTSAnY41r3IRuSkDnjbAriB+IrXRkDcDfCX rfolVt9t+N7J6cd8BbKuaKNOVX7bXuUPwMdk/KyJhAzbqqVJ7zZmSnndnpNv e/6Lx6qZqxz7wyrDsK1gR/TaoAXtGvZNMHYVLrtt396tDCvI2QEy04jH/w91 8/xWgeGwgfYs3MMinDCplEjWGK7gGQiLCvVDH4sE1/kywDgF1ttcg+B1O0YH DTDos43EgqrsOxsOMYIPpWh1ExHfVKoGwYnmVzAeqGLP1npS9lZC6vcX7/be FUYGk6p1GDNU+JRO2ySCne0tmC72RpbJIoBK/AgRzEZG7ip4B7qiJQ6co0k7 G0GqUEtXCI95HnIilDoAle/IdlgKDR4I8Gwj2/YVg3w3AZDwBwjxZ3sj4oYy yVho6Pap3+0Qi1QiiA0LiRU9OA3SlufPNmUH6l04BexV7Z+FZ3lN7kV77z05 WZ5lOwc2+C78jSa49yY5rosU+w5Ciwmd0pYGouCMFftmw7cqCF7pfAeA5OjJ IxkZGdkF6uvs7RcZGRnu7/DfZGRsoSv0Bfj8I471WIoNoQR+dARl2147m3EQ GxQ5CCGRkwk5DCQM5Gxsey4LFAUYLRyR7U0mMBQzIN2ZkLMkJygxFSyRkS0g NigsGJixsTAFMRE0QDwfGmxjU4/xATGQ+qKe5AFiVohqi1bAFp3LcD+gjiP7 v4e/C1ZlgzHTEs8w7SP67dtFBH5/QEB/cu6NcwF5WwaCCd2pmlfbNaEhvr2L 80FQW1+iGU4+QHQMgvcRlTYsNATAVrLaChZQqJUrnHRgPVa5FY1DAQP8Tn0H K0Yg634aanz2b6LFYphzIEULRjvzcyWfJbYWwT5JnT5wdd0tAaFAE3Ls657G 26uXuB8BdopkEP8pIVJwVpRdiVsKFiVpCHzrP0FcGAVTbGsEuAZeE24XaJLV 2ITZBqBTYaEt3LWgLoAkOFF9ZV36FfBSKmhoZStgZc1ixRCINUYFs5gzuVJM HIUOQgvxPZhWuAbxt5F7ElBloxR0Hzs52aJAL9gwMTFa0MEANl8Ds31nuFke GiUiAAYxBvXstVFGV2oDmB8ChcoBHfS4FBCGJphUA9zbphghGgV9pMM+YhMc cUuGrhHwB4FhgQFIgBKYpb5Ae518Of1AK1QF2DUUz0wHO32DA3IClEN+8FY+ 1MNmQA5oAqfs7zcgA8sSkLMy2wUo5N6NtThlP44Nbn/3Ooq8W/wIQoP6BXLy u7MBHNlZw7cBDogOSEaT2WVQSTCYzYiqEmJ0wPZU0/afprjSre5GHTwWUDXr K4oXsIWC34QVKEJJMPGPuMjKJwyNR/6JDNlbseFEYwK6+HLV47ASw4q41BAG xUhYpQ0+ITC9bLdeBhkxDl8wgI5kQ0g7XXzWVW2C3IKKLiwrCcUyWAtLgkDf jReNjRxRezCI0Apo4TwcOQF4WKVZ8wFXVvilggTsc1lybj3+5U0dbR53Z+jA 2hQxgPo2gvLlToD6SUE7yA//BDBVQEiFkBMIPr78W2D/A1wgmBFfgf6jYmmh enzg6wcQCTBfNougVOh22JBOlsFCjgRkXa2SZ0JPSltzgb3XvkxckBNHkVRj Xaw934uEj/iIBG6SBQz/GFvggmeLSo+/xxS+/KXZbFjJD3/K/RQFe3gRXDkd XOO178hFrXZWu2iSCT753rDZAf8zD74LjQEL5jhBG8AQHBsomiBaJ8MEE57g nqUnXK+BLMAD0N7CMAbwDRsuZ67wCjBz9iRh/81VvWM1gT0Fgyu0hCbAdgcX +XIJPSPvXFbwXB2mYBXLcxTBWMVJfD0+Q4ZgYUhZVtjGliCCACPQINwgw0A9 N1q9xX4FuHR44cqNHAYJZhCfUehFVXPqDJ6EYlZqXAdVaaENLJgzJ49LY1iw ARYyIy8+izmHALIVr1m7fB2zapifA1I4Vj0bDErycAsHu3AAzg3pIIfaRrBE nJ3/CzeuWVkxZAQccGIQODaiWXYTzfYRcI0hxmBkagduRpb0tPRWSFdskEGe k0U4gnqSIbnkcfT0IGQCufD0Sgbk5PTw9JJDDuTa7/QJOSo58PRKYFmwZxCl bOtlL2TwdTQSX6EiHGe97CMQYRwOAGmAhcLLalm/2qdDLDACLcef9JxawZyE yA4QAdrLVoqWh1AC9PiXywkt8FHw/gP0ABjLPTf+/gDoBVHw5NLJKkg79yiG y8R+f3YBWxkr2IqMPQiNhAaFwttb2Ct8OgR6fzUtKm5A5pDsDez8A20h4FYd QHWr9AeN4la0Ll/KA8OuFWNNFd21IgIF2FDgwLsFajlZ9kPE216DqAh3WLQC clAE0MJV8AR3S6xTTwq2AdJHn1JZvnIhB4F08vD+DYFJNzm8W2UG/gUm4KIE dvfW1RtAXSs57XYnVsQ/vNA2CBaB5v8MthQRM9bwgVIbKosdozPCYAV/K+0l DHLbXvfQ/H0HbiGA0EAc0nYjU1fy+926NTwxYoHjQTP7PTy9rKD9MsfKcuFf WzzvEAyGEJoZGb1sZT4YX2MS/LZH62AsbCo1B3xgWhpRrLfHw+XW08BP8QWo WTP2g1T/N8XGyfa6pTkCdApGg8IUO/Fyarbvg/T0XzrDJExWe/e31iswKVd2 G4sVSA+LOjt86ggSzVgvBPAkiidaoBVMrhG9EfiyeFmjSNBQGR3Z6N3TdSeh JLtQBIVJtjdS9jUlMehzwGCzWXpwRAoxxr62wTGKCBiBayu3PR8YsiBEw6aj FN6HvbE/oy2RdCahEwd0tgZTHXhM+GMx7L2GF412UdIRJtyhOAtVoLt1FYdW nZ5XnNRqWHhvHY7FkGZDy1xlOC/ixtPz/HSYi8OhFfi5BeF4X4hVC4cUJ1pN 413cG0+IU5OcDGnMO4rVl7H6wzS1iAbIDjgyTQuLXWnLwVcGPSVDagAHyWKE +DOeXjmkSbTpg9UgtwYbyPZX/tYjAZOOegwOcfVWQPCoYcb41CNim7Ym59I0 vPti+EvKDz2oHwYAv1aEWcL2QDWdX6E2VgBIKxARClYKDP3KFxWa3qQCFs9/ 7aClC/w2U4ocOfO1JcutC/+FAXNghNt0XIvBOJlfzw7/HAg1Dw9dgGX/hxuF qNwldh7HK0D+7d866QPWilQaATIniBQ+Rkh15/fVQtFPF/HqoSFDvI6IIqMI XalMBcsIW0OiQCUm2wjwEmYEi0g8chSQhYUN/FZ6Vz9yK+RpDl1TUyGYcLb8 JjY/DjvhwK3zER0BYUIRHQVBFtoANlMdVQBOZU2JZJ/gLLizGjlXRimKYit1 B3+A8bWH4sm0/1sNiixcCwGJVfhzIzveA+hQs28sA+viUOES374DOC/DS7ki cgKL3iqzgWYfNbAQgAELnW09A8UmKxaAKYCnOG4MFkPaBFXrTjRSRCunrNSK kB0Ig1QymwiOVOkQdMvGK/NtsYxvNQPYVlPAn3VwEhR7wkn064JB8UxCnKAX TASfeGDaJI+jOPeo8gU2RAQVh74baBC5VKM8lTG/jdFr22wfWPOrB1lComZk i/ELW1S4bbtB4WqmiRgECAL+LgSVDJMUPTp86FPg0TKCVLvRkY9ao8MkWXUF srHtO6+S7E04UzyT/Sb5XnmfWT3VM+2q4fdJdnYdvmSLBssGqiHijhiJHkXn LaD3+UY66CZUNb6h2brt1pciiV4ENgYeDQh7VSXoCO8yCvdZulu3XhA+FFTQ U92HRraw78v0FmeBA1wAQN9rYGSHTyVXUBfCYSXbHEAMRcSgLgBkCKRhJHw4 mAtPV1lYhMJkrVVM9D9cLc+1BNn82v5qyK3ke5z+WvxeUAIseXQXlMiCZ5xo OQyIOhgXC3IBLHqrfciCXik/fEgeULanhGVbFBskbGzyCX5/7Oe+mGXI86Wz agykiEWUr32VgoSw0axpqowRYAMU+3J+V84ElwJaI2/I22Z0BCjlwt1dlBfA gQHaL9HcTblFcYDw0rIFyFib1GSUOw6YCpLwbskYTnWpQ4aO3Blyng++wL18 Q5CR7mShZqWjvL2AvUuuXYU+plxI916EBSupvLxkqc6Fo/b0OBWN4AyFEM9U 8AomPhAG5BmQnCZoFZABlnwAZuuISdSCotN3XMBEpk+bnFRggVggBq9NyQFQ MyqxlcFMwBDLXmwZ6hMigm8XMJbuMsBHgGQw/xgD3n4XaaNZDWjcBTS6tgtq xD2FxmYyOHCCGFsEWvfQD4gsyxxscFuACwMY016WQfnRHoxf586IlUD52rmH EypakFv57JGkF5CkJAbZ7IDsQftA+3+ws8hmFfcF+jD5YjG3DrUTgroUM1w9 agd4pW7Y6UpCN/w1DINE0WgV0VbJizLbJbUutB44d8teFGgQag3z9eUG9ZVe aPkEvjhokg6KW+AwaMzIawQZewJoJBK0YYAdxJLfC2cN0zzpIt4LiwVzExPJ aGigaCQ7XruMBdCdsR30ur9NOjMRKg5X4dIladZ2UBDxLv3IM9lsCSm0/XE2 u2w1ZjILT37PJcK/R1DDh340gFVTRekf+aO23YE2c46jC9E699mV+SYRjMJN q2J2eAVn5IPNTqAaH7Q0FCx2sg2bHvRSiPsTFEcAWDxtrVmSoHtKGv7ADb7J 79RotxBh8Ob5S550w0AL+me1gjVyD3okWbcy6bNgjXwcz2gQaNyWNRQkqg7m 3YjP9pMYFOAuL7haekSzhbHRe9RlN6QsGGabsPK3IRhYn/cWBbvhNFlUVqWj a3ckQZFgvKLUoF8N9ux1GQ9O0ZwAKeI5kNDs4MFo6RM0ytwCBBkvYhsky94c 3GgCPQl6XdB1W/U1ReyIUWokCU2GBxLUw/aZaAgDz6A5hFNE9lN7BGhm6zcz CwVp/Z8coQ9AsgtMa2pT9JIB+W3pR3LjaPhn+aulZHm+8GdW3F9AmC3ZSw7Z GDQAw7sAz8KCScNhy/wsWJID+zdo5Iz+h1vBJAdgWb+BXnfAVqOqIIx0/3Qh z2HJRroMLRxYF3EemdRx9+kOIJNX7gIvyGUmkgP7vnPfdUa3tEhZcw9ovD0S MH7uMahBraRnjDZWidkQOMJdHgMyIM90lHRohjWIuYAYb+wJkkvOzkBQFVB0 7KwBYL7eViA0QLbBN5kEukBBZgwwbCkKwNQLZIf8Jlg1uGasCdklK9mcJjGA hGYhk2wrNWBYkw17hxIHlyEkoAF7ZX4cZqps4QSTj2oM2HcUpZJpRiSzZOKX Jdh5AF+p5PZGDBBZrgJwieqH4Lj6jqBRvAoQYj2m/5d4EhOL0FnB6hIj0YqS nIcu2doGafQQDwz1rBB1eQYjwY4UbW9x9oqAGvbR93RjFgF2W4JqBIQ9A/c9 YgRfi8h1GA2AtMZkK9fC9K6JIAtvQBIUfBJ3aFzcIthZrlZfVxNtLwj0kQVF uE+hIVA3rXGLVlkmK8kBQlsUZayPRlIChy5SYU1ZuyN8IgwomgMqcgrjqQGz 2J1dDmMwdjxCvpgnX1Bh+2TkSJ5g+7GwW0I+L2H6YPoV9+LCziIF+TD5s9g2 yl8i/zcFTCUHFmVhYOINyJFhhVJkQAbIaGBgQiaSAWBg5EKO5GBgYBmQI5lg YGAWD5ABYHRZZIRkCjlg+2AMiyRbN7A1W4yYONhyIDZfmZBBNnXkYGCfyZMj YGD7YPmzJ+QlYPlfO8cyIF+8FzYcNmAuOZFcYGD6sM0rOULQnwRXQHIBIGAB yHPJYL5Wk5yQzcd6o2D7vxcygDxXcWIWqYwlADYykZxMYGBgCjmAXFfpAoTk hJy2AqcC+QayeESody/IYSaSA/pHyGWxBEFWNw0WFYSg7ETYDWOJIWmIDWoO qoKcshAIaS9W0k0bEgAKNOSQZwnQaKzilOyWwzykaHBoww6LS4dWLmwUIV2S cAvFF0ALiZDFVprBMsgTh4vrwkMIkTRTBAgIwpJTyQh5TlQ+oCRWv4HsGPFW 5ABhDE38UJmgr0IdomiTQ5xFtKcA9KfPILiE475EQR3opRQnBEU+a+ijGEBd u1CAOFhEnWmlxD+k3vZsEbVi4GReKU4+BX1oQGnaJBIIEb1XiEQYdQjesWPE gL0PdCgx+zYSyd3ei6KJAY2NF0tESeBRh6MLfK/oZD0ywOnWHDtycpSoUOSl 1yIZkAvk5BmSI2Tk5OQoGUIO5OSl7ZP+VovxaNjHeqiEgziYyIe1cA2eDyho cCPWoHl7fxgfX2z9ehWvYKCZQ17DqfgT3UqDPgBZfFeLNnVwwxxxDFarIG0q VF2oIyAAHIwZ4QAfczC6qC/gBF/8UAHwsCBGDCTIzLc1qCOufRU+jRZ0z8Kx W8cIKGqzxzScDFFnhoBfBtZhmDXZBnZvhKg1XREO2P4ArvAVdbQAfg++YTjh lg0o0W4UXjxKckhXemEICAJLYF9qAw90KhoUAA8haF5tEAZRpB11mRC/gCDp ApRjUoxAhX8bCh59HLC8BRiLhfgAzAh3BcHoEMNggk2gBXTY4Dtdc+4fXdmN tAUEE3UEYsNVb6qOS3yMozv3D4P92dkzvTowVjED8DPJi6H0/wvExgqKKIpI AWaD+Q91brFseKCtHoomit9GF/AQrKK72kZQVthLQYGGfBSDKTi7Xahm+2Y5 J3MXKVBUqxYMdxc7IcuFd3ADdfjpFn4bEGDDK8kQHau4JJAzBCkaH31ws2Aw dCD85Ill8Mw2w9cc7LGiIcXsF1A7nhVofa/BN4sEBIxbIkYEQglyy3iN+g4n Go1PRvS4Q49Ac+1MFvWivrwIY0H9e/poxYNmBAA4uarcYZlRGgGGKmCvRZ1p Eath7kgLfMtOTbSKRIc8NB4N7NuA1Z/4zYhNzAfhDuAWfbBWhRCIjcz9Cl/9 sHrN/aIEv9Q3br7RkKW64AZX+8yQirpSEg7gKjo1i+IoDMdBEdkgP5CD6JuN m1AbBv30QC5DDXCPLs4oCNZLlg24CNcG7z+gFiMZNhtHGD24lsadONw3tBac 0IGiU7tUQ8FuTec7AF3hWccSABmaB56Pg/iQA9AhK7jfNhA5HXbOjbXgKUc3 n63paOitiUgGgnQxZFHX6Eh1fP1VU6TWDuzRa5wUQAGvR+YC+jZoOGpTLT2Z zgwhLKL7CkJp9vQUC/EOgijNgHPVqa66UE8QRuzRQLF0LDXzf524IyDPO8XO 0VATQ3n/gIOwlfBX51t0EiD5V8SMYIp3ksQOmwVaMsGOZVYF3FUweEf9UaFg 25qk6s4PRI9QJoBUsMRLkbBtRQXeoycZy5YU5IoEiq72BWb1LNRnQRWsKUJJ 7r650dJJjgCNSgi7sBBWO9H23vgFePNzGivKkOmNuhJ4f6mq0cGfO81dg+ED 879v3Bpfc0IHxuD4UaNBWlGagC3+X3YnMQ4xVnJ4hNa97ZOonIsOixKhIYha KEWaEAgHbYHaN9kVFw/4/XsTAPcejAEFeLCpXNHXCCUOAED/2pu7YUCCKz0Y LwWgukQdBC1AmMGLX8KbGisqFfqKcnJWvlq3tpGBjUcxIQSxQ2vbCAASKfWx DwXdbS5eJ38InEC4HLu/jVagBAuIUpE0G8m70Gqh93LKsrlAPRpDmHtpRY/j uPiFIfjv7sLNsEMD/l7InCeldTahm/14l86LDVWECHwCgfOtA2IVHaII2LYY vX8eX8PHBTQ227m8ReWo6bMcu0TbrAvCBAG8JiDWfUA1IFkAwQgJe+59L3o7 ifcFzGjvtxE1KKNgdFNtrBC4hU4MBiZXovzeHXtzFTkHdQ0sgqo5NSly665+ vxTRyV4PtpFvJf/wzfz/9oHi/381weAFM8JBg/kCcuOjmKdGHdhrRTC5VZ30 /xLl4JXAi+pYi/krxTvwD45beFlw6fXH0+BmDXQeVnBHuGYLyNg9/lc9E/H9 MT5zGYiIS9JAitWIkApA3odnjz7rTVMZQLtyO8MVL9js2bMXDW5WU8fM1mY/ JEGvKlt17Dc9sAsruRASLvBmK86jD8+7z3bT74E96xOi52YJPQN4l4DY9Yku BsOhCLnZy14/CH5rtXMgdG/Y2CObnbVmih5Wuz0yvDO+GX3g1sz2zI+uyUAo dRYp7EJxsrJe6+R+IyF6Z7NZR0ZbPUtYwVL3GkRmE3SmaI4NzOBfqBVUby8B 4JIGPSC2DHzzuMw9D/YQxEYAEYjERgglI8G88BxUsWbGqLVEjc3tbG6kYgWo C7FEfEWOO56w/GWIDRRhESPoKqYzAf70RtBEsPq+iwS9v/sm6iRyBD87BWyO f2t9L4s0tqre3YUgFos8hR1KsW/Vot4DHLlmCloPipaVqr/buKlOOpcFdwFA zX6a7tMuHFX4KpGxI3UR/Rlr5RH5LZZ2EIk0XBXvjm+L+HvR4OuNuAqTFcyC 2gyjAbydnhGhIKe++n5jmIIP6aFo6d+N3hZ665kGgTY78Y2Ysg1XG/a1O73r Tk16CiPzO2CwXBfFX6IQc4dyBMFt/ALFZ2uPnJw4/09AiHV1tn2h0rD012xC QUICQQ6QAdvaArENKQsd9tsBGREFO9Nyy4oCOgq3QvzuAUK+i8oryIHBkpaQ /9WVupv+z34XcIFyEqOnbnfpsFF9JZER/xYllNxMr1uLBEWT0hF2CekQtVDN D85utjdYQgRpQQhTHuDyZbvQBg5ZFAj0GFaLMQxQS8vkBKkIC7dcPLps5OSJ cKFwPqEJdgq5Pc8EtYNkhpi9P9YNFkA7wQ+NN6Ia9/b/Zi0/6IsIi9HB4gKJ VfCQRDICBKG6QTQviX4FGrS9K7zDO03kQRZ/Rmb/ruRboX2LNBP0fAkrBNaX FO3bDYCKsAPCNQwxD6//2tYHGojzfey0FuY+t2uFHwhOOAIfG6QfjcdmFei4 1W3oFghHwHyCZT2hQuytIZJT+sKNDGSUbRv+wjliSElJ6/aDuQPAfIh3c0CP FoOA5h8ODF0PKmL/uzt/yzvfi9N0Y40cEYcNFDsitwNC/HSXby3OaBaTQ5bt g+sEe6FstztefyXjTASGO8qm7bw5uPor+RW8+QE97b/dGdpQApSMW3XIi05K S0s716oKEXZWdaeWbbgF1V5JBNFsA2ALwZfaUtu9/w6LfAMx5tHWERCE6LWi M7Te3mDki7ADaOaL/lh8BeK9xFsNa4scfuaYfDFTbgUCGkIwelYCWquw3Q10 HCtMTdsDOwJM3xD5QVJX3wpnWQDfCm4IBlk6S3XWW7gdSkKiZD5ZEFMN3NgJ cQSLOfTSFNNW4WiF25INo74VPw6tEvEHfkMVYIEo/X5me2O30wvBQICiglpV /CeJjs1whBQf6w0rIWAp7VK1fRWDDATxfMitbIVS8QJ9UYuODAgIAzNwexE3 6wKnPFuNAAq1QIQEINZgjThaXf+CZocbFuAL/zACKfpZrLFU7FB8soyJxw9g AYB/mSvCi/DR/qN8Fn7pCsfPhi9O6++dn3sViLmNIvuEUjYYLV4LXNZaKmd7 xN6jFi/dJg2wfs/6SI0Uj4mHSKMWiQy8K9F2YRqHHLdWt6fr6sf6/YkYioar iomYwXMCisHZ3u1tsv7A+2aIgRYo8NdYaXtKAloESCBfQU6PRkQwpRWLb9ZM S1JWtJ6DBRWhEL2hKAMbimOGY6yH0Dc2iYbCy8ISvMf4VjPbJBZKV/FxAmqp BDVYTYDcpYC4iglDTe6bDcWM7YPBBkJXfqlD3BbeGk4zMTvYkjsIhL23pSAD 1zMaExS9qwdNrgpqjb0l7UEbcbmEQEvrdLoytwXWKKzuIg0VSkvRsGMUDUgT Khqf5KT7g/sKfxsbTkwDWo1L25CT7v3rGRpSUBf1CkeLbclaCtd4rcTANvUO zKixGSZ7Q+kGWOvu8Vh3ZgG3tNwEc/DdAx9hhGVEFCNXIiHY1tpQMk9fNSQP 7Qdkv2aBTJEGNyuAgp+FICTG330EX+uHDWFoIApmAQ7166gEGaIvh8C1WsxV xNYSB2/PPd33GRX0CQ1MBwjbz4WMdMtFv8ZfqXc3IF/ISnWEv4S2JzSwqGuM qBuM0g/Iwx07cdEPudAOE+HXC/3lahJYtIh8a+E8jZ8sUBvVVUgWfUn8kQqe SgPIjUxBEdncaj2i3zy4agXFEx4sho5seV//t4IJW4vLe2EUau3GCbcEHk/8 iu0Afhxi2WsonIW9/IVkKwIPc/xFO+985MSoi61PhIt4s6QLS4pWvGLeeJBK vGiYnvpQljQgOorc2RIsXYBH1eogFzPHFFp4oN32Lwe8olCCTF/9M9aCmivB EAAW3cvl7f8Bh7gMlnURVLsCjLt6uwBLlrtGj0wZhxQWlCF2YHaKjIPy6pl5 K/wKlB4G15ZER98y4Dkwr88rjiS8i65tMxZzgwIqOBG/df9RznMIioekHOuA x8HoB4o1FWjqgKQo+7a6+uwyWNfRUwMZUC4IVLhLfMgDpLpE+NBtyAXzjRh/ 6g+CLJXxkwIEAD3UMGyLAJLooWqKHAoZDl4G7QUb9hAunbmQ3bmwCQSDeG2w jZJnZCoDP0Ya2pCjBKEcRlbXIuDxjVABoTYYLdoewuHquomajl4bKVY3cLGX 3C0BAyD3t/uEAoXChZ10DAoWgwUVCDVs7wehBf0DvaH/jsL7w5B1QIXJow19 +QvHSryVV3IG62R9kkWs+T1JGKy1FAZ5kOWhw1J9kdHB+p5772SS0iyiLAbg lR4143A0BXxUeFw1DFUKGXII0Da+Ix/QJQuoGiYpRufXljUvC4Alp5/Rv+SK IGap/w91UgqL0CvdwmWADR4OsAMz+BYOC+++t4ueeIPgJUw08SfG+wPXS+8X 3kx4fONZX9HuOTWHi3P6SzT9EMHqAoHiKj+1/jvRchY9tqfeH4F0D4E9IJN0 UMDq7S4I1MNRM9M5FYJbh3Z4NhWoBUeWpii4GRUldzD1YwP3hSxplYPT4N+2 igI7oX7UyIrCineJMf7Yi+mK+42+ycMaEGYFqxJEAmNinOb+UnTzqiQcfLmI lhMhTvZI0rVvULh/UJeB5AWkJxDB/rZss7cHBx59TE4qxgdTCPtYg4hSg+kH WFag0SlkKOuvYlsrRiUSX04ZuAaUKMD6q5Pqu2+/aOADwxr0YzauE37ruORz 0rk6BhkJ9vav5HMycvqvB/JWsOo5ZG5aBk12sLoVCbcp6bn4bTPettxCT4AX 31ctRgIFheqGxhRnGgPzWUsgiPRTRFl84gaAgxtEYDVkJARtbeB44y7LW6Qg kfoLThM0VVe/f6apVaO2BAVMmPypTfAjx4HhL4stq8HhBTPABF1bDdaaRccF HGudM6MLI9d7lApNATAqR997+AT/6qOTW3RHO+BzP6Pgr154K8E9r3c0UU6z 2F9zhssdi3YGiweHFXzdjYOrdRIsBXI9BmLlNul2A6ri+yb4E1tzutjYD4ey hEJQ963OGf0rzUlQkPege6WzQVkQLDQBz3N7v6opHQ7YjgMVRmUr/Rr21yPP MtPKet+Fs4nu1+wsTc//QdydLeYDDNEsBzF1uYWYYzNDkkYxakAW6OSokvR/ 6gi+dRQBQQrJUmoAK9AGX5vtlo97lC8k68maAbbdfD90So2WcigdYE3EuXcw RBXjswvsOUgQDesIx7qcxXaBq0b/7Je9IMRvQxU5LRBzHL54CSPEExQta3Lk YyYyzQ3IGJtfApst7F10FJ0r5AHhGOQBXl93DDryjAhqIOUJ3wkS0KDIFN9J KLpksAoU+AmIFGB/9vpWilERLmQgjAjacoszEOcB21ANkmX5IzgVYIq/h5OT CugCxNeVRYkt3LsUEBTT/7pE3T+eQ0OB+0QRfB74+9c95C1QahBWB8CmUBiL TvGK9KyFlEzxu6MElgcUo8b1SBP0F65mo3Tb4PWCze6RSASDhpMMwRZzwQcQ aN2bkSNcVtQsJwEeaCJKVsREczsjAeBOwi8aR2jd7xPRNHN4aCAHi/gJCNCg mTqkCtIdH9oa5y36z33wgfDoQaIyv77QB/URBQNJzPRqICBS1k9WmMB8BdYm uPgHatletUD8juIbFGiLXZIzUVcf6CQCdpcgEf5yVYgQOCwBKtqI6ihhp2Dq /tJ0z41vBAHsFuRJkkkKYPHcAZCse7/sa+w3E5sG6mFOCWq+HMcEVrThFqOU bZvXVpvQA0Bh3Fr4NcAUdFKM5XURLnoFnlGRuYRZ2lcsDRLUIJ2EeaPlvob6 +o3U8oUFKCRCtt1I1n6yf1az+NgbuWT4vjYTsxLC21jNtcYqyDJI50zKUMb+ UtDC2sA9eyZm7lYNeLWDXgzqbgZ0g/8wdStR/927zzgQfQcpl+Pr5AaWi+vd UaEExUYGcoFEBagZQs74J1ltIOzlZABkN/ToIIM0zwIB9PjwIEOyDPjgwIIQ vYDiPpaNJQLvOXlZomY5QEb4c+QBWZqT8PRh4JcwabrwFuhKxeC9fbAlcLQ9 kF80WXMfgc2ChhyDlMdgGIipekd4kGWkYzt9dWTs+IzxooOdW3ZWcH5LaG39 cn6+WDaGsIRWClPbY2ZDFsiIwhsckBGwycJWvm6R8ZJxnW28HOMRGG2PGHQy FCnDVPV0LIYMJBBexnQcCHUVRGw0on4ZM9vZCo+UXMnyfTdjWyQXyFE6Dx6E EdaA+kODx65kpllddLLmcEa4AIibkzYobB0okvQjaYwhBxn5hdjYUFNDMiHb apf8/PwskVxZZOBrlmH2C3jrklPHW0gPlitgZUycTVmQL4Cbw5sWWfoEBmAJ d7r/QCXKUeUsCMX979gO9w0iFO6ApfwU2ju6U8CBCFEHF/d+s+prUc7v10+c X4omRwDYrCg/Q7f/bleIhVTwJbnndWhV8C4QgCBbM+BtnEie8rm/VzKFnARc VNfC2G0IWLa1cCyNHLY3Vd1eRuw0JUh0GwIRv11QXwe5ZHQbuVwGE7l31Z+f VAy5TAW5RHT/8AK4iEvUuzgIdQKLx552+BbRHIUNjtzWKGYx5Bx0/QTMjnQI uXMRI+g5IJj8REpDFoBWag9N5AkBKNWddrxOAgTgkVed4F5PELljRCKheIwR gWsulCwScAxn7ibi9aYPaGwOCwMBFAgMMeMLxP8PeAaIDkZA6/SAfv9caQZn VfD2XEZqBwV+Rl9bGrey/TeAwmGIFkZPdesZLgR0RiSq3WwDbXCAZpsSMsjz GUx8dLQAJgFNwNzO3ck0+8KioGoUXmmHRLUj/rTbBQ/4HPIvJ/Tw323w3E34 tHElE7Lc3FaCDyAG4A9gCioMK7k+UAAa4cg7fRiqZkU1CoKWZlTX3FMg3MKQ r0roF+3CqFjDVcc0G6wPqms+VyBWVTEsgLbURFvp3ExWkOH4psV/Ocmy+Qn7 CPt/wf0CESygwNUGk6reORAAK+QX8GIBrRKsi5qdzcAsdg2naSDPLhREAAL6 dIAcWT4YxsjZi1RnRCUMBJyR29OMnP0spV0BH1Et/3QtTAmCf0s/IQQVLVYN kfzc/fQAdk9o9HUGE2jsDGjki52I/gVo3HVmjHcQuCE71oBZpTVCMNbsxwaU szCRg41QjhOU2HXpZLZNIaKLjBjSzycnZwdozHjArJRm71uydf84D7eFFHMQ xmbfBXgQ/QUMEmF8k+1AdOH5HGewBrGkg/gheFiE7Hy9HM1lbGsPsNtFwNgD INXZWv3hNEtF1MHohAbQOQhvO8grxAmkQHWBCtAAxGVejgBAcewYuwBY4J09 AF4nU7mphmwAcsD9Oo9gW1i4auBqkTGCkcu7ca3C0bJsAiQXCqVkJeip1qRO CQcbMskYDFu4V6olxyKJCPs4cRIt3dD01HICAMuVkzPbAwDtD68ci+QDTSYm W4PoYkP063BsCQvwdI466xzQLDToYqTtdA5Wxt1rmX8IaLR0WwQjYRK8EZDi UqVqxg8bhb9ebpj7W6Q7GgcDAaEYBJ8Us9eBB6p44buZQ+aJA1XUMdLQh0Wg cqVEDtbZy0IAVs9cdQ0SWAXMPovL6yAMj4WoZa5XMWLBIs+TBND+DF6bnc0A xMaQIT7CHUamzIspPKGC1iu9MS4G2WBygHadFBCDYfZODRYUB5YXaXINGSvi 9GDz70/FqH7wRKggB/FBqAI+f/798kj2xAgY80OoAfRSqAT1U5Hd9lkB9lRO 2J2U/U02Vb0o3ItF2DmqJkVg/g+6Y1T7amQG4G3Twfh2B+ZSFOIqwP6cALmy z7BoSM0wAEFowEki5r4YAnATF0kQMGEEM8S/U0LBRsLJL2WyEB8ATMJ1EZNR UushmRuwDxBEkzmmMB0kLKLkZagmEE0CM5CXbJM2GalAdg9irJmP9lMQGM94 S366iPwLbYf8JAfkIIj8iPwdegt5iPx12jDD2ZsXygnXV2sIZsfjEI1HpFxi lWAgByXKnNVlQf4Je7yWcK4jwwjHC8WZXK0uFUR2O/NC2ZrrajmRAo8gCMKz keWSX/ARVpCOLPbuWmVBiJw1DmpBXGw106RBSitD6DDXAkYYnte2Xm9raEYv BQ2BIlrLPj8IQxQS6xErjOhhURsA91j3MIoOU9o7w1zawkVAdVwEUGBEbSMV 5KMTAI8o2OahY9FTlKsp8SYIKaoNRpAIQ4/TnYa3qpZt4bAL+Ap6y2KMdswR AH5VQ9wuO/spaPYtSsdTK8Yu0kH8maQImjv3fNxFh509IlMjVyQSOZjZTo4m c22UWSvA5xlcjSvBvVzqYfIxs5B6i7I3gqMBcAUVG8tOiF47NBpYWRfBkgwY WS6bUJyiA3oRoSVEMIfQQTWEdwW8/K6CFxv2pECEIgsHEwkhaAGJiE1Egvh6 N/wr3FaBgbjgjIZkirEobVHTLeHMFO2bUxBXRHPxOvy6FUaZbBZB+InaALZz zJwWNhxH67YniJsoSH6QXlYbH8UsfyrUt5C02dtcrQNTAEcfMvjKApdYJlo+ Gz1E/FOKXQtiMwc78WBAHYUItQWKGGgLiFb7aXR4oeguSQyIGB5H69tEGd4g HwW4wCA+Q/Kz813olQETOfx3IFFHOPyqLcTyOSE3FCz/3f7c/jlhnxON/Yz9 Psn3IZ8T8sj3GfkY+X4X8jlJ+0j7+CnI+C5kZELp6FnBBfmig1heyrUhz9lu +LgSeyHPrRZZufl4efgUQp4T8vj6+fqofC9k5KkICfrXaLqQ74Vp+a2YmdLw Rp7IP16PUv2CU0AsBXVnSQaLe33pSTzkJJ/ySPJI80nz0tUJ+cj1yfU0H2pB xl7J9iT2GkM1sr1gVff3XCh9ckjU1bmnYSjzQD5Humr+av6J/No22YHjOJFF kByNbEmAkl/09HPI54WLSfVI9QegUB2qxu+FSsmivRypVB+gSfKTFL96yfoi VTdXGQ2sN4Fn+GKKCywDLDslZCDsXLchgEfsVgBQAyhEDCBEvFbRVg1NgXYY kgmBE7jw1FZAcAZR9fAaMLFs4Ay6a9qkeaCBQVbbptRmkQeaZaikU3wqWfc7 34IMx8iSnvWe8wxAkltvGblUNbVeR/DPGKxJODoywYP7J59wCAY0uYx1VM1m bQpnJPVry4wa1/CAUFvRhl0zUJ8brv0NaPi/qExC4wYC6wuCw70VpkC4OwAa 2DSBIHFq9I6ts9RJWBI6iI7inVsQ04j8BgTAraNPBQR+fusdC7gRIEdNctxA 2xdhstRh3FgLUT5Rih8+qpvkyoJ0QzguGFPJATkBLP8Cm0oO2F9XMNz+Ay5m U8gBjP1TDCp52KOaXcj3TCUHbAUuGPkGsKnkgEj7B4wGZCo7+F0I6MkBu0oJ 6lj6q2wgUwqMTCUHhAumuPkMsKnkgHj4DbsG7CoZ+A4uqJIBuUoPCKtkwK4Q 6mhOQwaEEaaYKYrKhgpX8HaRipoTURgSMjgBatIK1B6rx5eZ2oqM+BcUC7Ld QKpEhyF2DRF7yx7bHVn+Px0QyCF52R3I98j3yV5IDhj5EFnkQA7JSPtI+/iO ZMCO+Dvo6HLIHkuYlVj6DuTIBlkYuMgO5MizuHg75MgO5Hj4d/gO5MgOqB2o CMgO5EgIaJU5Eg7kaJgNmJAPTiwsZPZJ4i059xk4wNTXSlEBNo8jShPQ12wJ Bf+qoFkEANcukyIKcBscv6R7pmogmFYaVDxGHZn4ngVZaFBzUSEcABElFpka 2fuVbLQY5W5IQBsNRy57KggRJDrXWnruYDB1oAmcEd/JXpJvlAzrH0kAs8Mg YFatDFM6A3JJNuwMW3ISr411bOUSVhIHdVqQAFySMFFbkL4dIibxC5K42WKm lVSoOzp9J4zsxPdZP15yCQmSBDnzJA/IRt/YA0cncFOdOiXXIsKS7moVNjCK PofwubEcUIwcRwNdyMOwqavodSSXPWCmp5JZJ+TwyAE/fGighgEgtJxyswh2 CxJEXbBsSOBOnhyM2TJmI0YPSWaotpYYa2hzEHMTFhtlNKJ/lmB7SC7gOmpE FBivqWEleSoOjYG5JyLexwUVOQgISUSMjSNQAFEiZBfyslQgURXMXEIkKoIb 3IBbyZBoGF8VLFhRFguaQijh5VnrBZj5WRgH9hXCUdjGnPpZJzYphFzU4ycw zpBc0FeJFsbBtEgW2I4qVZg+JTqQNC3BdCQxIGH4giNGpD+my3Tl1pBcEDVV ABIrCQ+KuPF5/z53H1gKaMh2WX4+QDTCD4dswk/EwVO/QlfgngYYscJ+uYiU MJSDV3+TKrQsW5HtK+h9VhmF7/OFQ2EED9U6XDSY5EAO4LpcCHVyQop4+P35 2hoxGZcIkGVWSRPAjFjQAQLgIWKCNxAHIHbwPZUrONkmaSMMBnvAuxREoo21 IWGAGhJdSw6BHAkZLtB39M4TTZkAQ0LQgg5YUTF/SVQtUSgTgDw3LtAkBfB1 AUNWOe0hgBNGxEP+fTaseC+7tQwdKchlZxNLDVMn/nCm2QsLOgynfsQZcA6N QA64TChiEgDh7FoWAEdzTeir7pYBpgGw/Aq+/8aFDdUMcr2cYZhqrAkQmI8G QkqgEmOzFxVO/LhFxbfs6YtHDLl0fya6QVC+2zQGUzjjPR9SqNyUSnJUvAEL iw40bBHwWyg8BgB1yRUCquOLEIknbN4RBsfZg+6pYnn4Vz580Y2YqjAH9lkO keLn3FmUJTZ+yAUDoDCw9jm/aB6xhAHJwdeH0xE/ij9ZvwFnkW0ZBZsV/SL2 oHAFFBpIBmSDGf395JIIuGM8/SZbZjjgFUksNhpCVcITeYNidinHdhsaMu9d xivrHki8nwsZLNJlHwy3+kjNJlGT97jUxIHcIMIOpCx4s2h2qDwaWcpxBgXF XyoCHjshUvYlEHRUCMzWldMILhwkAr1gyXpeG2tLCHTJ/PyfHNkOEy++s1Vj wEBGs9SaDVlHxbRUDvQOME8kwY2YnJ2HpIwYHEAG+yJMeBMUkAEZZGQMUMlB BmQEPPx3yIAMcij0FOHLXjLsdA2wRt9ZX+cmiwZX1LAcDsCAAEXE5kTIIcuA MkC8vUDJuHu/lJ2+UHhz3jLcCEW2+nY2DUjzEOm8/UgYmDAsRvwm6V1z4XDd 79bs/nT37LBnQj5AeOw4EwM7MBkUFxNLECx7YOp8p6E1SAWKBi0VWsN8VNvs yXk237L2GDoaCw0Yd4HDGSCBbBeKwRhS4tpqjhCEjJTwmffeVNGiKZkD0GnS 9jCDD9pS21xWM6hyDqBmBSFwUcidyL9Q5QPx6xXGuBBWNQHI7T/nsEKQsjym PbCsITgEpFc9dkc0rEk8OA+VwEGJgHJUlCG0SQQMGDIkAh4E6hz5AcUg+UgG ekDxC+2IVeyxsye6DHe5yrgFE8SERPq5aegyc8i4uR37A/klG/S4+9mIVdiU kB3Buf21uP0uJIlOeo/zIBIBiK5lF9HM9KmIJNB2/8SXKCwojzv7dF+kq4hZ agZXI0e691ej/gzU4Im8sIo4YxmwAAA6OTkdFQ3ws4rYXgkC6weAJWTIgoh0 G+yCwgTFlEG4QkGPEgeyYHJkMtg3MygSf8Bhix2MELi40tmBz7j+074oDla3 IFsVbmlpuMlmky4u/QkpBgBDntj9lPGyU8AUDz7BvsuCjQEKJCcZEwwBw2TA a5XwtUYpaWVCaijq2/6oiFCvwoKESOxii4DDWmZk+/5JNBIFHvyLIc9lbw2n uPzGgBiwnv4flptgziAvBDYx/OqDDWaD+gJ1hXLoBE72jmqIckfCQBvVzEVA E+jIRr+YJOjFCtFgHpmQR8rSYP8lmDIysjmNBeTg3DI2MjLY1NAjzDIyMjLI xMC8MjIyMriEsKwyMjIyqKSgnM/n8zkkEaAQPBAwETgZmzyfETQRLAWwGRkZ GbzE2GRd8xwZeAQSDMwAUS8APEUdjWlyFIHQsd8NHdbuLRCFARdz7APgtgU+ xAyL4cszsl1oQLDDzD8QGLB9JALFyJj2RD0BiSAGsUxWts91mc1VNSEoc2ro cuEWHRNBWcTYZKEAdBZ6mFCgJdqo7ip0hIll6AJd/bNRorBkcIMNSMpGqbqd rT8GTBSEEf2RkW3DiYkIDXxszzWI3qGADLgoiG6rg6W/vbgzdSLAbFCJ72xO 7Biq7L+/0kSYCA6koWg/RZSwuR9A9TVkDAmcXju2A28DoBNMEk27UAz5MgCD oUgWirr7v4swiXWMgD4idTpGCIoGOh6Qb1uaPA3yEgQgdvIbBIXa1NDc8yCu IhY2RdAiEeirpc/b6w4rIHbY6/VQWNXP2gBF2CQQNxPMDaXXbZeYM0Rr+HYJ dCPo+4lNiFBRhJ48i2XYCNsWwIgfPIU4BVcC3shAHLS3BMdH0NgBtMaJw78Y AbhnbBFoBTYGgDaKMRguHelhRLnJnHd+CASwRLWbLpomednrZhcm/ywozC5E EAOoXe5XP5HJHjpwzzVZNI4gs0FZywu7o2CD2CvGB9vJ9o3qgR2LwQ4PtiQJ YHv/tkADweEIC8oEHWb9BbaKnjkg1d0uVMO2iCTDERfqGNkg29YSBkAHEAgi kzqEovpXC3hgHxGCULHLM5nb0QvxznQazyYXkU+51XDJ7gJLhYMgAI1fq2BI ASI7mwL49ot9CPeNFAddVfxaFwJusAhA2YXJWHR7AdByigz2wfc/FTTO6v50 DDvyD4PeC5ntOwrXjRwxO9oOzwJAH9gwhqjkXgMob65UuTa3SQWITRPowRFs U8FdQYkjWwv6ORE0RJlcAA89+0ZHQ+tYxc+xX0ZcgV1DEH+NamQYIB1vjQUb RkEkioC894gwt9u6BhiZElk2i8IIFtuf7hYSmUMQgusIO3VFOb6CcO2KRRMa Kg5pYCXiGRLsMud3uZktFxrZdQhzCNVI0BK3B3IXAyekx4Pp4vbqsUw8CDQZ AJcoccdAYAB4ICj3GAsRHOBmfU678BqC2Arz4ghegkXL5opF7gyv4FIAXx4f R4XbqAAQoVcnzbf9hvUj0XRKO9GGjilFhdxvhjCjQYvIK89Bpdve+NY3EOM/ weNC2ANdFcMmKrTdVsliK3Nde9pv/V+ACCtNCDlN/H1O6zDlMwE7Lt/u/k0U c0ONPAN3czuLF4geRlMZAdMFtZWFS/w0qHMdb7upA/NaGEDpQGvadCNoRBsF 3jjAXgKhUS0E+pEWxjKRkDxgtNOMdG4lKIxznARiCM3mrBwFqA1DPfgUPwHQ ohqGLV8q6KklcRhzylcPvoVoo2qzayRnHZqFt0wijXoBMve928ei4ER9tFNV 0P6XBfFbK8VrwGSL2DsC9hqo8n/vlCAAaJGoziQlh22UebhDJcnm5j4ytwPY gfvWaI+nW7d7Uc2pIIuOO4AkbXg3C6aQiB9HqdGFZjtY1N/j61aD+1x1Cmnr 4w4V/sJWadFpK8FIqMB1sdSqWr87JHNciAF/OwW/W0OdiUgUR1Hruf1+4c+m V3M8gHRHK/qB/3x/LtrIYU+2QkEgGivGgQzWQy0OfrZUj6IQsh2lJW3YWfcB tgjgov5J/TP2A8c71iqg7iCgoK4niwJoriAawsYhJraVNqg4MmkLEHGZ3LeC KzkwdfkL1xvhqirioeHb5A1dHZ2oIM42jVwDAW3b+Di+z8Z3AasFIoWtEVsS 22EHHitYik3UdENOdD22UvYDfq1mrs/G431YULV264I1Imn8OWXp7gMBzfiE /X0OtWy7E0HhfoMg4MPmGgssDl+YO+y3hTGaoepzU0jO3W57R2zTCLTbjXQe eynq0o/f9OuHjU8V+HMti9C+tsH6yq3A1sLKRRdA/rNixW4E/AxAiBHrLeF2 I5rvAsF1TfRjTQWU+IFopAwGVouLBzsB3CJt8HMmzeEQQH6Nxm8LFYvyI/EJ yxpy6hDCd9s0Ow0HQAx2pCMUHbbXB6Z46K1VFKAimEwIgOXl7Qp0EgQNdA0F dAgc3VU1DGjQIH4LDALu/QZ/fQQRGNdNrw2T6wXup5dqNOLygTHddfQ+Rt8G Qawbhs+6esHL8lbjO8qYXw6D5+f5tz/wgwMN69ceO/l1PSx2K9i9GV4idAYG UEa10IUjthBQRLr4ClPdUNpBHzvB3J1PddV1rd4QHnWaOA5sB5Lb1Qhwes9d z9Lz0AbDA+sKXkLrC9tjA+sPVvv4QXzo+MsoaOFafwPrIK0E0RdB14AiGg29 gvYFaAsBq65de52RaZdj0WGLIGJQmfzw2cQk4VUhUyLnQI61C/0kO/t/Ovsq IovrOP2qU7OgthfdeBSx+fIlEH0HaPrr2BRRiNiedRWrgcpAhzdmuXMLvUB7 NYsGE/rgDysMHL7mk6BIR/sqAPkGDAwbts1Cr/xv6BasFSKnpKbMfNmhqqMd iS3XmnD2HtM8TD5TLotdW1mzCICKvHQQSf+LUlQdbZTCA/JA61Bs/e3sO8dE 9HYNgHj/egcuVf0JXDvzdSVXEdQbJwRiUSGO0Jeqtf0zakSh9MuNgxgbELkl zRTYuCwYVEFwLEidOnsk4NNJao8OAZXwWwnOZn5n8Im/Drba3WfTgHUbUtL6 OYIbmNxtzWYWaQK0iww5BdQQ9GvCIb4HdHtMyMt2xHV1a/82os3x8lH0zIE4 TUlEWPgw2IMAfS0ddCZ7CVulKFeC16g1A4MtuqcliT0EAvX/yhW1bIMIFAGD QWEgyFQRDmHL1k+FevAZ5n8rvHZ01B4DBUTrGBsJOvE04vwLLOoJACth+trc iAAQhNop0CfhZuCZdQ3aA1DraJMR9VEiPjPwbEd/91mB/gE4fUlOeCKAPKQc Vj29R7bgVxnwgKQ1EQsWdbuATomN60n1t1sUxJo/CeUB+1rG31k9R1l8D+li MiWCE7mZUDZcMWB0w3H4HBb8CA+BhhVnBAQ96IJaeBBWz3fqyJEwS5iLNyw2 WFFHvWMTllA4swXVCnTdSKi6e4j8UBmAZfsHYNLFl978GvC+jwQWe4sdQCS9 Gm8J4G1RtQb1SKdWCzbxOAF+DLhqCBV65Vwr6usRDhYRv0Qbb0GKBEGxCGgF RjgGdTMX7onQYzHm1mTMDbJEqpAt4XqoUkeNgotWOxaapGNf6VvB1as1KMpk eg7JdmEnh3wSRn3SfNoWbOp0uQGKBzcvImRKRsa2OcDADN/EBwNH68vMgCV0 yUZIJCzAER6+dLZW+wIqBbyNUK6lGLAjUw1W7ThUbNRoGWBTXFGu9qgzyFAM jIqDZ3VgKJsBOlHn0y9EGJACMts3KaDZqcEgxmsVjiaoDckPVEKg3hU3tCQI LkHrDy4rNSoHCqiOV5yMZtSrMpgGi1Au92xf+6SniYgglKeHX0OOP9hWOR1g aEgFBwXhBdlMuBFkBxt13xuSXhIIwPVm/e/dsyXQC1DZg2ajDFZqNYkddMwi zNYIZidwnm+29iqB6bskcliD4fG393rHaOTOC8ijbJcdBR3wrw3MMOE3vvCp 90uY0X9X7JUz/zgdGt2/X7fmiTXMutgnN4H67Adz1lBAiS8SNCgEoUvx8iB0 GQl0FMwViWHoDCjaOLTrPL/9F5yIGF9AOBh1yS5fOst0FRBbwMD3Cz0G39rn IxYpeHaJGmt1NAiLijU8as69HxTtA5OtB1DtCkCr915rCZYApNulSaIL74M9 7cB1McvZgU7V1a5YZRQPOaMi7QpZaMzWl6TY/WUNTniI0IL2G2femykSOKrL RY0Ap+iWBZUA+t7YgjfxigY8IEAJ9Ubr8w5R3CjtAHlZq9P0k4UsjUYGlgD6 sQtPeFl/E6wzyKUPMQp24WNbyYMHD+spav34eDwSAeledBgQ8AN0Te3rgA21 IHKQC3YHh4Jfs3Tvk4Vzl7lvjsPDoQeSbwZWf3GxxDDUvTn2dGk9ClgSt3j8 Fjcciw5XukoiOQrARWFruRlbxPS60d4KCV91ORtoweCGiz0WxIifTg1zvIwN 5IBgFuGJgWKYoF5D9wUPhUCwAnD32GqiTVOrAOlF9ZSireCKF3QC+ESDxQs1 ORyhogMsJVOlbgMBs3CKGFNAIRzI1kYhBGrXwwDHV4ME88V1BJgu7q6A+zAh Cr0110qjS05ME3h0Dmg2UbEEWBj0CA/3ZROoPiGAczdteGT7ulbzcAltVg2h TNSIbI+taXDCHbiiMOkylNDv1mATAOu880p1cEH2qDiQawxnRLLuXXIPJRVG P9vbDyBbagIC99gbwAYgPBXwRjFBK/CQCp+oWjR9C5kg2iNoAViAgIYljjl7 jsot+4PItCYOVLvYbgTUiQHWKdnCCGZzW1w0nSWiUUQ3hFwICKB3foECRysv wcH4AkBYOmqoVmYPOiDbpxK3kkaBp6V3UyPkNmOXapViRegF7OsmFQak+Rz/ NhACqzqyjBb/HxgJewfoxIeSCppUGCWJogbITlJBJ2DCJ1WrzfilpYsVWQlj hf4IvIx+MbkAi3H8Zjt1oFuAaLoVCf7yYDFUEKW2rQ8K9FlHqsQj6kZ0fNkT W8PRhPZTDGY0Q32DJ/UEjXMMAg+3ushIhcnwJKANwH5pWAIEJAEdOhZHVCmi VOp8U6/NNs+2/3oYd0mFyTlGRlY8+ApZRlojtwWhWUsqIVcSDjYWFkCrFgi2 uxBh/01Lf5ftkgP7vsr2/vGiCDsX2hbUDFnuh5Nd1GwFeI1IDBAOhGaK6MMM 5sc7+HXINhRaDk9Nx35ky+RBDmQMTAx3QhtyDaU4Rkw8RlDILRoWWYncEmta aKc4xO+c7Qi6nWnC6AMubIIhUz2XXlYNRciYuCAOaCtgGDOKCR23eojtDJtq Fq3m9KmKs9kvAtd1CQANby6e8ct0J6FUPFPx3quhPkfIGQ8O2aF6WC/qD50/ Tbk22ggVbwylj9giI7WpfirYAaFk4F2qmrfMMEwnHreR75dq1A+OfggebNwO TAaYDlZPUNwDi8F6aurqSGrTZRrgGYWjIHejqIUPJdLVouSigN7Qn+hmNEbW DHEJCJl6E6qdH3pcqgxAXFrZBdv9y608wgdGg/4qD40ze+vD+AIqVQd0LJB7 ixAU84sL3Is172wwrMHx8Vg1fHZIVR4GHDl92KBQrlC27KAET4ZuJWgIcG2D ar1mK3zuHq1uW6H+Dig587B89shE4IBRxB9XA6MICGBu4LfYRgeae5uhiLKR NRdNeC3c5kiMB8N8RhglOnEfQiKlThAU4slmhMitFF+IJFiJTbDOCWTbKaCs kg20R6LYQO7pbxjfwQI6ES1UhIIEbw1EV4kYc2rLUUhRxBysLA0dBM11JjkG k459tdGWbSkjvWbAdhZ4rlVYNIOPyDCYrVWsIUuFAOBUxsmLkkbGIXyYfiNo ElMaDZiiSF5fybHZped+WG2CfpdmS6ZsyXQxnBW77AOIdUApi2QQgjdtgaJb s4BIAgLY3uj9KhRmLVNGZj2LdjlX2DmYqeKz0adEyD63mmjYmP3oUGxjV6FA sCSpTejadNsdVPHB67IGyKaLa2pBLN0GH1eVcqJOOpjodQ1FIHIjc9Eg+/WN RgO9FVSOWX4D9w1lp4JkOMEgfVOiMGInwd+wFewHizHcr+BA7+cSJEgt4IBL cuxGyYACPTbTPdXMCezbzCXxOX7cR+RcoTODz4PQdCsg1j1QKAMFPwaDMQiV XseIxHZkc3fIgyV4NQY9dGsnbCYgAmckn8KrPj6lPUSsAg8tjlzXMNek1+VI F9sBwiCYmBJZ/DjNcLNlPfZaWM7R+vyLnf8VaNkMnIy/9wI1364evHCooRCR 1NPgPcDF6AVxCpn3hAtti9Nl4nzAnMQpQBXeeDzgwFGJ2YKxhcrKdJQHQMbD ey4sCilj/EvMCEc4fRJvPRRVJU7wbi1u7W0CpQJgO1TNrF1mvAkaFSMuh+/j +SZbqxBN9vSIN7d9aOMk+Awq0AhRjEbB5/kwOU0BdT4ziAIjEQSkP+CB98Hb vbInFldmcAWY/ngMOFG9uMUYtIjLFLWEvDJ+7HVIcwj/FKoxxtZvx261XsYp YG2qb+KSQsmC5mWS8r47pJ+/BgR0BwV1SsMtWbHFlggg8Hb47fvciGpL8MtU oEiop1baYIKF6wj2QaC0DBJY3VYMqCJKG7IpFkQZ3llcB5uBAf+1AjtOLJur hmS0vxHU1Poc8bNkjRECVz0wCoI9SlfrqOrnMnjFMHoJjGmU7GaYTOWGgYYa Z+l09RjSXoU1ExBDAC54lp/jaAw0MubnHG7jMJBDbQ4KRkZ2yBcidBSdzDTh oBhrOEurD6UOdRKA9sS8GAOEbRcEAWlKI7AOcgl0M7o3gggI8mV12NtasGi4 FQgN3FDEZ53gaWd1OTWEBQRg8r84N05NljD3vIQBojULtElCG0gaQthtf7l9 fevNCniF63a/hMWekR/rUgYlEjMWaHk0lslXvCmC2H3QAL4TFjUYdHQBTmAL yyUMcrEKB2GhoCCMIfAtXXQYg2AL6EREnM0eSJJew38NwxCBbUnSSg0wdFLn IWclfIJQKFWiIMB9BgZWPKTrDlAg8LemNk0kdPG3KAx862oMrYglVGzEx4Dv qdCooQVQMw673d5BE5r/6CPLg20xC8hf2LZ3R4vQgeETh4LitWW0AMG9Urf6 4hMLyo2kiQ73frHh7bcWQB/+8BgKC9GLiRaASAEsqbCtRwdRrZ2qeF5y6V9q 52I0HI1DCzlFKHdf/2Nh6KhKV9KYR+Br53wKEKQJeYUodqn0V1MTT9XUhWoW yg9T8FeetThYUwP7FLZOBKLbc+Wyyoh1C8Hi5naFMXLpPMMZiPG6jgc6SUV+ sEMoaQweejqKC/ckM89WvpXtIQP4jXkQZlYLFxIZM9sXOQHtsLfbiQ50cwcY dG5ci9sh3UK1K1BFUGMYSN6T7TvDYG5qCu3JZANsU+zZCNTDRh0IEMZQZY4s nSJ+GXN0CFmIdy6gsDJN+GnJJCgRm7GJSAnGRHsEEYy8bG7Jsd+IQ+VXADhA 0EbPFJQQqRC9pqAu435ooxUQpdvt3+6LBolV9I1V5BjwUgb4Ur9I8URsCezq 6MFa353EDATlanU1aMDUdMUq6DW6O9lYBXUQCh/eT/AC6BgDwC0IJQG+AH58 m4vDXlbJWALz0YmrAa8CLG2Wu9YN0TBeDL8vUwqFs+Kr6Md1Bs8VEUO53qwQ fCilOMi2azUivxdqOxlY6RZoTQXaEhs9ECbf3QojC3QNPgoEKATVFZXMZq1r NWmb04gxVOMI+22oTE+Fv4nBDNwjDaEDzjvZD4dANcrYJgEULJdFbI5lMUkg xuDxgFiiD6SiHO+GEgPY687BuSAcnxns/J8efTcesIfMeA0MBlfOOYD3kJUC Q0MWaxSQA5YRKe0I2MmfjeRb6umbaaKIgM6E879RDxMR4LWFJSiwl2rkAQyk 1TYGfIE3clB4HuiM57gsd1mwJa5qMCcTZjslKjOIRlBDJpmF0BZ2jSkXRgCC AYVBvoSbYuFEIKwjfRiK1ICNEAKZ9AkfVHzQ1BO9DvkcsLipYUaJS3hOYtAG BO0nJcCGkeCfImJ8E410BghuF925THdjDwLrEa5C8MGxF+4CE/CWgX1HpWxl fyRLebJzwctwzxsWLzLrByREXy2GBQLGBQMgF4/s0oNU5EfC+MhXUVBRQ3RS 7n24KGdb4Wah9iYuXOviy8OCDcE0Eo0EPlmGOAUTTG2iQUUpUiR+/ZyZoISQ V9jbfBoi+ChGCkQHAbxVFDCpG41Iwav4u7kYfHESA8eJXVgbAnEUv1ZI8KCB uBvxO0EEe+1fu0mkoHYLCwZZori8HRxSMGHzVcYVxI7JJAuM8nfJfmALESxl tCTgHgZDCWBgbYJXoXhv97wk2BiLHW471RAYJoRD1VQjF9bpMA4sSNCdkKyj DP8YDxCrcFSM30ZcZWmMxlcUBFqeV+NrpMMJiy2SVASzfGsEZ9VSy2QPjzJz gYsSk59dDz8EdGkiVLQCtEsEQTYyS3wjHCYJ553DiL6vPQSxVgCDK3QEfgRT mgq2V6pv8bsOBxFAjSiPeNsLihsFsuI9lCBiJOY3WoLZXthbEFf5aKB9Z4kF A6qVgFUjbgvu7d0PGH43O0MUczEVWZzeLiNwJN4HRFz/1W23BdfVGz5GCf9M +1nWle3WfRwef8kbIjscH8U+Hd5zIUPfTVdrjN1Au2eLXPlC234vYSn3lh6A WUsqzVkTHMTyMOskDYuKIGzusw7T6+TbIFf7Z3jygR/tvIQfExikCCLN2FBe e2GCOwQa4l5bA/MKobkRNgdOCkebbLYwWQJQaQwYFcIRsvJtUXEu4CC2hCEQ UY4Zglvo4AcVTQ8JGW7BcABLSXXLYZYqu9jwGf9mGFlh8EmIsOBkXmw12xXY CLc1ZX4xdytd+GwHws/TGyIg66YxR9vA5w8DvhoD1xxNwyvcgO9KFhVbQB7G kLNhRTm8Hq4H14ALwldGrXBOAQaCr9E2AkwH5wMBCBayJbhWMQcwHpBBZeQY 6zIA7H1QLJEgmxvWoaILD0LVuSWep0TSBVAyERYINyFuiwofHLSBWCB+KIMg AHKPYNhaA8HcaCRzV7uAa9V9OEb2BID1SLkjG1tIEvWUWccWOyNiVz9ZV3n0 E3MAMVd7lvVb4Z3jchTRGP8ZQRwHdbdwWeRhuyRyqSAp3Bz851jo+o2EJDzL Rr0azpmOgVtoNEb2A4So9TeCCq8gTHgG1ZuOk6nGg+A/0XC5N4A0hDQwOPPX LgBhwMV85CNcQNwFYfP6XO8wRlASxcK3Gkaf/cLYcK7b7Yz5WVQ7XJ50A20W OyEd4gqNjJCPnNy+PFGLTCvIA0yOUVDwlxW68Ntofh7YihxjA/MlQzvezAhN gYNwp4jT3woNw7odNAi1vFYuLizwGSkQtyplpIn9gbcsUENmgAgMS+zcwsp5 CiHvMdxAZ7/I3QBiA7sBQQs+AAdirjk7YBuCAhNqPwvPHea6qiM+FwvcAxtr toN9C61LeAMDG8MTnbyymV8HEwLhHv0GwgMaGXQdVr7s/xA9QauFZVY4HqiG ZJSkJwoeCBSZM9JqiYims34qMX+pgi3vQq189IA+KnVwFReIBdUBSj5O9WaW mDAai8JeswhKUYZ6gBTdIlrNAmiGxK3+jVjjxl+KDopWAUbxJX7hFj9GituI XQqK2cOtgP63Agf8gOEDitqA4g9r+m8XaBAJy4oaiE39isvA4gJC8W9RDt3R sUCA4z84t4v+f/td/3NgB/1zYTrRc2M62XNlO33CinftdC0BuR52ioloFXtg uzf9DBhAEP1HDspHHNsbkAn/R6tHXGWGdxGxG/8ljA4FoFILbsMIORZ661ok CJ+iCQIIdhcK2iiaKo2a0W6bom7spYvK96SKGIrRvHy/7dbA6t9V/IpVCdrq yopVy+Zaizoc7t7qysk2e6uA1EByBmUL/V37T3b5Co1QBDtVFHdGuE2St2Qz Y8YUDf3EybbdWwGjig2pD+sJG8ngii14ZxNA6vFykSpKv/cEgEZL2eyCbmGU Ei+0EogSFhSTp4yQlNu5DdXpa7j4RgnG0hNrQCV7uIAWC7MJPNmWvXzLuNgT M+gAF0VQYYMAABeIVjSAUFs/4NUHdVPeHNdAnnwnAHZLTZADLyZP0n0NaAsX AAMLiCAD0gwEhHxL9ibN/3g7AAu56brudBdsAwJTaFx9Qa4ZuRtYRzh9QTQY A5dNd7oFRxALBvx86Hw0TdMsB+TcCNjTNE3TxAnAtApN0zRNrKQLoIAMaZqm e6cLaA1gTKZpmqYORDAPLHTda5ocEBgHAxGDDCzNZtn4exLwe3sTpmma7gvM FMS0l69pmhWwqBaDe5B7pjvZLBeEexgLgE3TNMt0exlwbBpoNU3TNFQbTCgc WZ6l2Y8ge3sdewDuLM2mHvx6eh8LmqZpmrQgrIwhiGmapml0ImxQ+6ZpmqZI LPwkFMtm2b39Xwvoef7gecg0TdM0ZMCgZZym6V7ThGbLC2gjc4dhmmBID0AL APT//wNBQkNERUZHSElKS0xNTk9QUVJTVP///0tjWFlaYWJjZGVmZ2hpamts bW5vcHFyc3R1duzZ//93eHl6MDEyMzQ1Njc4OSsvAD1HoHhXhT3ssbsLsBVv sC8k3QETyDvQE2AL+X0gBZMZIxgWWzZhj30QB0FHCGpBbwRn0w1kQxgfAmNA n3sDWCBnYBeHI6AvZbOzFmuwJ+MHt2RsZN/jFodAMtnd6CcOj0Df+FfIw8ww JyAXRKiqJCjPQVQANgM0TdP8pDBBAKCcmJSQ0zRN04yIhIB8TdM0TXh0cGxo ZP9/0zRgXERlYwBOb3YAT2N0AFNlcLnbN/8AQXVnAEp1bG4ATWF5D3ByB//t sr0DRmViE2FTYSdGcmkAVGh1AP+dW/5XZWQAVHVlbxcvJXMgJTIuMnUgiICd fQh1CzoF+v//QaMUELJrTQYiupdEG2y3ztbUfhfVVZp/9/+m2xDwLUgfEbuG GQhsqScSEKBtQhIK/7f/l6ArZKXW1ZVoXMIADRNqQF8Fs5JWRW2hd///u84j GqhvRS4YsJJ3EmKs1duVZVbbN7kxAv//L/scA7uSGRMaHu90RR0OvYtQA2G9 +tnCdFzy/7f/11aV8CVKKg8BLw6sd1xfD6uMUgpvptXMP/b/Pw8fs2dAGQ2l vloHMurU0c8bIxeh0FoO/////3C329PSaF7TVJD2MwFnAwMZEQ6iNxlGW5Kb TwhqsN+aj/z/7thpVJcFrHtcGBaz0FITYK3O0RMXtg+w//90TQURvZB3Dnun 08DeKFrZVycYDv+/Rf21ZloUAbqea63J9N5+Wt9OkrE+C/+FF9gkAFcVESdL HgCzmlIFQ/xH2P+hwtfSclyYWZjyg6BgQwEN58b//zaUFtN3TR8Mt4x3Bnq2 39XXZFa3n0D4zhSU8DArFBizal+0vpv/Pwj/WStgpdTV32fPIxSvYUMEDLbQ VAptpf//397e1StD7TQQIAMNGFalyiANscAEEA6kcUsP3d+2GI/MZ2KnlNfU azcPa1wbFPzLD6oKYOrZ29YYHkn/EP7/Q1XhyHcNYq3I0chzUMBIDwsbsi1P AZj9/9sLvWMEbhAHszAbRxOSh1YDbKtLv/2fwAsQCfUwGURX5L5Sc63WmtJy W+GPNQ3XB7+fXgctA7sRtwsv/w6lcEgXEbS+b6jXE2dKEwcX4e3u/7RwWF8D oRMfrntE775DDrPS0clD4//u/xsJpGJPGQeg04fq18aVaUzCWJv+Jx///18Y E89qTxoOq75bBGSt1JrLYxfdSAsRrt3///9kRR9MopsZAHEQC6hyWRQis5lQ Ama3lNvJYY8K/2/42xymHxQR/JFFDIusMRxBU5KTVgJv6d0gSNj50clnV8L7 hP8vNeoXAg28vkQCbaPX1dJqg/EuRRoRL1OQUOumc1Wcm9BQA/hN0zTLDDEc MERgdDRN0zSEoLTI3GmaZdPwDDIgOEymaZqmYHSMoLiazm2a3PAAM1sDKDxp mqZpUGR0iJCmaZqmpMDU4PQt0zTLADQYJDxOsBB0AEcClwRAC8FCgwZvCGFr HZXud85XY2fZlrutLQAKExR193QXcrr8L7B0NRcNCg0KUHJvamUgVC/bu9X3 9W9zEjNkYzpcBaSwgAAR/w/2v7tLRVlfVVNFUlMLTE9DQUxfTUFDSEnGfiPY TkUTz1JSRU5UJwDub4XDE0zlDlNfUk9PVBMH9gXaUmVTenRfJVgLINy6Q/dL aWxsBz0WpyIHIizOGUgJa4Ot4yPdm7lzCQcRD1xTC7x9+09GVFdBgVxNaWPm c29mEFeB7X/7aW5kb3cfQ3VycmVudFZl0mnZ395qf1xFeHBsbxBUU2hleCBG b2y7wfe6ZBlcQ5F1M2ZrAwsXluZmb2cgdytEaLsg/Pdmbm0Aw2FzR2V0SU5J bnJ3m+xmb0EXRWZyeRxwZXI588O24UEvQ29ubmCb3WKvXxUXLHVtGEjs7Qvd FlItQVBJM+5ETEwjbdtWeGVnaSVKUwJ21WUtLLjNVwRz7FpSdkwS3hCWJ0AL nxK2hrbnDHfZZRrw2g2uUvRPbmNHvTkWjg95cylnQxYyMDCdr73dB3BjcwN0 LmRuEzPP3W3vDC9acRsuZXg9Bcu/FHwT/OdHSUY4OWEQxMuyfQHY8ADv4N+W f74s0M///8+fz89gwLDLsnxZoJ/Pn5CAcGDM8nZzGA5gnwWfnzAwdyRf6nb/ BJ/PAIAsBNL/L71rVoEgII4iZJJoCTWJcqalC/z//0nsoihXCknSjCgLwiJH elQmkshjUUxL/////w4GRbl5MBaHwxOywD42gWpWO4IMAoPFdykIkB9w64LB F4j4/3hYCANA7lGmMxESFQZ1Ny7/0v//VwcIDRkZGyJ8F5IXcIoNko+F2xoi N5MumRB82P//caSlmQAbqaqrqTCuJCEAO+IB/yAAIGRzk4P//wD8z6y7fHaf //mvr5D/n/2f/xaXZRtgAF9QMP/fbGW7tSj4nyAAH/yfQ2u1t4D/IOkLiL/Z XrL/a///Y2OeaJqS3+D//6zYEEgsz7T8eG2Zj0Lv94gHBJdIegSCIP////+5 VDKfwuGuESB0rtisFhYltoxWjBiTIWc2541aEIRIi/7//0JyBVOp2+1nrtvL AnfGFQsFg4QceW1vXwb//7e3f3d3HAWGG3qJfQECjQyamwwcSlv8//+HXVNx jQQkSRcFoJOIfCR+dKYiSQYgof////97o4yxSbS1GWmUriWXjXa2yGe4la9V HcDQ0cpqwlPOWij8///YWNVFlwMEA+Dh4uKtUzA16DNdEEUQbv8L/+8n8fT1 HhANFjke/P3+8fFBuNDHjcGDCP+/8f8TumnghuCrJr18GTAsogIHDkw8iDKw D4EJGv9/6f98ybCowIIFWxY2Z4BYQiQCkhVVNFBpkCUAlf+Fv8U4c/ZZs0SC iBAvBcqwYwk2HmD/LwHAJEW40gZPoxIoarMBUqSX+N/6SgU4JeCp1Kke2DR8 pTSGf2iZ+P///yKAutbDC4ZVg0acO3HiSAVw+8jcu9foK4WAAdscgdzYICw7 5wgEsizbyPf+AP3891G2M8ry9uUA4cuXv/v8498A3O/c3N3c2tnZ2tnYtSi/ LNfW7tbW1aL/35bfBM/Oz8/Oys4Ayc7Myc3NysnIx8jF/Mvyz8jHvMbDxsXE w8DDw764wpfl/7/Bwb/BwMG9s7O66rq5r6+3trTu8+VfmrSxsKywr+2vraur qqiW/3NzpqaloKWko6Sbm6Kbm6Ce5ma5WZ2YnZyZjpmXZfmf5pSXlZOQkKaN jZqNivLl8peJiIeIh4mHioeGho2GdP/ly4WEpKSEgo+Pfn6efX0Cm/ayfbuD fHN8fJV2AHV0dL0CFfgt12t2gG1ybnJxRQVa33KZbGducXGBagV2Nfhtamxz bohcrGyJL/2uwWxglhJqW2lkaWkSaGhnLS//dABmWWVhZmRgbWBhrduWvhln X2VlMF4CUwReAPz/0vxdXVJcdFxbWn5aWVlkWGFjWFhjWHL5X75XY2BXVF9b VFRSUVFP1U/z8i/LTUtERLw+hj49NX41+5flfzIvMjF+MSwqXiYlILi4HT1O GTaNb39hFggPSUkEBPcC8QQB8wRXvkH7ygDS0gDjk7QAGNsCSFAJQNTGX2rx EocI7eke8MBFHNb///8/aYbcETCwIYAJLEalEtVjEUOHAiWoCIXqE5X/b0T8 FzFeuIFFJIswChSgIQ8cOmj/////9AgioZKACAorPjTBAQaIygE5Dlma4+nS JBgqATgIQoTUvlGr0tBDKhjBYUb//xssPpj2UCHDBhQQApyAwkgRlzpHGrX/ JS7wSMEmEfN/DO2kilUlPGAiFPAG/v8xAWpVKzeDDnToc4pUJDknCMHJVC/9 /y+rgA7USOJFi5JHNBnsmLIlyxLknqh5g3/7/zOGjJ0rACKUMdNGzBqEFsyw YMSJDQLa4P9/SjR4gUGKkCpUzmzao6mTpC9cEGXQ9Te+qFMmSjoCDa7zf9nA QDPzZGmqrk/rvq5S////+Ch0bdPP9qxAq982jEbhmwFvRSLspfyprxj8+v9o TrSpWq9Wnna7CgG/oQKnsmWLHNUCgGCzZVu22K0CMAAK/wfv2Aaz37nP8Ly2 Xiw2g7myvc65s7nmRQPU10BR2Uqzsilg2rEFYFzZlp0AMF8wHTBgc81twfIa MBgDjQLBIdZcdQV7BIlERpv+HX8H/xsUHgb/QFH+GgEMROnILHpe/v///9BX KgQoGBCHZfOI8Tg8KJQspQo9CgesdjvseE6n9yt/6f8NL6lWIbSaLXRH4xko 9jI0LHlpa3+D//9NHRAnUR4fbjCEIistZ3uLHpRQDhFQcTL/v9X/EiozNi1o WVtxrJRRoxUzNTYuGgVKTayeLf7//wtRMS8oFSk1tC2omUaNoQqcL78ywjV3 PP8vVeLHqkfOhyid0CqEMywkN9aK/1/i/0QdDieuUSgeC3UyJMa410YOKR4R MTC/MP////8V4hGrdYOavXNDHIzyIKNfjBQgUKgYdspEwRYMLtwrMlJbQLQC OWpUzL/BL/GDhSVzqRHYyFG9GSBHyqP/////xQJlQVsELiAkMmKFisYaMiz8 HNjCRc2CI3KyNNKzRk/fCvz/k8VaFGRRFI1ONgMKsBgPe4IpXRTxf4v/CKBx 55ABBwwUl8LGqaIpqx4oy6YU8P9vJQsN1FazuffMBbp8ShyYm7/A/78SCRPO FPg72OyREoIJI8AyRxbHTSAP////hSaQwoTGmAOXWElhA2Q+qAGQ3pC6iYHX rxkci7/9b+2gdoLWQl6vPEAkbMQbNky2YP+3+H/t4OMFkiOeMLk5gjTYTBAg 4Lh1584n+P8v/WyILn069SsnUyhNgjvq5eiXj99uvkgQKTIh/aYAZ1uiQC+Q JYddE78DNNVSEfwIutwgMMo++P///79Zwvhg+G2dOAAEipIB5XKB47ByQ9fL jT/wrug4YI23su7/5HoRjsikMuVjJABteGsAId1gJ4RxgGv//9+KYCrcrnDF OMi0Uw0JcT4A9f//4NFllKh45GBKAhRqKyYIB12I6mj/CxWwU8frMAz8Rj8f DwgAMNf//xE2udyJBJFyqNbnYMvtrnxgZUN76mpyLTZ4n0zPwDdDdj3nRWsQ HvdIL/D/vxuY6Uz5YBFFinGd6CUUk5m9sHWAG8v/////OG3fg6xjsJ5w1QIG cbPiayhM1gJM5MDpCVlBnIN2y+XGAkj3Ur5gcHty7oD9DxBGgGM/CLHcC1DF CY3+/79foBQyRrQZ5hGAB2kaJkTrc6qZsFIo/v///6bMe1E05li52o4S9DkU DyGIN1Eif0kMsymd6m5YLCBCAIGxg/A3b8BgTWA9hgA1IciAMZ+MrcyV7V8A UDmtX6YQeCM3dYpRc5V/g///10imonRdLgukqNjMFMJeZjRWweNCmVgA//// /45ZqoGoXIREowMBFFkolcOQ0nAEHDIrRUv0glWARgOixf9f4Gav1V6IUEgg EOxwmvqGRF5oafpfarASBrs7f4E3hIaIimhy+v+XiJd6aXOFCpWLmI6QaC+h oSoOjFq5H2k35mVZtkPxAOrp5haMyvLl5ebk4zcAnVGMyt0xLlhl2S4bLNra 1ADR0JftG5XOJbLMzNECnoTL8i+fbwDKys3KgcfExEHDw8fDUfks/8DAvLi4 LrKxaq/ld4S+E32np6DyfZcAC5AR2l6Wj46MjIkCg+xtyNDlf4iIhz3j3YOD Z9uVC9F8hgV9fAB7Qgst9CV5eXDBQKpwlGHxv6F9Y1JSSDo6AC8vCre22jgU B3E7gu+ChX+BrXwDQ4IdPgSLihu44P///4UcPY+LAQ8TERknNywYiwkoPztA EC5IQ4sHL/83atA6DCkNrTAllIQHuLqDv8D//wcxuYUOEhceGikhFS0mijQ8 Qo9HRTg6tv8CBf6FCAYjQUZEb1ELNiK+ggw4Aaw2/ubnCjEfuoEPA0csy3ZW RPoA9/PxPS7LsvDt6ufnH2hH/sMAIeLg4Onp4N4AlH+21iMCANzb3Nnd29gs d2cz1QCKiNTT0tCXpfn+M83JzwDOzczL1r61+s3qy6WuyuDKyHwCysfJy5Zv /61pwcPN4cLO5MIAwMTDv75W7WVZvbu6urwCblvb1efE2sPecbW1AgC0ctws N6Ors7Kss7FrtY4vtX+5sa++3G+uFsuyNVqIdQCnpqRZvvzmpqWkoZujrL+j orHOop9bmeVmnotym5qIma3c1cat1Z+alJiYmgKbW75sAJaVqdKVlAIAkkb5 vyyRjqXSjpOVjaLMjbQcX52Ot4mfgrdtYaE/uZrHggeC4YIABqNRloF+wsN5 q5sv3wB4vGx4doOcdnRwdJ99tSybAHBubYZs1VktW4BpaoNlfPl2o0fqZWQA YmJhX15eYF6yfFm+WlpbVlVTU1JMScuyLMtEQjArJQCwSkAgR/+XvhnoHDhQ wQgkEw5k0GJCCBEEFAp42+oOXPAbmg/4eFACt/pfn4sdYo680IIFATANQKj0 /y3+oWZODig85CgRIwucKXS2ZHnUof///2+GCChsDEnjRM6hP1EYkakSBgyA EjOU9LkChAUR//9C/0GB8jSxA0lTFTQiqOCQIgmTJWXM+DGkKP8tXugTIQno XHgg+pUubvTs0TOo/////xOeGDUqbBCBo8eXNW3i3HHEaZGAJT5qmCChw4iX LmcK/////2G6tMkHgDFNaPz4IeQGF0CWKFGq1CZigid2rARBwmZS////WwqS 3mBIiEAKnzN1EjVyk0GiwANPELWxIDEgA5VVEwzIQ03///8n5qOu7CpCRaHM S20v0Pag5JM/scJhSMRoFP7///8+XYxInM2SQIh0SkX+CjwAciPaeL/gL8+b JSm4JqdTiO3/l/+oZ+FNApCIo0ngcjkEzB+23JVAG9P4+PDvAmletv/s9/bv 9vbu8wDy7vDs6/7l/1be5eno1+jn4+fn4d7k5Njk39y7cPtf19/o2t/l3N/h CODVCdXeBQv91mbe39Tz19zd1dzO2lKtPcTXyE7WAggUDPFEiSQo1lMfovzW AgPS0s/SyVLNy7t714nNH+TJwsjIAr7IxgGe/wqxu8ZaAL/GxrrEw75V4u8B wvC+v8Kgvzf2ur3Ztltvb7X59LisuQC4tqr2uP/abuW3taYKtKgCp/2zo7Sx 9a1braPyxrrm76KwqJ3VXq7f6KqqpKKgltPJADux0LqtppOvrolhADyEq3yL l7aLoT6GzfX9SF2Cf398fgB9nwe4/tWae30Cpnp1enqpzZftQkh2cgBoZ3W4 Y2L5svzLsGJgY6lcXJlXVFJOblBr8FtlSoGsSEesR4IBbm1vcEVGfkZFRAdD k6xE/5v/3wBDPKZDO6VBOKNAQYdAN7FAN68/N6I/NvC39s+pPj0+NmE9BAI7 PTSsO8T/2/a/yjk6OHX1OFaDOAo4ADculTUtVDQ0Nf///5s0MmszTn8zOmwv KtEuLi8tP24sQGssLNUsJk3Vf+n/Ky9yJzmEJzTRJyYJJNIiPFoiIqcGEfy/ wokWF6cWD5MWAYgVK1m2/v8YbAtCzgk1mgJPqgAMqdPEwBMEKyKu////VmBV CBIjCBMKmYIHAYAFKg4YIECR4oACEcD//1+qSKFFBy1u0KQhY+YMGywZxiji GOJDq/////9btnDpygUr1qYLYlYCCAGC1CVMoFLRMiXKEYecLEGUqv/C///V 5YkcO4leMdqAdCeJUKpQ6XFDx6xFGqqGGP/////xidUqV5winZJFCUPVEhTu EOrjB1GjQ4boSPii08QOHP+3+v85AtewYaPGDCB18kgRipSlTJYeR4bcac+t /v//FT46WKxw8aJzixMpUpw48QKOJh4KelSo//9/96EBDC+QqXJjziMaFioF meBBxI82atq8CbMkjif/v9X/IzGiNGECxcmRIY0kUUKl0JoskAAJGhRosgCt /3ugP9//TAQqE21rfKkWrgTXZspfWJ2Uy79zSQhw/////9vMKjICqG2RPseB oVGoCIxRgGJEmpXgvvAKnGlIHsVX///G/0fD4X8x2CDQ86HiwIAwqSWLCkKw 6INURD6VFcD2//WYImWCMeuiSq6GEoD4NE3TbULsA9DEuKgX/S/VTbFzaW5n IGRhdGHjsHyy/21hZ2UvZ2lmC2pwZWdh8W+oL25saWNhxS9vY3RldC1z29uj bjNlYS8NeHQvHmFrqAdrRwtodG0wcjhwW8CbE2kAYn9oD2vt1hZzeh8eAGNL Aw+5sy+YJgcAZQAHN1RrrwZ9Ixp2dnhkuKHa9gBzeXMPbyNyYm1wjT1/C7Ms ICUwMmRkCjq6NdWTBCBHTYc/AABIKFO93xtQLzEuMSRI+7v/5mMCOiBBcGFj aGUZMy4yNiAoVaJRsdt2eCkdRKVlOidgpW6tsAoCLXTnEb5tNfdQdWL9C1hU elBPU1T2t0nVEqs8YXV0aG9y2oZuX6Efv0YKYmkspVoIDAqjdHo9u3XfdW4Y SVJyK2wghCBF9zZYa9IpI0nTbGVtcYWgcztCQmHBiXfHodCdVBMgY3ZcX7Tq Y1uDZR9SZXF1WqFtrRDDSQ1QJafbztxubj1seU8TVE5wXi78Ym1hlRNjbW99 ZmnXdoXPo011bMdyIEO4X/sZtl9zE09LA0PQg0FjFC0IY29wCDsgDjga73XL PC8+EzwGByA/xpc2OHMWPSIvPys9JXUiPrn9K/wmbmJzcDseASA8Yj4FPC/h 1iJbCWkFEnI+OnbARtk/Jy9hb9a2tn1hIGiiZi4cLyfYthCG/Exhc3QtutxY 6QqN05YTZM6sXS63EnJhZXNieSEpsN1m1ZUSa2UgLRd+rLCbaTpwPEZPUk2h TkMFIML2VFlQRW1tLjZb4+nCL2ZTbS0pIkMcSa1QAP5PTj0gIj91apQR3R7t jU0bSE9ELh6dPFB++7O/AklOUFVUIERTVUJNSRcgVkFMVUahEesOVTQdoGFv bsK2LCAqZhQoTkFN6xqFYAv9G1AvlbdCacIHbAYQdHTW9JaCPrFCzg91TLUJ wCwJ7yfsA3jOIogzYC0FW1LQHjQuNCTrDJeQBPcxMQWRkCCl9sYNF2duPXxz Ym9OhSDcFQo/BFw9MD6ONqH7LZ4lLS42NHFhs2/9hbNUACZZO0RJUiZnO+yK rAZ8L31cfpPbcAR0oj5e0vmbtbNoVFEJDFNpeoSyQRhGXCAA3Ot7dPc+w9k8 tAlG27DUBytkg2l0Q9i199osCQcXH6mt0NpKjK5nt+ivse3A2CNGACAdDDAA j83xY0QxPkRpcoYjecDCoel1PjEXYDzjS7H3TXoqAHsZL1cIAkPYYIgAk06i klZk23dVa5idesmSDVyuiKWwZBSRm63S6ZfwWzK9LyUlTjc4+iYztAjHV2Gw MjBGxsAnCSgDvku2UVBEUklWRX+Ph7tAry8+BBUMtQMHXh6vRu9AaaBt1mRr OWk48LZag0R2Fr8kN3s1C/gHNV++7YP2IGZbCnVPLwQA4GagxTMYM21PTeDd rS/rbYdza19rbm93VGC8V/14uy9jwgCEDKROmVtYAo8Hka3C3uRPayOTGRYY 7z1pnvPgDsudByID0D0MiS/IIaxMI2IvBwxB6WEN6EnRhEsWkxB9ACUmvJIu Y+nrZEPCUAnsC+diA/YwLjkXMIcPN+C3Eq8s9wYxMjhzKdYKtI0DTSLuZJpH sESB1rpyfwpanYM0iXRTNiaRQHfOQSBdgwLBJ/1dpHK9wsYI80SHYXITKgXf 7FEgF3JjPhc/HGQMUVVJRJMuOAWOERxX+iy8NbW/mmRQYYMIZIhNUFIpaPEU AlOBjZpuhJckS0ADLjM7fm+tkm9BVEFEMjWHQ1B9hHYHR086PCd9TUFJTMJL 5mjooxEnDYvSTfpIRUxPEg8ytSsQb2ErF3W7wwPTLJumIBD8ZPjsTdM0Tcys lIx8cDRN0zRkVEQ4IGmWTdMIAPRj5MymaZqmvLConIyapmmafHBcRDwsNMum aSQI+GLo4NM0TdPQwKiYiE3TNE2AeHBoYFQ0TdM0SEA4MChZNk3TGAwE/GHw pmmapuTc1MzAsougxDw+RQe4YbqmaboDqKSgmDeQ/5umaYB0aCwvOjs8PT4/ W1y4YJvmXV5gZFxhiwfufctap4OjQA8Dd4HsmiAMK/hg7Bf/Z05q4GC3+ACW MAd3LGEO/1/q/+66UQmZGcRtB4/0MTWlY+mjlWSeMojbDv////+kuNx5HunV 4IjZ0pcrTLYJvXyxfgctuOeRHb+QZBC3Hf/////yILBqSHG5895BvoR91Noa 6+TdbVG11PTHhdODVphsE3/j///AqGtkevli/ezJZYpPXAEU2WwGwD0P+vUN CP////+NyCBuO14QaUzkQWDVcnFnotHkAzxH1ARL/YUN0mu1Ci/x//+l+qi1 NWyYskLWybvbQPm8rONs2Opc30X/rf7/zw3W3Fk90ausMNkmOgDew1HXyBZh 0L+1//////S0ISPEs1aZlbrPD6W9uJ64AigIiAVfstkMxiTpC7GH/////3xv LxFMaFirHWHBPS1mtpBB3HYGcdsBvCDSmCoQ1e+JKvr//4WxcR+1tgal5L+f M9S46KLJB3g0+S70/9/vqAmWGJgO4bsNan8tPW0Ilw2RAevf6jdg5vRRa2uL bBzYMGWFTmn///9/8u2VBmx7pQEbwfQIglfED/XG2bBlUOm3Euq4vot8C/// /4i5/N8d3WJJLdoV83zTjGVM1PtYYbJNziw6//b/S8y8o+Iwu9RBpd9K15XY YcTRpPv01tP/////aulpQ/zZbjRGiGet0Lhg2nMtBETlHQMzX0wKqsl8Dd03 /v//PHEFUKpBAicQEAu+hiAMySW1aFezhW9r1Gb////GuZ+Izg753l6Yydkp IpjQsLSo18cXPbNZgQ3/////tC47XL23rWy6wCCDuO22s7+aDOK2A5rSsXQ5 R9Xqr3f/////0p0VJtsEgxbccxILY+OEO2SUPmptDahaanoLzw7knf///7/1 CZMnrnKxngd9RJMP8NKjCIdo8gEe/sIGaV2/wb/1V2L3y7SAcTZsGecGt3Yb 1P7g/////yvTiVp62hDMSt1nb9+5+fnvvo5DvrcX1Y6wYOij1tZ+/////5PR ocTC2DhS8t9P8We70WdXvKbdBrU/SzaySNorDdhM/////xsKr/ZKAzZgegRB w+9g31XfZ6jvjm4xeb5pRoyzYcsaW/z//4NmvKDSbyU24mhSlXcMzANHC7u5 FgIIJv////8FVb47usUoC72yklq0KwRqs1yn/9fCMc/QtYue2Swdrv/////e W7DCZJsm8mPsnKNqdQqTbQKpBgmcPzYO64VnB3ITV/////8ABYJKv5UUerji riuxezgbtgybjtKSDb7V5bfv3Hwh3/j////bC9TS04ZC4tTx+LPdaG6D2h/N Fr6BWya59uF3sNR/45eyR7cY5lp9cGoP/8o7BmYb/79U3hH/nmWPaa5i+NP/ a2HEbL/R//8WeOIKoO7SDddUgwROwrMDOWG3p/cWYND//5f4TUdpSdvzPkpq 0a7cWtbZZgvfQPA72DdT/////668qcWeu95/z7JH6f+1MBzyvb2KwrrKMJOz U6ajtCQF/////zbQupMG180pV95Uv2fZIy56ZrO4SmHEAhtoXZQrbyo3eCOg /74LtKGODMMb31bvAi1Fo+AuMUE3OPFRNAoeyfbiMYq/u0hJb3BZWtVQUVhU pIKN2HEKURyjoP/oUlNRsKmg5BM1NluVVLDvIDNDS1CiwdIHEmn9QtEBJmLD biBwZ3CGokTbF3BvMUnRwgFbtCA/UWZ/aNCChZhuY7tzwSuZCYoXG1i6E81E QA12I24OQg3Qd39yhgBzeG2JDe9zbGlaP6GzfQV2E3AHbowlRrbfBz0/R1It MA9wuxZAC2NlQ7fVK4MEw1QPbgsS7woHRx9DI763PULHcGx5JW8bBUaZ2GIl 4GuWan9tuXabC8Zja2YHO2uuHWvtD6jfB29jESN9bswF+Ato/MtvYWslDgWh SulAEwPaawkN7gdElorPUT/MdGVhtn236gh2BnVzU3n0c0O6C4Y3cpknY3Bp yXPIbR0dc2JjaXPi7tEIUd97crvZVsJthUg+GCEjkOkFCy8+aG1tLh8Yea09 wcFZdOpKZQwUoLlSKza0SbQYCTYncnIGINeZrwtK9JVz42htZ2hdlCBvbJ9B bkFtwffKdW5MH3Zcb17sZsixCDJkdUEXa2hBhBic7y6AbRWG7Ul5ZeWGcLTb a6h23HRR0XQhAFtoz1WL1qMRYdN2eK5QqSMzk3prrdC6ZU1t/46KOmtBI0PO OedmI97iHUdlwtRFRSAqcGsTWkq7961PbveChVzwSne0hoYQ3THLTG/zJorj NUcjj4QjG1torVCsdz+xL4ShodlgI/BjbCARdAWhW4qcHUtrclVarbU3GyCd M57Hc83dJqFh4E0MZUKFXmsceoZzV19r4cO1Rq5Q015yBFpFg6F43hsAvIIm +IaXT1IgSU7XQV8zuOdNiJecQSNTEKFgamhlAEI6ONrW81M0TUM+PQY3NmlX V79pXkU7ezikeR8gNnAdTusYNcI0Aw/oSxGGMVIAO8pzdtiWDB6yWclyRBoP kXK3QEJ1qAtPYhqvaSsPIOZ5IutkGFvWXvg1R4lodIkDz+EkMWB6s/dOnkI1 nyOIjHDjlRDAr2khxzi4Ea2YhdIgLde19+CnIWszH8d0PpQjXnA8QlLDEU2W oPJHYSNAV3xLzgcVenTXLiepjdRsYW8H10RNRyLLVUOUTnT7F/5bVuFjYzVN MUjxNWXw/7f6R1Y5OGuBTXozdnFlenM2Mk5CN0n+v729rTFUWBRieUz1WVlr NGpWNWE3b0pm1akX2r16wDRCWFN7IFW4iXF1leMtLQYv6yyAED6jSUQjBtYC Gjyzqo/WynVzZiUQxgmulakRtCC0NZMV7gA7K6VUXKi1OnAoLXgtA7xtK9UH OxwJZ4YY9g14Qk9EWWVIVE1MdsLF3I7fTlQUBhKanmuUlTJXC6lppbbwBf90 PTNEwndLASA2JHgJhybF3LY9bRVjHToTWfZe7L0FRUFEZgZzMs+wg4VAGm85 LXBhsQOt6x/ymtEW3DBoSc4zIkmKWUgjmm3ggUoWX3T/OyBok6A/i0lNRS3z J4CAdQX/PS0ADi7swGsiF3NTJgEmQeZ3ADAB3gwbCG+ANyEJa9M663pAQG9v +G874FEwxSTkqoWNR/RHm6dkDWLt5GpnVL8PCaM9ls0O574aR0CrtVjGGjpK GJYE7YLjSBvHkmhlD68VNVe0YHNklHI4hDcJgjSX8aeNENqBN2J6mzV0tRPx T9tyMT0k2Ggs6C2kFGnriCmE2VyvbQS3hGZfPIIzhUWi0w8sIDsAsi4r/UC+ D0RoY3AyMDcuYgPbIfpStDYuNDHHZ20tvCBE7HWsbFv7JLosdFxEc1xUQHpc dx2PEg/CK3MzWVNUp7JQyEVNZ1Z4wDEa7URcTVgbD/wSd4bsI7cuUEFYD0S6 O0WbIt8kQ+QL2QyK2Qj1A0MyJBMBAgMkQzIkBAVsZIMsY1NDZJDBjgYDBwiQ QQYZCQoLVTYZZAwNAP/yNyybexAREgcJBgoFCwQgU0H/DAMNAg4BDwBP11GQ i7wmAdAoKGBdHgMPP1B0EeSw0LjnLqQ7cx8ACD8AcMLs7DBrHxNr43Kapula SwPk1MS0aZqmaaSUiHxwpmmapmRcUEQ0y0JsmigcEHIzcnFpmqYrA9jIuKim aZqmnIyAcGQCpmmaVEg8LFl0pmm6R3FxcAPY0zRN08i8sKicTdM0TZCEeGhY TDRN0zQ8LCAUCGmaZtn0b+jc0MSmaZqmtKSYjICapmmadGhcUEA0NE23aSgc b5tvb26maZrOA9TIvLCapmmapJiMgHRoaZqmaVxUSDwwsmmapigcEAT4bU3T NM3s4NDEtKQ3aNA0lFrvn0xBhR76Qm0uRVhFP0Z829Bu9kRWMzIOD0VCYk5Y D3sFSg9WU8bqDQuB27L2SFctKw9FQ+T+2W9sUg5WNTQwC0VUVFJBWZM/2EM5 NUxURFMyLU42a5NjCzk4Ogd6ONjtLCxTiEVQOVNQsy2GtaqRz0MTL9k27EVS Vlg1UjgIsstesFDcCyNBua1QzH1TQUZF5wx4GTdzt9lVRRezVjfgFwv25O0w 51BrU0ZXUEMJ22ato7ZJ+CcPQzKAbS+YyCs3Vws7YFu0XA5ED0NMDIOVcAX6 nutPkkcw0FVU5i9OVkOmDrl9TlVQR4dERU4kG9bEsEknZE4nFGyCG3ZVTQt/ Ygv7DUvyMzIWC0xVGDSX7DcLQVAlGwqehCc7KsNNUEbLTU9PYIY22/hWjkAF JLY/c9tMF0vDF09DS0RPgjK2cFiJGUNKAkkLD6GVGuJFLklGslth2EFD3FDD UFCizC05WA85NTcrb2CFlmUWKw83azhgK0JNeVBjC/ZoNVhTOEk6NhesxeRy QVBQqu6xDWvxRlCzVAstHvZIhwoAIklSVV9GLb3BShWENTMtNHmbzZZ7Dw0b QUdOo9QaAWo0SxEpmGNZD4gMSV1LQntFTkdn63D8X9SGvQlCC0Tq95JNvr5O RVIzDw4Le8sabUFXKKAbDw3ZEro2FVxU5w9GQH6yG0FVRElUnWsLpVtHQtRJ oA+CIxgJ1WKnMaRu2URXD0l0MLMtm/4cK1A3y75Z4VAJGQtNP5kGVmohC09h OdjAlj9LO05U8lsSLkvfC0dDVFJMjaaADUU3uVPHZI+NZDO3T68P3W5L/lBW WERXSV5JLUhPSk0IuGBf+QNflgzYgLxfrF8ataAB400fqwFoaQBsTkVoTapc FOvsar2EnR9zEw4nxFmVqyoAMP///998wXHtruM49RO/THiIAObdgpojvd4s yGhDX8088rr/////Br9RqtAugJKHtgDUWxHOO5C/vw9BEDJdsWmwqKVypERf 4P8vnb5sKdglU/x+pj94koJxATZW8//////sqtzXf1fhsGpjwvSuHDOhR6ip TkwOqySO0WOBjNZD3P////+mdFM/I2+dSCHAi7787ZyGVLgkdL311mTSiOO/ Y74I5f3///9jpyV7GG0Nr2ImzsJAGTno8yHStWbQiRscaI7rOar+Q/+/LZCd FcFbGiOUtGRF1IFHl7/0qyUtAjaCjbM2ui1srS1UF+4qCQoDKKYcNbUpOmNR VmiB+wSYZ2UHkc7I1Yxil/tzZ9VXpnGbdWtUgIfbWqgDRQS/hAGDDOfjSZ0A tG5vOrMesBKAG7gjcEMAHwy/gKNKfWMvQ2zsigLwuV99cy8SDCwsgFcAQio+ K8BnEytjQ0QtHAukYAIwM0dwXbXYy3wnIRGCIwGF+xNkTd2ivuZ1b1FkmSBQ bBarUmf9HGyAFgQbZFNCXQq2Jjd2EC71YnVstDO3J2QcG1dIlnPrDABD2Bsg SpYGNmwxFxbDAN9hS8MKAgALP0M/DLK5d0pJMzg2Bgc0NRm40Zo2sVI0/MGI md4MVU5LTlp403fXWmvPpxfIBiclLieM7NVscyeXOhWj4GpTB1wqD7EfZF/B 7jjFN3PqLQTKbbKC+SA5MjaH1iYD4wBLR9Z4GAAHizdhCjw3AQmdhJ/ggzs4 XsQ1b296Bql7CWFhADqPL29pTfeK5wM0ZwNkaz1M0zRvc2aHW2AgA/fDxyUg XKl+I8h3RwNNd2SO0wu4A7CoNE3TNKCYkIiA0zRN03hwaGBYC8EgTFCfRW6Q qXGgZ58RGWvE1zA3q49wAAdb12rFe0SUcB1zIthhADtzB3R2UpxfC28fQxwz TbBKZPNTP2FktKK99i5A3geuwtcwf1dOVUxTNDBDcAbEiFuMLvX7SCxFU3tO Qk9YM01NRR75a0wHTkNITUJYJyOPLaNMF1RCQkQqExE7wC4q9xMwEPCePwdJ TklcHHQRWpX7gwdvODCgQYOHPwG+PRWsc19MZm9AQOsLQwfWJUic7bbWoEQT XOJkdnNFiY8zX/+tD1CDQ0CCQFD62PWNACt0NiNlc2IRW+6gmhk65nvfoTVt DZxbCiMDBxTlsugDECefgn+7cEBCD/uWmAzh9QUAypo7xa9vqH4iYW55IhdS TiSiizC6okFoB7YRWq2PQYRSIws0FgoMtyB5P24aFqJALFlk0ClzFGgoa0Qf 5hroDXMrUxvzDHRkM1QkVZfWTg/kKyxhKiHbooko0XArIinO9sEe50EfYm94 LRhsIxZ2KEcpE4SB9hDwemFdGN4nJmRfWEbCO2sRJyrSWB4jqFCQI0k7Y4sF FPqcXnUjvDdZRDIpG4oStTYYHyAGGo9amdoakFYjqCuRizaiIKLTPs1keCkf ysv8E9FM7nBvaelTBVXbZrgyLEU7oXgjdil7RGusJkwjDTvUVq9UD4PFhl3g XBp2NsDPGuWlzwAHZ71ncmHVti0Y4fzpUXcHaFw9NNgrYRA/RyEQHhShk9G2 lN+1MdNYk2V5AEtFWfm1rRQUFXVi90lHyu7RRT9fJjxuc0Wx3sB/G9cgb+2h kmhSsqNTRE65ZH9vDwdYMjUWCxsZNmo7DiBHwFOr5A6JIJIADM1/0hNNNLVp SHBvRKZwLltpMUUthuFrG1MPhCXj1xRnPE1YR9thjgrGTYNWGLMIdiCXGxvp e4cJh7zM8nf7ESNOoi1Sc5ltodGFlVcuE3UjtdkrWNuXlyF1UrDtS3tSD2Bt 15J0D4oAq0cL8NRRDwLhOmFTK7SWnavaZk8RBl4E1E5ntcoNc89jyRMabEhy llNGH2SRkmKPQOtLuobwCoZReYYACMboEJtBs1k4Q6PQ2/3vIxtbrhgLgUE8 onsJ7i4fagAjCiIJIrttdHAoiDKAg1EAGZCdAqhAQgVQgYQKoAIJFEAFEiiA CiRQABVIoQAqkEIBVCCEAqhACQVQgRIKoAIkFEAFSCiACpBQABUgoQAqQEIB VIGEAqgCCQVQBRIKoAokFEAVSCiAKpBQAFQgoQCoQEIBUIGEAqACCQVABRIK gAokFAAVSCgAKpBQAVQgoQKoQEJEgBGEmoX8TwUEAEgARgBOAE2GQBTxTVqQ lwgaqijRuL+7Ss7CQIAEDh+6DgC0PwG2/AnNIbgBTCAALg0NCiQh/+VgV1BF TAEGAByRXz3Pmu3b4FUhCwEFDAgKE6AV74vcdQQQCSAAAAsCt13SzWYABwxw ArphC5spAwZHZlgOssHoPORg9Ci7CinOeFc9gSJiLthWBpsL+4KQ6wR9IC5y 2RgVEcFmEGy3sLPUDCdqQC4mJYM8WyfkMA6MzZ49wC5pKHwBECcQyOf+lVNI QVJFRJYnULP8UzIS0C5yZWxvYzgQUzLIYBRCqggRJBHGG2+K5moBo8QyEFjC VzqsiqDFU67vIgLiCFYPhWIdVEDN9vZFE4AJVYsgCipb0JC7+11HYoidM/87 8A+PXzIPhEIFludzu4P+IQ5QATQBEaMsb//vK3R+i8aD6Ah0bUh0VAcDdDks t3W/zVYtND3MgBAyhAzfbtN9OR0EUQALeGi8F+lgCbg834A9Vh9YFbBA8z3P gEKoKgmgDcgy2SBiESEVW/7c8yKY/augEnReRZvuZZdlHweRASvpAU5gyyGf kNEBFNIiM2DPM8aIrjiwYMskz4CYEpkiM2DPM414dRV3EP03z3BfjUbeg/gM D4f9e7djUdOoExc5NUsoFnsGbE40Qmj/FQPyPAMsYBQWeS75PFj+AABQ8jQH 5OjqAEjSA/I8A9RAvL48A/I8OKaoMN48A/KQkijrfWggv5/9/gZ2OQXVdHwh dHRoGBZfuKKIbriRKWt0QQKg9pB7qEAXqBgWjL8UF8x2qv4arC0BdcF+/+8L gL0fIHMCM8CInAUL6yNg3Yd9kBsTaBAwSFDorf1ZMFuEs1kNiV8Tkw7roKgc ViSC2GdDawNNLlk9czw+xPe9c2iNDaEhjTnsw7cmUERI/MQMQj+oYtOkAWh9 F2ZzJyG8Nch0wqQjFAS567ZLC2bZbLcSDfURA98hEk2aAWmaN2Ozeb3e35Pp I4zbo+LDiw1oR1XQ30tWV4XJdFirgAr6fTvPfjK+mFdWFS5meGCqXK6iVcxc Veq182d3EcsVfEAVx+seUWjoHZCxMHmDJQgLr6GI7KG7KnT72tiGEp6cQAoH HRQAJIBeoQWEfg8fKzkIZgsZdAXoxM3CwQwTIGoAAcRo2c22iQ/kagJHoDPJ o1kZ2dz/D5XBisHD/yWAFAWEeEAtF6zMAPO1/ttMBeLy0DDJfjFJid2fscUK EJQUixGJFdQQdQuR7cVTaMHgiCrccw2GY2F1BnNxxxvi3Wy+nxRoBAQAo9jo FwEefG/PGFM1CECjCLj+7yNL9zV6QNx0Nos1L1FDUdCD7oQVNjsGQMD/0B4U 3nuyPXPrUX6QxwUWcwCAtslMkABTPOzYH4gUhfZXFXUT13UJ4GJVVUkmVlig 3c8ci1wkawFKBPfCyfYCdSiB4AXeU//Rdy1zpl0MCOjfIqA5xo1d+RT6+TmL 6H2F7X75/p7tV1Ant/ZLA3UiOKaH97Yxje0idBChXNmCm317XM7oX4vFTq+N iMgqzIz/2eghlXtQIIYBm2b5BQMoIDhI5hO6rlkuTxR93AtWE1pEFKbpA15i FUQxSLVsZBBR/PRmZ2QlfyAi42twC3tzY3JsfXd7n3cHbmxja2RlDgdwchnf 3pFdfQ93bnVwBidyZ2h0jhUmP2xmdPoHZW59sZFPaG9taTYfdZDvQY4PYWxh dXNvY8mRv21lZn0nY3RyYnNs5GyrtGIXbAqrHapAeGhpfe9gQKADlpcLDkGc t0DAgHMyy0JBw9M0XZcbOAMaJGLrzjZNVk5sQSPkO/oDVmWbprTQxkA7L8GN Ld5DPWxOQEhvb6KK+O1rRXgROgJUb0EAxf/vRAAGAUdldEtleWJvYXJkhHtX ByhlvwJVbmgpHmwWUfg0JQJTRNES1ikSdv7H2lSgMzLCAJICbWVtY3B5szWW N4y5AnNs0Am1AVC8sROTHUDx7D9CTVNWQ1JUM1kCIm6PBWMLAV9YaXSBaxug DACMKa367Qs1I5ohYWRqdUJfZmRpdrgACCsjEPT/f4zfBzCIMJUwoDCqMLUw wDDLMNYw////L+TrMPgwAzEkMS8xOjFHMVIxXTFoMXMxgDGLMZZL////MaEx uTG/Mcsx1jHhMewx9zECMg0yGDIjOzL/////OTJEMk8yWjJlMnAyezKGMo0y lTKdMqQyvDLXMvYy/jLo////BTMfMzwzXjNkM38zlDOaM6gzrDOwM7QzuDO8 ////35czxDPIM8wz0DPUM9gz4TPoM/0zDTQaNCM0MDQ+/////zRHNFA0WzRl NGw0dTR/NI00ljSbNKM0qjS4NL40xDTb/////zTmNOw09zQENQw1ITUmNSs1 MDU6NUM1VjVgNXU1gzWMIVG/1DWzjTU1NlI2nUwxUBDEj+GAfylLAVNsZWVw AM2imFBFegAoRqhNARSu/RAYSGFuZAURKigMACEOCIo7p1RvTEwEFLNhDjsq IvYedjoOov09ietFeEhsb2ItRRGpKi9oA4tQfCILYncAotVUb2z2vwGChDMy U25hcHNob3QZqojZH0V2ZW50kEIVxSxJhFgEFA8BRHVERbl0s6OJU0xhbbMH ELxlVXWSFRWxokmb2GzZ5kiVaUJjDhkAFC9lD727Bwt5b21tY0xpbhBChNm7 DXB5HxsNCcFKsEspcHWQO3PtbWt6bGkeaXplaQkp2517m6NjiKwUb2ZSd298 2c1t1mM8R2FkDUZpbrcSHJJ8731ickHxYguieWaxCzabRQw5HJIKilkwblhA OKS7QaQUtlvbHldhk0YKiW5nzU+SPQooSRRZkIAohRaE1p2EKlRoBmQNMugK rRCvqMg1bGzhbCy7QQljBGl0CRsnDB5DCnOr8GIHN1JGRCUIJYw37A9lD3LM YoeBRhpKCsVaMkOgLw6P+bA2mw+KTpRweW4MhTY2HnQRM6r44UIQ9hdza2VT cGEoGu1FcRIgfByWOQoZ1TStcJg1yGW57HQyWAhWcElBWjZs7GCIoO3/d1gZ W7cJTNd2BGsPwWHioFREZVX8ccocJ0VuRjBVbljY2b+IcFZpZXdPZoNNDm2T dUs/GHCWVERrcSC9tq11Ug0kVC3pBEBIAyQh2bYRT+9uDOa+D9g6ZTLR0wG3 Z/idSvEnAeRTVXMbNnPJ9ByGHhANa+22UXUeeVbIBhH2DgkzrA/SMWVUUJjN 3iwBYrMDc3WuQRIpvTcrFB44DogN2ZL0gh0KOUzmGQqFp0Bf4EPMa/+soQmT Zf1fX21iX2MpBhttWHdheA1wIEUZZrGm1noyuwXPYzTjuVZzAgdKbg4OSAUU 3SJjYwRRFN5mCyPo3jE2yl9o4nIzX0pfGTE+a4hfWF9mdMKXtxSuvR8ZQeFk HdlZQIq2G2YZ7rXb9mZmbBhoB2FitTY/6S20s2l+Z1/lZIcR94CgOHOzu+c2 1wo3ewdyjBY2K2YzBn1wVbzZZ47uTGx3cpQWmJt0VkcB0SZSvpnbcF81bm8Q az9hVjD/71Q/PzJAWUFQQVhJQFr2PuecW7pbc2sGn0oocrQIM1MQynSbvTFn I05lbnYI05Va7PRmd2EQkBnnmm/L9a5pZjNYZ2ZH6e29rBtQQ3h4t3gNhd8s WBJFSDqSb9ZeK7hnJvMWupYQaYQl0AAuOWTg03OF2Us36UuLbtJhATpFyHAm dnZnCwR2yXMGcHWMXwYAxTGWVUFFV3sY40BYWgBpnljQY6+1wd50jRJh2p1i s3FTe3f8cnJnc53x0BrbZlQCQ2gQVScxwtOmYIR0YWdMd9FsmaELClBSGDEy MNuYQqpmNbYGM2haR3LmZAEM7fBMA1S/NLkEm/SgAti47A6BmOwtLg1EwGZ7 4IRSdXKq/MuybJuE/zQCERIUcCzLsiwDCzMID7Isy7J0Cm8EOcuyLMtzFwkC DRURy7IsDBATAf0lPyCaBABdRZcPAQsBBiXiWNMMAQUTPtdeEzGDOFOab8lf SRDwBgAAEAwTBjGwEAeJKOLyLQFmjDfQcBaIWyCw8lfsAvgir5Ka9wDrEA12 Coma4BP7IHsIiZgHmpScBSdtSppmMFAwwE/2XotaDCXr80/v1lZygHAboBoX AAAA2ovoCQAJAAD/AAAAAABgvgBQRgCNvgDA+f9Xg83/6xCQkJCQkJCKBkaI B0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR 23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D 0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz/ //9eife5fwUAAIoHRyzoPAF394A/DHXyiweKXwRmwegIwcAQhsQp+IDr6AHw iQeDxwWJ2OLZjb4A4AYAiwcJwHRFi18EjYQwZAAHAAHzUIPHCP+W8AAHAJWK B0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+W9AAHAAnAdAeJA4PDBOvY/5b4AAcA YemhyPn/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEAAABYAACAGAAAgAAAAAAAAAAAAAAAAAAAAQBnAAAA MAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAASAAAAHDQBgAAFgAAAAAAAAAAAAAE AEgARgBOAE0AAQAAAAAAAAAAAAAAAAAoEQcA8BAHAAAAAAAAAAAAAAAAADUR BwAAEQcAAAAAAAAAAAAAAAAAQhEHAAgRBwAAAAAAAAAAAAAAAABKEQcAEBEH AAAAAAAAAAAAAAAAAFURBwAYEQcAAAAAAAAAAAAAAAAAYBEHACARBwAAAAAA AAAAAAAAAAAAAAAAAAAAAGwRBwB6EQcAihEHAAAAAACYEQcAAAAAAKYRBwAA AAAAthEHAAAAAAC8EQcAAAAAAAEAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQ STMyLmRsbABNUFIuZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXU09DSzMy LmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9j ZXNzAAAAUmVnQ2xvc2VLZXkAAABXTmV0Q2xvc2VFbnVtAAAAX2lvYgAAU2V0 VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA ------------49OP8AW5QHG4B7-- From greearb@candelatech.com Tue Oct 8 18:11:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 08 Oct 2002 18:11:40 -0700 (PDT) Received: from grok.yi.org (IDENT:n1YMitcmE6OwAV6mUGGMvSP4MOSKZpl5@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g991BRtG027778 for ; Tue, 8 Oct 2002 18:11:34 -0700 Received: from candelatech.com (IDENT:hb9MOT3MrgepS9WjGNxLfyYF1rWODNVz@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g991Aiq18715; Tue, 8 Oct 2002 18:10:45 -0700 Message-ID: <3DA38214.9050607@candelatech.com> Date: Tue, 08 Oct 2002 18:10:44 -0700 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: Andre Hedrick , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) (problem solved) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 589 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: > > It does seem like you need a lot of packets over a period of time > to recreate it. So if what you are trying to do can achieve that, > you should reproduce it. How many connections and sessions can you > support? BTW, does iscsi call for a zero-copy receive? I ran it at top speed for 4+ hours today with no problems. I was actively cooling the cards with an extra p-IV cpu fan sitting precariously on top of the cards. So, my problems were definately heat related. I have yet to try to see if the same things makes the tg3 nics behave better, as they ran even hotter than the e1000s. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From dfawcus@cisco.com Wed Oct 9 09:00:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 09:00:47 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99G0itG031413 for ; Wed, 9 Oct 2002 09:00:45 -0700 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA10091; Wed, 9 Oct 2002 17:00:18 +0100 (BST) Date: Wed, 9 Oct 2002 17:00:18 +0100 From: Derek Fawcus To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021009170018.H29133@edinburgh.cisco.com> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20021008.000559.17528416.yoshfuji@linux-ipv6.org>; from yoshfuji@linux-ipv6.org on Tue, Oct 08, 2002 at 12:05:59AM +0900 X-archive-position: 590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Tue, Oct 08, 2002 at 12:05:59AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > Hi, > > Prefix length for link-local address should be 64, not 10. > This patch fixes prefix length of link-local address. > > Following patch is against 2.4.19. Huh? Without reading the kernel routing table code a bit more, I'm not certain what that change does, but it looks as if it might be changing the connected route for a link local from fe80::/10 to fe80::/64. I'd actually say that is wrong. All link local's are currently supposed to have those top bits ('tween 10 and 64) zero'd, however any address within the link local prefix _is_ on link / connected and should go to the interface. i.e. it's perfectly valid for me to assign a link local of fe80:1910::10 to an interface and expect it to be work, likewise for a packet destined to any link local address to trigger ND. DF From yoshfuji@linux-ipv6.org Wed Oct 9 09:54:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 09:55:10 -0700 (PDT) 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 g99GsmtG032303 for ; Wed, 9 Oct 2002 09:54:50 -0700 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 g99GsXlw028266; Thu, 10 Oct 2002 01:54:33 +0900 Date: Thu, 10 Oct 2002 01:54:32 +0900 (JST) Message-Id: <20021010.015432.63506989.yoshfuji@linux-ipv6.org> To: dfawcus@cisco.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021009170018.H29133@edinburgh.cisco.com> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> <20021009170018.H29133@edinburgh.cisco.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-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: 591 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 <20021009170018.H29133@edinburgh.cisco.com> (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus says: > All link local's are currently supposed to have those top bits > ('tween 10 and 64) zero'd, however any address within the link local > prefix _is_ on link / connected and should go to the interface. > > i.e. it's perfectly valid for me to assign a link local of fe80:1910::10 > to an interface and expect it to be work, likewise for a packet > destined to any link local address to trigger ND. First of all, please don't use such addresses. By spec, auto-configured link-local address is fe80::/64 and connected route should be /64. If you do really want to use such addresses (like fe80:1920::10), you can put another route by yourself, at your own risk. We should not configure in such way by default. and, we should even have to add "discard" route for them by default for safe. --yoshfuji From dfawcus@cisco.com Wed Oct 9 10:11:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 10:11:32 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99HBQtG000410 for ; Wed, 9 Oct 2002 10:11:27 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99HA3JS004114; Wed, 9 Oct 2002 19:10:04 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA14471; Wed, 9 Oct 2002 18:11:11 +0100 (BST) Date: Wed, 9 Oct 2002 18:11:11 +0100 From: Derek Fawcus To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021009181111.A23231@edi-view1.cisco.com> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> <20021009170018.H29133@edinburgh.cisco.com> <20021010.015432.63506989.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20021010.015432.63506989.yoshfuji@linux-ipv6.org>; from yoshfuji@linux-ipv6.org on Thu, Oct 10, 2002 at 01:54:32AM +0900 X-archive-position: 592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 01:54:32AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > In article <20021009170018.H29133@edinburgh.cisco.com> (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus says: > > > All link local's are currently supposed to have those top bits > > ('tween 10 and 64) zero'd, however any address within the link local > > prefix _is_ on link / connected and should go to the interface. > > > > i.e. it's perfectly valid for me to assign a link local of fe80:1910::10 > > to an interface and expect it to be work, likewise for a packet > > destined to any link local address to trigger ND. > > First of all, please don't use such addresses. Why not, they are perfectly legal? > By spec, auto-configured link-local address is fe80::/64 > and connected route should be /64. Yes auto-configured have fe80:0:0:0: in their upper 64 bits, but that is just for autoconfigured addessses. That is a seperate issue to which prefix desinates link local. Connected routes don't have to be /64, things work correctly even if one picks any other value. > If you do really want to use such addresses (like fe80:1920::10), > you can put another route by yourself, at your own risk. No - what I'm saying is that all link locals should go to the link. There is no risk inherent in using such an address or link local prefix. If a mechanism is required such that autoconfig generates the correct type of address, then add it. But that doesn't _require_ that the connected route be /64. I happen to use link locals like the quite often, since it makes testing and reading packet traces a hell of a lot easier. > We should not configure in such way by default. > and, we should even have to add "discard" route for them > by default for safe. Why. In what way is it not 'safe' to have any link local address sent onto the link? They'll either reach a destination or not, but given that they'll never leave the link, they can't be inherently unsafe. DF From pekkas@netcore.fi Wed Oct 9 10:17:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 10:17:08 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99HH2tG003291 for ; Wed, 9 Oct 2002 10:17:04 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g99HGeU17944; Wed, 9 Oct 2002 20:16:40 +0300 Date: Wed, 9 Oct 2002 20:16:39 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: dfawcus@cisco.com, , , Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021010.015432.63506989.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 593 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, 10 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article <20021009170018.H29133@edinburgh.cisco.com> (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus says: > > > All link local's are currently supposed to have those top bits > > ('tween 10 and 64) zero'd, however any address within the link local > > prefix _is_ on link / connected and should go to the interface. > > > > i.e. it's perfectly valid for me to assign a link local of fe80:1910::10 > > to an interface and expect it to be work, likewise for a packet > > destined to any link local address to trigger ND. > > First of all, please don't use such addresses. > > By spec, auto-configured link-local address is fe80::/64 > and connected route should be /64. > > If you do really want to use such addresses (like fe80:1920::10), > you can put another route by yourself, at your own risk. > > We should not configure in such way by default. > and, we should even have to add "discard" route for them > by default for safe. Personally I think the interfaces should be configured with a /64 but there should be a discard route for the whole /10. -- 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 ems+F2ETWB4MTTSKEH@bounces.amazon.com Wed Oct 9 10:48:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 10:48:45 -0700 (PDT) Received: from mm-outgoing-110.amazon.com (mm-outgoing-110.amazon.com [207.171.188.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99HmdtG004013 for ; Wed, 9 Oct 2002 10:48:41 -0700 Received: from mail-ems-104.amazon.com by mm-outgoing-110.amazon.com with ESMTP (crosscheck: mail-ems-104.amazon.com [10.16.42.233]) id KAA-21335390-28204; Wed, 9 Oct 2002 10:13:46 -0700 Received: by mail-ems-104.amazon.com id AAA-21335390-25986,1135; 9 Oct 2002 19:13:04 +0200 Date: 9 Oct 2002 19:13:04 +0200 Message-ID: <.AAA-21335390-25986,1135.1034183584@mail-ems-104.amazon.com> X-AMAZON-TRACK: 21335390 To: netdev@oss.sgi.com From: "Ok2mail.com" Subject: Offerts : 7 euros sur Amazon.fr ! Bounces-to: ems+F2ETWB4MTTSKEH@bounces.amazon.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1202 X-archive-position: 594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amazon_reply@ok2mail.com.sgi.com Precedence: bulk X-list: netdev Faites-vous plaisir! Ok2mail.com vous offre un cheque-cadeau de 7 euros, a depenser illico sur Amazon.fr!!! Valable sur tout le catalogue Amazon.fr: Livres, Musique, DVD, Video, Logiciels, Jeux Video. Uniquement jusqu'au dimanche 27 octobre 2002. Profitez-en vite! Pour cela, notez bien votre code de cheque-cadeau: CAWX-KTWQ8C-V9AEW6 Vous entrerez ce code sur la page de paiement, dans la case reservee a cet effet. Cliquez ici pour en profiter: http://www.amazon.fr/exec/obidos/redirect?tag=gcbuon2-21&path=tg/browse/-/405320 -------------------------------------------------------------------------- Votre cheque-cadeau est soumis aux conditions d'utilisation a consulter sur la page http://www.ok2mail.com/conditions_amazon.htm Important: ces cheques-cadeaux sont limites a 1 par foyer fiscal et par adresse de livraison, a utiliser avant le 27 octobre 2002. La livraison est gratuite a partir de 20 euros d'achats en mode rapide en France metropolitaine. Vous recevez cet e-mail de la part de Ok2mail.com. Si vous ne souhaitez plus recevoir d'offres speciales de notre part, rendez-vous sur: http://www.ok2mail.com/amazon/desinscription.htm [[HTML alternate version deleted]] From kuznet@ms2.inr.ac.ru Wed Oct 9 12:06:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 12:06:19 -0700 (PDT) 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 g99J6DtG005942 for ; Wed, 9 Oct 2002 12:06:14 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA20130; Wed, 9 Oct 2002 23:03:29 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210091903.XAA20130@sex.inr.ac.ru> Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses To: pekkas@netcore.FI (Pekka Savola) Date: Wed, 9 Oct 2002 23:03:29 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: from "Pekka Savola" at Oct 9, 2 09:45:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 595 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! > Personally I think the interfaces should be configured with a /64 but > there should be a discard route for the whole /10. I agressively agree. :-) Alexey From jgarzik@pobox.com Wed Oct 9 12:47:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 12:47:16 -0700 (PDT) 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 g99Jl8tG008707 for ; Wed, 9 Oct 2002 12:47:09 -0700 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 17zMnO-0002HP-00; Wed, 09 Oct 2002 20:47:03 +0100 Message-ID: <3DA487BB.9010007@pobox.com> Date: Wed, 09 Oct 2002 15:47:07 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcelo Tosatti CC: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: [BK/GNU] net driver series 9 Content-Type: multipart/mixed; boundary="------------070701080306050109040006" X-archive-position: 596 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. --------------070701080306050109040006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit mostly natsemi bugfixes and cleanups... --------------070701080306050109040006 Content-Type: text/plain; name="net-drivers-2.4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.4.txt" Linus, please do a bk pull http://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: drivers/net/natsemi.c | 867 ++++++++++++++++++++++++++++---------------------- 1 files changed, 488 insertions(+), 379 deletions(-) through these ChangeSets: (02/10/02 1.731) drivers/net/natsemi.c: fix compile error - s/KERN_WARN/KERN_WARNING/ (02/10/02 1.730) drivers/net/natsemi.c: boost some printk() levels to WARN (02/10/02 1.729) drivers/net/natsemi.c: cleanup version string, fix compile error (02/10/02 1.728) drivers/net/natsemi.c: stop tx/rx and reinit_ring on a PHY reset (02/10/02 1.727) drivers/net/natsemi.c: janitorial - whitespace, wrap, and indenting cleanup (02/10/02 1.726) drivers/net/natsemi.c: comments update (02/10/02 1.725) drivers/net/natsemi.c: lengthen EEPROM timeout, and always warn about all timeouts (02/10/02 1.724) drivers/net/natsemi.c: write MAC address back to the chip (02/10/02 1.723) drivers/net/natsemi.c: stop abusing netdev_device_{de,a}ttach (02/10/02 1.722) drivers/net/natsemi.c: OOM handling (02/10/02 1.721) drivers/net/natsemi.c: combine drain_ring and init_ring (02/10/02 1.720) drivers/net/natsemi.c: create a function for rx refill (02/10/02 1.719) drivers/net/natsemi.c: add dp83816 support (02/10/02 1.718) drivers/net/natsemi.c: sync with 2.5.x --------------070701080306050109040006 Content-Type: application/octet-stream; name="netdrvr-9.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="netdrvr-9.tar.bz2" QlpoOTFBWSZTWZNLu1UAaxh/l/78AgB7//////////////8AgAAVIAAIAAYI YFd++774RSAKSSkr7nVOwsX3u97u6yFH3rT53330fe9699vd92+7FkYPtgAK A3segACEO5PrPnl77vIGhKmO++Xz4CB3fW4bV1X3ney33WVvr3euHoOmgaNb y69VTtaOs2fe56901BdmjGbQ1dodg77m71vr3nkhvsPQoXtfc+vPeX3DF6L7 2uhT3N6sK97zdrvt5dMfc7s0wU1VdO611zranbOxTm6+vt9ee7YDeRui016+ ZnVLwN77zuz3bNl74Pu8+vez3tueHQTtNej3t9PqUX023s0Pu570JIhNNACB MTIE00GpiTDTFT1PaqfoJ5KPRPD1U9TJ6TJ6QeSAGEpoEIQITUwqe01PRoTI T0yGhPUGjQDEAaGmhoAAAJGlJFSPUaGg0aGmmRpoBoAPUAAAAAAANAAEmkkQ QIaaCZomqeRNHpqfqj0m9UPSBo2k9I9RoD0mhkaAAACJIhGIJqp+amk2JM0F T2oyaniDSeKZPTTSMmmJ6DUyGgaGhkekESRAQJpomCDVPRpgJiamCaap+lPU 9pT1HtUfqg0eo2ppoBoAB/F/Srp6fT5fP6O/zX8/p9N7YendrYXO1jcrTUIB BQm8UV7YAdQBtc9+yqm602WmK5wYSW3WWoZqQzNGFjKma5q7IMzMTbzEPUeL jM2+4JJ0FKQLYiDIIwtoRkiEiikoWpIAk0CmsIIRQGSWDJsw0kkhPND2tktw KtkX24YS5iIstlbLbbajGlUslii21ViqLWjaLBCrFjZBsJWStVC6b+mfaySs 2lSgiKixFERrLUq21ixqqq2WpQUGqtKxa2UpaMQVFVbbVg1RsiWwKwu6DU1A 2DFNDGKFpG0IuVVUqiKoKoiLFFUMRlzcwE+LaZtdq0zRb+Tu+n6fyfzusDnx 5cqXKGEFhWjLzxpAPeLw5jUKYTLAtk1HIu1pbNYFzFTWjYDLSO0w5G7plrbL yLQt5EqbbGc1caNSUxraUTBaYrTCJYWWDkNEsxrRKNTbW4u2FttRVKJjGrUq JaW0BhphLGzW0obIXZ0aA0cirWKkoUoVDGJi5aYsLAtgxG0plCC5XSGrqals tDbUym2dR1MmLqXOkNvnQ3hOSyICk2IMA2YcGODLJYx06yYTIjl604HHjVzb jNqto4eJwpil5mtFTSlhtiqOjraJQaagrN8c8I+t834iTCHWn4Wc+a84W2Y4 hlLgkMZ+EJHBSTVlCoiVka6cBRZAGOUGpUpYOXMbsmy3KIuuxhRxmo41utjm FdMU0uttsmKFJdGFiiMigzEKhRSxrg1UpkmIIwBVEcxxEUyDM9MmExzw3GFr Z5F3G3sUbs64ubtLsNMZGo0KMS2skEYRPAWSSGnWoK1tDC5klVIyIMSLIWwa pYCCsKokoJhhEKFwXS1xry95LDnOtMUluqUBNTENsgNbKraJcaJlko4ZcREY jBZGAYhYhbZCx10XFmZQyitKWkllCoiU+oY/z04wdRifZ/l9/0/gPW++EbD4 JehnYug1wRaLwPiQ0hjBG9yb7jxWMkIdtSShiUOQk20w7uPJm5ansEkxyeWS WzX+GQ9aztsf0+8lJ1n83oN+37fD0eKtY2m5aK40fq9R4p2Xz5t/qa4YLuLl M7MpeJtRw0eZzCENdOkPbqLQOgjpGcXxvAm08lTiWcM1dByQqTZBZrJhcLhl sQSCUUmIHmYJQFoEg8fV9P09u8HXci9FeM/fRYx7jPe53dCIcZChD9YeV1dy Ekq6o63qQO2rzhQHv6bpvHxBrQczTsmrdnPEhiJt60Nasss33jld8sttOW2p uu2ysiMUdZvrU1dZt06x01rNF2yC8BGGyyhXZPRxzY0lbUFBu1o4xmuA61iJ hXWZrV1MWJFGJA4JBQCsG0rEls1mswr6qBRtpS01GuNNn75T/gmvZJC9bdh6 bw30YVDhSW/sKlpbvTNMzCTodJ/7U7aUibo44lLpNVw2brcym7lvmN5PB4Qs RP1O3Gt265NpmHhH7usWE9oUeKZpEGkaNS0C993u5jvscKrfP5sKNnViPWmh VeCuTEkidJgWj3RbMkJHC+/7wu32uXd/p4Ot/DyH+VX8rRLydvwdvr9rcO77 PgfTt5Hz8YHPzwhk6qD1RgMhoTn52fdgJTUZ+O5rb82JafWh0BCEhkGXWztc KM4WiszTmfeT1d/6HL6/OO1D2sx5TnW8qhWtrkO/pNret0aw6lLE6N1cVnl+ dwnoXVFvq1QLaVQj6fogu9pia0bWJy90yZ07Q3MSyMmvtjT6zI6Q7lXgmnar p3hiopCkdnZMz3GSbBYtipse+3eulProwfdYeHhvgbO6bJo/YlMnDSDx7E5M 3Z1BeXDZhPjt8Lwx4uO84vvsRb4dvY4lCFl9TBbtUfRc8hmi0M1oQlXih2Zq Q+E4n5JhSF8h4s/Y71uCi7pELCI/dEgKYxxoEmEhEQC5UzeJd2WjKITIUYdi HoHZKUNMu4hA8O2ED04QWb/H83r7dV8Nv9L8mjp83JdHcTPL9/SNCJo7Yi6d SznqITnGzmaLjDIkXN3bVwQNadOy7lufYsJTSWjGHnZ2ioiRiLQZm10Ga3m/ 49cZUfphwr1Iq59/wEoF0lyMAjoud+E9J8T1/gQ/aYjo2EePHk2PatxF+mz5 lAkJCR8So9G1B4L0UzrYT+3w8qERpy1l3wqPU/111R1VpYdkzs7u+J1qaEu9 Y48Y9GH1eQURT7IyfSW5neitJprbDX+Ivr7guUrEF/aqAyWgiHi0hAKWEbD2 zzSEm2MSE2ECA1SoXgIB7zf9/TcFc4oHiw5BMpaFgsfpN8MwjIoUEjs6sSO3 uKG3437pPX1+egntMeck1LG6xCvo76QM4GED74JjFDpVPtViJRCQFPYQnWQ4 hciaEIWiX39tkbol2DDCBT921bJIP8/mc1SdYLyQp1DI2X44Us73B74qWYaM qDPq0Fv2eufyEf5/fe/s6OH0ya+XvMD2k9iIU7BznjHXXyqtGTlRCtytZhMc rhlGY0rvQ18pk7WEzgZoLPBsnr+ztMjiAZEMjY09O7gTJIqYsGaBfAmoE9aE rvL/jb/j3i9tiUMezzJJHcWjcccsb7QsdRMEpiUXG+oc/5EZBvvfxTHY7Qn4 one8MIHt7UiYwFhE3nwb85v8gEm7O5tY2zczvCEGZ2yhFsKyH8/Mj7iRTpg7 wq2L+BRZhI0NZuPOOgrmN46RIDJUEDAHnYBvgim46Sn1nd4CwmgZ6ta37bns ZH3VQUo1ttNDydclQvvR3V46521y7Fx1a6og6EwylQPYJpA9vu9EeP1J7jqH b5/O+kd3uvft/jo+zVoPbX5EY/RnTZKId1F7fNXf9Ey6UNJwZeFDEedr9Z0m ORvn14HNY8dV1TTRzzRdmKmQ2ntgUk9uv8xdzNYkHWs3BH8w4W/E8i9rVWeB /yaoB7ZFHrnkox+XonxQNaokChRcth8z9b5q6zJth8/qcxTUXMM42xeO+bHb m6l4jblsLTXsd3C8obxBObtuGEqZM06pz0iQZmm1QPV/LhdfDd832i04ev8o JfX+lAkHah3C4noTzkt8Ksw/dEIT3C/J8p/oTJqdLvGdOhQQUiQWSfQe2w+z AVnuBKPiKfUrAK0jmpXlRM5gl9OFRxCSE6a0tPyb1efZ1UXu+/7Pf9+ZmZmZ mVEy7zMzMRuN7pvzH29h92ex5zw7zwn2ePot5Z3dSQzSdYLb9y/7zienwkPD F9CRcvee8xuKheeh7B5re3xgrIf5nJbPVcYwpH74JnReM0kl8cY1VL9D4RwC wB1aKMLLQwGLQ/mTdbO1IPaEkUzndQKyeqmuJUuI1tU7VXa8crVbFK/4Ykid qqLh7NeDqBocxCekm8zsen1+0Pplvrq5XsuXWT54F6mJiFiJY+sj502reE4n l825jNPmTLJZdnguAxbPCB0zpISCIHlooqS5gwpHRi3LyEmWJ8/zvMcT4I/q 9XvYEy+goPkWFmenHynXYTb+WXzGc3bELHwUhemjSEnBPPbUvT6gt8bD7giS uOmG3PDbIXoojGEIQlkL+pN/P7NrYTHaOHcEF0UsIDnsutsuDv+KL71Q9C0d BduD8sH6cr0j5sg+wKEn2UasZw0wB9NwFBg29QpUCtixghqsv/hajvq57CKh RjMDEuAPQZB0eiasGMZDQCC9vPkzO5gHWcqugkknkUZ1g2/EPYVewZk2AJVG tioi1wSLJNqNaY9S6qlt5zX6Rg8GXK8MtNQ3mtVfK0e/1+BzD7MP1ydjsDVi n+3OiwTR39yWCxvxp4HHv4KG8flq5rk6mNEd7RTChyYN2Xo5f8a1ezDQxQh7 C/bAIfNZ3V1v0YigVrsYDWzMhmBgvhCOwIpUukRDqqbluqLGkUQZ7ms0GRcx tRJhto4uyNhq3GFoUuLFMrZNgr/qPA9Kzr4/UbPQ2nl7cYMjYtdUVnYvKQXc Je4ScPbRPUb3KZ3ywN3YvxMZmZNj19Z18cImSrJmwbKFnQyjbIkDVJhzZLXo Ev6vE+SyoxaH9cyuyr4IqJfIcqCrUPT7eO6UylrLQ4ulrD12xtUibM17Fw17 FKjY5GY9/TQ8ol3CUizkmyMZy4mThqTwhm+dXpjKFirETsNay5dV36PznYTH Nyne3X7sgzG6NLda2Fp9JJmwSbSpj2WYylxqi6MjM+Ax/Tu829F0C1PwttlP cSwNm/VbYWZhSk5S5Dxw6U8ByB7KsiSXcyxTI9S6uteOR04+Gy+1s3fDK7z0 OylEzGW06ywFdd0FLf00hxONdigrIKoeEhHpPYwLDM6HCvrKKTKw2ruF271e VYtfjAY1luh8/Pnjl+vjkKavb6bB+m/cWDwQJAkikg2UNrILvNDPan1yFwFE VFJlmY+iclTkiV5Aw8sxz2FfE8CZ89kgghgrZsdIO0Do/OJQWJzPWbbOrki0 vIo7N3vMSXHA/WkKnUSUTaIhjqRQidPjCbVxPaUktVPT+zqykFtnUu9YZxxe 8Osg9FxayGOr3s6goy32Ftvp+i4ZjhhXamOmzJr0VF7o34EO0jUQRZFWxJK2 RMpwnnNOTU2rLX0maKFa4HYivG+XcPUq0XWtWpi7+hPGtWEAh+tiZlhI2p3/ ibFBQMOScPpAO7oPVAGwv4rYmIb1euuUsmpxKvrD17QhvJKq22tSCbfB9Wek 0aUF2vrczvCzxc+jzZ6Jnl4+lrlvhoqdlJgbFfPkI0UwqQYM4OOGkB+u09jH 8m2FbKqT5LIzHq8qkR/IV/U1W75yyArmBVpjzxxr5TunUbWxi7DDw5275Fmu yyvm9RB7SE+N0FvG6Zhm5kOgYCQsrvb5u+bKH9Jo69HnnHRkSkvq9Nh5vrbw zM41rOCcmWFp9B3HfUFYMMqYz0XbatVz9ic50jrqJRxOVD1XVS49HLlfvw1m vVk97uza1bbFJBOg4lCbkItXZ5IxkhENk1FZU8IYpxF1uwY6ze6V+MjIvSDa rtXyfgbFsQx7hOQIOGrwxgBuGJMjYmgMQjnqNtGDJmEQNzqB99hajzlMuNgc UWBdIbhC5MdsZLvJIfJDK1bmjqlHstnnIrnc6Y9XDybT7VfQt8KYPEz4Zc9N PnIh06kmDOd6m9fXdWbEVMXL54yr1hyGNUUzWtqAJkJPrjUYVSDvjf3jrL9p qFJMM1JOrcyzLeHoKzOVyqyRII7TM8eq5iRYX+egPEXpDV5zWVkzXXdUgjkv qKsrpQCFZFOF72Iz5JkVKDx2RIQNTYkbyYOiIR9r2Fx6GmVnGjDSmordUMQx vD3jEg7fsyYYhlWQKjfIies3LrukFZRvS61HfYIcp8SS7FxsLWjbZ2R85VFy 7wnTu9EqI4h9z84ZyPPRVVUg3pARbJqZpbyxytrYCadTTTFEOxcZ1ltDfCi+ DZS80G6FQRHrwD6JSx3ku/R1RjvVsGVxDqm37281Z8sQciTGWy+W0ThBAsZm veHfazTcpQY2PPuem7Fl8bGjWb45nF4LVV7WKrho1OEbwXVIpG8l3QYpvGeo cRZPNpbJrPZnq15n+qtp5QeII8FtZt1xNB6NP2VHK5JhvhVLOJEJuc93nU9g cqeoN5dba6zdWh9IaiSLtVLDIhSmp65jltSxH8wMnoYs9wRys8LJ4sV1tcXE FBCVea4DPccKrbHCX62C2TtYdFAiasx4ZoAqCJrxKXpV1j9PhUUV+WxYKRXq nqLT4GC6fTfVS3PVCsSjJtyqGXNx1Oo/1Mb88OjpeRjzMCu0kJFJMIlRAEY7 2HXv7JDJskmzAwQMGAoPwZkMq0rnL0HQHTuR5tMEeZ8vi/PlGeydp5DpOx2+ o6BXifymX7cPn9+UskIwDhT532d9mPs/gwbX7I4e7jkYuOIP44z7R4Tsbp52 YF6N5LQGQf1w+XTJ+J2qWQbIlJEbPJ9n4T0w/AHyzzPcd7rYY42w8eWFdL5I KdHuUjVUnCIMD0Uge1xvIiRwKWKRRTxlRl8aCkO3JfG6Lr4Ak/5JEJNg/eCA w+35xVVqFKBOYifNFkeByKPxCKh4iBcVCediEIKMRi7iI9mgocb3GwnLw/n5 Dt25L8MTrB5wS4SQf3DHM+RAgWfaSYCjAJ/EIikvpPcOrK+/a2Flo7Sq/VIr NBgsNaB15GU23+KHAzK3rYoAD+ppVuHdKF1oaU90OiD+xgPh94c4eBT07fWe 404bx+3xW9Nbyd8MznnLymLS3GIMTdqq7v0rrqMI696EIjmx5WYOjnGH+4jk iveaEPKyAtJDiDgGzOCRJAYjDPWrNVCIRPYUITlO/C+VPL4aYw92911dSh3J Ph1Zx3HfM6MEFDr3igs7zU9dRPSz704TTCeLfbNoqQxpuYoZ5lRVg11xrhfY reJEMWXLlibXkt5M3jTJOSKpSiDG1xO23orniguUzQdCJpsm6Ma+FX3T9OuS PBdLrgM1QMNuYsyrqzYPv1y9uygplp9VWrewcyz7uOFC1Nc4WXazAcvrK2vV rlrSg6Jsipkf2PZWn2cvxmte/fnGYy8ikazxGe4O84ENaO38F3QG019X6ps5 +0gtTG05Pt17e3j2G+X6jrIww/sIR8J1G4kuonOoEDfrDRLcTHV+Ucn92Zf4 N4JTJjQZzB72nsW6ZlJ4Ayw0bdyGVNfB9T387D8nXBVM6YQPVOvs3lU59XCI lfL+piADwc35FeRQYboIt3dtM4jsRjv51Nqajv+GA+nsNK8L+h/VDrvmz1wV dbPwqG19BVbwJiwtLOw506IxwrKYzvpY56JvlzgO27CRA4SsvenCrXnOpbWO 8vSRu4IwjyfEHj869ngVWo5+SiuXA7aRIJmhrJMwX6tVxjrjvyVxjnPgt/NW pzENHY8ugaWwhm22c8okIvRmr1XFsNt732mmrWFhZspS974fu12yuU6Wj6XD 06wp6mNdnleTUSh8dl37yc96xXe994PaEu2bUwpT/VP9jE869MIFndfjydeS 3G6ogV3HyhGTD6BR3m79T6qnLHk2W7lZ7f2arKWOuowXvDwTf9fmF+0ZgZmY YRBYRSKMSIT7RSgsCxLElYUEhbWMpaCgxiwYwGIKLBiQRgNa0kUbSFGgylqP 2bZTDBawbY2MbKjRClh5XmuDkoVCXvctdqKLIp9SKAfDBPKC86FTzEBDFIn7 UAFiIHvFg0hQIYocPlo54kq2At/Enb56WsqM8TE0EU76aESoiXEI3fvpEusc 2OvyfmCwu/sSTt8nbY40eUgGqXPbj9ndCPV9ZLN/U8e3G172J+WPSknop+mP lk0iBDefyR8Xtzf3fxccbBzEbRt0sg5icce9kMH5q4/4Y2Y44XNnaKjVa9vR ExwhDLboQCr0l28p0ZRGzgVhdJj8pQ8VAciNaq/9lmpsXA4nH+nsYeVXENpr Zk3u6dmnACtZxLF4moGHNRrkDHvaJNHrqJDR2BxL/snuYwCvH0917NczdSbm QGErhZMNq5VFo00Cfq0HHglg3WYvj6MvTG5jPdszyDLRSjh6eJYGbd7IrGZd 5grTdobN+hSUh90iTWqOQxmVFsoaaNrU4omzF9hGOwkPm+S/P/RjVcxxYsgy coe/w8OWn74+Dema+mLF19LU5ReqqzFPcvUZ1Wc6qlgd9LFRD5vOne5p5mIx RFFambd8WTGH0qd8XqKvOsinSVYvOswIfLlZM/HqNLOpH2xOp2zOdnKl5zhK MUpMWrrBl61Vou9Tdq8RGqcpKTTYUaSesabA+ouRVWpIiXu1N6h5znWi4yrI zN0PqMy9Q6MvN0qs0Pge9YfLvRjGYnUYrSRyG8p7BBE9x7xYpubLYFkESCwF si/AWKEU83i4WRTcwA6lYbPYHsewV2NlTvgZCgTzm2BkIapIJ7AGDhIGRRBM KAeIWUMKbIKWMaFYYhYsgN2jRDeJBY6kA2Tw+n126Pkr0stxHiUYS56DpBvl uxQWKPvi+AIrY1g0YbQ4c2tK8xebi0Q9e/VFc1Jc9Ie17FlB7OI6294Ns0U5 thA+CPgU3yNHcUb8r2OEcVG3xzW9GBHuBLOKHvES+XaaSKSiVhca7YuEfQa2 X+T/Hjrv8XPP2bz3EHvAHpCAenvALLYWa6YzomcuBAgwIaaWLklwaxxueIxi YdMfKh7TyKgcmwh+9czksSaGg9kDa3O7maB9fx2I1qBQ1lC4GocrWAv1eoPR 9qKH6ooB5z89AokJJ6J8IWtZtlSgsIL9hKgqICyRQFg4lCQiRJ/toCotot/z Dyi/oF2vr+PyvL4ejv8qH00+T4p8OfJpVVVVVVVVZIknr2DRED1BsFAuHm5h ZssfeHDl1i0VJCAgdHnuJjytmsKQvXtzHoY5aUnXCkaPbv8I6H+1fvZyo+e3 0qw8Wnxj0PWdN8gBsM326ZmA9wg2FvI5rZQDAfWD7XvDM0455d3iZlJRKJaH nRqQ7tpMpQgJti0/RsMEkc/ywOeddhdd1jwzHY8rGX9Iu7CMimN5n1i7Ngsg vIgHXwGZzLZ/gNTuKfICs76hmbdRjHXgeacyw7oaI/fGxi2O7nZg3xZsT8m4 EjMqfkB2ZmzOStG3YbhXHKzeUDxUqCf9wCT8P5QpAhm/uT7HDBTQGww9oxgl RJFESDrT6u7ut+3XNcytKLVsKJYdR6xyY0GZnIuBAffddyItu5SePrx5MY5Y qHzKvjVe63DH3khIQfeaGPAZobferG+QuQwiZp9fPPPtEvuL9uu9VkIDJiAl E/A462ferJG/caInzUoiumu88evESbdkkc34OPKrYnf9HLuOff28uPIVEeiW +BoqPLOIHfh0OVTZhsXeljwZqJ3GMSFiMBkap12vSaRRxETNswXLRivI7Ozn BAztOfp7OOh5CioSQrgGbAB+0NoBNAJiEpOejtz433SESEk3yiZ+XVN1jXPV 4aaMIQkkmtTIN7w1G553x1hbbJS79Hd3da0Kb41HNGcpCEuFHMAsmMGQwvjw cn6nBC6ppjpwNJcWnhQhUFgKgauw23FhBIkm3TJV6D3js9848t2tMiV0GteL zlIhEuh1BelnESu0Mq7cIVIbpVKMSTiJL28bfnzM6LVeporbmuh6/Bw3Vdrd +bbNnK1jEQog2d0krM8XzSu0KHdJCSXa963VliNncSSW6fGDODJq8ShzMQQO 7xnLb3lVaxjDYbF1WDXROVg6d7dBsFpLG3EEg6EIyOzz3YcxFdpLjKe+L6Sn uEE9sRrs4q7TipWNHHjbgY+UTqdIF4nwilxbGOjYeajdfnm7uKOnOuYzJdLK sOmsVURhBbYjuWu4BmrQmwkjDOdDv5atYYZjovw5mikydxO7Fe09cr5mofoh 0oeub41b1nbOZuYWZxXmDMQh2PFxhzvQ/nBq0QxABxvW63LMS+cY5YoErdZe cA8sqdvLOc5oyjOXHm5USQw62JmCc5fwR4U3hmescdKF0muwa6zXW86aDqDJ Ek3YGwZO4lOZsnbO9cYKKm+HkzZ2zqZL1rVcu45cgJrfltpttyfHMnJmZWJF cEbKUTeYWcFGceRRrW7M0k4M658+GzPZobMzUlpyquiFKupFNHfphcHcsgpC ToaKSUkCUvtw7eCZmfvJOcwr6p73N6iZu3zlxRdPavMQinfk5ziS99bUYQjO HJ1tG0PgVDNkZmxts9XlbPXM+XfGcxvqYOkuXbjNcRtir5LNZt3SwclSGzCV 4rS5fljqACTAyRlkzGkMDQgHIYjFnXUWVtyTLeSySrmi4mLp3w71GM2ccvIR s4wkON34HwuTMyvflHiJJpl8iTEa62NWGMJVze13wxdKyT8Rs1BkOwhMY2t0 8M1IEgpCsCOf5GmDkPyeoTxMbdKer529u7vU8Uj0ORyznn0gALQDb7G064f+ fsx6UOB+4zsO6YdAOhm5458+emnrc8U1ypmLwNvCuJiq1fkJUDeCwWoZ3bEm Ey5tu61rb1avs9IzHL0shmnfbfMRlTC6Xhc8caRj2rCI21SVkS94VXv43P1o 4zhPD4/QI93m4e/7c+ikvwnK14mP5rfbwSwMz9l7eR1pT8DB8umNlLQQqTjH M6MTAvo0mUktCQ4NVnFMYfF14PU564hZv1HDUOYB4AS5guAiJNfrXx9Z+Pzl p+rNrWFx/M4GneOH+1nGNYl4m3wcrHTsoLQGoH84YkWQ07Mt3XhwgcxveGT+ 9r2Myt0im51XsNtcS8d49TQIIxYgyT2w+7eRmw3v2c7X/fj2+FOU6HgihKr5 Biy9ti4wfoYSZo690AWdTrBrndL7SqEGY2X46pf11HZ8qQvbsetkkGd1Pkyr pgeNkj6qErDvfJqw2d1EqhyGNmvqeQSTHPQeAxUxcyKTjnf166VrHouazW2u 716K+dWB2hty/M0dTtEPMMx8VvrYcH3vxtRubx3ujTd1M90UbuDm3sn17J2T yrcXQx0NDXPhu6QpNAW5wgpNsYdnwvjpJr3Fxu6/74krL79XrJH3DHNknlvf RPn8tEj9L4jIt5aPZBfsOJwbBYnYQDmQSfMJAPuSP9JdzIP47/UuZ34O5w3/ tON0hqUhQECCYgTJMKAAgRcoNooeM3GhcP4fMPx8ydvoHX4n2Ead/beCuANA DrIGoZHw8WwWFsFggqAHK3KqA7TV/zEFCyCh/cgoYgZ714DDD3f6k/Meby0e 8n3sGh/QCfn+Ykl0xEhL+tmHcwAsC4Gn27mKFZn4xNDVR/oDQ4OuQtB9ixGT nB/p7LXIeVicR7fhLaTp47Lv4hJ+MY4kD20A+mU2R4wd5vHQkZlEfWv75Vjy AGgzjn1soFOlWr+C8SoSMbOQwiPUPABRdGPAooGs/AyIkrVWql5StB4sku9g Q/X98IwPz+Z/B0LhMj6NeJ2kE+3YJ+uyAZQQ5D4JIeo7quDWBgJLASJ3o0MY HysA8sAIT+2OKjMjwAV7C+SurppttKKSqnxHCY1xlEaZswjTCMDlA9L6USYL 3e+TwTw9tLcmZAbn4hyD8OFZDY99gSsSLixlMaDGPtlQT0oB7fnzczpifNwE Pv7qXkE3/pdu9NzZ2lhPUJjZR5xxNDIwQGwAC/3CSFoCuEF2q6mG5g/ixwGx qohUFs4+Bd5RGEQgJGMaz08PwIJz9pgMiwI30uGj6g5I4jkHnOKWYqGAEIED wCfEHxm3AhGcE6TcduCorFRRgwWBIkgTIjJ162ExDyjrt445EfmjvNCOgKZD sPHttb1XU1QNFfzWfDcyR6sew1zSECMgZkcbhc297HFTxqWcQ5IGSlZxpCjE QrRUMjVm1A8DICl+TOvEHYTMxMM7Y6mR36uGZtdVBy0XepSJUCqOwyQIebvs wiSDiTwEHB+/y+0uPzehPkSGaiZZGJIWQLWtLKH+SIE7wTh3GLnf4BQ6rh2l YRhCQkuFhOoe1wce9R3pACxmYZ3GA/WbD5Icg1wxlSQTaJFe0PqpCm0yTUcT ne5S93imxDDguSRn6mX8SBWhZ2qbfJQGlydSBREbtbpmdh2d3etXkBazEAoG eZIzSkfKW+2kqxf9v0Fh73hrYfd9kjZNyEA5cmo2gc4mUIH4AG2g+bJ7TGk0 FRwDQQ5Bn8rd75NiniljZ4qVpm0VGHeT8E5x6iPYL6FA82lB5CAVvFsJYLPp B86j2aBH2Kc74BOMiEiBFiHWEXRDoI6voSIaieZ3HqOzPL4G5dohggbnN1Fd Q8pTcs0+ACWBhiakILu/IEWmZaC/ftb9/taKjD1VaqVCTLtc6+2KgB/va+Cx SkB7CiQojIlrGsdtFQXLDw+K2bwqkmR6wY6G6jhgObRktSy56gRWbaKAJGRz OleqApBUaUexCLYz1UMBNy86IgGoPqJ50gHuht1OSMg3DzxfjIB5Q/BCNKl0 IvYyJFGLqEey1MeY6Q6tUNvQawCIwxkqiaQt8tHVi0EWJAnNg3gRQxMohg+v 7NceM56pxM89z+4MOXlKH2sQsQR1+GlqQ62hOp6A8TQ0D5WcOAuD4ALmoOJd TFA8jiUc4mT60Ld2x7g2qOvYO870/pPHYff5Xl4j2h02xeXrpD3ETaSoFoDe /apZV7Yh2AYVXYVCgIEbW9c8EDrfeRDvUbieeJ2PWTuMgxoDzNs3uQMU2IeH lsaL5CZnUp42AQV2VFeljumKjo0D3IEXTkElAeQeJXqnRQMgowWRIqxnVOvk rbre/eX0BH6vZ63sphH7fzPwhc6aPzyqpmfcVYQSJDQTcsDElSpaPytMDRIf p/H0vxtHn+AiwPv+3+vAWQKlZJoc1eTCfOdWp85+x9/5fogKvkzDNaw+Q/Bs H0o6qrFEeG9DERGRRUEYiKxDrEnLPhn8XRKbc6VVr3+ZG3l3eKKI83ady9h4 GATZeFSJlFt+6TuwmD2IB8ADM46KbEfjQWPah+O43BggUaqhPae9vsQ5uh4C bTjqp22MMgTONnF5F3MTivAFN+Rz8KUKkKpJEDV0Oj9yByOODq6btwnFR5Y9 b9EPojB7/s/jBHvIFB735MsLpYwD9njP06A2E9IFfpCfENH8hsyBofb9RZKM h9DbJ/rDcUpAp1m0eAJ53AULG5C5AITYVN8rMaALEIT38QxoeCihjP9XPpIu 3LrbB5FQMwrXsNQ6e0wRWEQL0lUFo2hAMdRYaW0CoTqAgKMyEfKCvMQEwWjA Vl9ZtCcLE3H1siKmom51zXGB0iDkfa1eIOrFY5pmZ5ENAyhqBiiVYj/mDHg5 fveIkl0Q3huMKGQ7AsOHgtgmCvQlHRq3RgAPMnI4DAjjKXe8BwgWC4x4LiWK zDphpEkjow0FDO2xNmA4FUFDQdVi1EGOPBTZ5m80ytlpTd54s4eiQ6DyDoHq s4mBmZjLBu4JqHvD+oB4dGjHkGZawQB3VdER31WDCV6NpThjRXRDcOjekpnS MSNqYc6UCgxGAogygaWIsNJWSYEiUkM6MZ7yPUl8zDwJN0mt7KKRIRJgJVQi wqdvbqmpF6SBsDXY/yO3crtSbDAIGQe8M0dDAhxQ5xgrCAQC9ZYgxYpIxRSI owSM+WFnshhvmgda0bWIyIKG5tBUGlAmhL40P1yQskTYu52E5PQdCnoMUwDu 6NwuJpsQKO09kg2EyOwIG5zi9RLzMjgjF9p4gsnEMQMq8BKh4M7VYIkptJA7 jWX7V0UocdqQESBqZhcJFlCTznQdOwOnPNQwiEuhMjAlnmJI3WAKwDKIP07s cEBuW1LAZ8EoCiaozyAJHQhLPn+lkdIaQxlIBQjVywfA6vVPJxd5uTUMzT9j Eu8E4QSHafoFfgGegcxTIkmiacukEK/YFViU8DgMAz/cb6NR8OlDWJcdEJIS RMTH5zrfhEJJIkULi7KOUI+AEySrWoObvlw3MzMkjiqmw/TlsbThYvJqNbQy MYK35gI8TxhnggjmieZNg878zF5J3nRPpTVHzwsdIPabYH80ue1CGNIh8doL TeMg/LYYsfsDgK1625SBFnjGAdMU98NgROoimRgUkj1GIAmcPZOOA/iTWfWu ECqCfBPn+kSWc/xn3KD0EnAU6lQx++fJTYwWg+sbvpJYdSHoghqMGEOkqshE 7XcQNIUOrnRgLRXmKUWUVQUVI4LoQsQfqM88fNg9Qw44Itft2qbYuzTCtgUq FoKdvYYQGgyIl1DgvMEHIiQYFoH8sygwTr/1x9Y5jpiP0dB2iyQS78eKob7k Ya2LUU1aiiNEEXtgdgTMPIeJJH1zU47POTdVQRVB39swTuNKz2StXCFAULhO C2SI8YlRAqSKfMeihyDnAJznYaMwOLrqYJlL0lDAKYCcsgYKNJA0thHQDBDG ydhPFOtZ4HMOOrkuHhB8zB5MWwbv0gWBbBtyWlDeWqk0R3SWNsLPL8vc3Vub yJTabS2FoRUhmEyQVsEAzNPYpfybsmO5/0g70V5ErOknAZXQ+z8oLx8JGCCR IDDhBkyIQYEo6m4+I1Do3HN5Zz8DtUjGQIxN2RmJu3S57rVW2rl64hYjb8y6 4rMC9GIQFsjloEY7opmBYIJHa6w1m45ovw0mhziXSj122MDLbZGcoWMka3Zl KaBNCJDWdbddA2dDl7x7btKGDsLbqEiSm9lTE2kFZ5ishTRrMhpMYdhxGKZs RKdFIB0yX56MslgYk3WcWM6CSyJcucgrynHmI19fsuw50oMIRns+UTMNy9bB UPPCQixjBJADa7rlDIv8kgaAdrMVzmUrvLu3+sU9dBsQuefuc9SbWbCJ3dgU foUdCHAHaWqAWGZlB0B0/nOmEOEhKMkKAMJwbLYKLVcm4LJYTCmU0GoiwFUY gsQFBZDi0Efqp9TQVZFiiKsqSlEKsTIWhZkkbWKkLAmR59Mrt86NUidyJaOb alAwagoQhGBIA7u1GC2UI/qF4c5bwVyPGjuQM2MgR2yAR95EzMhGeUgtETco 4sMjEC16JB8EcC1HhIdPKnsUFiZkYQpDx52QkT1T1ALFcyF4R5q679xOVosL KOJ0tJTXP2uA3z5a9FvWwGgdx1eAXhyLRjDd3f0PDhuK89fh5Ze8aFJRsbdb VQfB68tgkuGHH4W4zBIMZsSbcgQ2Pogc5a4xWAbSDhG5EYTe42spg4jkY4YJ iRrww5yHMVSvVvOcyRPOX2ccQzWjhBUioLLt9pRqb9pbMNaWqLUbLsV0TjwX IyMsKfAzmNPSigqFHEPPM4KWKwzGGk5dJbobdLM73Dm5HMExKbGWq8IokzqZ bCZYo+Z21nF4bZh9m43c2qq6dSHjPI6KmgIXHN1uGEPeEXBLMbJrAyOU0bCz XV2WCZyOMYNytuvRma0QhciOPFse8wwUdkGq42HhFNmm6xWKZbeWB+xImp7J hzbYdJvUB7RyDbdCNhmbiIeMujO+xuczCCU3LZFiMh3IZm0DiGybOOQMjIUC kfBlhz5p9DCwjUk8YDEpQi4LDGg4pAtDhScE7TxUuQb0XbiRJYzQPiXaNBs0 mYZAdMYwmxOo03m+n4OlpZu/vfyH0AzLhhjTmqdLcqR68IbjHZ5tcVCgYYc3 ySV9jri1iKW2zHWBG25DTHCjBGltpjjOw4mMnEDxKuQnkOOsUKgKYqeTH3GQ YXFirNbJFsTySFtkuAupdH8d/7FAuG7XD9AXlgdR9uBCg/6DEpPXIJgqcGjy bBqDAtBShiFMXzN0S4eFBxR8R3ZdVzqCkqw6EXEezp92cFHXXtydh2GvncC/ lLoIxMLIeDPadw4b9qGi4PF7rZXzC5iAwhaq7czGOle9dzA83qJlVod1qz00 gOycGV9YjYoRPy6SQZoP3FHi5uTRpj2NywnN9w67F2mYnQZvOJz+FQNzszZW B6Abq9L1Du3B1Nlf8JA5xDC74uk3Bx50vrJ14IGj4sME8d88a+zRQTlrOEZy BfirkqKdXJcMIhwwSGCBJrZ6RLPooIjHlN8Form2AmE2TacDYYA2iYscNDhs 27lvN7zBk0u4NcDMDdarNDYMF5eMTVkSA8OBI5KpqQHSRsqDRodObfrnHGfS qE7gSDPqaDAdPq+THiIyaUS5ONmd7XinoneR+yr50VihCBwA0Qe+DINvbHjp cikGRRTqKWPHhCgdHbYXqeuynlCkMxKGNPVCeVep1OXUAyNGSAMskDqJR3rY RDktETtPCN0RLBjMqh7RtsLoq4p0g6oWIKAkSCIZ6AcsauKhg2eSEDFUwcIH WxuEgsC50j2Oc5+rYRBEoUhrQ3LlBcpqI1k2fdut7ETRcgaV0MGUzUGaCMh+ xwKUfeShtT4yOCQRjAJA2IiUDnrolNwcALDArPEChaG4QdL0LDDMtaMFDD3G Uu27mlih7j95CIXNGbaCpXkOKjqgWCwRgEClSKeifpCId2eQhCx8z+EwghYR MITN5FWX17Nj9y4ABgXM2nyP40OUwMQNh7tZhJqkXqBpD6AZZAVWwQahvrdX ZqobBjRKlkHyll1QhkQMIIYMDZ60klGGMCDo3yUrXeWsZtU4FNzV3d2qwbkh ChR8gAWYCe8K522jgR8kK8+BvIHEDm27oQHNHhRoBsVIjQrmlieS63DVgxWt GQ2JvMw9EPCnwD12QqPhGwRljBEsXC0h9i0kTYtWHknSBxYyJzGDAY4dsKgQ M4OSHswaSAfeGKiQFIsWSIwEZAdiwYysBZERVRRIDxA0aJwEk4GHnJkucIbi hL6ShKAhCFyxAKckDNSC4FhhFhC8QmYYkfPdpYhiEcxNwU4gZ1kbFf4HukGB j1kAIAdXzjzhcuRR/4xCQKPj8S3mknEM1EKDIyEMQFywMUGRSBCIkXyA+Snm QtaCUNeujx/lUhfSwZmVIA4ClB8spPjCQ84wX8tX5zR1DJn0w3p9xu7Q+SEw gpqoc1CXuePt483WYmLwNEIECRJqfXoDlAO0ZCAh92DYGK2ggGFsIjyREozM wOGIvsJ1lX2uJmUp5hIBIfl1HMHgi5nKHloEo5jYP2RA9SbQ8xAmSa4p2n5J RIiUIwDL5geniCO6bjWvobABlA9cQfep0+sLSyHEBxRiu480nQeI2IXg8qFL hgm7hL2MTyR3HnfGy1iZ9hymtqkkfsn9+YT5U9/WWDOD3wpO6cfpnuKqox6o XTJ1m6LmqovmcFC2KtuREArIoWiUVQTgFCh44pZG9MJA39p1HV09PUMTgVCN USSrlB3ck9EWE6Xp0xEM4L5pZZE89aFi+CgWOTVAmwIFE2kAfi0tgMDEYQi+ 3lrbk+FHEbEkkUgehDpwsOU3O4EjIMRIoCKJGJCa3NxxnaEiAXmECw9PmOl8 RomwBdAKglZb9vzHhkk6IbDBRFgrFTuazup+qEkg4I7FmZtzGFqJWHSHcDCJ 17V0iRbtr7QsyzIOJftPX002EMuwKAmjJCc4nR5QQA6IhcH7kFwAsYmpq5uD tKNQkjqmptHhAE8PHkXsBdIwSMYSBBQOZo44GUp9BQXsrWm8nnDyK/9lbJ9Q rkeTlTDemlQIows8SxIQAHvuNyRuDCKO+6I8AwmIhkKlYa26oG2ENqBCyAOA Og0FhaCIHkYA3Zg5WW30+YgSE5dD4tyhh5cBZXBBQGRBAsRO4LNrEaIBYXkk IoXaQmAJC5s8HNONMwwxq2je0Sl1atELby1FhKdQuZ7Q4htBdRhq7WVEE0xc lii7zCHByLGZ1TwCAtTUWJwakWTDyV3IUiNAnRPm890QDzT6yIdm/CdWzKMU 8k4G0PhJIEeiMQhB0/IsUHF0EzMxNg4FKlyydI4XDryLpbcBKPfIZ55pjXvx us6KhCNMrbbIDkhaoHMrzMuDCljFsnlOxLtNrA2IWgITSSXYhwQXokLyPC+m WQlSFrlliLFRRVVIMoHxTjeQHUF7wfFzfunSTRoqruDas2hvRSlxMwwUvtS2 Nx/y7t5E0PZMgl8rgrFZHCnVlicSTqWJNdMhcBmNYIzEDjqUh2IJtSB5AA7P j7awJjlZR9UBkqoK6bDDDovXRaVk1IFxiHXuJc+p5jDF0nF7sjoOlIYSUSYy WZv2YOMGthU2ipJIosh38sDL2ggdBNuK894SNOmxA2MACGxzMUBOoirWMIE/ j2Oc9RwLdoabFN4bXmMIEIQ3w1hEMkyQyTYQYUmkJDLX2+80YL39qXYBnCiA 0CZrL7OF0WBoaPrWkxLClKYEGw4RLWCxjY3LGdBtJQ3Axpa9jgznKBjNh7On IJtdyDM3ThLIgYf3xNCRichIVQO2j++AE8ZOIbCaKU57yF4bNmnNYZMagoJk Um3CHgoEtnaHTisoeFS3CalgwW3ykuCP45wgEUghZzcUwCURdLV5+YU4xkBC iIHL04nnfCgvRECBhGEOkpqBCTyL0Q4cWEJQbU+eB0BDjkhlkEkgLCaZKixQ MoJaMZMMhuXJCMDAwBMC9yyjdOVxSohJJEniOQJKhoUXHrG1JoGz1s73HCb+ IoFlFKiT93+/7/o+fz/R7P0fw8f0a/R/GnugcYEKPz1RAgMYhCEISKwiWTkF uqNz9B3Bb60fN5x229ZR7hDMnaAEUSzCMWMUqKlRBJACBBRpssoBpCxcC93x jEA/IxLYDQB4w1aILLHlIoWTylGOZjglo54kMSIZwAyI/J7ihyBHfIQLlB+2 FrNRWDIIgyd2MDDH8EIFJo0kmhDVUeFkpT4WNux8EwaXv08O4IWjmLKnRu5/ MUvA4J4gwnO3S0W2lt7kObsjQajNZktoxDIcuo7EBQ9t8OBwaE7NBDJgJ4pI zUPdNroIiALFIxBGRNpZYRwZQsTYyB5EkYMgsULBFAYEaIMFYKWGyI3tXjYY re5i43LPV6ofJMKKQPqSIf1Ed9/jbE/FpXKQn3I1ijsPjCiwXGiAOiPwCajQ CUvw/HBv0rBLqdTQBQCn4VPkQ27X4ldkAjYrJmo47VE8ANusV730DzN5wfvC B6E+4ue/sOPa2CPxJWlsLhx6Y3DqzA2hvoXXRISIDVEoShYyUDuKGgjgJCeg 8sU8CdUAoZBZIXJUhkHgOJb72K5rOrNe7LDshRoprxyEjIQCHWJ/A4MOBQYi G9yOk4KFIGfykfZTJgR08Owz6siiK9XUmZdukjCBX4eYogbgTA7EGYphaflQ t58qAoQAkKGb0wF4aggf0fihEsuwD2IryI1RiNZDolyA2NB4wA5wjGLP4NFB 0XEGNyhhsjIsHtEMySiOcymRRlV2JVz+8MVI0M2zmoHJt+i84zHZxM6JlBZJ hMFg4PmgRaaeXVCyzeryBLjXW/Hw+PBDSEcm0zBRFJkUzjXBZJMQDxAJchzA wNbSOMzAGSIBCr6pYOQfzOG3PMEo2MWBqBbMo47w/RB3kKtws56HhFsXdcSy Her66PaT2hNpGiiBa3SHxpMe9Idqdeg/KlKFToShOGYWP41UDgE53FUOiOht cEOPQFPLMHmVMg322fXcg68EqPEilMWpawaG7gBCITQF96Jg4AQ8HgqkQKIh 8ZUKhUXkoYImHup5Rwugb0SOM15BtrCEgsgMFvQbhLYDYTkeQVzDFoYgcVRM nYawxBXfVD1HA6JI6SpIevDGFQthJM5Q0TAGgJkkQYMQSIwNIWCC9KSjEWCR RjETLUEHpwpm4cB5YaYHENlGCVyw2mrK1oMYaYVRLYGoMzby4YgifnSR4s3Y Brizg4ocWBFIxSskLRBReQCYDApApAoLNgbTYeayaYvvMha9SHmxfbCQYHol Xg9ybihGL9nPJb9EIkUCmwtiDpwimZhEXhZcMsQwtJrS45ZzHO/u91zxz1va ecZIDTWsffaKN3dRRGRYdQJzXZfiMU5JcU3w3REu+01SG0YGBO58dI5gSG7q 97O2HTLMExIu/OizejUMQp2k3Hg6lMy/TBHTI2BxQOBd5pF62skKQFGLb45R gRAxG07MOaGI2h6QumJre1MYkgRZLNKBhG0ETmJSagg5uHSOyuwRLHutTDEB N0h8jCQMnTBQHjyLDAKK98CYCTIXCA945qPwbj4gLIkLFFnrDVtE5AvAtpxC vk37/EqJ50eIn3ituKRC1wiSQADGK40K1S3cYGBGKskkNzJkNQZGFGkFAoyg geLMybQLzPOaMlWB9AvFAHgvWmTpaQBOJTACNwHswQpR8IFBIeIO2rI3WxaW XyUbxwDCxgOFqBKqgG/1IGqZ8Sl4RQLFhA42Leee6x19WVvVMfhpgRJAogJo EXpyJlOnMt1R55K6vew07doEcHh228D0eCdY9/6KMikP5zlJmsNG0Z3l8sU+ mRDZGRoT6yzwGnd2soxCCk7VmdrlhWUz38nNzJ72xRy2pNxp+K58Eh7Cn2Sf jZpOTesoOh6+DR00OatVtx4HDTyzfSTUNtYabF7fY4zi2xhpZMkn1HaD0nUi GYFdMwkobGHE1S1S/Dk+E5t5y3j105VdJupfG2LiEYUclN9tUysrAONQkBzw jtd7cRCVgwInFuXNSFQmyneo8AqKFj2704jqqjW0Gxk5YDA8YfMPW5Xx607K qW2GKNrS0vVJAouLcwwY3ECkXMKrWNJCYX8BF4JjAhKcpBDcBAaPAUKeQ1YD FUPUU8IXbtVzO67eBCLgCOptS2hgFPrLU3E9QYoazAgfQwjzMBAhqautI51D fMenEYgrwBhEDu1CvAZA5V7/fMmRZxfuHqg0kvkRrYKENQ0Cj0GrxDkNxCTs IZQmPITc3iyBIiRnfdG2SLth0wYUBCQyCBORZ6LSTaXMDBjeJjYwyyVuhW+O 7CTrjCIiqGEeYAqB3mQJ3pIWGKksVtF0NnjYmpATIDFkYDoES04LOSJIjSRC ClSmgoogF+Ew4fXkuQ1DjNGCkR6ioEaHQh0apOybBiKcfFnd9pD5QxRHQhWJ lrHBeQwWVba4wfX5olRU28Ent1rd68mC9m9hnSwbtIoIS4MEIl/VAe7wbMXc MfBGZaQxJhGuYmwgxoeCs2zZblSyNo6c7GrQ4YDF3XPc4a2OmmuSWrZmduIO f0CCQz04ZENtlUKeZUsoW1dpeS3HywwyEwxucQzzTdY7StAos6Djg3z4FYhb c6Z1kDsxd2Y2NNMp+EcnZzorNjdnNjLYLL2aOKJ2sWmtmE1Rpt2rDUBgE2Bk RydpE0DtRbIsI6aMW1Cottzobtg2HtWLmC2vnbbHVm1DAwcRcRJkQSPs2GG5 Bz3I7bEjJgYxowDI6CNIDNuMFuzYIpooNMDHU2Cf7E4khI5h6waHTEH7UBXi SiIMYoEipIwgyLCRgkiQm0uYSbnRWHHMRCx3EEYF6Siy2DjemEJcSOguBRzJ y5c1XpkEQFllDwRlgaGphN0F1BN8BooT1TYEkRCs+HQ2UTBZJEIb9TfrKVKI BEhaeh3byiagnZEO6AJCAB5YgmAQ2ZQyLB9VbNBpKiuxe40bGjA1drWeAGY4 KpRDiPUY5IicCmwwWIdSFUQEPePKeU3TmNYTqnRN55KiInCwoiixcr1vbUt7 puwQsaKAxxaCPcHMcTfkkXEiDxgVBeArbcHEIpfR8HbBkBNycApd7CjF5w+B uAhARsHZvoTKSH3UEhWpwATOIsGSAvDXjF72cJ5sSJTUnDtGKxDXLEj2KHmE oAHhwhhMDDZR7YQLLi1coXnD1jns5YIPCJmgjPEWCk5/GJipbZAbPMnkBi41 lNhww8ziQGqE7AKAwmPNzk5Ktw0oOsIL0hiNjR7AYQD0RDOEJUkZgA+45GXd 6XV6jxG4AG6TJs6ISp0pg2of4BcSf+wT3wA1gg/SRctpniPcd39UBPDinxDf 9pdYRJBDBLpyfGEZqLkh8z5iSPUkuSjaJo+snOJ2CmCdjGxcWwYZEJL9Aavo SNsyDuB+zBNwLhtUTNUPUGvZXdMgwuq+GjtfMG/BENsEZe9rMKg1FGEffI3N c3h1yQjEE6mfBAtwTK1cBOtf4q3wHcEjAIh5QglQy2PrxJCQsnE3+uBzgc4q gVABT+x2hR5khAZCACafccXoo6bL6XbpGA+rnCHV2dExVKUwyYGWC0sOmBkF kYhYh+IQCVJIUKBkHepHT1dtjLnQrRVNkRdaobChStWYQiXSclY2XiE7Mh6H I5QlgOY8qEMginEg4EDfubbZohN9+soiMRdtThOLYMwFpCm8A9MWxEJjvDeH pDjp/Z/RwIH7fmsBgwmhQUQB/yklCPkQ4kTl4LkiPMYGdJiEGYFWwXJrZkeB YjbC1UTCbmGWaNkURWKsS5hzE1Du2D/DQahtKUKaZ0MqElMckL/1oDq55mZM CprkQhHKFLIkQEhEGRjIqycZ5jbgERYICiyDEUFRWMQPSCSVYsRYqyIosYog grFVESCkQYxRBILJwPcHIxwim0sD1DDfa7zakqEiEHHMDn2uKA6J9TqNUpnc ozZRTAdQNInGEQ44tKc1DDiBxN6h3TILJHxDBobbmadmxwcM0wZhb2t1ArAI l1WktM30iaie2PjDJMQxXMMcTeCaUD2hwIEgDrLiBKQ9iAI/YJIgnekf3kDv IsgsIkOPjPx+E+sJsbogAoICiigsVIm1g/DEPTXz4FxkkFfVTp1JQZCgf/i7 kinChISaXdqo --------------070701080306050109040006-- From yoshfuji@wide.ad.jp Wed Oct 9 13:03:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 13:03:38 -0700 (PDT) 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 g99K3YtG010160 for ; Wed, 9 Oct 2002 13:03:35 -0700 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 g99JNXlw029211; Thu, 10 Oct 2002 04:23:33 +0900 Date: Thu, 10 Oct 2002 04:23:33 +0900 (JST) Message-Id: <20021010.042333.122713397.yoshfuji@wide.ad.jp> To: kuznet@ms2.inr.ac.ru Cc: pekkas@netcore.FI, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200210091903.XAA20130@sex.inr.ac.ru> References: <200210091903.XAA20130@sex.inr.ac.ru> 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-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: 597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev In article <200210091903.XAA20130@sex.inr.ac.ru> (at Wed, 9 Oct 2002 23:03:29 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > Personally I think the interfaces should be configured with a /64 but > > there should be a discard route for the whole /10. > > I agressively agree. :-) How about this (against 2.4.19 / 2.4.20-pre10)? Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.1.20.1 diff -u -r1.1.1.1.20.1 addrconf.c --- net/ipv6/addrconf.c 2002/09/27 17:17:06 1.1.1.1.20.1 +++ net/ipv6/addrconf.c 2002/10/09 18:18:34 @@ -783,6 +783,7 @@ struct in6_addr addr; ipv6_addr_set(&addr, __constant_htonl(0xFE800000), 0, 0, 0); + addrconf_prefix_route(&addr, 10, dev, 0, RTF_ADDRCONF|RTF_REJECT); addrconf_prefix_route(&addr, 64, dev, 0, RTF_ADDRCONF); } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From kuznet@ms2.inr.ac.ru Wed Oct 9 13:50:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 13:50:15 -0700 (PDT) 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 g99Ko8tG011328 for ; Wed, 9 Oct 2002 13:50:09 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA20234; Thu, 10 Oct 2002 00:47:24 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210092047.AAA20234@sex.inr.ac.ru> Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses To: yoshfuji@wide.ad.jp (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Thu, 10 Oct 2002 00:47:24 +0400 (MSD) Cc: pekkas@netcore.FI, netdev@oss.sgi.com In-Reply-To: <20021010.042333.122713397.yoshfuji@wide.ad.jp> from "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at Oct 10, 2 04:23:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 598 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! > How about this (against 2.4.19 / 2.4.20-pre10)? It can be made global added at ipv6_route_init, I think. Alexey From sekiya@sfc.wide.ad.jp Wed Oct 9 14:46:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 14:46:48 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99LkitG012178 for ; Wed, 9 Oct 2002 14:46:45 -0700 Received: from KAWORI.onaka.info ([IPv6:2001:258:3:f050:a8e3:375d:524:7871]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g99LkHMa023793; Thu, 10 Oct 2002 06:46:22 +0900 Date: Thu, 10 Oct 2002 06:46:16 +0900 Message-ID: From: Yuji Sekiya To: Derek Fawcus , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021009170018.H29133@edinburgh.cisco.com> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/20.7 (i386-*-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15pre1-IPv6 (SHOUBU:63) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev At Wed, 9 Oct 2002 17:00:18 +0100, Derek Fawcus wrote: > Without reading the kernel routing table code a bit more, I'm not certain > what that change does, but it looks as if it might be changing the > connected route for a link local from fe80::/10 to fe80::/64. Why do you want to use /10 prefix for link-local address ? RFC2373 defines link-local address format as below. | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ > All link local's are currently supposed to have those top bits > ('tween 10 and 64) zero'd, however any address within the link local > prefix _is_ on link / connected and should go to the interface. If you wan to use /10 prefix for link-local address, you can add the link-local address with /10 prefix to interfaces and routing table manually at your own risk, but it should not be a default behavior. -- Yuji Sekiya From dfawcus@cisco.com Wed Oct 9 15:44:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 15:44:45 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99MibtG012982 for ; Wed, 9 Oct 2002 15:44:39 -0700 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA26972; Wed, 9 Oct 2002 23:44:21 +0100 (BST) Date: Wed, 9 Oct 2002 23:44:21 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021009234421.J29133@edinburgh.cisco.com> References: <20021008.000559.17528416.yoshfuji@linux-ipv6.org> <20021009170018.H29133@edinburgh.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 06:46:16AM +0900 X-archive-position: 600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 06:46:16AM +0900, Yuji Sekiya wrote: > At Wed, 9 Oct 2002 17:00:18 +0100, > Derek Fawcus wrote: > > > Without reading the kernel routing table code a bit more, I'm not certain > > what that change does, but it looks as if it might be changing the > > connected route for a link local from fe80::/10 to fe80::/64. > > Why do you want to use /10 prefix for link-local address ? > RFC2373 defines link-local address format as below. It also states that all fe80::/10 are link local and all fec0:/10 are site local (sect 2.4) > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ and for site local it says use the following: | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+ whereas draft-ietf-ipngwg-addr-arch-v3-10.txt says: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111011| subnet ID | interface ID | +----------+-------------------------+----------------------------+ So we've already changed what is recommended in the top bits for site local, if someone can think of a use for the top bits in link local they'll probably be defined. (Do you arbitrarily restrict the bits in site local addresses?) However link locals are a bit different. Once you have matched fe80:/10 then by definition the rest of the address specifies a directly connected neighbour. As that's what link locals are - host routes to directly connected neighbours. There isn't really a connected prefix as such, that is only there to trigger ND. Making a restriction that all link local neighbour entries have to match fe80::/64 rather than the full fe80::/10 is pointless, it gains nothing and makes an arbitrary restriction for no real purpose. > > All link local's are currently supposed to have those top bits > > ('tween 10 and 64) zero'd, however any address within the link local > > prefix _is_ on link / connected and should go to the interface. > > If you wan to use /10 prefix for link-local address, you can add the > link-local address with /10 prefix to interfaces and routing table > manually at your own risk, but it should not be a default behavior. My point is that it isn't really a route. Once you've matched fe80::/10 then you know that you've got a link local address, and you switch to looking up a connected neighbour entry in the conceptual neighbour cache. Other than allowing the use of the whole address field, the only difference in behaviour between the two forms would possibly be in the type of ICMPv6 error generated for a non existant neighbour addressed by a link local with those high bits set. If the prefix to match link locals is /10 then type 1 code 3 would be generated, whereas if /64 is used (together with a /10 drop) then type 1 code 0 would be generated. Anyway, I'll not bother following up again in this thread. If you don't see the point, then forget it. DF From davem@redhat.com Wed Oct 9 16:21:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:21:35 -0700 (PDT) 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 g99NLUtG013601 for ; Wed, 9 Oct 2002 16:21:31 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA28812; Wed, 9 Oct 2002 16:14:15 -0700 Date: Wed, 09 Oct 2002 16:14:14 -0700 (PDT) Message-Id: <20021009.161414.63434223.davem@redhat.com> To: dfawcus@cisco.com Cc: sekiya@sfc.wide.ad.jp, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: "David S. Miller" In-Reply-To: <20021009234421.J29133@edinburgh.cisco.com> References: <20021009170018.H29133@edinburgh.cisco.com> <20021009234421.J29133@edinburgh.cisco.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: 601 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 I think the change was made because some TAHI test failed without it, USAGI people is this right? Most of USAGI changes are of this nature. :-) From dfawcus@cisco.com Wed Oct 9 16:29:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:29:21 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99NTHtG013986 for ; Wed, 9 Oct 2002 16:29:18 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99NRscQ007670; Thu, 10 Oct 2002 01:27:54 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA03984; Thu, 10 Oct 2002 00:29:02 +0100 (BST) Date: Thu, 10 Oct 2002 00:29:02 +0100 From: Derek Fawcus To: "David S. Miller" Cc: sekiya@sfc.wide.ad.jp, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010002902.A3803@edi-view1.cisco.com> References: <20021009170018.H29133@edinburgh.cisco.com> <20021009234421.J29133@edinburgh.cisco.com> <20021009.161414.63434223.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20021009.161414.63434223.davem@redhat.com>; from davem@redhat.com on Wed, Oct 09, 2002 at 04:14:14PM -0700 X-archive-position: 602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Wed, Oct 09, 2002 at 04:14:14PM -0700, David S. Miller wrote: > > I think the change was made because some TAHI test > failed without it, USAGI people is this right? > > Most of USAGI changes are of this nature. :-) There are areas where the TAHI tests expect a certain behaviour when more than one behaviour is acceptable. As I recall there is an issue around the behaviour of a packet being received with a zero length payload. The TAHI tests seem to expect one type of ICMPv6 response, whereas depending upon the value of next header and the order in which header field validations occur, two different types of ICMP error can be generated. Specifically parameter problem identifying the payload field or the next header field. I seem to remember this being triggered when a jumbo header is received by a node that doesn't understand jumbograms. DF From davem@redhat.com Wed Oct 9 16:31:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:31:56 -0700 (PDT) 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 g99NVstG014232 for ; Wed, 9 Oct 2002 16:31:54 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA28860; Wed, 9 Oct 2002 16:24:39 -0700 Date: Wed, 09 Oct 2002 16:24:38 -0700 (PDT) Message-Id: <20021009.162438.82081593.davem@redhat.com> To: dfawcus@cisco.com Cc: sekiya@sfc.wide.ad.jp, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: "David S. Miller" In-Reply-To: <20021010002902.A3803@edi-view1.cisco.com> References: <20021009234421.J29133@edinburgh.cisco.com> <20021009.161414.63434223.davem@redhat.com> <20021010002902.A3803@edi-view1.cisco.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: 603 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: Derek Fawcus Date: Thu, 10 Oct 2002 00:29:02 +0100 There are areas where the TAHI tests expect a certain behaviour when more than one behaviour is acceptable. Great, that's what I was trying to find out. Now I just need to know if this link-local prefix case is one such issue. :-) From dfawcus@cisco.com Wed Oct 9 16:36:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:36:48 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99NajtG014697 for ; Wed, 9 Oct 2002 16:36:46 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99NZJbu008050; Thu, 10 Oct 2002 01:35:20 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA04676; Thu, 10 Oct 2002 00:36:28 +0100 (BST) Date: Thu, 10 Oct 2002 00:36:28 +0100 From: Derek Fawcus To: "David S. Miller" Cc: sekiya@sfc.wide.ad.jp, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010003627.A4481@edi-view1.cisco.com> References: <20021009234421.J29133@edinburgh.cisco.com> <20021009.161414.63434223.davem@redhat.com> <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20021009.162438.82081593.davem@redhat.com>; from davem@redhat.com on Wed, Oct 09, 2002 at 04:24:38PM -0700 X-archive-position: 604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Wed, Oct 09, 2002 at 04:24:38PM -0700, David S. Miller wrote: > From: Derek Fawcus > Date: Thu, 10 Oct 2002 00:29:02 +0100 > > There are areas where the TAHI tests expect a certain behaviour > when more than one behaviour is acceptable. > > Great, that's what I was trying to find out. > > Now I just need to know if this link-local prefix case > is one such issue. :-) That I can't answer, since I've not had that one specifically thrown at me as a test failure condition. However, in a previous email I did indicate the two different ICMPv6 errors that could be generated. So I guess it's a case of see if this was a TAHI failure, and if so then is it that TAHI want's to get a 'no route to destination' when 'address unreachable' should suffice. DF From sekiya@sfc.wide.ad.jp Wed Oct 9 16:42:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:42:15 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99NgDtG015069 for ; Wed, 9 Oct 2002 16:42:13 -0700 Received: from KAWORI.onaka.info ([IPv6:2001:258:3:f050:a8e3:375d:524:7871]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g99NfrMa024539; Thu, 10 Oct 2002 08:41:53 +0900 Date: Thu, 10 Oct 2002 08:41:52 +0900 Message-ID: From: Yuji Sekiya To: "David S. Miller" Cc: dfawcus@cisco.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021009.162438.82081593.davem@redhat.com> References: <20021009234421.J29133@edinburgh.cisco.com> <20021009.161414.63434223.davem@redhat.com> <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/20.7 (i386-*-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15pre1-IPv6 (SHOUBU:63) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev At Wed, 09 Oct 2002 16:24:38 -0700 (PDT), ++ David S. Miller wrote: > There are areas where the TAHI tests expect a certain behaviour > when more than one behaviour is acceptable. > > Great, that's what I was trying to find out. > > Now I just need to know if this link-local prefix case > is one such issue. :-) No, there is no test item in TAHI test that supposes link-local prefix is /64 :-) The reason we change the prefix length from /10 to /64 is following spec and adapting other imprementations. -- Yuji Sekiya From davem@redhat.com Wed Oct 9 16:52:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:52:21 -0700 (PDT) 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 g99NqKtG015571 for ; Wed, 9 Oct 2002 16:52:20 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA29366; Wed, 9 Oct 2002 16:45:04 -0700 Date: Wed, 09 Oct 2002 16:45:04 -0700 (PDT) Message-Id: <20021009.164504.28085695.davem@redhat.com> To: sekiya@sfc.wide.ad.jp Cc: dfawcus@cisco.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses From: "David S. Miller" In-Reply-To: References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 607 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: Yuji Sekiya Date: Thu, 10 Oct 2002 08:41:52 +0900 The reason we change the prefix length from /10 to /64 is following spec and adapting other imprementations. I think Derek's explanation shows that the specification allows the /10 behavior. Also, I suspect that since Derek works for Cisco, some "other implementations" behave how he describes. :-) From dfawcus@cisco.com Wed Oct 9 16:52:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 16:52:06 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g99Nq3tG015488 for ; Wed, 9 Oct 2002 16:52:03 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g99Nof8H008989; Thu, 10 Oct 2002 01:50:41 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA07788; Thu, 10 Oct 2002 00:51:49 +0100 (BST) Date: Thu, 10 Oct 2002 00:51:49 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010005149.A4699@edi-view1.cisco.com> References: <20021009234421.J29133@edinburgh.cisco.com> <20021009.161414.63434223.davem@redhat.com> <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 08:41:52AM +0900 X-archive-position: 606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 08:41:52AM +0900, Yuji Sekiya wrote: > > The reason we change the prefix length from /10 to /64 is > following spec and adapting other imprementations. I said I wouldn't comment futher on the spec issue. I know of at least one other implementation that allows any set of bits within the link local range to be specified. (Two if you include the current/previous Linux behaviour :-) Changing to restrict the allowed link local addresses doesn't _enhance_ interoperability. Leaving it as it is/was doesn't harm anything. DF From sekiya@sfc.wide.ad.jp Wed Oct 9 17:00:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:00:58 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A00stG016270 for ; Wed, 9 Oct 2002 17:00:55 -0700 Received: from KAWORI.onaka.info ([IPv6:2001:258:3:f050:a8e3:375d:524:7871]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g9A00ZMa024700; Thu, 10 Oct 2002 09:00:35 +0900 Date: Thu, 10 Oct 2002 09:00:34 +0900 Message-ID: From: Yuji Sekiya To: "David S. Miller" Cc: dfawcus@cisco.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021009.164504.28085695.davem@redhat.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/20.7 (i386-*-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15pre1-IPv6 (SHOUBU:63) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev At Wed, 09 Oct 2002 16:45:04 -0700 (PDT), ** David S. Miller wrote: > The reason we change the prefix length from /10 to /64 is > following spec and adapting other imprementations. > > I think Derek's explanation shows that the specification > allows the /10 behavior. Hmm... we interpret the spec as /64 prefix. > Also, I suspect that since Derek works for Cisco, some "other > implementations" behave how he describes. :-) I have cisco box which installed IPv6 IOS. But it defines no prefix length at an interface, FastEthernet4/1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::201:64FF:FEA3:ED55 and outgoing interface of routing table is NULL ? :-) L FE80::/10 [0/0] via ::, Null0, 7w0d -- Yuji Sekiya From dfawcus@cisco.com Wed Oct 9 17:02:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:02:50 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A02ltG016499 for ; Wed, 9 Oct 2002 17:02:48 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9A01PxA009690; Thu, 10 Oct 2002 02:01:26 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA15099; Thu, 10 Oct 2002 01:02:34 +0100 (BST) Date: Thu, 10 Oct 2002 01:02:34 +0100 From: Derek Fawcus To: "David S. Miller" Cc: sekiya@sfc.wide.ad.jp, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010010234.B8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20021009.164504.28085695.davem@redhat.com>; from davem@redhat.com on Wed, Oct 09, 2002 at 04:45:04PM -0700 X-archive-position: 609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Wed, Oct 09, 2002 at 04:45:04PM -0700, David S. Miller wrote: > From: Yuji Sekiya > Date: Thu, 10 Oct 2002 08:41:52 +0900 > > The reason we change the prefix length from /10 to /64 is > following spec and adapting other imprementations. > > I think Derek's explanation shows that the specification > allows the /10 behavior. But as someone else pointed out (sorry I'm to lazy to check the thread), one would still be able to manually adjust the Linux routing table to get it into the /10 behaviour. So frankly I'm not too fussed which behaviour is the default, I was just pointing out (what to me seemed to be) a change of dubious quality. (Then letting myself get into an argument over specs - when will I learn :-) DF From dfawcus@cisco.com Wed Oct 9 17:04:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:04:55 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A04rtG016831 for ; Wed, 9 Oct 2002 17:04:53 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9A03VC0009829; Thu, 10 Oct 2002 02:03:31 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA18007; Thu, 10 Oct 2002 01:04:39 +0100 (BST) Date: Thu, 10 Oct 2002 01:04:39 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010010439.C8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 09:00:34AM +0900 X-archive-position: 610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 09:00:34AM +0900, Yuji Sekiya wrote: > At Wed, 09 Oct 2002 16:45:04 -0700 (PDT), > ** David S. Miller wrote: > > > The reason we change the prefix length from /10 to /64 is > > following spec and adapting other imprementations. > > > > I think Derek's explanation shows that the specification > > allows the /10 behavior. > > Hmm... we interpret the spec as /64 prefix. > > > Also, I suspect that since Derek works for Cisco, some "other > > implementations" behave how he describes. :-) > > I have cisco box which installed IPv6 IOS. > But it defines no prefix length at an interface, > > FastEthernet4/1 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::201:64FF:FEA3:ED55 > > and outgoing interface of routing table is NULL ? :-) > > L FE80::/10 [0/0] > via ::, Null0, 7w0d Turn on 'debug ipv6 nd', 'debug ipv6 icmp', 'debug ipv6 pack d' Then do 'ping ipv6' specify a link local of say fe80:1910::10 and an egress interface, and watch what happens. DF From dfawcus@cisco.com Wed Oct 9 17:11:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:11:04 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A0B1tG017411 for ; Wed, 9 Oct 2002 17:11:02 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9A09dhT010306; Thu, 10 Oct 2002 02:09:40 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA18359; Thu, 10 Oct 2002 01:10:48 +0100 (BST) Date: Thu, 10 Oct 2002 01:10:48 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010011048.D8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 09:00:34AM +0900 X-archive-position: 611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 09:00:34AM +0900, Yuji Sekiya wrote: > > I have cisco box which installed IPv6 IOS. Did I mention any specific names :-) > But it defines no prefix length at an interface, Not really suprising, it's meaningless. > FastEthernet4/1 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::201:64FF:FEA3:ED55 > > and outgoing interface of routing table is NULL ? :-) > > L FE80::/10 [0/0] > via ::, Null0, 7w0d Well, that prefix is on all ipv6 enabled interfaces. so again a bit meaningless. Anyway, that's showing a Local entry not a connected entry. DF From sekiya@sfc.wide.ad.jp Wed Oct 9 17:15:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:15:08 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A0F5tG017748 for ; Wed, 9 Oct 2002 17:15:06 -0700 Received: from KAWORI.onaka.info ([IPv6:2001:258:3:f050:a8e3:375d:524:7871]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g9A0EjMa024840; Thu, 10 Oct 2002 09:14:45 +0900 Date: Thu, 10 Oct 2002 09:14:45 +0900 Message-ID: From: Yuji Sekiya To: Derek Fawcus Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021010010439.C8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/20.7 (i386-*-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15pre1-IPv6 (SHOUBU:63) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev At Thu, 10 Oct 2002 01:04:39 +0100, Derek Fawcus wrote: > Turn on 'debug ipv6 nd', 'debug ipv6 icmp', 'debug ipv6 pack d' > > Then do 'ping ipv6' specify a link local of say fe80:1910::10 and > an egress interface, and watch what happens. OK. Oct 10 09:09:15: ICMPv6-ND: DELETE -> INCMP: FE80:1910::10 Oct 10 09:09:15: ICMPv6-ND: Sending NS for FE80:1910::10 on FastEthernet4/1 Oct 10 09:09:15: IPV6: source FE80::201:64FF:FEA3:ED55 (local) Oct 10 09:09:15: dest FF02::1:FF00:10 (FastEthernet4/1) Oct 10 09:09:15: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating Oct 10 09:09:15: IPv6: Sending on FastEthernet4/1 Oct 10 09:09:15: IPv6: Encapsulation failed Encapsulation failed ... ??? :-) -- Yuji Sekiya From dfawcus@cisco.com Wed Oct 9 17:21:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:21:25 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A0LMtG018173 for ; Wed, 9 Oct 2002 17:21:23 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9A0K0rJ010934; Thu, 10 Oct 2002 02:20:00 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA18957; Thu, 10 Oct 2002 01:21:09 +0100 (BST) Date: Thu, 10 Oct 2002 01:21:09 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010012108.E8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> <20021010010439.C8102@edi-view1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 09:14:45AM +0900 X-archive-position: 613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 09:14:45AM +0900, Yuji Sekiya wrote: > At Thu, 10 Oct 2002 01:04:39 +0100, > Derek Fawcus wrote: > > > Turn on 'debug ipv6 nd', 'debug ipv6 icmp', 'debug ipv6 pack d' > > > > Then do 'ping ipv6' specify a link local of say fe80:1910::10 and > > an egress interface, and watch what happens. > > OK. > > Oct 10 09:09:15: ICMPv6-ND: DELETE -> INCMP: FE80:1910::10 > Oct 10 09:09:15: ICMPv6-ND: Sending NS for FE80:1910::10 on FastEthernet4/1 > Oct 10 09:09:15: IPV6: source FE80::201:64FF:FEA3:ED55 (local) > Oct 10 09:09:15: dest FF02::1:FF00:10 (FastEthernet4/1) > Oct 10 09:09:15: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating > Oct 10 09:09:15: IPv6: Sending on FastEthernet4/1 > Oct 10 09:09:15: IPv6: Encapsulation failed > > Encapsulation failed ... ??? :-) Well there was no one to respond to the NS, so it couldn't figure out what dest MAC address to shove in the ethernet packet. Hence the ethernet encap failed. Say if you sent such a packet over the link to the router, and it tried to forward it without the neighbour being there, you should get an ICMP error generated. But anyway it was trying to resolve a neighbour entry, if someone responded, it'd have sent the packet. Now try it with a box on the link which will respond to the NS for that address. DF From sekiya@sfc.wide.ad.jp Wed Oct 9 17:35:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:35:48 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A0ZjtG018585 for ; Wed, 9 Oct 2002 17:35:46 -0700 Received: from KAWORI.onaka.info ([IPv6:2001:258:3:f050:a8e3:375d:524:7871]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g9A0ZQMa025007; Thu, 10 Oct 2002 09:35:26 +0900 Date: Thu, 10 Oct 2002 09:35:26 +0900 Message-ID: From: Yuji Sekiya To: Derek Fawcus Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021010012108.E8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> <20021010010439.C8102@edi-view1.cisco.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/20.7 (i386-*-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15pre1-IPv6 (SHOUBU:63) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev At Thu, 10 Oct 2002 01:21:09 +0100, Derek Fawcus wrote: > Now try it with a box on the link which will respond to the NS for that > address. OK. I have assigned fe80:1910::10/64 link-local address to USAGI linux box and tried to ping ipv6. Target IPv6 address: fe80:1910::10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands? [no]: Output Interface: FastEthernet4/1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80:1910::10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Oct 10 09:27:35: IPV6: source FE80::201:64FF:FEA3:ED55 (local) Oct 10 09:27:35: dest FE80:1910::10 (FastEthernet4/1) Oct 10 09:27:35: traffic class 224, flow 0x0, len 64+16, prot 58, hops 255, originating Oct 10 09:27:35: IPv6: Sending on FastEthernet4/1 -- Yuji Sekiya From dfawcus@cisco.com Wed Oct 9 17:42:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:42:58 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A0gttG018979 for ; Wed, 9 Oct 2002 17:42:55 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9A0fTmJ013615; Thu, 10 Oct 2002 02:41:29 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA17103; Thu, 10 Oct 2002 01:42:37 +0100 (BST) Date: Thu, 10 Oct 2002 01:42:37 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010014237.F8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> <20021010010439.C8102@edi-view1.cisco.com> <20021010012108.E8102@edi-view1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 09:35:26AM +0900 X-archive-position: 615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 09:35:26AM +0900, Yuji Sekiya wrote: > OK. I have assigned fe80:1910::10/64 link-local address to > USAGI linux box and tried to ping ipv6. > > Target IPv6 address: fe80:1910::10 > Repeat count [5]: > Datagram size [100]: > Timeout in seconds [2]: > Extended commands? [no]: > Output Interface: FastEthernet4/1 > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to FE80:1910::10, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms > > Oct 10 09:27:35: IPV6: source FE80::201:64FF:FEA3:ED55 (local) > Oct 10 09:27:35: dest FE80:1910::10 (FastEthernet4/1) > Oct 10 09:27:35: traffic class 224, flow 0x0, len 64+16, prot 58, hops 255, originating > Oct 10 09:27:35: IPv6: Sending on FastEthernet4/1 Well what do you know? At least one implementation supports that type of config. Anyway, I as said in an earlier email, do whatever you want. I just considered that change to be dubious. DF From sekiya@sfc.wide.ad.jp Wed Oct 9 17:56:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 17:56:51 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A0umtG019506 for ; Wed, 9 Oct 2002 17:56:48 -0700 Received: from KAWORI.onaka.info ([IPv6:2001:258:3:f050:a8e3:375d:524:7871]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g9A0uOMa025114; Thu, 10 Oct 2002 09:56:25 +0900 Date: Thu, 10 Oct 2002 09:56:24 +0900 Message-ID: From: Yuji Sekiya To: Derek Fawcus Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses In-Reply-To: <20021010014237.F8102@edi-view1.cisco.com> References: <20021010002902.A3803@edi-view1.cisco.com> <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> <20021010010439.C8102@edi-view1.cisco.com> <20021010012108.E8102@edi-view1.cisco.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.3 Emacs/20.7 (i386-*-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15pre1-IPv6 (SHOUBU:63) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-archive-position: 616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev At Thu, 10 Oct 2002 01:42:37 +0100, Derek Fawcus wrote: > Well what do you know? At least one implementation supports that type of > config. ??? I can underdtand there is no interoperability issue with cisco box (with /10 link-local prefix ?) and USAGI kernel(with /64 link-local prefix). :-) -- Yuji Sekiya From dfawcus@cisco.com Wed Oct 9 18:12:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 18:12:11 -0700 (PDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A1C8tG020118 for ; Wed, 9 Oct 2002 18:12:09 -0700 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9A1Ak0n015393; Thu, 10 Oct 2002 03:10:46 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA14581; Thu, 10 Oct 2002 02:11:54 +0100 (BST) Date: Thu, 10 Oct 2002 02:11:54 +0100 From: Derek Fawcus To: Yuji Sekiya Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses Message-ID: <20021010021154.G8102@edi-view1.cisco.com> References: <20021009.162438.82081593.davem@redhat.com> <20021009.164504.28085695.davem@redhat.com> <20021010010439.C8102@edi-view1.cisco.com> <20021010012108.E8102@edi-view1.cisco.com> <20021010014237.F8102@edi-view1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from sekiya@sfc.wide.ad.jp on Thu, Oct 10, 2002 at 09:56:24AM +0900 X-archive-position: 617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dfawcus@cisco.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 09:56:24AM +0900, Yuji Sekiya wrote: > > I can underdtand there is no interoperability issue with cisco box > (with /10 link-local prefix ?) and USAGI kernel(with /64 link-local > prefix). :-) Mind it's interesting that the above currently works. I suspect that this is because the ping was originated on the cisco box, and hence ND was triggered, with the linux box probably gleaning info from the NS to create a STALE entry. That STALE entry would then probably have been probed to get a REACHABLE entry. What happens if you clear the ND entries (on both boxes), swap the link local addresses, then ping from the Linux box to the cisco box? I suspect that the ping will fail. As ND will never be triggered, and hence the host routes will not be created. Another alternative would be if one was say fe80:1910::10 and the other say fe80:2010::20, that would probably fail with the ping originated from the linux end, but I'm not sure if the linux box would respond when the ping was originated from the cisco end. Assuming my guess about the gleaning above is correct, it probably will. DF From hadi@cyberus.ca Wed Oct 9 19:29:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 19:29:25 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A2TMtG021026 for ; Wed, 9 Oct 2002 19:29:23 -0700 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 WAA01839; Wed, 9 Oct 2002 22:29:22 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9A2M5U16158; Wed, 9 Oct 2002 22:22:05 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 9 Oct 2002 22:22:05 -0400 (EDT) From: jamal To: Jason Lunz cc: Subject: Re: How can we bound one CPU to one Gigabit NIC? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 618 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, 8 Oct 2002, Jason Lunz wrote: > hadi@cyberus.ca said: > > Can you repeat these tests with NAPI and no binding and see if you get > > any reordering? > > Wouldn't he need a NAPIfied SysKonnect driver? I wasn't aware anyone had > converted it yet. Or is it enough for him to check the blog_dev path? Duh. There is no NAPIfied SysKonnect driver ;-> Well he didnt bother responding, so he may have figured that out. SysKonnect gige is a bad piece of hardware (bad csuming hware; we tried to build a NIC out of it) so i wouldnt recommend for him to use it. cheers, jamal From hadi@cyberus.ca Wed Oct 9 19:31:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 19:31:25 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A2VNtG021224 for ; Wed, 9 Oct 2002 19:31:23 -0700 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 WAA02441; Wed, 9 Oct 2002 22:31:22 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9A2O6m16164; Wed, 9 Oct 2002 22:24:06 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 9 Oct 2002 22:24:06 -0400 (EDT) From: jamal To: Jason Lunz cc: Subject: Re: How can we bound one CPU to one Gigabit NIC? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 619 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, 9 Oct 2002, jamal wrote: B> > > hadi@cyberus.ca said: > > > Can you repeat these tests with NAPI and no binding and see if you get > > > any reordering? > > > > Wouldn't he need a NAPIfied SysKonnect driver? I wasn't aware anyone had > > converted it yet. Or is it enough for him to check the blog_dev path? > > Duh. There is no NAPIfied SysKonnect driver ;-> > Well he didnt bother responding, so he may have figured that out. > SysKonnect gige is a bad piece of hardware (bad csuming hware; we tried > to build a NIC out of it) so i wouldnt recommend for him to use it. > I mean tried to use it ... cheers, jamal From hadi@cyberus.ca Wed Oct 9 19:54:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 19:54:13 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A2sAtG021898 for ; Wed, 9 Oct 2002 19:54:10 -0700 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 WAA09284; Wed, 9 Oct 2002 22:54:03 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9A2kls16212; Wed, 9 Oct 2002 22:46:47 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 9 Oct 2002 22:46:47 -0400 (EDT) From: jamal To: Vividh Siddha cc: , "David S. Miller" Subject: Re: PROBLEM: Interface address change netlink socket problem.(Patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 620 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 Moved to netdev where it belongs. Vividh in the future please post to netdev or at least cross-post to it ... because the kernel list FAQ says so. In your posting you say: > Imagine a interface eth0 with address 10.10.10.10, netmask 0xffffff00 > and broadcast 10.10.10.255. > >For eg: if the following command is issued: >ifconfig eth0 10.10.10.50 netmask 0xffffff00 broadcast 10.10.10.255 > > The kernel sends the following three sets of messages on the netlink >socket: > >Interface address delete: (with address 10.10.10.10) >Interface address add : (with address 10.10.10.50) > >Interface address delete: (with address 10.10.10.50) >Interface address add : (with address 10.10.10.50) > >Interface address delete: (with address 10.10.10.50) >Interface address add : (with address 10.10.10.50) > >Ideally as only the interface address is changed only one address >delete/add should be sent. State is not maintained in user space. You change that IP address, it actually gets deleted then a new one added. The bcast and netmask changeto defaults as a result; you then change the netmask and broadcast with each requiring a call from user space. If you modify your netlink program to print both net and broadcast address you should see this. BTW, you MUST check for these. Example try just: ifconfig eth0 10.10.10.50 and after you change it try: ifconfig eth0 10.10.10.50 netmask 0xffffff00 and then ifconfig eth0 10.10.10.50 netmask 0xffffff00 broadcast 10.10.10.255 cheers, jamal From vividh@ipinfusion.com Wed Oct 9 21:23:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 09 Oct 2002 21:23:59 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A4NttG023468 for ; Wed, 9 Oct 2002 21:23:55 -0700 Received: from user-112ugs2.biz.mindspring.com ([66.47.67.130] helo=ipinfusion.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17zUra-0003lW-00; Wed, 09 Oct 2002 21:23:54 -0700 Message-ID: <3DA500D7.8000704@ipinfusion.com> Date: Wed, 09 Oct 2002 21:23:51 -0700 From: Vividh Siddha User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: PROBLEM: Interface address change netlink socket problem.(Patch References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vividh@ipinfusion.com Precedence: bulk X-list: netdev Thats true but we are working around a problem which exists in the Linux stack. Ideally when we set only a interface address, the netmask should remain the same as it was before. Also the default netmasks based on classes might not be what is set. If we set netmask as /23, then: ifconfig eth0 10.10.10.50 will cause the netmask to be /8. The end result of all of these is correct but the intermediate messages can cause problems in higher layer protocols. vividh jamal wrote: >Moved to netdev where it belongs. Vividh in the future please post >to netdev or at least cross-post to it ... because the kernel list >FAQ says so. > >In your posting you say: > > >>Imagine a interface eth0 with address 10.10.10.10, netmask 0xffffff00 >>and broadcast 10.10.10.255. >> >>For eg: if the following command is issued: >>ifconfig eth0 10.10.10.50 netmask 0xffffff00 broadcast 10.10.10.255 >> >>The kernel sends the following three sets of messages on the netlink >>socket: >> >>Interface address delete: (with address 10.10.10.10) >>Interface address add : (with address 10.10.10.50) >> >>Interface address delete: (with address 10.10.10.50) >>Interface address add : (with address 10.10.10.50) >> >>Interface address delete: (with address 10.10.10.50) >>Interface address add : (with address 10.10.10.50) >> >>Ideally as only the interface address is changed only one address >>delete/add should be sent. >> >> > >State is not maintained in user space. You change that IP address, >it actually gets deleted then a new one added. The bcast and netmask >changeto defaults as a result; you then change the netmask and >broadcast with each requiring a call from user space. If you modify your >netlink program to print both net and broadcast address you should see >this. BTW, you MUST check for these. > >Example try just: >ifconfig eth0 10.10.10.50 > >and after you change it try: >ifconfig eth0 10.10.10.50 netmask 0xffffff00 > >and then >ifconfig eth0 10.10.10.50 netmask 0xffffff00 broadcast 10.10.10.255 > >cheers, >jamal > > > > From newsletters@the-financial-news.com Thu Oct 10 00:16:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 00:16:22 -0700 (PDT) Received: from wtnserver (213-96-214-72.uc.nombres.ttd.es [213.96.214.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9A7GAtG026697 for ; Thu, 10 Oct 2002 00:16:12 -0700 Received: from EI2 by wtnserver with SMTP (MDaemon.v3.1.2.R) for ; Thu, 10 Oct 2002 09:12:49 +0200 From: "The Financial News" Subject: Development countries. News in brief To: netdev@oss.sgi.com MIME-Version: 1.0 Date: Thu, 10 Oct 2002 09:08:56 +0200 X-Priority: 3 X-Library: Indy 8.0.22 X-MDRcpt-To: netdev@oss.sgi.com X-Return-Path: newsletters@the-financial-news.com X-MDaemon-Deliver-To: netdev@oss.sgi.com Reply-To: newsletters@the-financial-news.com Message-ID: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 4625 X-archive-position: 622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: newsletters@the-financial-news.com Precedence: bulk X-list: netdev The Financial News, October 2002 Production Mini-plants in mobile containers. Co-investment Program "...Science Network will supply to countries and developing regions the tec= hnology and the necessary support for the production in series of Mini-plan= ts in mobile containers (40-foot). The Mini-plant system is designed in suc= h a way that all the production machinery is fixed on the platform of the c= ontainer, with all wiring, piping, and installation parts; that is to say, = they are fully equipped... and the mini-plant is ready for production." More than 700 portable production systems: Bakeries, Steel Nails, Welding E= lectrodes, Tire Retreading, Reinforcement Bar Bending for Construction Fram= ework, Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum= Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasse= s, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Me= sh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitar= y Material, Hypodermic Syringes, Hemostatic Clamps, etc.=20 Science Network has started a process of Co-investment for the installation= of small Assembly plants to manufacture in series the Mini- plants of portable production on the site, region or country where they may= be required. One of the most relevant features is the fact that these plan= ts will be connected to the World Trade System (WTS) with access to more th= an 50 million raw materials, products and services and automatic transactio= ns for world trade. Due to financial reasons, involving cost and social impact, the right thing= to do is to set up assembly plants in the same countries and regions, usin= g local resources (labor, some equipment, etc.) Science Network participates with 50% in the investment of each Assembly pl= ant. For more information: Min= i-plants in mobile containers By Steven P. Leibacher, The Financial News, Editor Mini-plantas de produccion en contenedores moviles. Programa de Co-inversion "...Science Network suministrara a paises y regiones en vias de desarrollo = la tecnologia y el apoyo necesario para la fabricacion en serie de Mini-pla= ntas de produccion en contenedores moviles (40-foot). El sistema de mini-pl= antas esta dise=F1ado de forma que todas las maquinas de produccion van ins= taladas fijas sobre la propia plataforma del contenedor, con el cableado, t= uberias e instalaciones; es decir, completamente equipadas... y a partir de= ese momento est=E1n listas para producir."=20 Mas de 700 sistemas de produccion portatil: Panaderias, Producci=F3n de cla= vos de acero, Electrodos para soldadura, Recauchutado de neumaticos, Curvad= o de hierro para armaduras de construccion, Lamina perfilada para cubiertas= , techos y cerramientos de fachada, Bidones de chapa, Cubos de aluminio, Me= naje de polipropileno inyectado, Piezas de melamina prensada (vasos, platos= , tazas, cafeteras, etc.) Silenciadores para vehiculos, Malla electrosoldad= a para la construccion, Bolsas y envases de plastico, Unidades moviles de a= sistencia medica, Material sanitario (jeringas hipodermicas, Pinzas hemosta= ticas, etc.) Science Network ha puesto en marcha un proceso de Co-inversion para la inst= alacion de peque=F1as Plantas ensambladoras para fabricar en serie las Mini= -plantas de produccion portatil, en el lugar, region o pais que lo necesite= . Una de las caracter=EDsticas relevantes es el hecho de que dichas plantas= quedaran conectadas al Sistema del Comercio Mundial (WTS) con acceso a mas= de 50 millones de mercancias, materia primas, productos, servicios y las o= peraciones automaticas de comercio internacional. Resulta obvio que por razones economicas, de costes y de impacto social, lo= apropiado es instalar plantas ensambladoras en los mismos paises y regione= s asi como utilizar los recursos locales (mano de obra, ciertos equipamient= os, etc.) Science Network participa al 50% en la inversion de cada Planta ensamblador= a. Para recibir mas informacion: Mini-plantas de produccion en contenedores moviles Steven P. Leibacher, The Financial News, Editor ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, pl= ease return us indicating: remove or un-subscribe in 'subject' field, Thank= s. Editor =A9 2002 The Financial News. All rights reserved. [[HTML alternate version deleted]] From hadi@cyberus.ca Thu Oct 10 05:10:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 05:10:43 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ACAbtG012992 for ; Thu, 10 Oct 2002 05:10:38 -0700 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 IAA18242; Thu, 10 Oct 2002 08:10:35 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9AC3IN17026; Thu, 10 Oct 2002 08:03:18 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Thu, 10 Oct 2002 08:03:18 -0400 (EDT) From: jamal To: Vividh Siddha cc: , "David S. Miller" Subject: Re: PROBLEM: Interface address change netlink socket problem.(Patch In-Reply-To: <3DA500D7.8000704@ipinfusion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 623 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, 9 Oct 2002, Vividh Siddha wrote: > Thats true but we are working around a problem which exists in the Linux > stack. Ideally when we set only a interface address, the netmask should > remain the same as it was before. Also the default netmasks based on > classes might not be what is set. If we set netmask as /23, then: > > ifconfig eth0 10.10.10.50 > > will cause the netmask to be /8. The end result of all of these is correct but the intermediate messages can cause problems in higher layer protocols. > calling it "a problem which exists on the linux stack" is pushing it .. You pass three operations to ifconfig; "change" ipaddr, "change" netmask, "change" broadcast. 1) There is no atomic "change" operator. It translates to "add" then "delete" from userland. 2) You delete the IP address which as the primary piece of data resets everything including netmask and broadcasts to defaults There are 2 ways to formally and correctly do it: introduce some form of two-phase commit. You send all the commands to the kernel and then send it a commit to tell it to make the changes. The other way to do it is to introduce a change operator; Both these two break BSD semantics. OTOH, you can do either by working with netlink by batching all three atomic operations and introducing some new flags. cheers, jamal From pekkas@netcore.fi Thu Oct 10 07:29:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 07:29:55 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AETmtG019929 for ; Thu, 10 Oct 2002 07:29:49 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9AETc309322; Thu, 10 Oct 2002 17:29:39 +0300 Date: Thu, 10 Oct 2002 17:29:38 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: netdev@oss.sgi.com, Subject: Re: [PATCH] IPv6: Improvement of Source Address Selection In-Reply-To: <20021006.033351.33728380.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 624 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, 6 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: Dave, Alexey.. I think there has to be a high-level decision on how to proceed here. I'm referring to the optimization. TCP or other connection-oriented protocols use this one per connection; UDP and the like probably once per packet. The latter is at least quite undesirable, as you pointed out. The question is how one can proceed here, what kind of caching or a the type of approach taken. Putting the stuff in the routing table could work, but then this algorithm would have to be re-run always when there are changes in any address in the node. There might be other ways. -- 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 yoshfuji@linux-ipv6.org Thu Oct 10 08:23:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 08:23:23 -0700 (PDT) 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 g9AFNJtG021277 for ; Thu, 10 Oct 2002 08:23:20 -0700 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 g9AFNLlw005073; Fri, 11 Oct 2002 00:23:21 +0900 Date: Fri, 11 Oct 2002 00:23:21 +0900 (JST) Message-Id: <20021011.002321.27802563.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Improvement of Source Address Selection From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021006.033351.33728380.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-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: 625 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, 10 Oct 2002 17:29:38 +0300 (EEST)), Pekka Savola says: > Dave, Alexey.. I think there has to be a high-level decision on how to > proceed here. I'm referring to the optimization. TCP or other > connection-oriented protocols use this one per connection; UDP and the > like probably once per packet. The latter is at least quite undesirable, > as you pointed out. Hmm, what we think is, performance critical applications such as DVTS (Digital Video Transport System) will do bind(2) so the latter is not fatal problem. We need improved source address selection for further feature(s) (like privacy extentions). Our code is easy to implement further rules and order of calculation cost is same as before; O(n) while n is number of addresses. We think netdev and/or usagi can develop optimization later, and we think people can survive until then. > Putting the stuff in the routing table could work, but then this algorithm > would have to be re-run always when there are changes in any address in > the node. There might be other ways. How about - store one (daddr,ddev,saddr,tstamp) set in sk - update addrconf_tstamp in addrconf_verify() (etc.) - check tstamp and addrconf_tstamp and use saddr if ok in saddr selection --yoshfuji From jmorris@intercode.com.au Thu Oct 10 09:36:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 09:37:04 -0700 (PDT) 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 g9AGaotG031016 for ; Thu, 10 Oct 2002 09:36:57 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id CAA03243; Fri, 11 Oct 2002 02:36:41 +1000 Date: Fri, 11 Oct 2002 02:36:41 +1000 (EST) From: James Morris To: Martin Pool cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 626 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 Martin, Below is a simplified version of your patch, which maintains the (skb->len < mss_now) check per Alexey's comments. Note that I've not been able to reproduce the problem with network configurations from 10-1000Gbps and various combinations of hosts, kernels and 'server' applications. I did run into what looked like stalled ESTABLISHED/FIN_WAIT1 connections, although these turned out to be the (valid) result of the server advertising zero windows after it ran out of resources. The FIN_WAIT1 states on the client were running timers and performing zero window probes. A further check showed that it didn't matter if the client socket sockets were corked or not. Would you please give this patch some testing? (It would be really great if any of the RH 6.2 distcc users who reported problems could test it also). Thanks, - James -- James Morris diff -urN -X dontdiff linux-2.2.22.orig/net/ipv4/tcp_output.c linux-2.2.22.corkfix/net/ipv4/tcp_output.c --- linux-2.2.22.orig/net/ipv4/tcp_output.c Fri May 10 12:10:08 2002 +++ linux-2.2.22.corkfix/net/ipv4/tcp_output.c Fri Oct 11 01:22:33 2002 @@ -766,24 +766,7 @@ TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_FIN; TCP_SKB_CB(skb)->end_seq++; tp->write_seq++; - - /* Special case to avoid Nagle bogosity. If this - * segment is the last segment, and it was queued - * due to Nagle/SWS-avoidance, send it out now. - */ - if(tp->send_head == skb && - !sk->nonagle && - skb->len < (tp->mss_cache >> 1) && - tp->packets_out && - !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_URG)) { - update_send_head(sk); - TCP_SKB_CB(skb)->when = tcp_time_stamp; - tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tp->packets_out++; - tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC)); - if(!tcp_timer_is_set(sk, TIME_RETRANS)) - tcp_reset_xmit_timer(sk, TIME_RETRANS, tp->rto); - } + tcp_push_pending_frames(sk, tp); } else { /* Socket is locked, keep trying until memory is available. */ for (;;) { From jmorris@intercode.com.au Thu Oct 10 09:43:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 09:43:27 -0700 (PDT) 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 g9AGhHtG031323 for ; Thu, 10 Oct 2002 09:43:19 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id CAA03284; Fri, 11 Oct 2002 02:43:10 +1000 Date: Fri, 11 Oct 2002 02:43:09 +1000 (EST) From: James Morris To: Martin Pool cc: netdev@oss.sgi.com Subject: Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 627 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 > configurations from 10-1000Gbps and various combinations of hosts, kernels Er, that is 10-1000Mbps :-) - James -- James Morris From bcrl@redhat.com Thu Oct 10 15:35:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 15:35:37 -0700 (PDT) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9AMZTtG014284 for ; Thu, 10 Oct 2002 15:35:30 -0700 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 15F308001D2; Thu, 10 Oct 2002 18:35:29 -0400 (EDT) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id g9AMZT213482; Thu, 10 Oct 2002 18:35:29 -0400 Date: Thu, 10 Oct 2002 18:35:29 -0400 From: Benjamin LaHaise To: davem@redhat.com, netdev@oss.sgi.com Subject: [patch] add iocb to network protocols Message-ID: <20021010183528.A13432@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev Hello Dave, Below is a copy of the bk tree at: bk pull master.kernel.org:/home/bcrl/net-2.5 This tree adds the iocb parameter into the sendmsg and recvmsg operations within the network operations. sock_read and sock_write are also replaced by sock_aio_read/sock_aio_write, so this requires the other aio changes to fs/read_write.c that are in fresh trees from Linus. Comments? This will update the following files: include/linux/net.h | 9 ++ include/net/inet_common.h | 6 + include/net/sock.h | 82 ++++++++++++++++--------- include/net/tcp.h | 5 - include/net/udp.h | 3 net/atm/common.c | 8 +- net/atm/common.h | 8 +- net/ax25/af_ax25.c | 7 +- net/bluetooth/af_bluetooth.c | 3 net/core/sock.c | 8 +- net/decnet/af_decnet.c | 8 +- net/econet/af_econet.c | 9 +- net/ipv4/af_inet.c | 17 ++--- net/ipv4/raw.c | 7 +- net/ipv4/tcp.c | 5 - net/ipv4/udp.c | 7 +- net/ipx/af_ipx.c | 8 +- net/irda/af_irda.c | 9 +- net/llc/af_llc.c | 9 +- net/netlink/af_netlink.c | 6 + net/netrom/af_netrom.c | 8 +- net/packet/af_packet.c | 10 +-- net/rose/af_rose.c | 9 +- net/socket.c | 141 ++++++++++++++++++++++++++----------------- net/unix/af_unix.c | 12 ++- net/wanrouter/af_wanpipe.c | 9 +- net/x25/af_x25.c | 7 +- 27 files changed, 255 insertions(+), 165 deletions(-) through these ChangeSets: (02/10/10 1.741) correct sock_aio_write prototype (02/10/10 1.740) eliminate a compiler warning for aio_write in net/socket.c (02/10/10 1.733.4.2) clean up whitespace and patch import errors from net-kiocb patch (02/10/10 1.733.4.1) net-kiocb.diff through these patches: # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.740 -> 1.741 # net/socket.c 1.31 -> 1.32 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/10 bcrl@redhat.com 1.741 # correct sock_aio_write prototype # -------------------------------------------- # diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Thu Oct 10 18:27:23 2002 +++ b/net/socket.c Thu Oct 10 18:27:23 2002 @@ -92,7 +92,7 @@ static int sock_no_open(struct inode *irrelevant, struct file *dontcare); static ssize_t sock_aio_read(struct kiocb *iocb, char *buf, size_t size, loff_t pos); -static ssize_t sock_aio_write(struct kiocb *iocb, char *buf, +static ssize_t sock_aio_write(struct kiocb *iocb, const char *buf, size_t size, loff_t pos); static int sock_mmap(struct file *file, struct vm_area_struct * vma); # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.739 -> 1.740 # net/socket.c 1.30 -> 1.31 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/10 bcrl@redhat.com 1.740 # eliminate a compiler warning for aio_write in net/socket.c # -------------------------------------------- # diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Thu Oct 10 18:27:24 2002 +++ b/net/socket.c Thu Oct 10 18:27:24 2002 @@ -619,7 +619,7 @@ * is readable by the user process. */ -static ssize_t sock_aio_write(struct kiocb *iocb, char *ubuf, +static ssize_t sock_aio_write(struct kiocb *iocb, const char *ubuf, size_t size, loff_t pos) { struct sock_iocb *x = kiocb_to_siocb(iocb); # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.733.4.1 -> 1.733.4.2 # net/socket.c 1.29 -> 1.30 # include/net/sock.h 1.21 -> 1.22 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/10 torvalds@penguin.transmeta.com 1.733.1.27 # Clean up after timers - move the "timers" Makefile info # into the proper subdirectory (kernel) where it is used. # # Drop unused variables. # -------------------------------------------- # 02/10/10 axboe@suse.de 1.733.1.28 # [PATCH] excessive stack usage in cdrom # # CD-ROM puts struct cdrom_changer_info on the stack in a few places, this # is a bad idea since it's big (a bit over 1kb). This makes us allocate # it instead. # # Noticed by Anton. # -------------------------------------------- # 02/10/10 sam@ravnborg.org 1.733.1.29 # [PATCH] drivers/scsi - Makefile fix # # Reference to .ver file incorrect after recent makefile changes. # Grepped the kernel tree, and this is the only Makefile that # uses $(MODVERDIR). # -------------------------------------------- # 02/10/10 olaf.dietsche#list.linux-kernel@t-online.de 1.733.1.30 # [PATCH] 2.5.40: fix chmod/chown on procfs # # This patch allows to change uid, gid and mode of files and directories # located in procfs. # # Without this patch you can change uid, gid and mode as long as the # file is open. As soon as you close the file, it reverts back to its # default, which is root:root and readonly usually. # -------------------------------------------- # 02/10/10 paulus@samba.org 1.733.1.31 # [PATCH] add PCI device ID for Motorola MPC107 # # This patch adds the PCI device ID for the Motorola MPC107 host bridge. # The entry is already in the list at pciids.sf.net but isn't in the # kernel pci_ids.h file yet. Please apply this to your tree. # -------------------------------------------- # 02/10/10 paulus@samba.org 1.733.1.32 # [PATCH] adjust PPC sysctls # # This patch takes out the unused KERN_PPC_ZEROPAGED sysctl, and # restricts the KERN_PPC_POWERSAVE_NAP and KERN_PPC_L2CR sysctls to be # present only on those PPC processors where they are useful. This # patch only affects PPC. # -------------------------------------------- # 02/10/10 Andries.Brouwer@cwi.nl 1.733.1.33 # [PATCH] isofs fix # # The patch below removes some dead code and nonsense code. # The part that changes behaviour is # # - if (sbi->s_cruft == 'n' && # - (volume_seq_no != 0) && (volume_seq_no != 1)) { # - printk(KERN_WARNING "Warning: defective CD-ROM " # - "(volume sequence number %d). " # - "Enabling \"cruft\" mount option.\n", volume_seq_no); # - sbi->s_cruft = 'y'; # - } # # that has already bitten lots of people. # # Nothing is wrong with a volume sequence number different from 0 or 1. # (Cf. Ecma-119.pdf, Sections 4.17, 4.18, 6.6.) # -------------------------------------------- # 02/10/10 torvalds@penguin.transmeta.com 1.733.1.34 # Merge http://linux-isdn.bkbits.net/linux-2.5.make # into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.35 # [PATCH] A basic NFSv4 client for 2.5.x # # Instantiate a new file, include/linux/nfs4.h, which contains # constants and typedef's for the NFSv4 protocol (by analogy with # include/linux/nfs2.h and include/linux/nfs3.h). # # Also #include this file in a few places where it will be needed # later. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.36 # [PATCH] A basic NFSv4 client for 2.5.x # # In a number of places in the NFS client, I had to change # # #ifdef CONFIG_NFS_V3 # /* ... */ # #endif # # to # # #if defined(CONFIG_NFS_V3) || defined(CONFIG_NFS_V4) # /* ... */ # #endif # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.37 # [PATCH] A basic NFSv4 client for 2.5.x # # This patch changes the interface of the ->readdir() nfs_rpc_op # so that its first argument is a dentry instead of an inode. # # [Explanation: The dentry is required because in NFSv4, we need # to make use of the _parent_ directory's inode. This is because # NFSv4 servers no longer return an entry for ".." in the READDIR # response, so the client kernel needs to fake this entry, inode # number and all.] # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.38 # [PATCH] A basic NFSv4 client for 2.5.x # # This patch changes the interface of the ->setattr() nfs_rpc_op # so that its first argument is a dentry instead of an inode. # # [Explanation: The dentry is required because in NFSv4, we may # need to OPEN the file before doing the SETATTR. (This is # required if the file size is changed as part of the setattr.) # Opening the file requires making use of the containing # directory's inode.] # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.39 # [PATCH] A basic NFSv4 client for 2.5.x # # In NFSv4, there is no hard limit on the length of symlink text. # This patch changes the -ENAMETOOLONG test in nfs_symlink() accordingly. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.40 # [PATCH] A basic NFSv4 client for 2.5.x # # In NFSv4, an fsid is a 64-bit major number together with a 64-bit # minor number. In previous versions, an fsid is a single number. # This patch changes 'struct nfs_fattr' accordingly. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.41 # [PATCH] A basic NFSv4 client for 2.5.x # # This is a nontrivial change to the NFS client. # # NFSv4 defines a new file attribute, change_attr. This is a per-file # opaque quantity returned by the server, whose value is required to # change whenever the file is modified. If it exists, we want to use # it for all cache consistency checks in nfs_refresh_inode(). Some # operations also return a "pre-operation" value of the change_attr; # we want to take this into account too. # # First, define flags # NFS_ATTR_FATTR_V4 - indicates that the 'struct nfs_fattr' is an # NFSv4 fattr, so the change_attr field is valid # NFS_ATTR_PRE_CHANGE - indicates that the server returned a pre-operation # change_attr, so the pre_change_attr field is valid # # Second, change nfs_refresh_inode() so that the caches are invalidated # if there is a change_attr mismatch. Exception: If the pre_change_attr # tells us that the mismatch was caused by our operation, then do not # invalidate the caches. # # This patch should leave the logic in nfs_refresh_inode() unchanged # if neither of the new flags are set. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.42 # [PATCH] A basic NFSv4 client for 2.5.x # # If the NFS_ATTR_FATTR_V4 flag is set, use the NFSv3 convention for # the 'space_used' part of the fattr. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.43 # [PATCH] A basic NFSv4 client for 2.5.x # # This is a nontrivial change to the NFS client. # # Synchronous READ operations are currently done via the ->read() nfs_rpc_op. # Therefore, the synchronous READ path can easily be adapted for NFSv4. On # the other hand, the asynchronous READ path contains several NFSv3-specific # features, which make it difficult to adapt for NFSv4. # # In this patch and the next, we modify the async READ path to be # version-agnostic. This patch just changes the 'struct nfs_read_data' # so that the v2- and v3-specific parts are moved into a private area, # with room for a v4-specific part in parallel. None of the logic is # changed. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.44 # [PATCH] A basic NFSv4 client for 2.5.x # # This is a nontrivial change to the NFS client. # # In this patch, we finish modifying the async READ path so that it is # version-agnostic. We define a new nfs_rpc_op ->setup_read(), and move # the v2- and v3-specific code in nfs_read_rpcsetup() there. We also # have to change nfs_readpage() result so that the 'count' of bytes # read is a parameter. The extra parameter means that it can no longer # be ->tk_exit(). Instead, it is called from a version-specific ->tk_exit() # routine which is set in ->read_setup(). # # The upshot of all this is that the version-specific part of the # async READ path has been encapsulated in a new nfs_rpc_op # ->read_setup(), and NFSv4 can share the logic for asynchronous # READ's with NFSv2 and v3. # -------------------------------------------- # 02/10/10 trond.myklebust@fys.uio.no 1.733.1.45 # [PATCH] Fix NFS locking over TCP # # The 2.5.x RPC code is currently broken in that it demands that all # tasks that call xprt_create_proto() in order to open a TCP socket must # have CAP_NET_BIND_SERVICE capabilities, and must bind to a privileged # port. # # This breaks the NLM locking code and its use of the call_bind() RPC # portmapper lookup feature. # # This patch allows the built-in portmapper client to use unbound TCP # sockets if the user does not have the necessary capabilities. # -------------------------------------------- # 02/10/10 greg@kroah.com 1.733.1.46 # [PATCH] minor i386 timer changes for 2.5.41 # # Here's an additional patch that contains the cleanups I did to John's # timer patches. It does the following: # # - uses C99 initializers # - makes the timer list static # - adds better documentation to the timer function structure # - makes the timer init function return 0 on success # - NULL terminates the list of timers to make further patches # easier. # -------------------------------------------- # 02/10/10 dledford@redhat.com 1.733.1.47 # [PATCH] atp870 driver # # This is a minimal patch to allow me to load/use the atp module so I can do # further testing work on it. # -------------------------------------------- # 02/10/10 bcrl@bob.home.kvack.org 1.733.4.2 # clean up whitespace and patch import errors from net-kiocb patch # -------------------------------------------- # diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h Thu Oct 10 18:27:25 2002 +++ b/include/net/sock.h Thu Oct 10 18:27:25 2002 @@ -318,30 +318,6 @@ return container_of((void *)si, struct kiocb, private); } -/* sock_iocb: used to kick off async processing of socket ios */ -struct sock_iocb { - struct list_head list; - - int flags; - int size; - struct socket *sock; - struct sock *sk; - struct msghdr *msg, async_msg; - struct iovec async_iov; - struct scm_cookie *scm, async_scm; -}; - -static inline struct sock_iocb *kiocb_to_siocb(struct kiocb *iocb) -{ - BUG_ON(sizeof(struct sock_iocb) > KIOCB_PRIVATE_SIZE); - return (struct sock_iocb *)iocb->private; -} - -static inline struct kiocb *siocb_to_kiocb(struct sock_iocb *si) -{ - return container_of((void *)si, struct kiocb, private); -} - /* Used by processes to "lock" a socket state, so that * interrupts and bottom half handlers won't change it * from under us. It essentially blocks any incoming diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Thu Oct 10 18:27:25 2002 +++ b/net/socket.c Thu Oct 10 18:27:25 2002 @@ -117,7 +117,7 @@ static struct file_operations socket_file_ops = { .llseek = no_llseek, - .aio_read = sock_aio_read, + .aio_read = sock_aio_read, .aio_write = sock_aio_write, .poll = sock_poll, .ioctl = sock_ioctl, @@ -541,7 +541,7 @@ struct kiocb iocb; int ret; - init_sync_kiocb(&iocb, NULL); + init_sync_kiocb(&iocb, NULL); ret = __sock_sendmsg(&iocb, sock, msg, size); if (-EIOCBQUEUED == ret) ret = wait_on_sync_kiocb(&iocb); # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.733.1.15 -> 1.733.4.1 # net/llc/af_llc.c 1.31 -> 1.32 # net/ipv4/raw.c 1.11 -> 1.12 # include/net/tcp.h 1.19 -> 1.20 # net/ipv4/af_inet.c 1.19 -> 1.20 # net/ipx/af_ipx.c 1.21 -> 1.22 # net/ipv4/udp.c 1.11 -> 1.12 # net/bluetooth/af_bluetooth.c 1.6 -> 1.7 # net/ipv4/tcp.c 1.27 -> 1.28 # net/irda/af_irda.c 1.31 -> 1.32 # net/socket.c 1.28 -> 1.29 # include/linux/net.h 1.4 -> 1.5 # net/econet/af_econet.c 1.10 -> 1.11 # net/rose/af_rose.c 1.17 -> 1.18 # net/netrom/af_netrom.c 1.20 -> 1.21 # net/netlink/af_netlink.c 1.11 -> 1.12 # net/decnet/af_decnet.c 1.17 -> 1.18 # net/unix/af_unix.c 1.28 -> 1.29 # net/packet/af_packet.c 1.15 -> 1.16 # include/net/sock.h 1.19 -> 1.21 # net/core/sock.c 1.12 -> 1.13 # include/net/inet_common.h 1.3 -> 1.4 # net/atm/common.h 1.1 -> 1.2 # include/net/udp.h 1.4 -> 1.5 # net/ax25/af_ax25.c 1.15 -> 1.16 # net/x25/af_x25.c 1.20 -> 1.21 # net/wanrouter/af_wanpipe.c 1.9 -> 1.10 # net/atm/common.c 1.9 -> 1.10 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/10 bcrl@redhat.com 1.736 # Merge redhat.com:/md0/linus-2.5 into redhat.com:/md0/aio-2.5 # -------------------------------------------- # 02/10/10 mingo@elte.hu 1.733.1.16 # [PATCH] timer cleanups # # This is my latest timer patchset, it makes del_timer_sync() a bit more # robust wrt. code that re-adds timers from the timer handler. # # Other changes in the patch: # # - clean up cascading a bit. # # - do not save flags in __run_timer_list - we enter from an irqs-enabled # tasklet. # -------------------------------------------- # 02/10/10 akpm@digeo.com 1.733.1.17 # [PATCH] mremap use-after-free bugfix # # I have invented a new software development methodology! You send an # email to Hugh saying "I don't have the foggiest idea why this guy's # kernel is oopsing" and next morning, you get a patch! I shall patent # this. # # Since 2.5.3, move_vma() has been passing a freed vma into # move_page_tables(). Fix it to move back to the previous vma in the # list if we're about to delete this one. # # Thanks to Morten Helgesen for patient reporting, diagnosis and testing. # -------------------------------------------- # 02/10/10 akpm@digeo.com 1.733.1.18 # [PATCH] move_one_page atomicity fix # # The atomicicty fix for move_one_page() was not quite right. # # We only do the page_table_present() test if CONFIG_HIGHPTE=y. Which is # fine, but even with CONFIG_HIGHPTE=n, the pte mapping functions still # do an inc_preempt_count() due to their unconditional kmap_atomic(). So # we get a might_sleep() warning. # # The warning is actually bogus, because those pte's are always in # direct-mapped memory. # # So hm. Three fixes suggest themselves: # # 1: Run the page_table_present() test if CONFIG_HIGHMEM. # # Rejected: penalises non-pte_highmem setups # # 2: Make kmap_atomic() not do inc_preempt_count() is the page was # direct mapped. # # Rejected: I don't think we want kmap_atomic side effects to be # varying according to the page which was passed. # # 3: Change the pte mapping functions so they don't run kmap_atomic at # all if CONFIG_HIGHPTE=n # # This is what I did. And guess what? For CONFIG_HIGHMEM=y, # CONFIG_HIGHPTE=n this patch shrinks the kernel by 5 kbytes. Because # kmap_atomic is inlined. # # The lesson: we do way too much damn inlining. # -------------------------------------------- # 02/10/10 akpm@digeo.com 1.733.1.19 # [PATCH] fix the raw driver # # Fix the raw driver by tricking it into performing O_DIRECT IO against # the bound blockdev. # # - rewrite the i_mapping for /dev/raw/raw0 to point at the same thing # as bdev->bd_inode->i_mapping. We've performed a bdget() against the # blockdev, which should pin it for the correct lifetime. # # - set the O_DIRECT bit on the caller's file->flags. # -------------------------------------------- # 02/10/10 akpm@digeo.com 1.733.1.20 # [PATCH] remove radix_tree_reserve() # # From Hugh Dickins. # # radix_tree_reserve() exists solely for the tmpfs move_to_swap_cache() # and move_from_swap_cache() functions, and yet they don't need it: there # is no problem in the one page being simultaneously listed in two radix # trees (while both locks are held). Use radix_tree_insert(), and remove # radix_tree_reserve(); also removed a few blank lines. # -------------------------------------------- # 02/10/10 akpm@digeo.com 1.733.1.21 # [PATCH] remove the sched_yield from the ext3 fsync path # # The changed sched_yield() semantics have made ext3's transaction # batching terribly slow. # # Apparently a schedule() fixes that, although it probably breaks # transaction batching. # # This patch largely fixes my complaints about the new scheduler being # extremely sluggish to interactive applications. Evidently those # applications were calling fsync() and were spending extremely long # periods in sched_yield(). # -------------------------------------------- # 02/10/10 akpm@digeo.com 1.733.1.22 # [PATCH] make readv/writev return 0 for 0 segments # # Should resolve an ongoing fiasco concerning what we should return to # userspace if they do a readv or writev of zero segments. # # SuS is ambiguous, but implies EINVAL. We're currently returning # EINVAL, but 2.4 returns zero. # # I think zero makes more sense, and it is what 2.4 does. # -------------------------------------------- # 02/10/10 bcrl@redhat.com 1.737 # fix symbol export in fs/read_write.c # -------------------------------------------- # 02/10/10 johnstul@us.ibm.com 1.733.1.23 # [PATCH] linux-2.5.41_timer-changes_A4 (1/3 - infrastructure) # # The i386 time.c code is turning into a mess. We've got multiple # functions that do the same thing, only with different hardware, all # surrounded #ifdefs and even more difficult to follow #ifndefs. George # Anzinger is introducing a new ACPIpm time source, I'm going to attempt # to add the cyclone counter as a time source, and in the future there # will be HPET to deal with. These will not go in cleanly together as # things are now. # # Inspired by suggestions from Alan, this collection of patches # tries to clean up time.c by breaking out the PIT and TSC specific parts # into their own files. Additionally the patch creates an abstract # interface to use these existing time soruces, as well as make it easier # to add future time sources. # # It introduces "struct timer_ops" which gives the time code a # clear interface to use these different time sources. It also allows for # clearer conditional compilation of these various time sources. # # This first patch (part 1 of 3) provides the infrastructure # needed via the timer_ops structure, as well as the select_timer() # function for choosing the best available timer. # -------------------------------------------- # 02/10/10 johnstul@us.ibm.com 1.733.1.24 # [PATCH] linux-2.5.41_timer-changes_A4 (2/3 - bulk move) # # This is part 2 of 3 of my timer-change patch. Part 2 is just a # bulk move of code out of time.c and into timer_pit.c and timer_tsc.c. No # code is changed, only moved. # # Please note, this code will not compile without the final third # part of this patch collection. This was done for readability alone. # -------------------------------------------- # 02/10/10 johnstul@us.ibm.com 1.733.1.25 # [PATCH] linux-2.5.41_timer-changes_A4 (3/3 - integration) # # This is the final part 3 of 3 of my timer-change patch. Part 3 # integrates the moved code (from part 2) into the new infrastructure # (from part 1). # -------------------------------------------- # 02/10/10 johnstul@us.ibm.com 1.733.1.26 # [PATCH] linux-2.5.41_cyclone-timer_B2 # # In order to demonstrate how new time-sources are added to my # timer-changes patch. Here is my current version of my cyclone-timer # patch for 2.5.41. This uses the infrastructure set up in the # timer-changes_A4 patch set to add the cyclone counter (found on IBM # Summit Based hardware) as a time-source. # # The current code is not enabled as it also depends on James # Cleverdon's 2.5 summit patch, however it illustrates how cleanly new # time-sources can be added. # -------------------------------------------- # 02/10/10 stevef@smfhome1.austin.rr.com 1.733.3.1 # Initial check in of cifs filesystem version 0.54 for Linux 2.5 (to clean tree as one changeset) # -------------------------------------------- # 02/10/10 bcrl@bob.home.kvack.org 1.733.4.1 # net-kiocb.diff # -------------------------------------------- # diff -Nru a/include/linux/net.h b/include/linux/net.h --- a/include/linux/net.h Thu Oct 10 18:27:27 2002 +++ b/include/linux/net.h Thu Oct 10 18:27:27 2002 @@ -81,6 +81,7 @@ struct scm_cookie; struct vm_area_struct; struct page; +struct kiocb; struct proto_ops { int family; @@ -104,8 +105,12 @@ char *optval, int optlen); int (*getsockopt) (struct socket *sock, int level, int optname, char *optval, int *optlen); - int (*sendmsg) (struct socket *sock, struct msghdr *m, int total_len, struct scm_cookie *scm); - int (*recvmsg) (struct socket *sock, struct msghdr *m, int total_len, int flags, struct scm_cookie *scm); + int (*sendmsg) (struct kiocb *iocb, struct socket *sock, + struct msghdr *m, int total_len, + struct scm_cookie *scm); + int (*recvmsg) (struct kiocb *iocb, struct socket *sock, + struct msghdr *m, int total_len, int flags, + struct scm_cookie *scm); int (*mmap) (struct file *file, struct socket *sock, struct vm_area_struct * vma); ssize_t (*sendpage) (struct socket *sock, struct page *page, int offset, size_t size, int flags); }; diff -Nru a/include/net/inet_common.h b/include/net/inet_common.h --- a/include/net/inet_common.h Thu Oct 10 18:27:27 2002 +++ b/include/net/inet_common.h Thu Oct 10 18:27:27 2002 @@ -20,10 +20,12 @@ int addr_len, int flags); extern int inet_accept(struct socket *sock, struct socket *newsock, int flags); -extern int inet_recvmsg(struct socket *sock, +extern int inet_recvmsg(struct kiocb *iocb, + struct socket *sock, struct msghdr *ubuf, int size, int flags, struct scm_cookie *scm); -extern int inet_sendmsg(struct socket *sock, +extern int inet_sendmsg(struct kiocb *iocb, + struct socket *sock, struct msghdr *msg, int size, struct scm_cookie *scm); extern int inet_shutdown(struct socket *sock, int how); diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h Thu Oct 10 18:27:27 2002 +++ b/include/net/sock.h Thu Oct 10 18:27:27 2002 @@ -51,6 +51,7 @@ #include #include +#include /* for sock_iocb */ /* * This structure really needs to be cleaned up. @@ -242,9 +243,10 @@ int (*getsockopt)(struct sock *sk, int level, int optname, char *optval, int *option); - int (*sendmsg)(struct sock *sk, struct msghdr *msg, - int len); - int (*recvmsg)(struct sock *sk, struct msghdr *msg, + int (*sendmsg)(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, int len); + int (*recvmsg)(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, int len, int noblock, int flags, int *addr_len); int (*bind)(struct sock *sk, @@ -292,7 +294,53 @@ #define SOCK_BINDADDR_LOCK 4 #define SOCK_BINDPORT_LOCK 8 +/* sock_iocb: used to kick off async processing of socket ios */ +struct sock_iocb { + struct list_head list; + + int flags; + int size; + struct socket *sock; + struct sock *sk; + struct msghdr *msg, async_msg; + struct iovec async_iov; + struct scm_cookie *scm, async_scm; +}; + +static inline struct sock_iocb *kiocb_to_siocb(struct kiocb *iocb) +{ + BUG_ON(sizeof(struct sock_iocb) > KIOCB_PRIVATE_SIZE); + return (struct sock_iocb *)iocb->private; +} + +static inline struct kiocb *siocb_to_kiocb(struct sock_iocb *si) +{ + return container_of((void *)si, struct kiocb, private); +} +/* sock_iocb: used to kick off async processing of socket ios */ +struct sock_iocb { + struct list_head list; + + int flags; + int size; + struct socket *sock; + struct sock *sk; + struct msghdr *msg, async_msg; + struct iovec async_iov; + struct scm_cookie *scm, async_scm; +}; + +static inline struct sock_iocb *kiocb_to_siocb(struct kiocb *iocb) +{ + BUG_ON(sizeof(struct sock_iocb) > KIOCB_PRIVATE_SIZE); + return (struct sock_iocb *)iocb->private; +} + +static inline struct kiocb *siocb_to_kiocb(struct sock_iocb *si) +{ + return container_of((void *)si, struct kiocb, private); +} /* Used by processes to "lock" a socket state, so that * interrupts and bottom half handlers won't change it @@ -390,10 +438,10 @@ char *, int *); extern int sock_no_setsockopt(struct socket *, int, int, char *, int); -extern int sock_no_sendmsg(struct socket *, +extern int sock_no_sendmsg(struct kiocb *, struct socket *, struct msghdr *, int, struct scm_cookie *); -extern int sock_no_recvmsg(struct socket *, +extern int sock_no_recvmsg(struct kiocb *, struct socket *, struct msghdr *, int, int, struct scm_cookie *); extern int sock_no_mmap(struct file *file, diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h Thu Oct 10 18:27:27 2002 +++ b/include/net/tcp.h Thu Oct 10 18:27:27 2002 @@ -648,7 +648,8 @@ extern int tcp_v4_tw_remember_stamp(struct tcp_tw_bucket *tw); -extern int tcp_sendmsg(struct sock *sk, struct msghdr *msg, int size); +extern int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, int size); extern ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset, size_t size, int flags); extern int tcp_ioctl(struct sock *sk, @@ -739,7 +740,7 @@ int optname, char *optval, int optlen); extern void tcp_set_keepalive(struct sock *sk, int val); -extern int tcp_recvmsg(struct sock *sk, +extern int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len, int nonblock, int flags, int *addr_len); diff -Nru a/include/net/udp.h b/include/net/udp.h --- a/include/net/udp.h Thu Oct 10 18:27:27 2002 +++ b/include/net/udp.h Thu Oct 10 18:27:27 2002 @@ -64,7 +64,8 @@ extern int udp_connect(struct sock *sk, struct sockaddr *usin, int addr_len); -extern int udp_sendmsg(struct sock *sk, struct msghdr *msg, int len); +extern int udp_sendmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, int len); extern int udp_rcv(struct sk_buff *skb); extern int udp_ioctl(struct sock *sk, int cmd, unsigned long arg); diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Thu Oct 10 18:27:27 2002 +++ b/net/atm/common.c Thu Oct 10 18:27:27 2002 @@ -336,8 +336,8 @@ } -int atm_recvmsg(struct socket *sock,struct msghdr *m,int total_len, - int flags,struct scm_cookie *scm) +int atm_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, + int total_len, int flags, struct scm_cookie *scm) { DECLARE_WAITQUEUE(wait,current); struct atm_vcc *vcc; @@ -417,8 +417,8 @@ } -int atm_sendmsg(struct socket *sock,struct msghdr *m,int total_len, - struct scm_cookie *scm) +int atm_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, + int total_len, struct scm_cookie *scm) { DECLARE_WAITQUEUE(wait,current); struct atm_vcc *vcc; diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h Thu Oct 10 18:27:27 2002 +++ b/net/atm/common.h Thu Oct 10 18:27:27 2002 @@ -13,10 +13,10 @@ int atm_create(struct socket *sock,int protocol,int family); int atm_release(struct socket *sock); int atm_connect(struct socket *sock,int itf,short vpi,int vci); -int atm_recvmsg(struct socket *sock,struct msghdr *m,int total_len, - int flags,struct scm_cookie *scm); -int atm_sendmsg(struct socket *sock,struct msghdr *m,int total_len, - struct scm_cookie *scm); +int atm_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, + int total_len, int flags, struct scm_cookie *scm); +int atm_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, + int total_len, struct scm_cookie *scm); unsigned int atm_poll(struct file *file,struct socket *sock,poll_table *wait); int atm_ioctl(struct socket *sock,unsigned int cmd,unsigned long arg); int atm_setsockopt(struct socket *sock,int level,int optname,char *optval, diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Thu Oct 10 18:27:27 2002 +++ b/net/ax25/af_ax25.c Thu Oct 10 18:27:27 2002 @@ -1410,7 +1410,8 @@ return err; } -static int ax25_sendmsg(struct socket *sock, struct msghdr *msg, int len, +static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sockaddr_ax25 *usax = (struct sockaddr_ax25 *)msg->msg_name; @@ -1588,8 +1589,8 @@ return err; } -static int ax25_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +static int ax25_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sk_buff *skb; diff -Nru a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c --- a/net/bluetooth/af_bluetooth.c Thu Oct 10 18:27:27 2002 +++ b/net/bluetooth/af_bluetooth.c Thu Oct 10 18:27:27 2002 @@ -207,7 +207,8 @@ return NULL; } -int bluez_sock_recvmsg(struct socket *sock, struct msghdr *msg, int len, int flags, struct scm_cookie *scm) +int bluez_sock_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, int flags, struct scm_cookie *scm) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c Thu Oct 10 18:27:27 2002 +++ b/net/core/sock.c Thu Oct 10 18:27:27 2002 @@ -1047,14 +1047,14 @@ return -EOPNOTSUPP; } -int sock_no_sendmsg(struct socket *sock, struct msghdr *m, int flags, - struct scm_cookie *scm) +int sock_no_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, + int flags, struct scm_cookie *scm) { return -EOPNOTSUPP; } -int sock_no_recvmsg(struct socket *sock, struct msghdr *m, int len, int flags, - struct scm_cookie *scm) +int sock_no_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, + int len, int flags, struct scm_cookie *scm) { return -EOPNOTSUPP; } diff -Nru a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c --- a/net/decnet/af_decnet.c Thu Oct 10 18:27:27 2002 +++ b/net/decnet/af_decnet.c Thu Oct 10 18:27:27 2002 @@ -1733,8 +1733,8 @@ } -static int dn_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +static int dn_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); @@ -1901,8 +1901,8 @@ return 0; } -static int dn_sendmsg(struct socket *sock, struct msghdr *msg, int size, - struct scm_cookie *scm) +static int dn_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c Thu Oct 10 18:27:27 2002 +++ b/net/econet/af_econet.c Thu Oct 10 18:27:27 2002 @@ -97,8 +97,9 @@ * If necessary we block. */ -static int econet_recvmsg(struct socket *sock, struct msghdr *msg, int len, - int flags, struct scm_cookie *scm) +static int econet_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, int flags, + struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sk_buff *skb; @@ -230,8 +231,8 @@ * and hence whether to use real Econet or the UDP emulation. */ -static int econet_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int econet_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sockaddr_ec *saddr=(struct sockaddr_ec *)msg->msg_name; diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c Thu Oct 10 18:27:27 2002 +++ b/net/ipv4/af_inet.c Thu Oct 10 18:27:27 2002 @@ -753,22 +753,23 @@ } - -int inet_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, + int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; int addr_len = 0; - int err = sk->prot->recvmsg(sk, msg, size, flags & MSG_DONTWAIT, - flags & ~MSG_DONTWAIT, &addr_len); + int err; + + err = sk->prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT, + flags & ~MSG_DONTWAIT, &addr_len); if (err >= 0) msg->msg_namelen = addr_len; return err; } -int inet_sendmsg(struct socket *sock, struct msghdr *msg, int size, - struct scm_cookie *scm) +int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, + int size, struct scm_cookie *scm) { struct sock *sk = sock->sk; @@ -776,7 +777,7 @@ if (!inet_sk(sk)->num && inet_autobind(sk)) return -EAGAIN; - return sk->prot->sendmsg(sk, msg, size); + return sk->prot->sendmsg(iocb, sk, msg, size); } int inet_shutdown(struct socket *sock, int how) diff -Nru a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c Thu Oct 10 18:27:27 2002 +++ b/net/ipv4/raw.c Thu Oct 10 18:27:27 2002 @@ -295,7 +295,8 @@ return 0; } -static int raw_sendmsg(struct sock *sk, struct msghdr *msg, int len) +static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, + int len) { struct inet_opt *inet = inet_sk(sk); struct ipcm_cookie ipc; @@ -476,8 +477,8 @@ * we return it, otherwise we block. */ -int raw_recvmsg(struct sock *sk, struct msghdr *msg, int len, - int noblock, int flags, int *addr_len) +int raw_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, + int len, int noblock, int flags, int *addr_len) { struct inet_opt *inet = inet_sk(sk); int copied = 0; diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c Thu Oct 10 18:27:27 2002 +++ b/net/ipv4/tcp.c Thu Oct 10 18:27:27 2002 @@ -1013,7 +1013,8 @@ return tmp; } -int tcp_sendmsg(struct sock *sk, struct msghdr *msg, int size) +int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, + int size) { struct iovec *iov; struct tcp_opt *tp = tcp_sk(sk); @@ -1475,7 +1476,7 @@ * Probably, code can be easily improved even more. */ -int tcp_recvmsg(struct sock *sk, struct msghdr *msg, +int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len, int nonblock, int flags, int *addr_len) { struct tcp_opt *tp = tcp_sk(sk); diff -Nru a/net/ipv4/udp.c b/net/ipv4/udp.c --- a/net/ipv4/udp.c Thu Oct 10 18:27:27 2002 +++ b/net/ipv4/udp.c Thu Oct 10 18:27:27 2002 @@ -423,7 +423,8 @@ fraglen); } -int udp_sendmsg(struct sock *sk, struct msghdr *msg, int len) +int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, + int len) { struct inet_opt *inet = inet_sk(sk); int ulen = len + sizeof(struct udphdr); @@ -635,8 +636,8 @@ * return it, otherwise we block. */ -int udp_recvmsg(struct sock *sk, struct msghdr *msg, int len, - int noblock, int flags, int *addr_len) +int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, + int len, int noblock, int flags, int *addr_len) { struct inet_opt *inet = inet_sk(sk); struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name; diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c --- a/net/ipx/af_ipx.c Thu Oct 10 18:27:27 2002 +++ b/net/ipx/af_ipx.c Thu Oct 10 18:27:27 2002 @@ -2009,8 +2009,8 @@ out: return ret; } -static int ipx_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); @@ -2069,8 +2069,8 @@ } -static int ipx_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); diff -Nru a/net/irda/af_irda.c b/net/irda/af_irda.c --- a/net/irda/af_irda.c Thu Oct 10 18:27:27 2002 +++ b/net/irda/af_irda.c Thu Oct 10 18:27:27 2002 @@ -1259,8 +1259,8 @@ * SEQPACK services. This is possible since it forces the client to * fragment the message if necessary */ -static int irda_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int irda_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1331,8 +1331,9 @@ * Try to receive message and copy it to user. The frame is discarded * after being read, regardless of how much the user actually read */ -static int irda_recvmsg_dgram(struct socket *sock, struct msghdr *msg, - int size, int flags, struct scm_cookie *scm) +static int irda_recvmsg_dgram(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, + struct scm_cookie *scm) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); diff -Nru a/net/llc/af_llc.c b/net/llc/af_llc.c --- a/net/llc/af_llc.c Thu Oct 10 18:27:27 2002 +++ b/net/llc/af_llc.c Thu Oct 10 18:27:27 2002 @@ -677,8 +677,9 @@ * Copy received data to the socket user. * Returns non-negative upon success, negative otherwise. */ -static int llc_ui_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +static int llc_ui_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, + struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sockaddr_llc *uaddr = (struct sockaddr_llc *)msg->msg_name; @@ -731,8 +732,8 @@ * Transmit data provided by the socket user. * Returns non-negative upon success, negative otherwise. */ -static int llc_ui_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int llc_ui_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct llc_opt *llc = llc_sk(sk); diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c Thu Oct 10 18:27:27 2002 +++ b/net/netlink/af_netlink.c Thu Oct 10 18:27:27 2002 @@ -570,7 +570,8 @@ read_unlock(&nl_table_lock); } -static int netlink_sendmsg(struct socket *sock, struct msghdr *msg, int len, +static int netlink_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; @@ -639,7 +640,8 @@ return err; } -static int netlink_recvmsg(struct socket *sock, struct msghdr *msg, int len, +static int netlink_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Thu Oct 10 18:27:27 2002 +++ b/net/netrom/af_netrom.c Thu Oct 10 18:27:27 2002 @@ -966,7 +966,8 @@ return 1; } -static int nr_sendmsg(struct socket *sock, struct msghdr *msg, int len, struct scm_cookie *scm) +static int nr_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; nr_cb *nr = nr_sk(sk); @@ -1056,8 +1057,9 @@ return len; } -static int nr_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +static int nr_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, + struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sockaddr_ax25 *sax = (struct sockaddr_ax25 *)msg->msg_name; diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c Thu Oct 10 18:27:27 2002 +++ b/net/packet/af_packet.c Thu Oct 10 18:27:27 2002 @@ -288,7 +288,8 @@ * protocol layers and you must therefore supply it with a complete frame */ -static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg, int len, +static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; @@ -665,8 +666,8 @@ #endif -static int packet_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int packet_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sockaddr_ll *saddr=(struct sockaddr_ll *)msg->msg_name; @@ -1020,7 +1021,8 @@ * If necessary we block. */ -static int packet_recvmsg(struct socket *sock, struct msghdr *msg, int len, +static int packet_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; diff -Nru a/net/rose/af_rose.c b/net/rose/af_rose.c --- a/net/rose/af_rose.c Thu Oct 10 18:27:27 2002 +++ b/net/rose/af_rose.c Thu Oct 10 18:27:27 2002 @@ -1025,8 +1025,8 @@ return 1; } -static int rose_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int rose_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; rose_cb *rose = rose_sk(sk); @@ -1189,8 +1189,9 @@ } -static int rose_recvmsg(struct socket *sock, struct msghdr *msg, int size, - int flags, struct scm_cookie *scm) +static int rose_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, + struct scm_cookie *scm) { struct sock *sk = sock->sk; rose_cb *rose = rose_sk(sk); diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Thu Oct 10 18:27:27 2002 +++ b/net/socket.c Thu Oct 10 18:27:27 2002 @@ -90,10 +90,10 @@ #include static int sock_no_open(struct inode *irrelevant, struct file *dontcare); -static ssize_t sock_read(struct file *file, char *buf, - size_t size, loff_t *ppos); -static ssize_t sock_write(struct file *file, const char *buf, - size_t size, loff_t *ppos); +static ssize_t sock_aio_read(struct kiocb *iocb, char *buf, + size_t size, loff_t pos); +static ssize_t sock_aio_write(struct kiocb *iocb, char *buf, + size_t size, loff_t pos); static int sock_mmap(struct file *file, struct vm_area_struct * vma); static int sock_close(struct inode *inode, struct file *file); @@ -117,8 +117,8 @@ static struct file_operations socket_file_ops = { .llseek = no_llseek, - .read = sock_read, - .write = sock_write, + .aio_read = sock_aio_read, + .aio_write = sock_aio_write, .poll = sock_poll, .ioctl = sock_ioctl, .mmap = sock_mmap, @@ -517,64 +517,100 @@ sock->file=NULL; } -int sock_sendmsg(struct socket *sock, struct msghdr *msg, int size) +static int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size) { + struct sock_iocb *si = kiocb_to_siocb(iocb); int err; - struct scm_cookie scm; - err = scm_send(sock, msg, &scm); + si->scm = &si->async_scm; + si->sock = sock; + si->msg = msg; + si->size = size; + + err = scm_send(sock, msg, si->scm); if (err >= 0) { - err = sock->ops->sendmsg(sock, msg, size, &scm); - scm_destroy(&scm); + err = sock->ops->sendmsg(iocb, sock, msg, size, si->scm); + if (-EIOCBQUEUED != err) + scm_destroy(si->scm); } return err; } -int sock_recvmsg(struct socket *sock, struct msghdr *msg, int size, int flags) +int sock_sendmsg(struct socket *sock, struct msghdr *msg, int size) +{ + struct kiocb iocb; + int ret; + + init_sync_kiocb(&iocb, NULL); + ret = __sock_sendmsg(&iocb, sock, msg, size); + if (-EIOCBQUEUED == ret) + ret = wait_on_sync_kiocb(&iocb); + return ret; +} + + +int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, int flags) { - struct scm_cookie scm; + struct sock_iocb *si = kiocb_to_siocb(iocb); - memset(&scm, 0, sizeof(scm)); + si->sock = sock; + si->scm = &si->async_scm; + si->sock = sock; + si->msg = msg; + si->size = size; + si->flags = flags; - size = sock->ops->recvmsg(sock, msg, size, flags, &scm); + memset(si->scm, 0, sizeof(*si->scm)); + + size = sock->ops->recvmsg(iocb, sock, msg, size, flags, si->scm); if (size >= 0) - scm_recv(sock, msg, &scm, flags); + scm_recv(sock, msg, si->scm, flags); return size; } +int sock_recvmsg(struct socket *sock, struct msghdr *msg, int size, int flags) +{ + struct kiocb iocb; + int ret; + + init_sync_kiocb(&iocb, NULL); + ret = __sock_recvmsg(&iocb, sock, msg, size, flags); + if (-EIOCBQUEUED == ret) + ret = wait_on_sync_kiocb(&iocb); + return ret; +} /* * Read data from a socket. ubuf is a user mode pointer. We make sure the user * area ubuf...ubuf+size-1 is writable before asking the protocol. */ -static ssize_t sock_read(struct file *file, char *ubuf, - size_t size, loff_t *ppos) +static ssize_t sock_aio_read(struct kiocb *iocb, char *ubuf, + size_t size, loff_t pos) { + struct sock_iocb *x = kiocb_to_siocb(iocb); struct socket *sock; - struct iovec iov; - struct msghdr msg; int flags; - if (ppos != &file->f_pos) + if (pos != 0) return -ESPIPE; if (size==0) /* Match SYS5 behaviour */ return 0; - sock = SOCKET_I(file->f_dentry->d_inode); + sock = SOCKET_I(iocb->ki_filp->f_dentry->d_inode); - msg.msg_name=NULL; - msg.msg_namelen=0; - msg.msg_iov=&iov; - msg.msg_iovlen=1; - msg.msg_control=NULL; - msg.msg_controllen=0; - iov.iov_base=ubuf; - iov.iov_len=size; - flags = !(file->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT; + x->async_msg.msg_name = NULL; + x->async_msg.msg_namelen = 0; + x->async_msg.msg_iov = &x->async_iov; + x->async_msg.msg_iovlen = 1; + x->async_msg.msg_control = NULL; + x->async_msg.msg_controllen = 0; + x->async_iov.iov_base = ubuf; + x->async_iov.iov_len = size; + flags = !(iocb->ki_filp->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT; - return sock_recvmsg(sock, &msg, size, flags); + return __sock_recvmsg(iocb, sock, &x->async_msg, size, flags); } @@ -583,33 +619,32 @@ * is readable by the user process. */ -static ssize_t sock_write(struct file *file, const char *ubuf, - size_t size, loff_t *ppos) +static ssize_t sock_aio_write(struct kiocb *iocb, char *ubuf, + size_t size, loff_t pos) { + struct sock_iocb *x = kiocb_to_siocb(iocb); struct socket *sock; - struct msghdr msg; - struct iovec iov; - if (ppos != &file->f_pos) + if (pos != 0) return -ESPIPE; if(size==0) /* Match SYS5 behaviour */ return 0; - sock = SOCKET_I(file->f_dentry->d_inode); + sock = SOCKET_I(iocb->ki_filp->f_dentry->d_inode); - msg.msg_name=NULL; - msg.msg_namelen=0; - msg.msg_iov=&iov; - msg.msg_iovlen=1; - msg.msg_control=NULL; - msg.msg_controllen=0; - msg.msg_flags=!(file->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT; + x->async_msg.msg_name = NULL; + x->async_msg.msg_namelen = 0; + x->async_msg.msg_iov = &x->async_iov; + x->async_msg.msg_iovlen = 1; + x->async_msg.msg_control = NULL; + x->async_msg.msg_controllen = 0; + x->async_msg.msg_flags = !(iocb->ki_filp->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT; if (sock->type == SOCK_SEQPACKET) - msg.msg_flags |= MSG_EOR; - iov.iov_base=(void *)ubuf; - iov.iov_len=size; + x->async_msg.msg_flags |= MSG_EOR; + x->async_iov.iov_base = (void *)ubuf; + x->async_iov.iov_len = size; - return sock_sendmsg(sock, &msg, size); + return __sock_sendmsg(iocb, sock, &x->async_msg, size); } ssize_t sock_sendpage(struct file *file, struct page *page, diff -Nru a/net/unix/af_unix.c b/net/unix/af_unix.c --- a/net/unix/af_unix.c Thu Oct 10 18:27:27 2002 +++ b/net/unix/af_unix.c Thu Oct 10 18:27:27 2002 @@ -1175,7 +1175,8 @@ * Send AF_UNIX data. */ -static int unix_dgram_sendmsg(struct socket *sock, struct msghdr *msg, int len, +static int unix_dgram_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; @@ -1307,7 +1308,8 @@ } -static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg, int len, +static int unix_stream_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; @@ -1415,7 +1417,8 @@ } } -static int unix_dgram_recvmsg(struct socket *sock, struct msghdr *msg, int size, +static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; @@ -1517,7 +1520,8 @@ -static int unix_stream_recvmsg(struct socket *sock, struct msghdr *msg, int size, +static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; diff -Nru a/net/wanrouter/af_wanpipe.c b/net/wanrouter/af_wanpipe.c --- a/net/wanrouter/af_wanpipe.c Thu Oct 10 18:27:27 2002 +++ b/net/wanrouter/af_wanpipe.c Thu Oct 10 18:27:27 2002 @@ -540,8 +540,8 @@ * a packet is queued into sk->write_queue. *===========================================================*/ -static int wanpipe_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int wanpipe_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { wanpipe_opt *wp; struct sock *sk = sock->sk; @@ -1647,8 +1647,9 @@ * to the user. If necessary we block. *===========================================================*/ -static int wanpipe_recvmsg(struct socket *sock, struct msghdr *msg, int len, - int flags, struct scm_cookie *scm) +static int wanpipe_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, int flags, + struct scm_cookie *scm) { struct sock *sk = sock->sk; struct sk_buff *skb; diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Thu Oct 10 18:27:27 2002 +++ b/net/x25/af_x25.c Thu Oct 10 18:27:27 2002 @@ -916,8 +916,8 @@ goto out; } -static int x25_sendmsg(struct socket *sock, struct msghdr *msg, int len, - struct scm_cookie *scm) +static int x25_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int len, struct scm_cookie *scm) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); @@ -1091,7 +1091,8 @@ } -static int x25_recvmsg(struct socket *sock, struct msghdr *msg, int size, +static int x25_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, int size, int flags, struct scm_cookie *scm) { struct sock *sk = sock->sk; From davem@redhat.com Thu Oct 10 16:29:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 16:29:30 -0700 (PDT) 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 g9ANTLtG015331 for ; Thu, 10 Oct 2002 16:29:27 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA07751; Thu, 10 Oct 2002 16:22:41 -0700 Date: Thu, 10 Oct 2002 16:22:40 -0700 (PDT) Message-Id: <20021010.162240.102769920.davem@redhat.com> To: bcrl@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [patch] add iocb to network protocols From: "David S. Miller" In-Reply-To: <20021010183528.A13432@redhat.com> References: <20021010183528.A13432@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 629 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 +#include /* for sock_iocb */ What is this? From bcrl@redhat.com Thu Oct 10 16:40:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 16:40:30 -0700 (PDT) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ANeRtG015834 for ; Thu, 10 Oct 2002 16:40:28 -0700 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9BD9D8001D2; Thu, 10 Oct 2002 19:40:25 -0400 (EDT) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id g9ANeP013755; Thu, 10 Oct 2002 19:40:25 -0400 Date: Thu, 10 Oct 2002 19:40:25 -0400 From: Benjamin LaHaise To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [patch] add iocb to network protocols Message-ID: <20021010194025.B13432@redhat.com> References: <20021010183528.A13432@redhat.com> <20021010.162240.102769920.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021010.162240.102769920.davem@redhat.com>; from davem@redhat.com on Thu, Oct 10, 2002 at 04:22:40PM -0700 X-archive-position: 630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev On Thu, Oct 10, 2002 at 04:22:40PM -0700, David S. Miller wrote: > > +#include /* for sock_iocb */ > > What is this? The private area of an iocb for network operations contains a struct scm_cookie. The alternative is to allocate it via kmalloc when needed, but there isn't currently a way of identifying which network protocols require the scm_cookie. Since most network protocols do not use it, would you rather remove the scm_cookie out of the default path and allow the protocol to choose to create it? That would remove the dependancy on scm_cookie from sock_iocb entirely. -ben -- "Do you seek knowledge in time travel?" From davem@redhat.com Thu Oct 10 16:43:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 10 Oct 2002 16:43:25 -0700 (PDT) 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 g9ANhMtG015987 for ; Thu, 10 Oct 2002 16:43:23 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA07832; Thu, 10 Oct 2002 16:36:46 -0700 Date: Thu, 10 Oct 2002 16:36:46 -0700 (PDT) Message-Id: <20021010.163646.35014672.davem@redhat.com> To: bcrl@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [patch] add iocb to network protocols From: "David S. Miller" In-Reply-To: <20021010194025.B13432@redhat.com> References: <20021010183528.A13432@redhat.com> <20021010.162240.102769920.davem@redhat.com> <20021010194025.B13432@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Benjamin LaHaise Date: Thu, 10 Oct 2002 19:40:25 -0400 On Thu, Oct 10, 2002 at 04:22:40PM -0700, David S. Miller wrote: > > +#include /* for sock_iocb */ > > What is this? The private area of an iocb for network operations contains a struct scm_cookie. I know this. But the comment is wrong, when you say "for FOO" next to an include that means "I'm including this to get the definition of FOO". Just delete the comment entirely, it really isn't needed. Otherwise looks ok at first glance. From mk@karaba.org Fri Oct 11 01:06:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 01:06:16 -0700 (PDT) Received: from zanzibar.karaba.org (karaba.org [218.219.152.88] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B868tG029392 for ; Fri, 11 Oct 2002 01:06:09 -0700 Received: from [3ffe:501:1057:710::1] (helo=hyakusiki.karaba.org.karaba.org) by zanzibar.karaba.org with esmtp (Exim 3.35 #1 (Debian)) id 17zuo1-00045r-00; Fri, 11 Oct 2002 17:05:57 +0900 Date: Fri, 11 Oct 2002 17:05:59 +0900 Message-ID: From: Mitsuru KANDA To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: [PATCH] USAGI IPsec MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-archive-position: 632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mk@linux-ipv6.org Precedence: bulk X-list: netdev Hello Linux kernel network maintainers, I'm a member of USAGI project. In IPv6 specifications, IPsec is mandatory. We implemented IPsec for Linux IP stack. At present, our implementation includes: PF_KEY V2 interface, Security Association Database and Security Policy Database for whole IP versions, IPsec for IPv6,(transport, tunnel mode), IPsec for IPv4 (transport mode), Would you mind checking it ? The patch is a little too big to send to the mailing list. Please visit our ftp site and retrieve it from ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/ipsec-2.5.41-ALL.patch.gz ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/ipsec-2.4.20-pre10-ALL.patch.gz (more patches are available) Regards, -mk === For more details === ##### USAGI IPsec ##### Table of Contents 1. How to Apply Patches 2. Cipher/Digest Algorithms 3. PF_KEY v2 Implementation 4. IPsec Implementation 4.1 Supported Header Order 4.2 IPsec Mode 4.3 Packet Processing 4.4 Conformance Test 5. New and Changed Files 6. References 7. Acknowledgements -------------------------- 1. How to Apply Patches 1. apply CryptoAPI patch (if you need to compile for test) 2. apply ipsec-2.4.20-pre10-ALL.patch.gz or ipsec-2.5.41-ALL.patch.gz We also prepared rough split patches. (for PF_KEY, IPv6 and IPv4 part) If you apply them instead of ipsec-*-ALL.patch.gz, please apply following order: ipsec-2.4.20-pre10-PFKEY.patch.gz ipsec-2.4.20-pre10-IPV6.patch.gz ipsec-2.4.20-pre10-IPV4.patch.gz (sorry we haven't prepared rough split patches for 2.5) 2. Cipher/Digest Algorithms Supported algorithms: Ciphers: DES, 3DES and AES Digests: MD5 and SHA1 We use CryptoAPI as cipher/digest algorithm. - CryptoAPI http://www.kerneli.org/ 3. PF_KEY v2 Implementation We introduced struct sockaddr_storage{} to handle both IPv4 and IPv6 in Security Association Database (SADB) and Security Policy Database (SPD). We conform to RFC2367 (PF_KEY_V2). Many other implementations have extended PF_KEY_V2 protocol to process IPsec Security Policy. We have implemented FreeS/WAN's PF_KEY extension in order to be compatible with their IKEv1 daemon (Pluto). 4. IPsec Implementation RFC 2401 Security Architecture for IP RFC 2402 IP Authentication Header RFC 2406 IP Encapsulating Security Payload 4.1 Supported Header Order We support [AH], [ESP], and [AH][ESP]. 4.2 IPsec Mode Transport Mode IPv[46]: We implemented inside IP stack. Tunnel Mode We implemented IPsec Tunnel Mode by making use of IP over IP tunnel IPv6: We realized it by making use of HUT(mipl) IPv6 over IPv6 tunnel. IPv4: Not yet implemented.(Do we use net/ipv4/ipip.c ?) 4.3 Packet Processing Inbound Processing Our implementation parses AH and ESP in extension header parsing routine (ipv6_parse_exthdrs()). The kernel parses AH and ESP and keeps the information of SAs which are used during the processing in skb->cb as struct inet6_skb_parm{}. The kernel keeps the AH SA information as offset from a IPv6 header (the kernel doesn't remove AH header). It also keeps ESP SA information as SPI value. If there is something wrong in processing AH and/or ESP, the kernel drops the packet. When processing completes successfully, the kernel compares SAs information and policy in ipsec6_input_check(), which is called from ip6_input_finish(). When using tunnel mode, there are a couple of differences from transport mode. The AH and ESP parsing is same as transport mode. However, in tunnel mode the kernel uses the inner header's addresses as key to lookup IPsec Security Policy Database. Outbound Processing The kernel checks IPsec Security Policy Database using as a key the src/dst address pair. If it matches with the action applying IPsec, start IPsec processing (preparing AH calculation, ESP encryption, AH calculation). 4.4 Conformance Test We have tested TAHI conformance test. The results are fine. 5. New and Changed Files net/key: Config.in (NEW) - Makefile (NEW) - af_key.c (NEW) - PF_KEY_V2 socket interface (derived from FreeS/WAN 1.9 pfkey_v2.c. changed a lot.) pfkey_v2_build.c (NEW) - building PF_KEY message (derived from FreeS/WAN 1.9 changed a little.) pfkey_v2_ext_bits.c (NEW) - (derived from FreeS/WAN 1.9. changed a little.) pfkey_v2_msg.c (NEW) - PF_KEY helper functions(SA lifetime,...) pfkey_v2_msg.h (NEW) - header file for pfkey_v2_msg.c pfkey_v2_msg_add.c (NEW) - processing SADB_ADD message pfkey_v2_msg_delete.c (NEW) - processing SADB_DELETE message pfkey_v2_msg_flow.c (NEW) - processing SADB_X_ADDFLOW and SADB_X_DELFLOW messages pfkey_v2_msg_get.c (NEW) - processing SADB_GET message pfkey_v2_msg_getspi.c (NEW) - processing SADB_GETSPI message pfkey_v2_msg_update.c (NEW) - processing SADB_UPDATE message sa_index.c (NEW) - Security Association (SA) index (handle struct sa_index{}) sadb.c (NEW) - SA Database sockaddr_utils.c (NEW) - utilities sockaddr_utils.h (NEW) - utilities spd.c (NEW) - Security Policy (SP) Database sysctl_net_ipsec.c (NEW) - sysctls (replay window and debug switch.) net/ipv6: Config.in (CHANGED) Makefile (CHANGED) exthdrs.c (CHANGED) - inserted ipsec processing functions ip6_input.c (CHANGED) - inserted ipsec processing functions ip6_output.c (CHANGED) - inserted ipsec processing functions ipsec6_input.c (NEW) - IPsec processing for input packet ipsec6_output.c (NEW) - IPsec processing for output packet ipv6_sockglue.c (CHANGED) - inserted IPsec processing functions. ndisc.c (CHANGED) - inserted ipsec processing functions (for ND packets) reassembly.c (CHANGED) - inserted IPsec processing functions. tcp_ipv6.c (CHANGED) - inserted IPsec processing functions. (based IABG IPv6 implementation) net/ipv4: Config.in (CHANGED) - Makefile (CHANGED) - ip_input.c (CHANGED) - inserted ipsec processing functions ip_output.c (CHANGED) - inserted ipsec processing functions ipsec4_input.c (NEW) - IPsec processing for input packet ipsec4_output.c (NEW) - IPsec processing for output packet tcp_ipv4.c (CHANGED) - inserted ipsec processing functions include/linux: ip.h (CHANGED) - introduced struct ip_auth_hdr{} and ip_esp_hdr{}. ipsec.h (CHANGED) - added IPsec actions and IPsec4 processing functions. ipsec6.h (NEW) - added IPsec6 processing functions. pfkey.h (NEW) - PF_KEY related structs (derived from FreeS/WAN 1.9) pfkeyv2.h (NEW) - PF_KEY_V2 header file ipv6.h (CHANGED) - introduced struct ipv6_auth_hdr{} and ipv6_esp_hdr. added 'espspi' member in struct inet6_skb_parm. socket.h (CHANGED) - introduced struct sockaddr_storage{} to handle both IPv4 and IPv6 sockaddr in SADB/SPD. sysctl.h (CHANGED) - added IPsec entry. include/net: sadb.h (NEW) - SA Database header file spd.h (NEW) - SP Database header file ipv6.h (CHANGED) - changed ipv6_parse_exthdrs() 6. References USAGI Project http://www.linux-ipv6.org/ CryptoAPI http://www.kerneli.org/ FreeS/WAN http://www.freeswan.org/ IABG http://www.ipv6.iabg.de/ 7. Acknowledgements Joy Latten and IBM IPv6 team From steve@gw.chygwyn.com Fri Oct 11 02:26:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 02:27:00 -0700 (PDT) Received: from gw.chygwyn.com (IDENT:root@gw.chygwyn.com [62.172.158.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9B9QstG006487 for ; Fri, 11 Oct 2002 02:26:55 -0700 Received: (from steve@localhost) by gw.chygwyn.com (8.9.3/8.9.3) id KAA19428; Fri, 11 Oct 2002 10:31:23 +0100 From: Steven Whitehouse Message-Id: <200210110931.KAA19428@gw.chygwyn.com> Subject: Re: [patch] add iocb to network protocols To: bcrl@redhat.com (Benjamin LaHaise) Date: Fri, 11 Oct 2002 10:31:23 +0100 (BST) Cc: davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <20021010183528.A13432@redhat.com> from "Benjamin LaHaise" at Oct 10, 2002 06:35:29 PM Organization: ChyGywn Limited X-RegisteredOffice: 7, New Yatt Road, Witney, Oxfordshire. OX28 1NU England X-RegisteredNumber: 03887683 Reply-To: Steve Whitehouse X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@gw.chygwyn.com Precedence: bulk X-list: netdev Hi, > > Hello Dave, > > Below is a copy of the bk tree at: > > bk pull master.kernel.org:/home/bcrl/net-2.5 > > This tree adds the iocb parameter into the sendmsg and recvmsg > operations within the network operations. sock_read and sock_write > are also replaced by sock_aio_read/sock_aio_write, so this requires > the other aio changes to fs/read_write.c that are in fresh trees > from Linus. Comments? > [patch etc. cut] I have a few questions about the way aio interacts with the socket locking and the consequences for atomicity of requests: Given two aio requests, A and B both for the same socket, can I be sure that they will complete in the order that I submit them ? Can I also be sure that parts of the I/O request for A will not be mixed up with B ? Will that still be true if one of the requests is aio and one a "normal" send/recvmsg() for example ? Currently with multiple sendmsg() calls (for example) because the socket lock is dropped to allow packet delivery to the socket during periods of waiting for events, it would be possible for our two I/O requests A and B to be interleaved so that B could be sent out sandwiched between two parts of request A. Of course you have to submit the I/O from separate threads for this to happen, but I'm wondering what the implications are for aio in this area. Do the standards have anything to say in this area ? Steve. From bcrl@redhat.com Fri Oct 11 03:27:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 03:27:12 -0700 (PDT) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BARAtG013476 for ; Fri, 11 Oct 2002 03:27:10 -0700 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 7A4EB8001D2; Fri, 11 Oct 2002 06:27:09 -0400 (EDT) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id g9BAR9q14793; Fri, 11 Oct 2002 06:27:09 -0400 Date: Fri, 11 Oct 2002 06:27:09 -0400 From: Benjamin LaHaise To: Steven Whitehouse Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [patch] add iocb to network protocols Message-ID: <20021011062709.A14784@redhat.com> References: <20021010183528.A13432@redhat.com> <200210110931.KAA19428@gw.chygwyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210110931.KAA19428@gw.chygwyn.com>; from steve@gw.chygwyn.com on Fri, Oct 11, 2002 at 10:31:23AM +0100 X-archive-position: 634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev On Fri, Oct 11, 2002 at 10:31:23AM +0100, Steven Whitehouse wrote: > Given two aio requests, A and B both for the same socket, can I be sure > that they will complete in the order that I submit them ? Can I also > be sure that parts of the I/O request for A will not be mixed up with > B ? Will that still be true if one of the requests is aio and one a "normal" > send/recvmsg() for example ? The POSIX standard does not seem to require any ordering between requests, and some implementations take advantage of this by using threads to execute requests. That said, providing intra request ordering for sockets is easy to do, and is one of the guarantees I'm trying to make as it allows the implementation to provide the same semantics as are required for things like zero copy tx. -ben -- "Do you seek knowledge in time travel?" From thockin@sun.com Fri Oct 11 09:59:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 09:59:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BGxRtG028837 for ; Fri, 11 Oct 2002 09:59:28 -0700 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07428; Fri, 11 Oct 2002 10:59:12 -0600 (MDT) Received: from sun.com (scl2.SFBay.Sun.COM [10.6.72.42]) by phys-ha1mpka.eng.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id JAA04129; Fri, 11 Oct 2002 09:59:11 -0700 (PDT) Message-ID: <3DA7035F.5080101@sun.com> Date: Fri, 11 Oct 2002 09:59:11 -0700 From: Tim Hockin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: PATCH idea - netlink and link changes Content-Type: multipart/mixed; boundary="------------050909010908040208070804" X-archive-position: 635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thockin@sun.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------050909010908040208070804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I'm not subscribed to netdev or linux-net, I was asked to forward this patch to these lists. Please CC: me on any commentary. Looking for feedback on this quickie patch. This enables netlink to deliver link-change events, as reported by drivers via netif_carrier_{on,off}. * We could use a different RTM than NEWLINK (RTM_LINKCHANGE?) if we care * We could do notifier_call_chain(netdev_chain) with NETDEV_UP or NETDEV_LINKCHANGE (new) if we care comments? -- Tim Hockin Systems Software Engineer Sun Microsystems, Linux Kernel Engineering thockin@sun.com --------------050909010908040208070804 Content-Type: text/plain; name="link_change_via_netlink.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="link_change_via_netlink.diff" ===== drivers/net/net_init.c 1.9 vs edited ===== --- 1.9/drivers/net/net_init.c Mon Feb 4 23:44:55 2002 +++ edited/drivers/net/net_init.c Thu Oct 10 11:44:18 2002 @@ -93,6 +93,7 @@ dev->priv = (void *) (((long)(dev + 1) + 31) & ~31); setup(dev); + INIT_WORK(&dev->link_work, NULL, NULL); strcpy(dev->name, mask); return dev; @@ -163,6 +164,7 @@ */ setup(dev); + INIT_WORK(&dev->link_work, NULL, NULL); if (new_device) { int err; ===== include/linux/netdevice.h 1.24 vs edited ===== --- 1.24/include/linux/netdevice.h Fri Oct 4 19:17:35 2002 +++ edited/include/linux/netdevice.h Thu Oct 10 14:56:23 2002 @@ -35,6 +35,7 @@ #ifdef __KERNEL__ #include +#include #ifdef CONFIG_NET_PROFILE #include #endif @@ -437,6 +438,7 @@ /* this will get initialized at each interface type init routine */ struct divert_blk *divert; #endif /* CONFIG_NET_DIVERT */ + struct work_struct link_work; }; @@ -637,17 +639,20 @@ } extern void __netdev_watchdog_up(struct net_device *dev); +extern void netdev_do_link_work(struct net_device *dev); static inline void netif_carrier_on(struct net_device *dev) { clear_bit(__LINK_STATE_NOCARRIER, &dev->state); if (netif_running(dev)) __netdev_watchdog_up(dev); + netdev_do_link_work(dev); } static inline void netif_carrier_off(struct net_device *dev) { set_bit(__LINK_STATE_NOCARRIER, &dev->state); + netdev_do_link_work(dev); } /* Hot-plugging. */ ===== include/linux/workqueue.h 1.3 vs edited ===== --- 1.3/include/linux/workqueue.h Thu Oct 3 14:29:58 2002 +++ edited/include/linux/workqueue.h Thu Oct 10 16:50:36 2002 @@ -7,6 +7,7 @@ #include #include +#include struct workqueue_struct; @@ -17,12 +18,15 @@ void *data; void *wq_data; struct timer_list timer; + spinlock_t lock; }; #define __WORK_INITIALIZER(n, f, d) { \ .entry = { &(n).entry, &(n).entry }, \ + .pending = 0, \ .func = (f), \ - .data = (d) } + .data = (d), \ + .lock = SPIN_LOCK_UNLOCKED } #define DECLARE_WORK(n, f, d) \ struct work_struct n = __WORK_INITIALIZER(n, f, d) @@ -45,6 +49,7 @@ (_work)->pending = 0; \ PREPARE_WORK((_work), (_func), (_data)); \ init_timer(&(_work)->timer); \ + spin_lock_init(&(_work)->lock); \ } while (0) extern struct workqueue_struct *create_workqueue(const char *name); @@ -56,10 +61,13 @@ extern int FASTCALL(schedule_work(struct work_struct *work)); extern int FASTCALL(schedule_delayed_work(struct work_struct *work, unsigned long delay)); +extern int FASTCALL(cancel_work(struct work_struct *work)); extern void flush_scheduled_work(void); extern int current_is_keventd(void); extern void init_workqueues(void); + +#define work_pending(_work) test_bit(0, &(_work)->pending) #endif ===== kernel/workqueue.c 1.3 vs edited ===== --- 1.3/kernel/workqueue.c Thu Oct 3 05:37:56 2002 +++ edited/kernel/workqueue.c Thu Oct 10 17:12:28 2002 @@ -140,10 +140,13 @@ void *data = work->data; list_del_init(cwq->worklist.next); - spin_unlock_irqrestore(&cwq->lock, flags); + spin_lock(&work->lock); + spin_unlock(&cwq->lock); BUG_ON(work->wq_data != cwq); clear_bit(0, &work->pending); + spin_unlock_irqrestore(&work->lock, flags); + f(data); /* @@ -354,6 +357,28 @@ flush_workqueue(keventd_wq); } +int cancel_work(struct work_struct *work) +{ + unsigned long flags; + struct cpu_workqueue_struct *cwq; + int cancelled = 0; + + /* this should be safe to read - it only races with queue_*work() */ + cwq = work->wq_data; + + spin_lock_irqsave(&cwq->lock, flags); + spin_lock(&work->lock); + if (work_pending(work)) { + list_del_init(&work->entry); + clear_bit(0, &work->pending); + cancelled = 1; + } + spin_unlock(&work->lock); + spin_unlock_irqrestore(&cwq->lock, flags); + + return cancelled; +} + int current_is_keventd(void) { struct cpu_workqueue_struct *cwq; @@ -386,4 +411,5 @@ EXPORT_SYMBOL(schedule_work); EXPORT_SYMBOL(schedule_delayed_work); EXPORT_SYMBOL(flush_scheduled_work); +EXPORT_SYMBOL(cancel_work); ===== net/netsyms.c 1.29 vs edited ===== --- 1.29/net/netsyms.c Fri Oct 4 19:17:35 2002 +++ edited/net/netsyms.c Thu Oct 10 14:57:53 2002 @@ -471,6 +471,7 @@ EXPORT_SYMBOL(register_netdevice); EXPORT_SYMBOL(unregister_netdevice); EXPORT_SYMBOL(netdev_state_change); +EXPORT_SYMBOL(netdev_do_link_work); EXPORT_SYMBOL(dev_new_index); EXPORT_SYMBOL(dev_get_by_index); EXPORT_SYMBOL(__dev_get_by_index); ===== net/core/dev.c 1.41 vs edited ===== --- 1.41/net/core/dev.c Mon Oct 7 05:31:06 2002 +++ edited/net/core/dev.c Thu Oct 10 16:05:06 2002 @@ -629,6 +629,20 @@ } } +static void do_link_work(void *cookie) +{ + struct net_device *dev = cookie; + rtnl_lock(); + rtmsg_ifinfo(RTM_NEWLINK, dev, IFF_RUNNING); + rtnl_unlock(); +} + +void netdev_do_link_work(struct net_device *dev) +{ + cancel_work(&dev->link_work); + PREPARE_WORK(&dev->link_work, do_link_work, dev); + schedule_work(&dev->link_work); +} #ifdef CONFIG_KMOD --------------050909010908040208070804-- From jgarzik@pobox.com Fri Oct 11 12:06:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 12:06:45 -0700 (PDT) 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 g9BJ6btG015073 for ; Fri, 11 Oct 2002 12:06:38 -0700 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 18057J-0007lJ-00; Fri, 11 Oct 2002 20:06:34 +0100 Message-ID: <3DA7212E.8010901@pobox.com> Date: Fri, 11 Oct 2002 15:06:22 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcelo Tosatti CC: Linux Kernel Mailing List , netdev@oss.sgi.com, Alan Cox Subject: [BK/GNU] net driver series 10 Content-Type: multipart/mixed; boundary="------------070102000002060504000109" X-archive-position: 636 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. --------------070102000002060504000109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yay, ewrk3 has finally been tested^H^H^Hhardened :) --------------070102000002060504000109 Content-Type: text/plain; name="net-drivers-2.4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.4.txt" Marcelo, please do a bk pull http://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: Documentation/networking/ewrk3.txt | 1 drivers/net/3c509.c | 184 +++++++++++++++++++++++++- drivers/net/bonding.c | 82 ++++++----- drivers/net/e1000/e1000_main.c | 22 +-- drivers/net/ewrk3.c | 92 +++++++++---- drivers/net/mii.c | 2 drivers/net/pcmcia/smc91c92_cs.c | 253 +++++++++++++++++++++++++++++++++---- 7 files changed, 521 insertions(+), 115 deletions(-) through these ChangeSets: (02/10/11 1.743) Add ethtool media support to smc91c92_cs net driver. Also fixes a bug when UTP port is unplugged. (02/10/11 1.742) Prevent EFAULT errors when checking link status, in bonding net driver. Also some minor cleanups as well. [This patch qualifies for the cavemen ugh-lympics, because the driver does some really nasty things in interrupt context and this patch does not correct that. However, the patch is an incremental improvement over the current code so it's still worth applying. I'll fix it further if IBM does not fix it first. -jgarzik] (02/10/11 1.740) e1000 net driver minor fixes/cleanups: * don't read PCI bus for values stored in struct pci_dev * remove silly BUG() in e1000_sw_init, and * return error from e1000_sw_init (02/10/10 1.739) Merge ewrk3 net driver updates from 2.5.x: * multiple NIC support * report correct version * don't use autoirq_*, don't need to (02/10/10 1.738) Add ethtool media selection to 3c509 net driver (02/10/10 1.737) [netdrvr] Use ADVERTISE_FULL in mii lib, to clean up duplex check --------------070102000002060504000109 Content-Type: application/octet-stream; name="netdrvr-10.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="netdrvr-10.tar.bz2" QlpoOTFBWSZTWfQJ3G8ANop/h/+yIoB7/////////v////+ABAEAAAQACGAy Xvvh9FA2z11rrpTu8c9jb33vpw7tbT2yrW73vXerdlvsn33vQg+Pnzx3xz2+ PfeK+fNzq9vbO+51e241az3zano+zQFVFVQczW5gXsO906ZTSopjz7j699h1 rmm+sJ2z1uy2yoaUZ7tp3WzD1duZhbTz53T2tbPC0SnzZ7YaglCEAQMQmNJp plPU9TAJiMpPNTINPUxMJqaZGgGR6mgYaaIAEIJhTVP2KaJinqemCmh5TE0e ptQAAAAAAYJQCEJpEyZTynqDao2m1I8mT0KeQaaIbRPRGCYRk0wh6aTNBJpI oIIaGo08qnmKn5TUPGlNlGjyCPUZNGgA08oNNHqAMgCJQgmUw0I0jTKZoTTa kzRkGpDanhGgmNTTTaaJiNNMTQNBIiCBGgEaAgmASYon4qPJ6jRPKb1I0wjy J6g9QNPSAZ+lcvD2+Lx9vj/r5KjbG2paFJGZACckIBwvyM5zFj9RmRdpoabs K7SWwwh+10ijvzuCgSxgOmRnRayWgRQEakCjFYwBRFGBBGgCFSIkFAiyLIGg YiSrCLbLCQB0k9SD9i/WmOMI1aoiKWJW/EXWtZccDKTIMmK5VVilVB3ZBSR4 snZkz2/ubngtg7Xt/w0orxa3UcRdQs+nLARFBVEEi8JQpEugsMuX8utKGBYg 6zMBkKZZMRwtFg/oWmQ1aMJRpfbuj3Gcx/VPvzrDv/k3JPb51EDRhlVWVcbj QS09sPCeAr+bd/2o4rts2/X/dUWDYgon1E9KsO/nNbDyGWTI2yg1KkQ9ytrE QVFBxgN7cKCZTWBbQoqhiUrLaDlwKMplYixGjLrymgM3vAsykxLGWUwMMMLi ZLQqHqC0XVZrMIrbRMpSoYwuSgxD/NMcVFFoLboLKoKxDLjY5w43NCuGwHBV wJ9OuVn/Bp1F4hhUcEfotUcQ8LVfKJk732N47S9GMiIlWclWGIV3VuPv1NTT tKo6/5mTwvER3vFROIV8Wa3s4NRg8GpQtm0LBB6WqpT8LjnFt0feutJvWtB7 LXdK2ZzKoZYPPWsEU7yxDm7nUU/HCfgrPu8CyyZ/yiPGSzOOE5bb4mXqoXeZ HKeBJdFqAsGdXZ5fNp9MLy2y15fKpm9D/bjPR0XOnPcP18LZHricd5WIQ4hD 91MSx35Pe6dKCHo3nHQqXrklw0k8CC/wCVy76/4o38mfO/5JZhOnrcenVX6c 028q/pWBl3GXMhwMyozGI91bDzMZs1gd1sz3bnCwxMHwOM2cWohL3tDkzEBk sFCiKrFi7NzWdHLNhcKSilyzYk+JA0gYy87JX8lOOZuzjheA6Qbq7TCqMM7Q rtBYGUygK0IvMCNHEfOlAwWKioJtJVR6LSJwCl36X9Trs6HkTno4w0yIo4I2 u08OB5k9TxSceBZYpD8eJ+RqOc+jf4W+JD5l5Mt+7moI565LwSpLrdeqe+Fu 8E8EMzZwdjp24NiqAk5uvGn0+Lo1w5hXjnLWA8szFypu4lVmR2ata7fu+9xc EYrNeu1rm5dmuN3tlwnQeKbOSYykR11HosrMpyqyoqq6jHRd+iKnKrP4fm8x 2u2yxapmCOJ6oaq3lyu0zHzY8rYaunG/GZ3dX5A2wq+QCACv0KoSA+qCjppQ 4RQunxTbDxxQtvpSB3o6oyAdsULIie8sAUOMFRa7dVWBqj3+6/2bDTyn7nwn 7f2u84E58pUDoZDBWRakaZTDCshYtZUbYQoyGQ8QySTmccDWx6TgY+P463Ms G22y+RDcGbfXTMDF/O8Bo6KN5CD0zuIWcPP2tl1x7T+EJe/0Cp1njOt5uzzP s0PkgfqjUz/RU7LeqxyVTbZvL/5J82k0r/BLU0prGt9R+76fXxvfh1qmFBPL lcdQaemiN5+hkJNKhvt2ZzfV/4vhOTCpWs+Y0XcQ2PQw0Z/v8mvAnLn7eFZM C4o3MJbpwh66+3m0epfI+iZmCE4f1jIbpalVTNqXgeb2m/XYpuRbPj1YyuBD FNO8fDP1zvHnXFW8nqnjT9sFec1WO+v6/ux9w7eN2vQRyV8WbZcZXA16CYRE KA/6nfIfSB/QKBc4JqiD2hr+b1fGfePFCRLQPphKknrL3Xalb15d6W7yrkWZ 2ZbsOKzHGGQ/79fRB/AgH2vhxpT6LKtgSsDeuVPjTtPnsVTmPkH3f265Fcz0 r34GWSHLQfB4XdllShAlJSSEAUNEx43c7hj38j9d2EQp1VDOE6ucrJBEyWx2 48+8Ij8ht3HFH5yeXHbs10Od3hnOc9mzbNn0oXChC63VXvmvMbsWX5E/0cNP 1WHvU6reU5pU0rjM3HwkDs3A7x0bTM8A3xRmzPx9B4/FRSU1JNIMdpUOZ7x0 PA1j1dLJOXWxybXNJwFJXSNdPhM0gLe6lSgTMa9AJStqUB1tUQgmGfTB35WH 8ssrmhuBieHWbxe1XMk3bpIvJsUSsQzXjeHY7izekwklMRvb1biCoqpxm+po U4rR7uVXsnIozkgrhT0ddoVlL9dsYioW9YghaiXIW/onF7WvZ7p2+6x7PP3O cTm8gmfMKkh5Q8eWUQlftiXnySoqBgoDi4Afw2c9oz2G+Xkv9NxRShmFFEvu YukwNE/ScxORtNe8rqlnw6BjGbDxcNJDz5+EfTFnjF7u5LoD3BprAGWoQVHN 6d0nEybUAQLh73I64x8ELjmnSeT5kHhZUo8+MIh1mAS+GuBDbG8Pu7MNjNWj LMxIGwxDmmqZWywXC36TlinHsX/KtXho0yUAqqKkzMkqDTCbB2uaobLgWncz GY3ewkkkkkn1e9NIrMJxBA9o1Du8beLvh4YZU7Vq8cLAP6DdV3v/O+Z4KpX8 Ub8BtD+zEO2vNj6ySSSSY0434mGVUXrQfF8+Pc+rGK667pGgqddqkVV6JS/e Vr1u8PTOmuTBTJ3bIRxuygybRCtKX7l5IJAk9XYoXQ+UTEHyIjn1bY6Yi4NF U88PXGf5xXCXNpAHIomFX7s8qa6tcT5ZU9/Yq5EUyikEM9Pfr8daoo03l9kT 0Z8RmYXejrSiRA3qQKTUR6FnMEy8hgznEVUlxESYGBro/7XXxWOBbfuTokWG vLfk2opHcveljGozHDVgJmvdzj31SbR9A85DfSEYUVfhWko2lEIRu7nI3FFR H8ZbhvboMZXJLjcBdHIIhOugUAiQCIQNNCa8fR8WrLv9CzQUe87TqU6V2jYp EW5x0rG2sSuZ09809Ua9vL5tejg8WGeNFLFW9eehW4Ll8bE7nB87yr4PcC4R VYSNhqcprVneP75NDCrA2I3dOu/CjLLBjLhUy/P1SsE104THDK4WMhUGGedN s1yj7r83jxfgxRf0+h2HzuIBEAyNT77t1xrZPHScFnxHsXSdqCLDTcwZ1WWA 6iMGsl+lfauCZcZcQCh2ocRMhfgU2xR6bHNpRmDm8jm7FumrbsWXZrDcwboK geRqq4ESVtr6kb4d/TAN1sPRXwn/xokfdr7O6gjhGxsbGmPUGQ2lBSeodE61 9N0lCUvGoAn2CEgwHIXY4qBuaxit1ncKNHtijtnL4stiapS7u9W32Vy0GtQc 9wkhTJwNLhY8qWb000RhmGFZ+tBCrtNGE3XlzEOgrG0ZurFe11RL6m3rH5SK 0VKWaiBPM+C0XoHI4ckj0Op+TtmIPLhIguhUBoZVPtMNuG3V50rc7Dp4RjWv eeEE9w22m0vc14wHKUAyMYoJTKBS0W32vUQ49/9P7Hifxl5MSLQY6QDTgGX8 +yhm+W8di6zJWIhbnDm1r1LvaXRuJDDJoglmBotOJjnG3nOJ2RIk8IjDBOqK qc3W2JNp3yB/4RkDfDQUoliyxKMiyKRQUFqRnw37SHwRA74MIMYHlGGYQCEZ uoH74tJUYMAIkPj+/U8/d0cFNoJwRQnlc3Xe5M0nviQoEDQpyd4sH9lEJonr MeO0bmfL4fP++Gy1sjZVVkPxfeTDD/7FQ+MGjDUWqhXHSLQXOfaDz+C7vuni B6Cf8OnlmxxneDiyqqqbo0TyTWa2vYhkNA4DGcHby5zMviWCiliww6Fuf4/w jhYJpHYG0kxyC1x5TR1Z2sJE/HODEoQt55QUMGrko2cPHWi5mkJNcIOnPS0T BDtjoWGF1tavTeMqx4E0rVoNg6vvxF3xNjY4NP0Rw6u3IXYeZXCrNVAds9U/ EIqm7QMIrm4B97uZ8GpuTjUUuHXGeKqO90mp5CXDEmTj+MXn++Tkoh9Gunba dPgxZqKzvstFY99ix/opn8g1494p8C2v6h51hiJFta5h9VPYQGjKqq4PHkbt T/smfXmN6JJu3wRNHeiIFg9Kb2rKPEafQ/sOLf42yWefHT4MQvcoxn4D3L6c X3uSA4MMbuCzLW46MG67Z/N00i+X9FuXQ8q6Uv7Gf0GvE6JR8YrRe+TCTR68 3u08WSS8uXeYN5/N7zhtOljS/qy4Nwr0pc09WFYc3xYab7tbRlZV8BhTUbVf qHHZWr3deTlyGTQGnFH9MlZvPFW0UX7Nk0yHuSSs/2urD43w8/Lw9n1eB4e7 +v8hw/I2qMVRRFAVRGIgpWSosQZBEBggiLIJnChD64J8pH4IH6yDhAD44P+0 UJFOmGpgIH40URxgtFWiwKC0Keuizv2XnEyqiA+8YkrJhKEl3eP2P5d3zrX8 nX7v32MoojXH0nsY+9GKJFHGBi+Hr082LpX7Yi7PdjuZwpUUSL99SV3HsDGk +/mvRCp7qZFugV2AOjbbfAP5zkL7vWcn7eTcOOzPqyCw9GmhKkiVRFBsR4nF wAlikPi933OHBrxmadvLannr6y9Vutyx7D9iaV2/Yo9hbu8Xhrdi1QQ9sLVo doMTiItiGxgw9Uz4vfDzh71FYxcuSTAWvizrGMYWb4octipxa2LU+JtiMSh1 EAQ5j3vQfR/O1rLaVuUoLIhSA+A/YWWoNgfk5zn6J1rcga4ukEN5BG3m8dKV M8g9ognnT0Al+gZ54Cc4w+I4+zKqF1ynJT3yIHJCFErS4mQFAvMsKg/AQVBA WYcVR0QlHOFvGY891ATBnMYbo9EfwHFuaoWJ7cxMIHE93CqtZbNhcTxp9yye iV0S7sHSbOR8jTEF80sAXofg8UDWiYgTMwmqyjH85pKCsxnCZzfMQ0IQhEkI QhCGlxuJmxC4rr8rg8fXbzI49NmuQ3CNsZOi8SXw1dfGmbP1eg38BzHC0vEO Cxw3GvAz4heqBp6UxdQ5ycevh96SEft/L9nrZDIZ8jMv3NacsqAiBiq25lC0 KK4JUsPX6/P0IxktD1HuB+fs7h+cNB2+/XXe8BERERERHQcw31iYHnC+lndo L0AeJAI9QYiqE9w1mHlGRNtBM4sSPqIOSnmfdTQ8KU3hiskvw/Rcta0azTmB PR8voTvy8fXM/tnNXsyD3IkqhzBB9VAH7IYfDKa4o1vhA6DJEhRBvVLv1ylR jjnqwLr0HKnrKn3xwkZomQiWte4iMKG3ssmglY1ZrlU2dx2l1fx21ksm9e6w jXRHljVEWZhakbXPojqDGoYTwDENO0n1NQl6Jwmvx3ySKyQwnCHfB7qKECbB tFNqfWNLrfvsTLAGXKnrtU72FvzXDRjTdI53vpOFqVGbj+E8cfGG4e8W46L9 gfifx67O/zwAg+4PKKmQ6paEPfhwhZ2kDF1tRYOy1+XyiHjZkQi98o5FrJpt p/uisweJGGmkLKha0pJCT+UM258l2Q3UmLr1FtRqVu+RePE7VwvOmOO5a8pX LZxgziDsTtEVtdrQiSQykvGgRHIpB6+QH4TvudOCS7TcZ8fVBzYkxmzVcGVo bKnmzIqbLCVG7u5TGeekThoVdlqMuUqwhfYm8Lv4LgHX8oKpdEdmdiunuH8c 3wiig1BDNOI4PeReDEs8Cm3xpm1U3z4+GlrFYM88DrQ6JJ89zw29jN1lQ7YX MPzK0TQK8atrH2YJK9uZAY+a+whY03ujoNXZx277GHCX365aSkKVrpqK6H5x +pSDoIdqkIO7DTkCyfECDUqRlTJcLnIyMk9Ub5HY65RyvhUVsI/Tek8oynET 6meXCFIVEno6M1k4WaNXCcZ96lWUnAoPGgHgCtXBSlboCOnqiOhgH6pCnU/W sNIrGFm5DZHsF1hKumnp6T0znSeSUxjEOsY0aS34X1cEbkdqs0gYoqJt25CM osbM7FpowrHGHJPZhmpNEk6ASoRM6XqKbOLzDIwBKowJaA27ZNtmPLa8sdLm bxvI9mIWLSBW3bsESc6oZmKZ9UjJhBm2y+ssCdWxFOG1Hz8OI2cSl2cK0UvC nAEFJUkQeGPZvxqO+tnruzreXkXEyKPbPYkqNJQYG1EKIrFFAHrs0b2b6/T0 +CPG0uC+6Ts6XcNLaPNQyfSMyJNSK21R/ZmdBn+GEn40cBiVHM4l0IiLYIm7 umCb4RLG71++pwbludxFyjA1xkvKNh7bg8317dwj5Yp4kGyPc6uHPZAh6q6H vY829pAxn2SZw45Ztky9ZRvtchBZTfeDtJMQgyP57MxKW5rt9yaV78fjcmit +TbBNq2qZRfZuMJnVLFXCKyOFoO8ixFyBwA+aW/I6h+EpIcVoL/Gw5lORGw4 Nx5AtuEJrGFD3takwEPTgRteTN0zQ+fGh0vxbvTXGo6ys890P2uhWPO1WkY8 V/LrcxHeyD8aqc5I5x0Usmu5uDFxdkO8od7dYSFTMRqxbXkcl9RMPr9WOuBc vsCqGDNXE+Jm0fBuq4x9kjcXLZ03W79l2D0xYOA8agKgi3pElWTq9j1Srejg R9EEPLED6yK/g/3L6BSMlCpD8R/dZvZQWNFaJSozg5iFrG0qiYDVEgYybQJ6 BCekZNpD2AkJEmGAT3JRMCSBKHR6hVBNmGZ7OZ6PZgmuGo1Uqne+2CKUfzxT 95ifYAAbiwAH1gAW/tFHbBtqazWYCjPGP1dc3IyMvm7Q8v5fs+kT0SI5ESQP LIH8SQJH/QPlaueYPzbENZQ2IfOYo2AzBxH9jruIxPzm47oUIeIPY58wbd4N VKxGMU/sOij9cKL88OEYm78oda3LKbL86HiKA7DFiye0C4IdHFpHYuIVKKfe XUpg/T7tPqhzXGs2xnZmv0HTjilnv1oOxNwR1ZgWqYbrkbHzmKHQlyNBOtwU MVKBiJQsn5g1FK5mZsPBD7OoypogqEOSDiANwRhAkDMzCyBXGEG+IOMFnpmg qVKCDHA2hizmZehlsS4vxSvcCVoah6zQUhmjER/cwJLbchUEzeIwDCBFA/CH sqarECGHAGN7+7Eb1KnVc+OJJY7Osmx/a+ok5PL2Lew2krGalmiyNgQHUDhA XPPa0Rh4VDqIUEuSAoZtZDREsiAhdiCjU4mBz7sUTmGwSRrMU9yC5CLmUiQS lvBb0HtWyFkMrcDcEVFNQxv3UGLBYG4YCbW9kLE4/qjzbOSFiCtC7ddgqhQQ FyN5YevTeEnNjqcZJcXiEjdXBUs2mMB1PhwTUCDIRIiobdDvRCAKAEwCgSlF VkAWY3mVubKBldyh9nc04clIUXjrdydVuzdxqJ3iK4gwDFg2GCO68o/i7mxt 1utr5CTAxucg5Dz9Ese4fOdtU2pvnnHwqGIZjub9ocrsYFkECPK8lwydUEpM cjLpDEJsRfaOE2G8aIRwwiSxxQ8PiTzhOmagDX7CNjPIB7ezAdFKKUwxAdpX I3hoCcxuwcz8JsyvUyAwF0/AU1HeIEGSSGZ5MkLkOtM8idepFa3IxQQkUBT2 HDt62/BoqlswMD2U7QrUtoAZ7SjfyEMg3mxDRGGC0TC5CgRSPOAbTFUIDYCv oB+O1/IIMjCkoY0SLrokHNykyCvfTNDgFrPu/z5NPMSS2Aa9QtTiZU74PiQd hhm82H0V8zluqqtwsjka9qW4PuORUbJVbIUnJuR4LmntYhUzHihedJ6iJiYA ORN+oxDaF56AG4dsGxsNuKODq1JepDcEDp9u8Onp3nIDMDsR8I8YwJKg7Sg6 CXI4KU0OszRtU5vbJ7k0ckO7Icw57idKdC1QxM0NT1oVQKnwBkOoGyamLQ/N uoJwGhroKGUUQiMA9n2o2X5l6Rfi/+lv0R80PI97wFZgH7BOwi5Fn2fX0d15 nc5R6+37T5Ufe7De45CBEKeSJnKqqnsUz5uvmeljYYi9P3jlg/yTKRdlPeT8 UXPj9Z8ksr+9/WGNdDxNAoZ2FoWa8zVps2anySUhBWu7CfXKUCUNudL9a92w Uo4g+2nBN3rahq2joaX8daGMSksTT7/+0Cp9aRlkLOpyjisznwIhZHVgXw2h VGhvBaYg74Wqe5RhRDV8O+jvTtPuPx9kSE+31gadPq0JpSIUHVDk+UxqCilk wGSIBIKRLdwsgDKYZAxPwlxWy2ZsdHfTCWDXO9qEXXQ52YeBI0BE8+hv1ILs U8lJtN+1fdnSaUiIoGf25iWA1hVp8sGyeL5cBGwpxDjz+tYoDTtNcGzcG2zb bfVbjHETy07eSxM+wDnOgrwSCzFzMa57zDf2mRnoWvfoGMLeU4U5CO3FcOQj fLcdXqYJYnIChpIi7E0dJpwFOp29nak3oclloLcKVoi9AVV96WR1NKA8v5yQ o0vCBtjf8kSk2BrQlQRUHC/C5t/2CzuhcnSEhe5B0DMMuRLqHB9gbPQd/aur IGB/V5FRPxzjxhtjEgUtIJhLbKkskJFJAQoBUAHIr7IN63mtOAjr1jy9HCp0 wQzQFDjU/PdddNlmQUDnP3nbBcNjNOARVGwlfteQk+BrX0ZhJxON8y7F/8+R xwwuuHWIaRx4LQLkeaBmxXBqgEkAzZOG5JaJXkSka08MqEmFUkXQWJwXC2BV GDxS8ZkAheKlFbrqbFTQnFoAwmSdbwu3xtO90GIZmUgyVHKQDlA6vCQ8kHQ2 X3XJJJZ2BQfopPMaiinbuDbsP3wOPgBgW9JsO0uH2Oh3HAsMdg7/PpsV58Ch +QnW+Qodw/pDlCQT2cw+u8eCQe15Pj6RpjhUaLiVnvK/D4FrjD+oIg5D88D5 +mkQ2mziO3IPbwcyTw0TfOdHXFkP2dZxCFRtIKtvZA5m+EgQVLzoeso+4Nlf uq5GF2m+cQwCdLILOZwmuo6xCdrED2lVYqDeUOy8oZ4WADZUEqSiB1dkmvXr VcydacxvAvi4mS2nPai1GFnG+uimg7LrteeBI6S2EEGQFQ4+JO7svUciQ6SU MPHyMDwlA0Io/p5gYwXLZIFNZNgKmQ8YSgSsgmAnibbUK5FkVYp9H+cS7kC0 GQkSqcTsxsTsIBv2UOk+Wdpy5dZQVO0EiWg1KHRhfXrezV7LozVlxZwBP0jM MLQOyTRVFZkmshCUkNDvCi4pAwQlDB2JG0C6bFjHGkFAT62QxQNpKym8VKK8 QypRWRUVIgrp9pKSg5nIO59AyB+wgJaCYOoXMVi2AhNhzEjgFB2XDavm2MZ4 HgfuQlgaeX0vDSK1iPabI2IOEb88gaOQiMM8q10WzTCJEWwpYWQdkKdsFf6N ystR1KMY0NXT9GzbXCMz6zNBXYGMSEiAgaUeF5GNcAaAaCe0RNomgH6lg98A LumtDFgeOJUYRImoh+UvVE7YAXEGyco8AHDYBs2YyUtSpXpGENYeTiUTJr1v l1HjA9Ht2tsdINvKbfBbliq0hAyb8UQiCmJwqKvCwDIgohzrccIloRJYsLTt jevsShgZcYbpIbL5PA11yR7XYlYGBkC0DMQ0ktaFYvhHBZnQ9OVqTC2A8mJU rE2Dr1mBUgQk9HcJKrctYRV4Mwwz1MMVuL5lf73QZizEDVZ30yuSq05dQYDB r1MfbAYmJplnmbraxXmmLBcIEG7XJViMlMGBYpjYQHFkXwE0F0e08YilH0YR E9rmvloG+Fgcwg9k2YhhnMzkYFYUITIk0Dbr4Z7/ApxIL9pPxc8cKi68/Ax7 vnkqbXjg7g4BxDi1N6nMePE0TQNPxTvW73FXMirbruD5UPvIe3znLgB5Jh7T 1/TwFVEVVz5uuQ7umGeBiHpsa9M2HkOG0nbxxhLfn2j3j7xok8MA17cWV7od AqD2WcH1AZiztUyZkVM4H6OUpewFRLZ1gDHAOWooW7oa76KxWJtFIgpDniDY pFSRwJq/panblgEg8ELGDeyiU9/dnQwDhgZV1qypBDDeplRESmHm8BW/ZhuP l1ulJIyEeuL0VWTPJzyefMgy/TCgGP1dVqdMbHBi2tLjw9lEeIS3EQ2lslkJ sghWSBhVVVIxncZCSmemZTmQfVe0qGg9qTFb9V5+GmiFoIFuYIwTrVBOtqeG qI0iLvufFM3aHoaBQJ5fNuYQn1UaNjWGcB4F2XihHPmewD2WCIdQVXz5NAoY ZJ+CvSb5A7gbZYI1CfOrIcV1z4dMwuTT1aikarkGy+WfI1uO1fQXcNVLpUWt i9VoBsI8SBg3oeLZCylMCxu59WKOHlCEQiVEQstx9uddl4DajTZvKskShpQz a0xWFEdQ52d/PeksRpCEWOdAJDCjozHKrmcsKNa7gjpEztzZZkYYZoMnQVIu M3H2Fkqp1RzqYp0D38yFAjv4WsNESzQ6+4oPykDcG8vRrFWK6iPkaqXSbM7i 5utAr9NEkFvwBphBHb48uHmZJJOTpgpuRczBm8o0OItS7xHYdvYYGuGEGCWZ Qkew1H1A2edIqTF1X1NECZXvIJ2kRBllvg6UAAw+UIyBC+H6NeXP1o7mmIuQ C8WIlsSN94DbG/WFgWA7T0fY+3kx7RArAr7HFiiKRZEY7oFghzKH2p2JZ5/i TNfaNKviHXOrUQ1JlloJ3mR6wlHgkhfcgOp4ntxvTSRY6egHmVsShsMYCxc8 RBjwEi5sf60fpy0QllaNDu4Ynh6J6Qbs19dLcNzM8G01uiTfiDLID3RMJIuO 7dXNU4EwF9mr3iBHXPoZlhdGkel4jD0jQTA3ANDBTFKWiUR4e7yvLCWUnMoR DZAgbu2onOAGiiCDBYoqQ6SgdVFOcmdWw91CicsiISZ06AvYQQDGBmVw2rjN Q5/Tu7Ho4ZYSa2A6JHH20mpSrrWtVhCyGNNg0mE+c6Tp7fd7+7DyyebZ0Mf2 Woh9lCisqPvkvODQPehUwmWKYkcBTWTFYEgL+J0CQ7kLkeBj1YfSeb8Kpf3J QfhbDeQvkJe6UN6DG0HhZiFELBgD2PnzCNGMyaybwrJMyzCZDGBD1zJqwLjx n17DEIMgPHXG9Gawa+z6NljcFtgqaV9w9ReXa2TLY5IiHuiZrhmZglzRbCL6 Cm9UtUgazLW5ugSDShNLdv7RGn5y1QWALEmMvhj4T8CGMXnPqmsw1iyEzijE UnIOSLd6zANhhiOypRRiO4/eeGXVkdxUAPv96KXd6tsf+zCpYVhETPkAelcJ NhxfD9m8mlCE/CgNpFGtvBgft1kJ9HjvS646UbEISEYyS4ZOR7nsbvj9A68N r2m3BQk9RyQGgkSJePKLiuzdSvl0FiGBHa4MehJHwrHrVLtDZiBRTBaiovf2 cGEx7PEv3QUN9pPIxTw3txrdNoiPOqpsxcEidpKSVo62pR597YZEGQOouXUw n2sI4xrO6EfQ8wyzunoa40TGs0eJGwZ6BBWNzBtULxG6Fn+S+c8hYlhgyQZq HkID3UWZgVJveowpUzXyuTA6BSBNIBhjZ2Tdm97uqUyrTRrczNWhtDGGV8Zm BraV/5klyJ12XQ7HkYWIOTyuAhBSaYeBWED5AmiKUyOgGmoEVhSAN6UXGJIN KFqQCPkbsNJ1esC2IGI6qTIUVMYQrJVbPMTrORuUOHDv3D3k5HGgJBJCIgcA cZr7cEAzMFvl8ni//5M/Jv7nY0TMFng7qePtJOiAiKMRZEQWSWAgeVo87FpI ffdCTEkgsBYQ/L3kLxt3TzSdcgq18LK6LGMMRISKcry2A3SCBDaACMSNiJQW 1WgMO/edJ+hmTUL1C+IVDxufQvtmNfpvsrX2MTaBsbjAnKgQxlLAnO18lpDJ uhBIhPxfZoQn4TrJ4tAFnbREuED7ge6PoJJugHMGp3EdAfSUePAv+4q7PVwb x93N3kUbva3BZJIsZmmNNDeGhNqYNg9Q2SUGIrXtST1visRHNo5gWxFKCuox JVxCDdqvPE1U5EmSDPtCWupbKUUHyiF+Fdw2H1C5GBbODSapNUC59iOKQMY2 NNJVYdn6+a3Gxj5Bu506C+tRpqbt1TqSuwtkEazoFToZjuMYYozAhdqFO7CY g88SQUC09BOiG0XdnIjQfyqI5yEe9qGMdhbvOtUY2Ksu7lu2YThEksdvqDCd UAW4TB1IaxFSMM6H146QpQFHf87w8R4fiVVVVV0B5+o129EgeUPCAdfc+gyQ OxKzPm6JpjmXWKEkUncfmqVYMZb4rvZyK/3FjVmH7ergE2b4ySJemESOub8+ 6BrV0LvBqpjee0XiVDsBCRFuomKxuuCi9pJLLLJGVmrRRFrXiccMYrNUqMVn xiKSvA9LKgiKDukqfASlgNkuwgSw1LE1uY4JjSboSwpUL2CIohlgDGUKC+bo kfTuNgXwNpxN5kpLGJlsFj0lFaUJknvpCbl8sGgMzx2gqBtDG+9H/CvQ7MyT y8h1KbDG3EZR6DUNZogjUZB0FEfvHfCyUBqBe9PiQ0RhESRFZoQqKRMzwb7t vQvKRmlNk+kWNvyeTwZA3PYjRE4IBk1QEwoYWlRkJANjDm8BbD6LnRFGvu/Y Tgh5nWi+cOf56qPRUnZtDA0DQqpQ20Vcaol0kFkGQC6hQsxoU2++uCIniM3r 3JgdCBrMmSIF+W9018rpGe5z0kYiBVJWWgkUfc/b08oeStkLPDTzm66QtF6L 040LpeLjN8lxrJ6F9SxFDmQoI9ogHh8HugovZQq6U+P9Vaa8NoGF5Tv1Ox4w +MhIFKbdsHzrQKNrSScAl4P030cQAknjrstUqHkxsiYwN+1IvRASwNCLbdtx rw+Hv9/Px8/FLtPlwK+TsA3vvwU3dFmJWgGVqtII6eLXMEG2dkp222lfjUPk OL+EqGNJrpsUClg94MyfiFYSOT2o7+ZQp07Cc6EF17A/CRaqrALqd8UQycuQ 0+rnOmbHc3BYGCcIkiPiJ5PMYqlCJwpTiHIwxiyLCw+C9A018TF5u94HldgY kjw4yWdBzgKn4ICR+7K1UUSDSlo0mQDJDbrKJYxh7Us1njActbVphZUxL9Ap gMgh48MvuGSEw1RTLRSaC15+Gah1NgKEjDdsKRDHKRoBn5Bv3lpIekyptbKg OKTBp+Wb06CU+W4pLFhkZDRKoQQQYCLBa1YqUPhyalKMdPcThUzFoENobGkn mTpWM2pCVsENacnS6ooLQpE02BYAdhi0JayDQZuIgMToWICAFEozcsqFypB0 ChGKelVIjAZmL2mbK4Wm+dlHYVhlPLZkWmJl1sRBbQzM5XZVsX6hmZoqAjmN AdtGAxaszH2kAhUdhwyEzKUQFRAc9ypwsUcgWj8MRQqEFpBzMTUOoSURaK0g sDuZDeOiWMBOCWmEG4ItMiG2iEp3wK2UYMXszzawVUDBgBE8T9IVK1pMiPSd fBgybVEK6RtkwI2JJLmizm4YctCnCBgRguhJIQc5wKtcgwKmixE4kR5uZdz1 MWkCtCL+mIGhCExm5dTsjXqd5IQU06dtA93EvwPIUFVTYOEIRpyTeJpBVlHD dJlg6IX2KBxuKIgYlFKGxa0Xb4wztWQxQ0cejuzwOh5HKlPx9rYi1Js7fLwN HtIOiInSKc0ESI0oh4hXeSy/5I9/8CGEQoPGXVu7gaET4C2FaHQoRGUJi+To UntTOINAhjDJbB4GcVBUjGTjKSmFPN8wDUAsaIyOwGYxXvk8GIS/K0LicYWP NfSpI/B6yjcfu6qHET4H8vEbOqbj5n+q3FtYOQxedQ9pTuJCIkIshIqlSID/ 2f16s2sRYE493HyHxzyE6g/oScwOHJYSls5xt7jHQqkUahqGArev5x5m6LpA tmYOFJvYDA8DZZLCvv8ySFGM3OpJAI2V6BLea/+P1vMcIZHbQPghzTFYHs9N NYwbA8hvWpQGbRNooSI8nyUP5FT3q0P9ekr0/N8IBcIYkD/wi/wI+xoeAN+9 2N7rd/M3tSQeXdNCECUtjU8/SZml4U6h+YQ7DsLT2tRCTCk4noekDamQdMvw S5eYtvR2IHeP8O9mCNYHyxYIMEknrRGHwAyIzQfIWFYslWzbI/bIkQqkEfRu Q/mQ0Af/i7kinChIegTuN4A= --------------070102000002060504000109-- From kuznet@ms2.inr.ac.ru Fri Oct 11 13:18:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 13:18:59 -0700 (PDT) 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 g9BKIqtG017913 for ; Fri, 11 Oct 2002 13:18:53 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA28278; Sat, 12 Oct 2002 00:15:48 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210112015.AAA28278@sex.inr.ac.ru> Subject: Re: [patch] add iocb to network protocols To: bcrl@redhat.COM (Benjamin LaHaise) Date: Sat, 12 Oct 2002 00:15:48 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <20021010194025.B13432@redhat.com> from "Benjamin LaHaise" at Oct 11, 2 04:15:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 637 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 private area of an iocb for network operations contains a struct > scm_cookie. The alternative is to allocate it via kmalloc when needed, > but there isn't currently a way of identifying which network protocols > require the scm_cookie. Kill it. It was not killed in 2.4 by plain luck, sorry, misfortune. However, I do not understand this. You need to pass forth and back SCM_RIGHTS is some way. It is quite dubious to make this asynchronously. The same is surely true about credentials, they should be latched on entry, not at the moment of real execution. Kill anyway, at least in synchronous calls this was my mistake. Alexey From bcrl@redhat.com Fri Oct 11 13:24:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 13:24:54 -0700 (PDT) Received: from touchme.toronto.redhat.com (to-velocet.redhat.com [216.138.202.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BKOotG018151 for ; Fri, 11 Oct 2002 13:24:51 -0700 Received: from toomuch.toronto.redhat.com (toomuch.toronto.redhat.com [172.16.14.22]) by touchme.toronto.redhat.com (Postfix) with ESMTP id EB9CA8001D2; Fri, 11 Oct 2002 16:24:48 -0400 (EDT) Received: (from bcrl@localhost) by toomuch.toronto.redhat.com (8.11.6/8.11.6) id g9BKOm601466; Fri, 11 Oct 2002 16:24:48 -0400 Date: Fri, 11 Oct 2002 16:24:48 -0400 From: Benjamin LaHaise To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: Re: [patch] add iocb to network protocols Message-ID: <20021011162448.A1309@redhat.com> References: <20021010194025.B13432@redhat.com> <200210112015.AAA28278@sex.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210112015.AAA28278@sex.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sat, Oct 12, 2002 at 12:15:48AM +0400 X-archive-position: 638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@redhat.com Precedence: bulk X-list: netdev Hello, On Sat, Oct 12, 2002 at 12:15:48AM +0400, kuznet@ms2.inr.ac.ru wrote: > However, I do not understand this. You need to pass forth and back > SCM_RIGHTS is some way. It is quite dubious to make this asynchronously. > The same is surely true about credentials, they should be latched > on entry, not at the moment of real execution. You actually do get to execute synchronously in the user's context the first time the function is entered to queue the operation, so collecting the credentials on entry and storing them for future use will work. I'll submit a cleanup that does this. -ben -- "Do you seek knowledge in time travel?" From pekkas@netcore.fi Fri Oct 11 13:33:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 13:33:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9BKXqtG018805 for ; Fri, 11 Oct 2002 13:33:54 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9BKXkS23996 for ; Fri, 11 Oct 2002 23:33:46 +0300 Date: Fri, 11 Oct 2002 23:33:45 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: IPv6 ioctl's? [Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt - new ioctls? (fwd)] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 639 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 What do folks feel -- should there be some ioctl's similar to IPv4 or such? Currently this is basically available through proc or netlink, but I'd prefer also to have some (at least almost uniform) mechanisms common to most implementations... -- 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 ---------- Forwarded message ---------- Date: Tue, 8 Oct 2002 11:00:27 -0400 From: Kristine Adamson To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-07.txt - new ioctls? On 25 Sep 2002 Pekka Savola wrote: >>This is probably a dumb question, but is there must be a reason why these >>API's don't talk at all about ioctl's etc? For example, I see no standard >>way of obtaining (all or some) of one's IPv6 addresses, or whatever else >>was useful with SIOC*. We also have wondered if there are going to be either IPv6-specific or version-neutral replacements for the SIOCGIF* ioctls that use an ifreq structure? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From haveblue@us.ibm.com Fri Oct 11 14:48:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 14:48:22 -0700 (PDT) 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 g9BLmGtG022357 for ; Fri, 11 Oct 2002 14:48:16 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9BLm9mn054752; Fri, 11 Oct 2002 17:48:09 -0400 Received: from nighthawk.sr71.net (dyn9-47-17-248.beaverton.ibm.com [9.47.17.248]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9BLm8QA221388; Fri, 11 Oct 2002 15:48:08 -0600 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g9BLm1L05256; Fri, 11 Oct 2002 14:48:01 -0700 Message-ID: <3DA74711.2050907@us.ibm.com> Date: Fri, 11 Oct 2002 14:48:01 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: Ingo Molnar , lkml , netdev@oss.sgi.com Subject: timer oops still present in 2.5.41-mm2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev Ingo, I hate to keep giving you false hope that this is fixed. But, remember this is just -mm2, so any current BK fixes that change it wouldn't be in here, including the keyboard timer fixes that you were talking about. Andrew, I noticed that you picked up Ingo's timer fix in 2.5.41-mm2 as timer-tricks.patch. Despite this, Specweb ran for about 10 minutes on, then failed with the oops below. 2.5.41, without Ingo's patch oopses in seconds. It's very hard to get results out of Specweb when it is crashing this often. Could a misbehaving timer be causing the TCP errors too? I'd never seen them before 2.5.40. I don't know how closely the TCP errors occurred to the timer oops. Attempt to release TCP socket in state 1 e099ed60 Attempt to release TCP socket in state 1 f58cf460 Attempt to release TCP socket in state 1 e0f7d5a0 Attempt to release TCP socket in state 1 e106c4e0 Attempt to release TCP socket in state 1 e02667e0 Unable to handle kernel paging request at virtual address b800298c printing eip: e027d3e0 *pde = 00000000 Oops: 0002 oprofile CPU: 4 EIP: 0060:[] Not tainted EFLAGS: 00010282 EIP is at E nlm_debug_Rsmp_53445f68+0x1fdd5114/0xffd932a4 eax: f58cf698 ebx: e027d3d8 ecx: e164e6f8 edx: c0375ef8 esi: c0378060 edi: c0375b00 ebp: 00000292 esp: f7f97f14 ds: 0068 es: 0068 ss: 0068 Process swapper (pid: 0, threadinfo=f7f96000 task=f7fc0060) Stack: 68c03780 c011fa30 e164e6f8 cb1101c8 00000000 f7f96000 00000001 c011c9b5 00000000 00000001 c0371960 fffffffe 00000080 c0356dc4 c0356dc4 c011c6ba c0371960 00000010 00000004 00000000 00000000 00000046 c0110efd f7f96000 Call Trace: [] run_timer_tasklet+0xe4/0x12c [] tasklet_hi_action+0x85/0xe0 [] do_softirq+0x5a/0xac [] smp_apic_timer_interrupt+0x111/0x118 [] poll_idle+0x0/0x48 [] apic_timer_interrupt+0x1a/0x20 [] poll_idle+0x0/0x48 [] poll_idle+0x22/0x48 [] cpu_idle+0x37/0x48 [] printk+0x11e/0x138 Code: a3 8c 29 00 b8 04 26 c0 a0 d1 27 e0 40 7b 37 c0 f0 d3 27 e0 -- Dave Hansen haveblue@us.ibm.com From Andrew.Morton@digeo.com Fri Oct 11 15:00:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 15:00:03 -0700 (PDT) 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 g9BM00tG022749 for ; Fri, 11 Oct 2002 15:00:00 -0700 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 OAA21005 for ; Fri, 11 Oct 2002 14:59:54 -0700 (PDT) Received: from schumi.digeo.com ([192.168.1.205]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002101115005830132 ; Fri, 11 Oct 2002 15:00:58 -0700 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by schumi.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 11 Oct 2002 14:59:54 -0700 Received: from digeo.com ([172.17.140.150]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 11 Oct 2002 14:59:53 -0700 Message-ID: <3DA749D9.83047205@digeo.com> Date: Fri, 11 Oct 2002 14:59:53 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Hansen CC: Ingo Molnar , lkml , netdev@oss.sgi.com Subject: Re: timer oops still present in 2.5.41-mm2 References: <3DA74711.2050907@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2002 21:59:53.0496 (UTC) FILETIME=[874C4180:01C27171] X-archive-position: 641 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 Dave Hansen wrote: > > Ingo, I hate to keep giving you false hope that this is fixed. But, > remember this is just -mm2, so any current BK fixes that change it > wouldn't be in here, including the keyboard timer fixes that you were > talking about. > > Andrew, I noticed that you picked up Ingo's timer fix in 2.5.41-mm2 as > timer-tricks.patch. No, that was random akpm hacks. Ingo's fix is in Linus's tree. And, hence, in -mm3. > Despite this, Specweb ran for about 10 minutes > on, then failed with the oops below. 2.5.41, without Ingo's patch > oopses in seconds. It's very hard to get results out of Specweb when > it is crashing this often. > > Could a misbehaving timer be causing the TCP errors too? I'd never > seen them before 2.5.40. I don't know how closely the TCP errors > occurred to the timer oops. > > Attempt to release TCP socket in state 1 e099ed60 > Attempt to release TCP socket in state 1 f58cf460 > Attempt to release TCP socket in state 1 e0f7d5a0 > Attempt to release TCP socket in state 1 e106c4e0 > Attempt to release TCP socket in state 1 e02667e0 Well it could be that TCP is abusing the timer code. It would be sad if we were looking in the wrong place. Might be a timing problem in networking which has been exposed by smptimers. Have you tried enabling all the memory debugging options? It'll cripple performance, but may help find something. From srompf@isg.de Fri Oct 11 17:00:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 17:01:01 -0700 (PDT) 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 g9C00wtG025461 for ; Fri, 11 Oct 2002 17:00:58 -0700 Received: from isg.de (shaft17-f138.dialo.tiscali.de [62.246.17.138]) by mail.isg.de (Postfix) with ESMTP id 7F456D627DC; Sat, 12 Oct 2002 02:00:51 +0200 (CEST) Message-ID: <3DA768EC.D8D69263@isg.de> Date: Sat, 12 Oct 2002 02:12:28 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tim Hockin Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: PATCH idea - netlink and link changes References: <3DA7035F.5080101@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 642 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, > I'm not subscribed to netdev or linux-net, I was asked to forward this > patch to these lists. Please CC: me on any commentary. funny. Today I've finished a new release of my link change patch that lay dormant for months. Now there is a choice ;-) Cheers, Stefan From srompf@isg.de Fri Oct 11 17:23:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 17:23:48 -0700 (PDT) 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 g9C0NUtG025997 for ; Fri, 11 Oct 2002 17:23:31 -0700 Received: from isg.de (shaft17-f138.dialo.tiscali.de [62.246.17.138]) by mail.isg.de (Postfix) with ESMTP id 863B9D61F91; Sat, 12 Oct 2002 01:54:58 +0200 (CEST) Message-ID: <3DA76407.F16521F4@isg.de> Date: Sat, 12 Oct 2002 01:51:35 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, davem@redhat.com Subject: Patch: link state notification for 2.5.41 Content-Type: multipart/mixed; boundary="------------BBFAC417D0AD1512B229B21A" X-archive-position: 643 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. --------------BBFAC417D0AD1512B229B21A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, some months ago I've sent a patch to the linux kernel list that enabled notification of network driver link state changes over the netlink socket. Technically, this has been implemented by a kernel thread that mirrored dev->state:__LINK_STATE_NO_CARRIER into dev->flags:IFF_RUNNING and sent netlink messages. Note: The in-kernel-flag IFF_RUNNING is unused at least since 2.4, it is the LINK_STATE_NO_CARRIER bit that is seen as RUNNING from user mode. This was followed by a discussion with Jamal (look at http://marc.theaimsgroup.com/?t=101751064400001&r=1&w=2), however, it took ...ahem.. a while until the revised version I attach to this mail. Don't ask ;-) I had quite positive feedback from LVS and zebra people, so I tried to remove most of the objections against the patch. -Anyway, I wanted to keep the current semantics of netif_carrier_on()/_off(). The extended states that can be found RFC2863 did not seem to useful to me for linux, mainly because "notPresent" is already implemented with netif_device_detach()/_attach() and especially for ethernet drivers there is no real difference between "testing" and "down". -Using Ingos workqueue implementation, I removed the need for the first versions' own kernel thread. -I changed the simple approach of iterating over all network devices, now the handler only looks at devices that had an event. This change also increases compatibility to broken drivers that manipulate IFF_RUNNING directly, there is a good chance that these drivers will never generate state notification events. I kept the semantic not to create a list of events for one device, only the latest state change is forwarded when the queue is run. Patch against 2.5.41 is attached for comments, of course with the aim of kernel inclusion. I have tested it on a UP machine, but hope that I've got the locking stuff right. Cheers, Stefan --------------BBFAC417D0AD1512B229B21A Content-Type: text/plain; charset=us-ascii; name="patch-linkwatch-2.5.41-new" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-linkwatch-2.5.41-new" diff -uNrX dontdiff linux-2.5.41/include/linux/netdevice.h linux-2.5.41-stefan/include/linux/netdevice.h --- linux-2.5.41/include/linux/netdevice.h Tue Oct 8 22:18:50 2002 +++ linux-2.5.41-stefan/include/linux/netdevice.h Sat Oct 12 00:40:34 2002 @@ -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 }; @@ -437,6 +438,9 @@ /* this will get initialized at each interface type init routine */ struct divert_blk *divert; #endif /* CONFIG_NET_DIVERT */ +#ifdef CONFIG_LINKWATCH + struct net_device *linkwatch_next; +#endif }; @@ -480,6 +484,13 @@ extern struct net_device *__dev_get_by_index(int ifindex); extern int dev_restart(struct net_device *dev); +/* This gets called by netif_carrier_on()/_off() whenever + * state of an interface changes + */ +#ifdef CONFIG_LINKWATCH +extern void linkwatch_fire_event(struct net_device *dev); +#endif + typedef int gifconf_func_t(struct net_device * dev, char * bufptr, int len); extern int register_gifconf(unsigned int family, gifconf_func_t * gifconf); static inline int unregister_gifconf(unsigned int family) @@ -640,14 +651,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 -uNrX dontdiff linux-2.5.41/net/Config.help linux-2.5.41-stefan/net/Config.help --- linux-2.5.41/net/Config.help Tue Oct 1 09:06:18 2002 +++ linux-2.5.41-stefan/net/Config.help Sat Oct 12 00:56:59 2002 @@ -472,6 +472,17 @@ However, do not say Y here if you did not experience any serious problems. +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'. + CONFIG_NET_SCHED When the kernel has several packets to send out over a network device, it has to decide which ones to send first, which ones to diff -uNrX dontdiff linux-2.5.41/net/Config.in linux-2.5.41-stefan/net/Config.in --- linux-2.5.41/net/Config.in Tue Oct 1 09:06:24 2002 +++ linux-2.5.41-stefan/net/Config.in Tue Oct 8 22:44:07 2002 @@ -82,6 +82,7 @@ tristate 'WAN router' CONFIG_WAN_ROUTER bool 'Fast switching (read help!)' CONFIG_NET_FASTROUTE bool 'Forwarding between high speed interfaces' CONFIG_NET_HW_FLOWCONTROL + bool 'Device link state notification (EXPERIMENTAL)' CONFIG_LINKWATCH fi mainmenu_option next_comment diff -uNrX dontdiff linux-2.5.41/net/core/Makefile linux-2.5.41-stefan/net/core/Makefile --- linux-2.5.41/net/core/Makefile Tue Oct 1 09:07:40 2002 +++ linux-2.5.41-stefan/net/core/Makefile Tue Oct 8 22:58:44 2002 @@ -21,4 +21,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 -uNrX dontdiff linux-2.5.41/net/core/dev.c linux-2.5.41-stefan/net/core/dev.c --- linux-2.5.41/net/core/dev.c Tue Oct 8 22:18:51 2002 +++ linux-2.5.41-stefan/net/core/dev.c Sat Oct 12 00:19:38 2002 @@ -198,6 +198,9 @@ int netdev_fastroute_obstacles; #endif +#ifdef CONFIG_LINKWATCH +void linkwatch_run_queue(void); +#endif /******************************************************************************* @@ -716,6 +719,13 @@ * Set the flags. */ dev->flags |= IFF_UP; +#ifdef CONFIG_LINKWATCH + if (netif_carrier_ok(dev)) { + dev->flags |= IFF_RUNNING; + } else { + dev->flags &= ~IFF_RUNNING; + } +#endif /* * Initialize multicasting status @@ -2590,6 +2600,18 @@ #ifdef CONFIG_NET_DIVERT free_divert_blk(dev); +#endif + +#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(); + BUG_ON(test_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)); + } #endif if (dev->features & NETIF_F_DYNALLOC) { diff -uNrX dontdiff linux-2.5.41/net/core/link_watch.c linux-2.5.41-stefan/net/core/link_watch.c --- linux-2.5.41/net/core/link_watch.c Thu Jan 1 01:00:00 1970 +++ linux-2.5.41-stefan/net/core/link_watch.c Sat Oct 12 00:48:51 2002 @@ -0,0 +1,113 @@ +/* + * 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 + + +static unsigned long linkwatch_nowake = 0; +static unsigned long linkwatch_nextevent = 0; + +static void linkwatch_event(void *dummy); +DECLARE_WORK(linkwatch_work, linkwatch_event, NULL); + +static struct net_device *lw_first = NULL; +static spinlock_t lw_first_lock = SPIN_LOCK_UNLOCKED; + + +/* Must be called with the rtnl semaphore held */ +void linkwatch_run_queue(void) { + struct net_device *dev, *next; + + spin_lock_irq(&lw_first_lock); + dev = lw_first; + lw_first = NULL; + spin_unlock_irq(&lw_first_lock); + + for( ;dev; dev = next) { + next = dev->linkwatch_next; + + /* We are about to handle this device, + * so new events can be accepted + */ + clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); + + /* State of netif_carrier_ok() is reflected + * into dev_flags, and a netlink message is + * omitted whenever the state changes + */ + + if (!(dev->flags & IFF_UP)) continue; + + if (dev->flags & IFF_RUNNING) { + if (!netif_carrier_ok(dev)) { + write_lock(&dev_base_lock); + dev->flags &= ~IFF_RUNNING; + write_unlock(&dev_base_lock); + netdev_state_change(dev); + } + } else { + if (netif_carrier_ok(dev)) { + write_lock(&dev_base_lock); + dev->flags |= IFF_RUNNING; + write_unlock(&dev_base_lock); + netdev_state_change(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(0, &linkwatch_nowake); + + 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; + spin_lock_irqsave(&lw_first_lock, flags); + dev->linkwatch_next = lw_first; + lw_first = dev; + spin_unlock_irqrestore(&lw_first_lock, flags); + + if (!test_and_set_bit(0, &linkwatch_nowake)) { + unsigned long thisevent = jiffies; + + if (thisevent >= linkwatch_nextevent) { + schedule_work(&linkwatch_work); + } else { + schedule_delayed_work(&linkwatch_work, linkwatch_nextevent - thisevent); + } + } + } +} diff -uNrX dontdiff linux-2.5.41/net/netsyms.c linux-2.5.41-stefan/net/netsyms.c --- linux-2.5.41/net/netsyms.c Tue Oct 8 22:18:53 2002 +++ linux-2.5.41-stefan/net/netsyms.c Fri Oct 11 22:38:37 2002 @@ -596,4 +596,8 @@ 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 */ --------------BBFAC417D0AD1512B229B21A-- From srompf@isg.de Fri Oct 11 17:23:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 17:23:51 -0700 (PDT) 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 g9C0NUtG025998 for ; Fri, 11 Oct 2002 17:23:31 -0700 Received: from isg.de (shaft17-f138.dialo.tiscali.de [62.246.17.138]) by mail.isg.de (Postfix) with ESMTP id 7B07BD59607; Sat, 12 Oct 2002 01:55:08 +0200 (CEST) Message-ID: <3DA764D8.FCDF34F8@isg.de> Date: Sat, 12 Oct 2002 01:55:04 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: jgarzik@mandrakesoft.com Cc: netdev@oss.sgi.com Subject: Patch: link state detection for 8139too against 2.5.41 Content-Type: multipart/mixed; boundary="------------69CFC4E010FA068A120E8BE6" X-archive-position: 644 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. --------------69CFC4E010FA068A120E8BE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jeff, attached you find a patch that enables link state detection for the 8139too driver. It applies cleanly against 2.5.41 and with some line offset against 2.4.19. I've written this stuff on a friends' computer using 2.4.18, so it is only slightly tested. Cheers, Stefan --------------69CFC4E010FA068A120E8BE6 Content-Type: text/plain; charset=us-ascii; name="patch-linkstate-8139too-2.5.41" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-linkstate-8139too-2.5.41" --- linux/drivers/net/8139too.c.orig Tue Oct 1 09:05:46 2002 +++ linux/drivers/net/8139too.c Thu Oct 10 00:37:37 2002 @@ -1534,9 +1534,16 @@ struct rtl8139_private *tp, void *ioaddr) { - int mii_lpa; + int mii_lpa, mii_bmsr; mii_lpa = mdio_read (dev, tp->phys[0], MII_LPA); + mii_bmsr = mdio_read(dev, tp->phys[0], MII_BMSR); + + if (mii_bmsr & BMSR_LSTATUS && !netif_carrier_ok(dev)) { + netif_carrier_on(dev); + } else if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + } if (!tp->mii.force_media && mii_lpa != 0xffff) { int duplex = (mii_lpa & LPA_100FULL) @@ -1563,7 +1570,7 @@ } } - next_tick = HZ * 60; + next_tick = HZ * 3; rtl8139_tune_twister (dev, tp); --------------69CFC4E010FA068A120E8BE6-- From davem@redhat.com Fri Oct 11 18:27:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 18:28:00 -0700 (PDT) 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 g9C1RstG027843 for ; Fri, 11 Oct 2002 18:27:54 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id SAA01275; Fri, 11 Oct 2002 18:21:19 -0700 Date: Fri, 11 Oct 2002 18:21:19 -0700 (PDT) Message-Id: <20021011.182119.122618649.davem@redhat.com> To: bcrl@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [patch] add iocb to network protocols From: "David S. Miller" In-Reply-To: <20021010183528.A13432@redhat.com> References: <20021010183528.A13432@redhat.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Benjamin LaHaise Date: Thu, 10 Oct 2002 18:35:29 -0400 Below is a copy of the bk tree at: bk pull master.kernel.org:/home/bcrl/net-2.5 Pulled, thanks. We can work out the issues Steve brought up independantly. From yoshfuji@linux-ipv6.org Fri Oct 11 19:43:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 19:43:29 -0700 (PDT) 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 g9C2hNtG031913 for ; Fri, 11 Oct 2002 19:43:24 -0700 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 g9C2hUlw015768; Sat, 12 Oct 2002 11:43:30 +0900 Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST) Message-Id: <20021012.114330.78212112.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: mk@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] USAGI IPsec From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021011.185332.115906289.davem@redhat.com> References: <20021011.185332.115906289.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-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: 646 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 <20021011.185332.115906289.davem@redhat.com> (at Fri, 11 Oct 2002 18:53:32 -0700 (PDT)), "David S. Miller" says: > We liked your implementation for it's simplicity. But Alexey and > myself believe several details should be handled very much > differently. Would you tell us the points of the "several details," please? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Fri Oct 11 19:47:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 19:47:46 -0700 (PDT) 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 g9C2litG032287 for ; Fri, 11 Oct 2002 19:47:44 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA01734; Fri, 11 Oct 2002 19:41:08 -0700 Date: Fri, 11 Oct 2002 19:41:08 -0700 (PDT) Message-Id: <20021011.194108.102576152.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: mk@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] USAGI IPsec From: "David S. Miller" In-Reply-To: <20021012.114330.78212112.yoshfuji@linux-ipv6.org> References: <20021011.185332.115906289.davem@redhat.com> <20021012.114330.78212112.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: 647 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 / 吉藤英明 Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST) Would you tell us the points of the "several details," please? We believe that the whole SPD/SAD mechanism should move eventually to a top-level flow cache shared by ipv4 and ipv6. Therefore all the interfaces will be architected such that a move to a flow cache based lookup system will be a very simple change. From becker@scyld.com Fri Oct 11 21:15:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 11 Oct 2002 21:15:07 -0700 (PDT) Received: from beohost.scyld.com (pool-151-196-174-217.balt.east.verizon.net [151.196.174.217]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9C4F4tG001125 for ; Fri, 11 Oct 2002 21:15:05 -0700 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id g9C4Eiu07790; Sat, 12 Oct 2002 00:14:45 -0400 Date: Sat, 12 Oct 2002 00:14:44 -0400 (EDT) From: Donald Becker To: Stefan Rompf cc: jgarzik@mandrakesoft.com, Subject: Re: Patch: link state detection for 8139too against 2.5.41 In-Reply-To: <3DA764D8.FCDF34F8@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Sat, 12 Oct 2002, Stefan Rompf wrote: > Date: Sat, 12 Oct 2002 01:55:04 +0200 > From: Stefan Rompf > To: jgarzik@mandrakesoft.com > Cc: netdev@oss.sgi.com > Subject: Patch: link state detection for 8139too against 2.5.41 > > Hi Jeff, > > attached you find a patch that enables link state detection for the > 8139too driver. It applies cleanly against 2.5.41 and with some line > offset against 2.4.19. > > I've written this stuff on a friends' computer using 2.4.18, so it is > only slightly tested. Uhmmm, you don't need to poll with the rtl8139. There is a link change interrupt. Here is the recently added from rtl8139.c if (status & RxUnderrun){ /* This might actually be a link change event. */ if ((tp->drv_flags & HAS_LNK_CHNG) && link_changed) { /* Really link-change on new chips. */ int lpar = inw(ioaddr + NWayLPAR); int duplex = (lpar&0x0100) || (lpar & 0x01C0) == 0x0040 || tp->duplex_lock; /* Do not use MII_BMSR as that clears sticky bit. */ if (inw(ioaddr + GPPinData) & 0x0004) { netif_link_down(dev); } else netif_link_up(dev); if (tp->msg_level & NETIF_MSG_LINK) printk(KERN_DEBUG "%s: Link changed, link partner " "%4.4x new duplex %d.\n", dev->name, lpar, duplex); tp->full_duplex = duplex; /* Only count as errors with no link change. */ status &= ~RxUnderrun; } else { -- 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 resplendor@spils.com Sat Oct 12 00:10:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 00:10:58 -0700 (PDT) Received: from toplinefurniture.net ([68.22.121.225]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9C7AotG023789 for ; Sat, 12 Oct 2002 00:10:51 -0700 Received: from plain ([200.161.191.108] unverified) by toplinefurniture.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 12 Oct 2002 01:05:04 -0500 From: resplendor@spils.com To: neteventos@cyberspace.com.br Subject: Resplendor Date: Sat, 12 Oct 2002 03:04:06 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" 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 Message-ID: X-OriginalArrivalTime: 12 Oct 2002 06:05:08.0867 (UTC) FILETIME=[51694D30:01C271B5] X-archive-position: 649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: resplendor@spils.com Precedence: bulk X-list: netdev Prezado Internauta, Conhea a instituio Resplendor, uma entidade que olha por aqueles que so portadores do vrus HIV e no tem condies de se manter sozinhos, e estamos necessitando muito de vossa ajuda, para continuarmos nossa jornada, ajudando nossos irmos. Visite nosso Site: www.resplendor.org.br Muito Obrigado e contamos com vosso bom corao. Caso no queira mais receber este comunicado clique abaixo: remover@resplendor.org.br From davem@redhat.com Sat Oct 12 02:17:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 02:17:55 -0700 (PDT) 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 g9C9HntG024892 for ; Sat, 12 Oct 2002 02:17:49 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id CAA24169; Sat, 12 Oct 2002 02:11:10 -0700 Date: Sat, 12 Oct 2002 02:11:09 -0700 (PDT) Message-Id: <20021012.021109.26965691.davem@redhat.com> To: srompf@isg.de Cc: thockin@sun.com, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: PATCH idea - netlink and link changes From: "David S. Miller" In-Reply-To: <3DA7EA1B.3D0430F@isg.de> References: <3DA7035F.5080101@sun.com> <3DA7EA1B.3D0430F@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: 650 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: Stefan Rompf Date: Sat, 12 Oct 2002 11:23:39 +0200 IMHO we should merge the patches, taking your one workqueue per device approach and my usage of IFF_RUNNING as a mirror bit. What do other netdev people think? I'm waiting for Jamal to catch up on his email and comment on this stuff, he had very clear ideas about what should be happening here. From srompf@isg.de Sat Oct 12 02:50:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 02:50:23 -0700 (PDT) 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 g9C9o8tG025400 for ; Sat, 12 Oct 2002 02:50:08 -0700 Received: from isg.de (dialin-145-254-207-035.arcor-ip.net [145.254.207.35]) by mail.isg.de (Postfix) with ESMTP id 0C999CE9EE6; Sat, 12 Oct 2002 11:11:55 +0200 (CEST) Message-ID: <3DA7EA1B.3D0430F@isg.de> Date: Sat, 12 Oct 2002 11:23:39 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tim Hockin Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: PATCH idea - netlink and link changes References: <3DA7035F.5080101@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 651 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 Tim, > Looking for feedback on this quickie patch. This enables netlink to > deliver link-change events, as reported by drivers via > netif_carrier_{on,off}. I've taken a closer look at the approach and like it more than my own implementation. What you are currently missing is some code to assure that a device does not have an event queued after removal - look what my patch does in netdev_unregister(). Patching f.e. the vlan driver to do some netif_carrier_on/off in the stop method is a good test case. Also, do not forget to call the network notifier chain beside emitting a netlink message - the kernel isinterested in the event, too. IMHO we should merge the patches, taking your one workqueue per device approach and my usage of IFF_RUNNING as a mirror bit. What do other netdev people think? Cheers, Stefan From davem@redhat.com Sat Oct 12 04:48:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 04:48:22 -0700 (PDT) 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 g9CBmHtG027368 for ; Sat, 12 Oct 2002 04:48:18 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id EAA29735; Sat, 12 Oct 2002 04:41:37 -0700 Date: Sat, 12 Oct 2002 04:41:37 -0700 (PDT) Message-Id: <20021012.044137.42774593.davem@redhat.com> To: ahu@ds9a.nl Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] USAGI IPsec From: "David S. Miller" In-Reply-To: <20021012111759.GA10104@outpost.ds9a.nl> References: <20021012.114330.78212112.yoshfuji@linux-ipv6.org> <20021011.194108.102576152.davem@redhat.com> <20021012111759.GA10104@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: 652 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: Sat, 12 Oct 2002 13:17:59 +0200 On Fri, Oct 11, 2002 at 07:41:08PM -0700, David S. Miller wrote: > We believe that the whole SPD/SAD mechanism should move > eventually to a top-level flow cache shared by ipv4 and > ipv6. Is this the proposed stacked route system? Yes, for output mostly. Also the idea Alexey and I have to move towards a small efficient flow cache shared by IPv4/IPv6 plays into this as well. There are changesets on their way to Linus tonight which moves ipv4 over to using ipv6's "struct flowi" from include/net/flow.h as the routing lookup key. The initial ipsec is intended to be simple, singly linked lists for the spd/sad databases etc. Making the feature freeze is pretty important right now, full blown flow cache is just performance improvement :) From ahu@outpost.ds9a.nl Sat Oct 12 04:54:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 04:54:45 -0700 (PDT) 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 g9CBsXtG027734 for ; Sat, 12 Oct 2002 04:54:33 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D1D7D4498; Sat, 12 Oct 2002 13:17:59 +0200 (CEST) Date: Sat, 12 Oct 2002 13:17:59 +0200 From: bert hubert To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] USAGI IPsec Message-ID: <20021012111759.GA10104@outpost.ds9a.nl> Mail-Followup-To: bert hubert , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20021011.185332.115906289.davem@redhat.com> <20021012.114330.78212112.yoshfuji@linux-ipv6.org> <20021011.194108.102576152.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021011.194108.102576152.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 653 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, Oct 11, 2002 at 07:41:08PM -0700, David S. Miller wrote: > From: YOSHIFUJI Hideaki / ?$B5HF#1QL@ > Date: Sat, 12 Oct 2002 11:43:30 +0900 (JST) > > Would you tell us the points of the "several details," please? > > We believe that the whole SPD/SAD mechanism should move > eventually to a top-level flow cache shared by ipv4 and > ipv6. Is this the proposed stacked route system? Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From skraw@ithnet.com Sat Oct 12 05:06:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 05:06:53 -0700 (PDT) Received: from heather.ithnet.com (ns.ithnet.com [217.64.64.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CC6mtG028210 for ; Sat, 12 Oct 2002 05:06:49 -0700 Received: by heather.ithnet.com (Smail3.2 #4) id m180L2c-0011ffC; Sat, 12 Oct 2002 14:06:46 +0200 (CEST) Received: from dialin014-sr.ithnet.com(217.64.64.14), claiming to be "ithnet.com" via SMTP by mail.ithnet.com, id smtpdlKwlGl; Sat Oct 12 14:06:42 2002 Date: Sat, 12 Oct 2002 14:06:44 +0200 From: Stephan von Krawczynski To: "David S. Miller" Cc: ahu@ds9a.nl, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] USAGI IPsec Message-Id: <20021012140644.0d403b2c.skraw@ithnet.com> In-Reply-To: <20021012.044137.42774593.davem@redhat.com> References: <20021012.114330.78212112.yoshfuji@linux-ipv6.org> <20021011.194108.102576152.davem@redhat.com> <20021012111759.GA10104@outpost.ds9a.nl> <20021012.044137.42774593.davem@redhat.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Sat, 12 Oct 2002 04:41:37 -0700 (PDT) "David S. Miller" wrote: > From: bert hubert > Date: Sat, 12 Oct 2002 13:17:59 +0200 > > On Fri, Oct 11, 2002 at 07:41:08PM -0700, David S. Miller wrote: > > We believe that the whole SPD/SAD mechanism should move > > eventually to a top-level flow cache shared by ipv4 and > > ipv6. > > Is this the proposed stacked route system? > > Yes, for output mostly. > > Also the idea Alexey and I have to move towards a small > efficient flow cache shared by IPv4/IPv6 plays into this > as well. There are changesets on their way to Linus tonight > which moves ipv4 over to using ipv6's "struct flowi" from > include/net/flow.h as the routing lookup key. > > The initial ipsec is intended to be simple, singly linked > lists for the spd/sad databases etc. Making the feature > freeze is pretty important right now, full blown flow cache > is just performance improvement :) Huhu! Just a word on this one: I recently came across some heavy performance problem regarding a setup with about 225 000 routes. It looked as if TCP experienced a tremendous slowdown to about 50 KBytes/sec throughput, whereas UDP worked pretty much normal. This was a 2.2.19 kernel with equal-cost-multipath enabled and large routing-tables enabled. The reason I am writing this is: please keep in mind situations like this with several hundred thousands of routes in one box. This is a familiar setup for the routing guys - and not a "just" case ;-) Thanks for lending an ear. -- Regards, Stephan From ahu@outpost.ds9a.nl Sat Oct 12 05:44:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 05:44:48 -0700 (PDT) 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 g9CCiXtG028734 for ; Sat, 12 Oct 2002 05:44:34 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 268424498; Sat, 12 Oct 2002 14:16:50 +0200 (CEST) Date: Sat, 12 Oct 2002 14:16:50 +0200 From: bert hubert To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] USAGI IPsec Message-ID: <20021012121650.GA10827@outpost.ds9a.nl> Mail-Followup-To: bert hubert , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20021012.114330.78212112.yoshfuji@linux-ipv6.org> <20021011.194108.102576152.davem@redhat.com> <20021012111759.GA10104@outpost.ds9a.nl> <20021012.044137.42774593.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021012.044137.42774593.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 655 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 Sat, Oct 12, 2002 at 04:41:37AM -0700, David S. Miller wrote: > Also the idea Alexey and I have to move towards a small > efficient flow cache shared by IPv4/IPv6 plays into this > as well. There are changesets on their way to Linus tonight Some people on #lartc were wondering about the use of a route cache if there is only one route. It was reported that a single default route on a system that talks to many destinations would lead to a huge route cache, which is probably not more efficient than looking up the simple route. Would this 'small efficient flow cache' also solve this problem? Or is this problem a figment of people's imaginations? > The initial ipsec is intended to be simple, singly linked > lists for the spd/sad databases etc. Making the feature > freeze is pretty important right now, full blown flow cache > is just performance improvement :) I know a lot of people are hoping that you make the feature freeze. As said before, if there is any help you need, just yell. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From ikerose@uymail.com Sat Oct 12 05:55:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 05:55:35 -0700 (PDT) Received: from mxcson1144.com (host-217-146-2-126.warsun.com [217.146.2.126] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CCtTtG029144 for ; Sat, 12 Oct 2002 05:55:32 -0700 Message-Id: <200210121255.g9CCtTtG029144@oss.sgi.com> From: "Princess Rose Ike" Reply-To: princess_roseike@mail.com To: netdev@oss.sgi.com Date: Sat, 12 Oct 2002 14:03:00 -0700 Subject: PRIVATE X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9CCtTtG029144 X-archive-position: 656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ikerose@uymail.com Precedence: bulk X-list: netdev IN VIEW OF YOUR PROFESSION INTRODUCTION: I am Princess Rose Ike, daughter of Osi Ike, the king of Ogoni Kingdom. I am 23 years old and a graduate of Mass Communication My father was in charge of Reviving royalties from the multi-national oil companies and government on behalf off the oil producing communities in Nigeria before he die. But before his death, he called me and told me he has Twelve Million Seven Hundred thousand Dollars (US$12.7M) cash in his possession, specially deposited in AFRICAN DEVELOPMENT BANK GROUP (ADBG). He advised me not to tell anybody except my mother who is the last wife of the (8) eight wives that he married. My mother did not bear any male child for him. Which implies that all my father's properties, companies etc, we have no share in them because my mother has no male child according to African tradition. My father there fore secretly gave me all the relevant document of the said money, and told me that I should use this money with my mother and my younger sisters, because he knows that traditionally, if he dies we cannot get anything, as inheritance. He importantly advised me that I should seek foreign assistance and that I should not invest this money here in Nigeria because of his other wives and male children who happen to be my elders. I am soliciting for your immediate assistance to get a bungalow for us, wherein will live with my mother and two younger sisters and further advise me where and how I will invest the balance money overseas, possibly on products of your company and other profitable ventures. I believe that by the special grace of God, you will help us move this money out of African Development Bank Group to any country of your choice where we can invest this money judiciously with you. You are entitled to a reasonable part of this Money based on our agreement, and God will bless you as you help us. Please reply through my private e-mail princess_roseike@mail.com. Looking forward to hear from you as soon as possible. Best Regard, PRINCESS ROSE IKE From hadi@cyberus.ca Sat Oct 12 06:16:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 06:16:49 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CDGktG001862 for ; Sat, 12 Oct 2002 06:16:47 -0700 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 JAA28115; Sat, 12 Oct 2002 09:16:31 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9CD9CK23592; Sat, 12 Oct 2002 09:09:13 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 12 Oct 2002 09:09:12 -0400 (EDT) From: jamal To: Stefan Rompf cc: , Subject: Re: Patch: link state notification for 2.5.41 In-Reply-To: <3DA76407.F16521F4@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 657 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 didnt do the most important thing we discussed: A global list of devices with work - not to pollute the net_device structure. This way it is more manageable. Imagine 10K devices (with software devices on top of physical devices this is not unusual). Devices register work to be done on this queue. If they register multiple times, then only the latest event if different from whats already on the queue gets propagated via netlink (this part you do correctly). BTW, did you ping the USB people on notPresent? At least one of them i think participated in that discussion. cheers, jamal From hadi@cyberus.ca Sat Oct 12 06:18:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 06:18:11 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CDI9tG002065 for ; Sat, 12 Oct 2002 06:18:09 -0700 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 JAA28471; Sat, 12 Oct 2002 09:18:07 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9CDAjB23598; Sat, 12 Oct 2002 09:10:45 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 12 Oct 2002 09:10:30 -0400 (EDT) From: jamal To: Stefan Rompf cc: Tim Hockin , , Subject: Re: PATCH idea - netlink and link changes In-Reply-To: <3DA7EA1B.3D0430F@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 12 Oct 2002, Stefan Rompf wrote: > IMHO we should merge the patches, taking your one workqueue per device > approach and my usage of IFF_RUNNING as a mirror bit. What do other > netdev people think? > Only one work queue please, not one per device. cheers, jamal From hadi@cyberus.ca Sat Oct 12 06:20:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 06:20:50 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CDKltG002574 for ; Sat, 12 Oct 2002 06:20:48 -0700 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 JAA29017; Sat, 12 Oct 2002 09:20:47 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9CDDTL23605; Sat, 12 Oct 2002 09:13:29 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 12 Oct 2002 09:13:29 -0400 (EDT) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <3DA82269.CBB65E89@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev I forgot about this. I hate to rain on your parade Stefan, but if you made one global worklist that will complete the discussion. cheers, jamal From srompf@isg.de Sat Oct 12 06:43:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 06:43:54 -0700 (PDT) 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 g9CDhZtG003100 for ; Sat, 12 Oct 2002 06:43:36 -0700 Received: from isg.de (dialin-145-254-191-131.arcor-ip.net [145.254.191.131]) by mail.isg.de (Postfix) with ESMTP id 6EDF3D76EFC; Sat, 12 Oct 2002 15:12:09 +0200 (CEST) Message-ID: <3DA82269.CBB65E89@isg.de> Date: Sat, 12 Oct 2002 15:23:53 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: hadi@cyberus.ca Subject: Patch: Idea for RFC2863 conform OperStatus Content-Type: multipart/mixed; boundary="------------398A509A5E7D7721460CBE29" X-archive-position: 660 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. --------------398A509A5E7D7721460CBE29 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, coming back to Jamals idea of RFC2863 conform operative state, I've made up a short patch on how an implementation could look like. It also takes Tims idea of one struct workstruct per device for link state notification (slightly modified). I know it's incomplete, it doesn't event contain the needed fix on unregister_netdev I critised on Tim's patch, but I want to put it to discussion early. May be it breaks the hotplugging stuff. If we decide to go this way, we'll also need an extension to rtnetlink and a new ioctl to transport the information to userspace. Stefan --------------398A509A5E7D7721460CBE29 Content-Type: text/plain; charset=us-ascii; name="patch-rfc2863-2.5.41" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-rfc2863-2.5.41" diff -rNuX dontdiff linux-2.5.41/include/linux/netdevice.h linux-2.5.41-stefan/include/linux/netdevice.h --- linux-2.5.41/include/linux/netdevice.h Tue Oct 8 22:18:50 2002 +++ linux-2.5.41-stefan/include/linux/netdevice.h Sat Oct 12 14:33:20 2002 @@ -39,6 +39,10 @@ #include #endif +#ifdef CONFIG_LINKWATCH +#include +#endif + struct divert_blk; struct vlan_group; @@ -204,13 +208,25 @@ { __LINK_STATE_XOFF=0, __LINK_STATE_START, - __LINK_STATE_PRESENT, + __LINK_STATE_PRESENT_OBSOLETE, __LINK_STATE_SCHED, - __LINK_STATE_NOCARRIER, + __LINK_STATE_NOCARRIER_OBSOLETE, __LINK_STATE_RX_SCHED }; +/* 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 +}; + + /* * This structure holds at boot time configured netdevice settings. They * are then used in the device probing. @@ -308,6 +324,15 @@ * which this device is member of. */ + /* Operative state, semaphore and work_struct for + * userspace notification + */ +#ifdef CONFIG_LINKWATCH + struct work_struct linkwatch_work; +#endif + rwlock_t operstate_lock; + unsigned short operstate; + /* Interface address info. */ unsigned char broadcast[MAX_ADDR_LEN]; /* hw bcast add */ unsigned char dev_addr[MAX_ADDR_LEN]; /* hw address */ @@ -631,34 +656,77 @@ * who is responsible for serialization of these calls. */ +#ifdef CONFIG_LINKWATCH +extern void netdev_fire_linkwatch_event(struct net_device *dev); +#endif + +static inline unsigned short netif_set_operstate(struct net_device *dev, unsigned short newstate) +{ + unsigned long flags; + unsigned short 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) netdev_fire_linkwatch_event(dev); +#endif + + return oldstate; +} + +static inline unsigned short netif_get_operstate(struct net_device *dev) +{ + unsigned long flags; + unsigned short 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 short state = netif_get_operstate(dev); + + return((1 << state) & + (1 << NETDEV_OPER_UP | 1 << NETDEV_OPER_TESTING | + 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 +734,7 @@ 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 -rNuX dontdiff linux-2.5.41/net/Config.help linux-2.5.41-stefan/net/Config.help --- linux-2.5.41/net/Config.help Tue Oct 1 09:06:18 2002 +++ linux-2.5.41-stefan/net/Config.help Sat Oct 12 00:56:59 2002 @@ -472,6 +472,17 @@ However, do not say Y here if you did not experience any serious problems. +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'. + CONFIG_NET_SCHED When the kernel has several packets to send out over a network device, it has to decide which ones to send first, which ones to diff -rNuX dontdiff linux-2.5.41/net/Config.in linux-2.5.41-stefan/net/Config.in --- linux-2.5.41/net/Config.in Tue Oct 1 09:06:24 2002 +++ linux-2.5.41-stefan/net/Config.in Tue Oct 8 22:44:07 2002 @@ -82,6 +82,7 @@ tristate 'WAN router' CONFIG_WAN_ROUTER bool 'Fast switching (read help!)' CONFIG_NET_FASTROUTE bool 'Forwarding between high speed interfaces' CONFIG_NET_HW_FLOWCONTROL + bool 'Device link state notification (EXPERIMENTAL)' CONFIG_LINKWATCH fi mainmenu_option next_comment diff -rNuX dontdiff linux-2.5.41/net/core/dev.c linux-2.5.41-stefan/net/core/dev.c --- linux-2.5.41/net/core/dev.c Tue Oct 8 22:18:51 2002 +++ linux-2.5.41-stefan/net/core/dev.c Sat Oct 12 14:54:25 2002 @@ -198,6 +198,9 @@ int netdev_fastroute_obstacles; #endif +#ifdef CONFIG_LINKWATCH +static void netdev_linkwatch_event(void *data); +#endif /******************************************************************************* @@ -716,6 +719,8 @@ * Set the flags. */ dev->flags |= IFF_UP; + if (netif_operstate_to_iff_running(dev)) + dev->flags |= IFF_RUNNING; /* * Initialize multicasting status @@ -2017,7 +2022,7 @@ 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; @@ -2432,6 +2437,13 @@ goto out; #endif /* CONFIG_NET_DIVERT */ + /* Initial operstate */ + dev->operstate_lock = RW_LOCK_UNLOCKED; + dev->operstate = NETDEV_OPER_UNKNOWN; +#ifdef CONFIG_LINKWATCH + INIT_WORK(&dev->linkwatch_work, netdev_linkwatch_event, dev); // FIXME +#endif + dev->iflink = -1; /* Init, if this function is available */ @@ -2457,13 +2469,6 @@ 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); @@ -2735,6 +2740,11 @@ #ifdef CONFIG_NET_FASTROUTE dev->fastpath_lock = RW_LOCK_UNLOCKED; #endif + dev->operstate_lock = RW_LOCK_UNLOCKED; + dev->operstate = NETDEV_OPER_UNKNOWN; +#ifdef CONFIG_LINKWATCH + INIT_WORK(&dev->linkwatch_work, netdev_linkwatch_event, dev); // FIXME +#endif dev->xmit_lock_owner = -1; dev->iflink = -1; dev_hold(dev); @@ -2767,7 +2777,6 @@ if (!dev->rebuild_header) dev->rebuild_header = default_rebuild_header; dev_init_scheduler(dev); - set_bit(__LINK_STATE_PRESENT, &dev->state); } } @@ -2848,3 +2857,32 @@ return call_usermodehelper(argv [0], argv, envp); } #endif + + +#ifdef CONFIG_LINKWATCH +static void netdev_linkwatch_event(void *data) { + struct net_device *dev = data; + unsigned int iff_running = netif_operstate_to_iff_running(dev); + + rtnl_lock(); + if (dev->flags & IFF_RUNNING && !iff_running) { + write_lock(&dev_base_lock); + dev->flags &= ~IFF_RUNNING; + write_unlock(&dev_base_lock); + netdev_state_change(dev); + } else if (!(dev->flags & IFF_RUNNING)) { + write_lock(&dev_base_lock); + dev->flags |= IFF_RUNNING; + write_unlock(&dev_base_lock); + netdev_state_change(dev); + } + rtnl_unlock(); +} + + +void netdev_fire_linkwatch_event(struct net_device *dev) { + schedule_delayed_work(&dev->linkwatch_work, HZ / 4); +} + +#endif + diff -rNuX dontdiff linux-2.5.41/net/core/rtnetlink.c linux-2.5.41-stefan/net/core/rtnetlink.c --- linux-2.5.41/net/core/rtnetlink.c Tue Oct 1 09:07:57 2002 +++ linux-2.5.41-stefan/net/core/rtnetlink.c Sat Oct 12 14:27:43 2002 @@ -165,7 +165,7 @@ 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 -rNuX dontdiff linux-2.5.41/net/netsyms.c linux-2.5.41-stefan/net/netsyms.c --- linux-2.5.41/net/netsyms.c Tue Oct 8 22:18:53 2002 +++ linux-2.5.41-stefan/net/netsyms.c Sat Oct 12 14:34:38 2002 @@ -596,4 +596,8 @@ EXPORT_SYMBOL(wireless_send_event); #endif /* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */ +#ifdef CONFIG_LINKWATCH +EXPORT_SYMBOL(netdev_fire_linkwatch_event); +#endif + #endif /* CONFIG_NET */ --------------398A509A5E7D7721460CBE29-- From hadi@cyberus.ca Sat Oct 12 07:16:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 07:17:01 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CEGutG003662 for ; Sat, 12 Oct 2002 07:16:57 -0700 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 KAA10461; Sat, 12 Oct 2002 10:16:56 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9CE9cO23697; Sat, 12 Oct 2002 10:09:38 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sat, 12 Oct 2002 10:09:37 -0400 (EDT) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <3DA82269.CBB65E89@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 12 Oct 2002, Stefan Rompf wrote: > If we decide to go this way, we'll also need an extension to rtnetlink > and a new ioctl to transport the information to userspace. Before you go doing that: IFF_RUNNING and IFF_UP are already part of the ifi_flags(struct ifinfomsg) passed today. How about making use of ifi_change to extend them? Alexey, would this be proper use of ifi_change? cheers, jamal From david-b@pacbell.net Sat Oct 12 08:09:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 08:09:34 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CF9VtG004535 for ; Sat, 12 Oct 2002 08:09:31 -0700 Received: from pacbell.net ([67.118.247.163]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H3V007RQJFUQ5@mta6.snfc21.pbi.net> for netdev@oss.sgi.com; Sat, 12 Oct 2002 08:09:31 -0700 (PDT) Date: Sat, 12 Oct 2002 08:10:49 -0700 From: David Brownell Subject: Re: Patch: link state notification for 2.5.41 To: jamal Cc: netdev@oss.sgi.com Message-id: <3DA83B79.3060302@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 References: X-archive-position: 662 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 [ CCs trimmed ] > BTW, did you ping the USB people on notPresent? At least one of them i > think participated in that discussion. That was likely me. :) > -Anyway, I wanted to keep the current semantics of > netif_carrier_on()/_off(). The extended states that can be found RFC2863 > did not seem to useful to me for linux, mainly because "notPresent" is > already implemented with netif_device_detach()/_attach() and especially > for ethernet drivers there is no real difference between "testing" and > "down". The "link active" issue for hotplug is perhaps just that while userspace sees /sbin/hotplug notifications when network interfaces are registered or unregistered, the right time to autoconfigure is actually when the link connects to a net ... or reconnects to a different one. So we really want (hotplug) events other than link register/unregister. (And some systems will want the events through a daemon instead.) So long as there's a clean way to generate such events, and to use them to trigger autoconfiguration, my basic concern is addressed. Delivery issues should be a lot easier to resolve. I think I mentioned the notPresent bit purely as an RFC conformance issue, since I was trying to make sense of what the kernel code was expected/intended to do. - Dave From rgooch@vindaloo.ras.ucalgary.ca Sat Oct 12 09:43:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 09:43:25 -0700 (PDT) Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CGhHtG006377 for ; Sat, 12 Oct 2002 09:43:17 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g9CGhCS12921; Sat, 12 Oct 2002 10:43:12 -0600 Date: Sat, 12 Oct 2002 10:43:12 -0600 Message-Id: <200210121643.g9CGhCS12921@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: netdev@oss.sgi.com Cc: Jeff Garzik , Donald Becker , Jason Lunz , "Patrick R. McManus" , edward_peng@dlink.com.tw Subject: Update on problems with sundance driver References: <200210052348.g95NmXK31793@vindaloo.ras.ucalgary.ca> X-archive-position: 663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgooch@ras.ucalgary.ca Precedence: bulk X-list: netdev Hi, all. I think I've found found a clue as to why my 4-port D-Link DFE-580TX hasn't being behaving well. To recap: using 2.4.19 plus one of Jason's patches (v1.01d), the machine locks up every few days or so. It doesn't respond to pings, nor console activity. Even SysRq is unresponsive. With 2.4.20-pre9 and the appended patch from D-Link (with corrections by me to make the patch apply and compile), I was getting transmitter timeouts every minute or so. This was causing traffic through the firewall to stall each time. I've now forced eth1 to 100 Mb/s FD, and the machine has run overnight with no transmitter timeouts. Before, eth1 was auto negotiated to 100 Mb/s HD (the other end doesn't do auto negotiation properly, but is locked down to 100 Mb/s FD). So it seems that running an interface at HD while the other end is set to FD causes transmitter timeouts. Why is this? There is a problem with the D-Link patch, though: throughput has been drastically reduced. With the D-Link patch, I'm getting 6.8 MB/s over TCP through this box, compared to 11.4 MB/s with Jason's 1.01d driver. Can anyone see something obvious in the patch that would cause this slowdown? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca =============================================================================== --- sundance.c.orig 2002-10-08 17:10:02.000000000 +0800 +++ sundance.c 2002-10-08 17:48:07.000000000 +0800 @@ -63,14 +63,14 @@ - Better rx buf size calculation (Donald Becker) Version LK1.05 (D-Link): - - fix DFE-580TX packet drop issue + - fix DFE-580TX packet drop issue (for DL10050C) - fix reset_tx logic */ #define DRV_NAME "sundance" -#define DRV_VERSION "1.01+LK1.05" -#define DRV_RELDATE "28-Sep-2002" +#define DRV_VERSION "1.01+LK1.05b" +#define DRV_RELDATE "8-Oct-2002" /* The user-configurable values. @@ -114,7 +114,7 @@ bonding and packet priority, and more than 128 requires modifying the Tx error recovery. Large receive rings merely waste memory. */ -#define TX_RING_SIZE 64 +#define TX_RING_SIZE 32 #define TX_QUEUE_LEN (TX_RING_SIZE - 1) /* Limit ring entries actually used. */ #define RX_RING_SIZE 64 #define RX_BUDGET 32 @@ -468,6 +468,7 @@ int mii_preamble_required; unsigned char phys[MII_CNT]; /* MII device addresses, only first one used.*/ struct pci_dev *pci_dev; + unsigned char pci_rev_id; }; /* The station address location in the EEPROM. */ @@ -588,6 +589,8 @@ dev->change_mtu = &change_mtu; pci_set_drvdata(pdev, dev); + pci_read_config_byte(pdev, PCI_REVISION_ID, &np->pci_rev_id); + i = register_netdev(dev); if (i) goto err_out_unmap_rx; @@ -867,7 +870,8 @@ writeb(100, ioaddr + RxDMAPollPeriod); writeb(127, ioaddr + TxDMAPollPeriod); /* Fix DFE-580TX packet drop issue */ - writeb(0x01, ioaddr + DebugCtrl1); + if (np->pci_rev_id >= 0x14) + writeb(0x01, ioaddr + DebugCtrl1); netif_start_queue(dev); writew(StatsEnable | RxEnable | TxEnable, ioaddr + MACCtrl1); @@ -944,6 +948,7 @@ long ioaddr = dev->base_addr; long flag; + netif_stop_queue(dev); writew(0, ioaddr + IntrEnable); printk(KERN_WARNING "%s: Transmit timed out, TxStatus %2.2x " "TxFrameId %2.2x," @@ -952,31 +957,36 @@ { int i; - printk(KERN_DEBUG " Rx ring %p: ", np->rx_ring); - for (i = 0; i < RX_RING_SIZE; i++) - printk(" %8.8x", (unsigned int)np->rx_ring[i].status); - printk("\n"KERN_DEBUG" Tx ring %p: ", np->tx_ring); - for (i = 0; i < TX_RING_SIZE; i++) - printk(" %8.8x", np->tx_ring[i].status); - printk("\n"); - printk(KERN_DEBUG "cur_tx=%d dirty_tx=%d\n", np->cur_tx, np->dirty_tx); + for (i=0; itx_ring_dma + i*sizeof(*np->tx_ring), + np->tx_ring[i].next_desc, + np->tx_ring[i].status, + (np->tx_ring[i].status >> 2) & 0xff, + np->tx_ring[i].frag[0].addr, + np->tx_ring[i].frag[0].length); + } + printk(KERN_DEBUG "TxListPtr=%08x netif_queue_stopped=%d\n", + readl(dev->base_addr + TxListPtr), + netif_queue_stopped(dev)); + printk(KERN_DEBUG "cur_tx=%d(%02x) dirty_tx=%d(%02x)\n", + np->cur_tx, np->cur_tx % TX_RING_SIZE, + np->dirty_tx, np->dirty_tx % TX_RING_SIZE); printk(KERN_DEBUG "cur_rx=%d dirty_rx=%d\n", np->cur_rx, np->dirty_rx); } spin_lock_irqsave(&np->lock, flag); + /* Stop and restart the chip's Tx processes . */ reset_tx(dev); spin_unlock_irqrestore(&np->lock, flag); - /* Perhaps we should reinitialize the hardware here. */ dev->if_port = 0; - /* Stop and restart the chip's Tx processes . */ - - /* Trigger an immediate transmit demand. */ - writew(DEFAULT_INTR, ioaddr + IntrEnable); dev->trans_start = jiffies; np->stats.tx_errors++; - if (!netif_queue_stopped(dev)) + if (np->cur_tx - np->dirty_tx < TX_QUEUE_LEN - 4) { netif_wake_queue(dev); + } + writew(DEFAULT_INTR, ioaddr + IntrEnable); } @@ -1090,7 +1100,8 @@ int irq = in_interrupt(); /* reset tx logic */ - writel (0, dev->base_addr + TxListPtr); + writew (TxDisable, ioaddr + MACCtrl1); + mdelay(10); writew (TxReset | DMAReset | FIFOReset | NetworkReset, ioaddr + ASICCtrl + 2); for (i=50; i > 0; i--) { @@ -1114,6 +1125,8 @@ } } np->cur_tx = np->dirty_tx = 0; + mdelay(10); + writew (StatsEnable | RxEnable | TxEnable, ioaddr + MACCtrl1); return 0; } @@ -1126,6 +1139,8 @@ long ioaddr; int boguscnt = max_interrupt_work; int hw_frame_id; + int tx_cnt; + int tx_status; ioaddr = dev->base_addr; np = dev->priv; @@ -1148,15 +1163,13 @@ np->budget = RX_BUDGET; tasklet_schedule(&np->rx_tasklet); } - if (intr_status & (IntrTxDone | IntrDrvRqst)) { - int boguscnt = 32; - int tx_status = readw (ioaddr + TxStatus); - while (tx_status & 0x80) { + tx_status = readw (ioaddr + TxStatus); + for (tx_cnt=32; tx_status & 0x80; --tx_cnt) { if (netif_msg_tx_done(np)) printk ("%s: Transmit status is %2.2x.\n", - dev->name, tx_status); + dev->name, tx_status); if (tx_status & 0x1e) { np->stats.tx_errors++; if (tx_status & 0x10) @@ -1179,20 +1192,30 @@ /* Yup, this is a documentation bug. It cost me *hours*. */ writew (0, ioaddr + TxStatus); tx_status = readw (ioaddr + TxStatus); - if (--boguscnt < 0) + if (tx_cnt < 0) break; } + hw_frame_id = (tx_status >> 8) & 0xff; + } else { + hw_frame_id = readb(ioaddr + TxFrameId); } + spin_lock(&np->lock); - hw_frame_id = readb(ioaddr + TxFrameId); for (; np->cur_tx - np->dirty_tx > 0; np->dirty_tx++) { int entry = np->dirty_tx % TX_RING_SIZE; struct sk_buff *skb; int sw_frame_id; sw_frame_id = (np->tx_ring[entry].status >> 2) & 0xff; - - if (sw_frame_id == hw_frame_id) - break; + if (np->pci_rev_id >= 0x14) + if (sw_frame_id == hw_frame_id && + !(np->tx_ring[entry].status & 0x00010000)) + break; + if (sw_frame_id == (hw_frame_id + 1) % TX_RING_SIZE) + break; + } else { + if (!(np->tx_ring[entry].status & 0x00010000)) + break; + } skb = np->tx_skbuff[entry]; /* Free the original skb. */ pci_unmap_single(np->pci_dev, @@ -1200,14 +1223,16 @@ skb->len, PCI_DMA_TODEVICE); dev_kfree_skb_irq (np->tx_skbuff[entry]); np->tx_skbuff[entry] = 0; + np->tx_ring[entry].frag[0].addr = 0; + np->tx_ring[entry].frag[0].length = 0; } spin_unlock(&np->lock); + if (netif_queue_stopped(dev) && np->cur_tx - np->dirty_tx < TX_QUEUE_LEN - 4) { /* The ring is no longer full, clear tbusy. */ netif_wake_queue (dev); } - /* Abnormal error summary/uncommon events handlers. */ if (intr_status & (IntrPCIErr | LinkChange | StatsMax)) netdev_error(dev, intr_status); @@ -1223,7 +1248,7 @@ if (netif_msg_intr(np)) printk(KERN_DEBUG "%s: exiting interrupt, status=%#4.4x.\n", dev->name, readw(ioaddr + IntrStatus)); - if (np->cur_tx - np->dirty_tx > 0 && tx_coalesce > 1) + if (np->cur_tx - np->dirty_tx > 0) writel(100, ioaddr + DownCounter); } From boroking@gmx.net Sat Oct 12 15:21:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 15:21:05 -0700 (PDT) Received: from mail.gmx.net (sproxy.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9CML0tG011371 for ; Sat, 12 Oct 2002 15:21:01 -0700 Received: (qmail 2602 invoked by uid 0); 12 Oct 2002 22:20:49 -0000 Received: from dialup60.hades.dragon.net.au (HELO MyWorld.gmx.net) (203.56.247.124) by mail.gmx.net (mp005-rz3) with SMTP; 12 Oct 2002 22:20:49 -0000 Message-Id: <5.1.0.14.0.20021013082028.028c6a88@pop.gmx.net> X-Sender: boroking@gmx.net@pop.gmx.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 13 Oct 2002 08:21:14 +1000 To: "David S. Miller" , greearb@candelatech.com From: Boro King Subject: Re: VLAN patches Cc: Bjorn.Andersson@ebc.ericsson.se, netdev@oss.sgi.com In-Reply-To: <20021005.211753.25232925.davem@redhat.com> References: <3D9F3D13.3080904@candelatech.com> <3D980A10.8B06F2C2@ebc.ericsson.se> <3D9F3D13.3080904@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: boroking@gmx.net Precedence: bulk X-list: netdev how the fuck do i get of that mailing list ive been asking for weeks now fuck.. plz take me OFF!!!!! From jmorris@intercode.com.au Sat Oct 12 18:33:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 18:33:52 -0700 (PDT) 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 g9D1XjtG012738 for ; Sat, 12 Oct 2002 18:33:46 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id LAA16691; Sun, 13 Oct 2002 11:33:37 +1000 Date: Sun, 13 Oct 2002 11:33:36 +1000 (EST) From: James Morris To: Alan Cox cc: netdev@oss.sgi.com Subject: [PATCH] Re: Sleeping function called from illegal context at slab.c:1378 [2.2.22 fix] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 665 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 Mon, 23 Sep 2002, Andrew Morton wrote: > > > That's a bug in ip_fw_ctl(). It's calling convert_ipfw() > > inside FWC_WRITE_LOCK_IRQ(&ip_fw_lock, flags); > > > > But convert_ipfw() does kmalloc(GFP_KERNEL). > > Hi Alan, This is the fix for 2.2.22, please apply. - James -- James Morris diff -urN -X dontdiff linux-2.2.22.orig/net/ipv4/ip_fw.c linux-2.2.22.w1/net/ipv4/ip_fw.c --- linux-2.2.22.orig/net/ipv4/ip_fw.c Wed Sep 25 00:06:26 2002 +++ linux-2.2.22.w1/net/ipv4/ip_fw.c Wed Sep 25 00:20:42 2002 @@ -1274,7 +1274,7 @@ return NULL; } - fwkern = kmalloc(SIZEOF_STRUCT_IP_FW_KERNEL, GFP_KERNEL); + fwkern = kmalloc(SIZEOF_STRUCT_IP_FW_KERNEL, GFP_ATOMIC); if (!fwkern) { duprintf("convert_ipfw: kmalloc failed!\n"); *errno = ENOMEM; From becker@scyld.com Sat Oct 12 21:58:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 21:59:00 -0700 (PDT) Received: from beohost.scyld.com (pool-151-196-174-59.balt.east.verizon.net [151.196.174.59]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9D4wttG015283 for ; Sat, 12 Oct 2002 21:58:57 -0700 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id g9D4wd110407; Sun, 13 Oct 2002 00:58:39 -0400 Date: Sun, 13 Oct 2002 00:58:39 -0400 (EDT) From: Donald Becker To: Richard Gooch cc: netdev@oss.sgi.com, Jason Lunz Subject: Re: Update on problems with sundance driver In-Reply-To: <200210121643.g9CGhCS12921@vindaloo.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Sat, 12 Oct 2002, Richard Gooch wrote: > With 2.4.20-pre9 and the appended patch from D-Link (with corrections > by me to make the patch apply and compile), I was getting transmitter > timeouts every minute or so. This was causing traffic through the > firewall to stall each time. > > I've now forced eth1 to 100 Mb/s FD, and the machine has run overnight > with no transmitter timeouts. Before, eth1 was auto negotiated to 100 > Mb/s HD (the other end doesn't do auto negotiation properly, but is > locked down to 100 Mb/s FD). Ackk!!!!! > So it seems that running an interface at HD while the other end is set > to FD causes transmitter timeouts. Why is this? Uhmmm, perhaps because the duplex causes out-of-window collisions. The transmitter is supposed to stop transmitting in this case. You should never force full duplex. If you have a switch with broken autonegotiation, leave the link at half duplex. Speed autosensing will then allow a working configuration. > There is a problem with the D-Link patch, though: throughput has been > drastically reduced... > bonding and packet priority, and more than 128 requires modifying the > Tx error recovery. > Large receive rings merely waste memory. */ > -#define TX_RING_SIZE 64 > +#define TX_RING_SIZE 32 > #define TX_QUEUE_LEN (TX_RING_SIZE - 1) /* Limit ring entries actually used. */ Ackk!!! How come everyone thinks "if I make this number higher, things will work better"? Has anyone, besides me, actually done measurements? If not, don't change the settings. > /* Fix DFE-580TX packet drop issue */ > - writeb(0x01, ioaddr + DebugCtrl1); > + if (np->pci_rev_id >= 0x14) > + writeb(0x01, ioaddr + DebugCtrl1); > netif_start_queue(dev); This is all of the magic. The chip is broken and requires an undocumented register setting. Except that this is a really bad condition to check. There should be a flag bit in the chip detection section. > /* reset tx logic */ > - writel (0, dev->base_addr + TxListPtr); > + writew (TxDisable, ioaddr + MACCtrl1); > + mdelay(10); I suspect that this is mdelay(10) is a similar hack/guess. -- 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 davem@redhat.com Sat Oct 12 22:49:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 22:49:10 -0700 (PDT) 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 g9D5n7tG015901 for ; Sat, 12 Oct 2002 22:49:07 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA01451; Sat, 12 Oct 2002 22:42:13 -0700 Date: Sat, 12 Oct 2002 22:42:12 -0700 (PDT) Message-Id: <20021012.224212.56861427.davem@redhat.com> To: skraw@ithnet.com Cc: ahu@ds9a.nl, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] USAGI IPsec From: "David S. Miller" In-Reply-To: <20021012140644.0d403b2c.skraw@ithnet.com> References: <20021012111759.GA10104@outpost.ds9a.nl> <20021012.044137.42774593.davem@redhat.com> <20021012140644.0d403b2c.skraw@ithnet.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: 667 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: Stephan von Krawczynski Date: Sat, 12 Oct 2002 14:06:44 +0200 This was a 2.2.19 kernel with equal-cost-multipath enabled and large routing-tables enabled. It doesn't surprise me that 2.2.x performs like crap under any real load btw :-) It has none of the 2.3.x scalability and threading work. From davem@redhat.com Sat Oct 12 22:50:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Oct 2002 22:50:07 -0700 (PDT) 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 g9D5o5tG016102 for ; Sat, 12 Oct 2002 22:50:05 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA01458; Sat, 12 Oct 2002 22:43:19 -0700 Date: Sat, 12 Oct 2002 22:43:18 -0700 (PDT) Message-Id: <20021012.224318.94555090.davem@redhat.com> To: ahu@ds9a.nl Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] USAGI IPsec From: "David S. Miller" In-Reply-To: <20021012121650.GA10827@outpost.ds9a.nl> References: <20021012111759.GA10104@outpost.ds9a.nl> <20021012.044137.42774593.davem@redhat.com> <20021012121650.GA10827@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: 668 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: Sat, 12 Oct 2002 14:16:50 +0200 Some people on #lartc were wondering about the use of a route cache if there is only one route. It was reported that a single default route on a system that talks to many destinations would lead to a huge route cache, which is probably not more efficient than looking up the simple route. Would this 'small efficient flow cache' also solve this problem? I contend there is no "problem". Routing cache entries are garbage collected, and even this can be tuned via sysctl. From srompf@isg.de Sun Oct 13 05:42:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 05:42:54 -0700 (PDT) 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 g9DCgptG025351 for ; Sun, 13 Oct 2002 05:42:52 -0700 Received: from isg.de (dialin-145-254-193-185.arcor-ip.net [145.254.193.185]) by mail.isg.de (Postfix) with ESMTP id E30EAD78AB2; Sun, 13 Oct 2002 14:42:41 +0200 (CEST) Message-ID: <3DA96BCC.B2589AC0@isg.de> Date: Sun, 13 Oct 2002 14:49:16 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Donald Becker Cc: jgarzik@mandrakesoft.com, netdev@oss.sgi.com Subject: Re: Patch: link state detection for 8139too against 2.5.41 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 670 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, > > I've written this stuff on a friends' computer using 2.4.18, so it is > > only slightly tested. > > 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. Stefan From srompf@isg.de Sun Oct 13 05:42:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 05:42:50 -0700 (PDT) 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 g9DCgktG025350 for ; Sun, 13 Oct 2002 05:42:46 -0700 Received: from isg.de (dialin-145-254-193-185.arcor-ip.net [145.254.193.185]) by mail.isg.de (Postfix) with ESMTP id 3F7AFD78926; Sun, 13 Oct 2002 14:42:32 +0200 (CEST) Message-ID: <3DA96B9D.412FDAF3@isg.de> Date: Sun, 13 Oct 2002 14:48:29 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus References: Content-Type: multipart/mixed; boundary="------------CB6C1EAC981ABB258BC1C4BA" X-archive-position: 669 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. --------------CB6C1EAC981ABB258BC1C4BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, > I forgot about this. I hate to rain on your parade Stefan, but > if you made one global worklist that will complete the discussion. here we go. Changes since the last version: -One global worklist. Still using __LINK_STATE_LINKWATCH_PENDING to know of a pending event fast -unsigned char operstate instead of short. If there was no alignment, this would have reduced the size of struct net_device by one byte ;-) -removed usage if in-kernel-IFF_RUNNING as a mirror. Useless if we want to broadcast complete operstate via netlink -Map only NETDEV_OPER_UP and NETDEV_OPER_UNKNOWN to IFF_RUNNING. I have kept UNKNOWN as a compatibility kludge for the majority of drivers that cannot determine any operstate yet -Use dev_hold()/dev_put() While doing tests with a hacked vlan driver that creates NETDEV_OPER_LOWERDOWN/_UP events I found that I get a "No buffer space available" in ip monitor if the event list is longer than about 20 entries. This can be worked around with setsockopt on SO_RCVBUF, but does anyone have a clue why netlink events are that expensive? Cheers, Stefan --------------CB6C1EAC981ABB258BC1C4BA Content-Type: text/plain; charset=us-ascii; name="patch-rfc2863-2.5.41-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-rfc2863-2.5.41-2" diff -uNrX dontdiff linux-2.5.41/include/linux/netdevice.h linux-2.5.41-stefan/include/linux/netdevice.h --- linux-2.5.41/include/linux/netdevice.h Tue Oct 8 22:18:50 2002 +++ linux-2.5.41-stefan/include/linux/netdevice.h Sun Oct 13 12:47:13 2002 @@ -204,10 +204,23 @@ { __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 @@ * 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 @@ * 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_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 -uNrX dontdiff linux-2.5.41/net/Config.help linux-2.5.41-stefan/net/Config.help --- linux-2.5.41/net/Config.help Tue Oct 1 09:06:18 2002 +++ linux-2.5.41-stefan/net/Config.help Sat Oct 12 00:56:59 2002 @@ -472,6 +472,17 @@ However, do not say Y here if you did not experience any serious problems. +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'. + CONFIG_NET_SCHED When the kernel has several packets to send out over a network device, it has to decide which ones to send first, which ones to diff -uNrX dontdiff linux-2.5.41/net/Config.in linux-2.5.41-stefan/net/Config.in --- linux-2.5.41/net/Config.in Tue Oct 1 09:06:24 2002 +++ linux-2.5.41-stefan/net/Config.in Tue Oct 8 22:44:07 2002 @@ -82,6 +82,7 @@ tristate 'WAN router' CONFIG_WAN_ROUTER bool 'Fast switching (read help!)' CONFIG_NET_FASTROUTE bool 'Forwarding between high speed interfaces' CONFIG_NET_HW_FLOWCONTROL + bool 'Device link state notification (EXPERIMENTAL)' CONFIG_LINKWATCH fi mainmenu_option next_comment diff -uNrX dontdiff linux-2.5.41/net/core/Makefile linux-2.5.41-stefan/net/core/Makefile --- linux-2.5.41/net/core/Makefile Tue Oct 1 09:07:40 2002 +++ linux-2.5.41-stefan/net/core/Makefile Sun Oct 13 12:37:08 2002 @@ -21,4 +21,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 -uNrX dontdiff linux-2.5.41/net/core/dev.c linux-2.5.41-stefan/net/core/dev.c --- linux-2.5.41/net/core/dev.c Tue Oct 8 22:18:51 2002 +++ linux-2.5.41-stefan/net/core/dev.c Sun Oct 13 14:00:55 2002 @@ -198,7 +198,6 @@ int netdev_fastroute_obstacles; #endif - /******************************************************************************* Protocol management and registration routines @@ -261,6 +260,9 @@ br_write_unlock_bh(BR_NETPROTO_LOCK); } +#ifdef CONFIG_LINKWATCH +void linkwatch_run_queue(void); +#endif /** * dev_remove_pack - remove packet handler @@ -2017,7 +2019,7 @@ 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; @@ -2432,6 +2434,10 @@ 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 */ @@ -2457,13 +2463,6 @@ 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); @@ -2592,6 +2591,18 @@ free_divert_blk(dev); #endif +#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(); + BUG_ON(test_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state)); + } +#endif + if (dev->features & NETIF_F_DYNALLOC) { #ifdef NET_REFCNT_DEBUG if (atomic_read(&dev->refcnt) != 1) @@ -2735,6 +2746,8 @@ #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); @@ -2767,7 +2780,6 @@ if (!dev->rebuild_header) dev->rebuild_header = default_rebuild_header; dev_init_scheduler(dev); - set_bit(__LINK_STATE_PRESENT, &dev->state); } } @@ -2848,3 +2860,5 @@ return call_usermodehelper(argv [0], argv, envp); } #endif + + diff -uNrX dontdiff linux-2.5.41/net/core/link_watch.c linux-2.5.41-stefan/net/core/link_watch.c --- linux-2.5.41/net/core/link_watch.c Thu Jan 1 01:00:00 1970 +++ linux-2.5.41-stefan/net/core/link_watch.c Sun Oct 13 13:59:23 2002 @@ -0,0 +1,115 @@ +/* + * 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 + + +static unsigned long linkwatch_nowake = 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; +}; + +/* 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; + + 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(0, &linkwatch_nowake); + + 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 = kmalloc(sizeof(struct lw_event), GFP_ATOMIC); + + if (unlikely(event == NULL)) { + clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); + return; + } + + 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(0, &linkwatch_nowake)) { + unsigned long thisevent = jiffies; + + if (thisevent >= linkwatch_nextevent) { + schedule_work(&linkwatch_work); + } else { + schedule_delayed_work(&linkwatch_work, linkwatch_nextevent - thisevent); + } + } + } +} + diff -uNrX dontdiff linux-2.5.41/net/core/rtnetlink.c linux-2.5.41-stefan/net/core/rtnetlink.c --- linux-2.5.41/net/core/rtnetlink.c Tue Oct 1 09:07:57 2002 +++ linux-2.5.41-stefan/net/core/rtnetlink.c Sat Oct 12 14:27:43 2002 @@ -165,7 +165,7 @@ 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 -uNrX dontdiff linux-2.5.41/net/netsyms.c linux-2.5.41-stefan/net/netsyms.c --- linux-2.5.41/net/netsyms.c Tue Oct 8 22:18:53 2002 +++ linux-2.5.41-stefan/net/netsyms.c Sun Oct 13 13:27:40 2002 @@ -596,4 +596,8 @@ 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 */ --------------CB6C1EAC981ABB258BC1C4BA-- From hadi@cyberus.ca Sun Oct 13 07:11:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 07:11:31 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DEBQtG026551 for ; Sun, 13 Oct 2002 07:11:26 -0700 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 KAA09504; Sun, 13 Oct 2002 10:11:21 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9DE42n26044; Sun, 13 Oct 2002 10:04:02 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 13 Oct 2002 10:04:02 -0400 (EDT) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <3DA96B9D.412FDAF3@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 671 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 Stefan, This is looking good; some small nitpicks: -where do you set the netlink state change, ifi_change etc? I know we are waiting for Alexey to respond but how do you propagate iff_up -> down and the cause fatale to user space? -Do you really have to malloc and free everytime for that lw_event? Dave, Alexey, It's your call now to dissect it's maintainability; i am happy with it when Stefan addresses the above nitpicks. On Sun, 13 Oct 2002, Stefan Rompf wrote: > While doing tests with a hacked vlan driver that creates > NETDEV_OPER_LOWERDOWN/_UP events I found that I get a "No buffer space > available" in ip monitor if the event list is longer than about 20 > entries. This can be worked around with setsockopt on SO_RCVBUF, but > does anyone have a clue why netlink events are that expensive? Take a look at the way memory is allocated in that area and you'll see it. May i suggest thats another fire that may need to be put out at some point? ;-> cheers, jamal From kuznet@ms2.inr.ac.ru Sun Oct 13 12:18:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 12:18:30 -0700 (PDT) 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 g9DJINtG013247 for ; Sun, 13 Oct 2002 12:18:24 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA09216; Sun, 13 Oct 2002 23:14:35 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210131914.XAA09216@sex.inr.ac.ru> Subject: Re: Patch: Idea for RFC2863 conform OperStatus To: hadi@cyberus.CA (jamal) Date: Sun, 13 Oct 2002 23:14:35 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: from "jamal" at Oct 12, 2 06:45:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 672 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! > How about making use of ifi_change to extend them? Alexey, would this be > proper use of ifi_change? I did not understand the question. Alexey From hadi@cyberus.ca Sun Oct 13 13:37:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 13:37:59 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DKbstG026751 for ; Sun, 13 Oct 2002 13:37:54 -0700 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 QAA04305; Sun, 13 Oct 2002 16:37:53 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9DKUYn26861; Sun, 13 Oct 2002 16:30:35 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 13 Oct 2002 16:30:34 -0400 (EDT) From: jamal To: cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <200210131914.XAA09216@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 673 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 Look at RFC 2863 section 3.1.12; there is some description on operational status. At the moment the only status is IFF_RUNNING in the ifi_flags. So the question was could we use ifi_change to send the other pieces of info (as per RFC 2863) and as implemented in Stefans patch? If not, could we take advantage of that pad in the ifinfomsg? This should not break any backward compatibility. cheers, jamal On Sun, 13 Oct 2002 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > How about making use of ifi_change to extend them? Alexey, would this be > > proper use of ifi_change? > > I did not understand the question. > > Alexey > From kuznet@ms2.inr.ac.ru Sun Oct 13 14:04:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 14:04:08 -0700 (PDT) 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 g9DL42tG031599 for ; Sun, 13 Oct 2002 14:04:02 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id BAA09316; Mon, 14 Oct 2002 01:00:29 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210132100.BAA09316@sex.inr.ac.ru> Subject: Re: Patch: Idea for RFC2863 conform OperStatus To: hadi@cyberus.ca (jamal) Date: Mon, 14 Oct 2002 01:00:29 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: from "jamal" at Oct 13, 2 04:30:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 674 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! > status. At the moment the only status is IFF_RUNNING in the ifi_flags. > So the question was could we use ifi_change to send the other pieces of > info No, of course. The question is really strange. :-) > If not, could we take advantage of that pad in the ifinfomsg? ifi_flags has lots of spare space, 16 bits. And the second: IFF_RUNNING seems to be enough. Their "dormant" and "lowerLayerDown" are logically undistinuishable. Alexey From hadi@cyberus.ca Sun Oct 13 14:41:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 14:41:28 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DLfMtG006256 for ; Sun, 13 Oct 2002 14:41:22 -0700 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 RAA14829; Sun, 13 Oct 2002 17:41:22 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9DLY3526967; Sun, 13 Oct 2002 17:34:03 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Sun, 13 Oct 2002 17:34:03 -0400 (EDT) From: jamal To: cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <200210132100.BAA09316@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 675 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, 14 Oct 2002 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > status. At the moment the only status is IFF_RUNNING in the ifi_flags. > > So the question was could we use ifi_change to send the other pieces of > > info > > No, of course. The question is really strange. :-) > > > If not, could we take advantage of that pad in the ifinfomsg? > > ifi_flags has lots of spare space, 16 bits. > Actually the extra flags are only valid when IFF_RUNNING is not set. Maybe Stefan was pushing it to also want to flag tx operational failure .. In any case please review his patch. > And the second: IFF_RUNNING seems to be enough. Their "dormant" and > "lowerLayerDown" are logically undistinuishable. Some of those states are useless. dormant may refer tothings like tunnel devices on top of physical devices. Example that was given was a ipsec tunnel sending pings periodically; lowerLayerDown is when you have multiple phyical devices under a aggregator like bonding or maybe even VLAN; in that case if one of the physical devices underneath being down would imply "lowerLayerDown" flag on the aggregagator device. A second query would reveal which of the underneath devices is down. cheers, jamal From kuznet@ms2.inr.ac.ru Sun Oct 13 15:07:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 15:07:56 -0700 (PDT) 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 g9DM7otG010846 for ; Sun, 13 Oct 2002 15:07:50 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id CAA09385; Mon, 14 Oct 2002 02:04:22 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210132204.CAA09385@sex.inr.ac.ru> Subject: Re: Patch: Idea for RFC2863 conform OperStatus To: hadi@cyberus.ca (jamal) Date: Mon, 14 Oct 2002 02:04:22 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: from "jamal" at Oct 13, 2 05:34:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 676 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! > Actually the extra flags are only valid when IFF_RUNNING is not set. Even so... Well, then I am inclined not to agree to give even one of those valuable 16 spare bits for this. :-) I cannot imagine how much should I drink to consider states descibed in this rfc as a valid abstraction. Device can be working and can be dead by thousands of reasons. The best which I can propose is to show a string somewhere in /proc (well, or as a _string_ attribute in RTM_NEWLINK), explaining why device is not alive and let snmpd to translate this string to these bogus states to generate traps. Alexey From rgooch@vindaloo.ras.ucalgary.ca Sun Oct 13 16:43:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 13 Oct 2002 16:43:16 -0700 (PDT) Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9DNhAtG025940 for ; Sun, 13 Oct 2002 16:43:11 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g9DHNov07599; Sun, 13 Oct 2002 11:23:50 -0600 Date: Sun, 13 Oct 2002 11:23:50 -0600 Message-Id: <200210131723.g9DHNov07599@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Donald Becker Cc: netdev@oss.sgi.com, Jason Lunz Subject: Re: Update on problems with sundance driver In-Reply-To: References: <200210121643.g9CGhCS12921@vindaloo.ras.ucalgary.ca> X-archive-position: 677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgooch@ras.ucalgary.ca Precedence: bulk X-list: netdev Donald Becker writes: > On Sat, 12 Oct 2002, Richard Gooch wrote: > > > With 2.4.20-pre9 and the appended patch from D-Link (with corrections > > by me to make the patch apply and compile), I was getting transmitter > > timeouts every minute or so. This was causing traffic through the > > firewall to stall each time. > > > > I've now forced eth1 to 100 Mb/s FD, and the machine has run overnight > > with no transmitter timeouts. Before, eth1 was auto negotiated to 100 > > Mb/s HD (the other end doesn't do auto negotiation properly, but is > > locked down to 100 Mb/s FD). > > Ackk!!!!! > > > So it seems that running an interface at HD while the other end is set > > to FD causes transmitter timeouts. Why is this? > > Uhmmm, perhaps because the duplex causes out-of-window collisions. The > transmitter is supposed to stop transmitting in this case. > > You should never force full duplex. If you have a switch with > broken autonegotiation, leave the link at half duplex. Speed > autosensing will then allow a working configuration. Maybe I didn't explain: the switch is a box I don't have control over. It's been locked to 100 Mb/s FD. It's Campus IT policy to disable auto negotiation (they claim it causes too much trouble because people plug broken auto negotiation hardware into their switches. Of course, it also happens to give them control, which might possibly be related to them charging a minimum $125 fee for every change). So given this situation, what's the sensible thing for me to do? When the interface auto configured to 100 Mb/s HD, I got transmitter timeouts. Forcing it to 100 Mb/s FD fixed that. Should I really ask for the switch to be locked down to 100 Mb/s HD and let the interface auto configure? What do I gain, other than reduced bandwidth and the pleasure of donating $125? > > There is a problem with the D-Link patch, though: throughput has been > > drastically reduced... > > > bonding and packet priority, and more than 128 requires modifying the > > Tx error recovery. > > Large receive rings merely waste memory. */ > > -#define TX_RING_SIZE 64 > > +#define TX_RING_SIZE 32 > > #define TX_QUEUE_LEN (TX_RING_SIZE - 1) /* Limit ring entries actually used. */ > > Ackk!!! > How come everyone thinks "if I make this number higher, things will work > better"? Has anyone, besides me, actually done measurements? If not, > don't change the settings. Actually, the D-Link patch *dropped* the number, so what's the problem? > > /* Fix DFE-580TX packet drop issue */ > > - writeb(0x01, ioaddr + DebugCtrl1); > > + if (np->pci_rev_id >= 0x14) > > + writeb(0x01, ioaddr + DebugCtrl1); > > netif_start_queue(dev); > > This is all of the magic. > The chip is broken and requires an undocumented register setting. Do you know in which way it is broken? Could it cause the machine to lock up, hard? The problem I had with 2.4.19 + Jason's 1.01d patch was the machine would lock up after a few days. Of course, with 2.4.20-pre9 and the latest D-Link patch, it hasn't been up quite that long yet... > Except that this is a really bad condition to check. > There should be a flag bit in the chip detection section. > > > /* reset tx logic */ > > - writel (0, dev->base_addr + TxListPtr); > > + writew (TxDisable, ioaddr + MACCtrl1); > > + mdelay(10); > > I suspect that this is mdelay(10) is a similar hack/guess. Hm. But that's just for Tx reset. It shouldn't affect normal performance, right? The throughput dropped dramatically with the D-Link patch. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From ahu@outpost.ds9a.nl Mon Oct 14 03:38:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 03:39:03 -0700 (PDT) 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 g9EAcvtG006249 for ; Mon, 14 Oct 2002 03:38:57 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 001D544DA; Mon, 14 Oct 2002 12:38:55 +0200 (CEST) Date: Mon, 14 Oct 2002 12:38:55 +0200 From: bert hubert To: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus Message-ID: <20021014103855.GA19962@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com References: <3DA82269.CBB65E89@isg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA82269.CBB65E89@isg.de> User-Agent: Mutt/1.3.28i X-archive-position: 678 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 Sat, Oct 12, 2002 at 03:23:53PM +0200, Stefan Rompf wrote: > +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. I know people who would kill for this feature. So powers that be, please consider merging. Is there no quick way of getting all cards using the MII stuff to support this in one go? mii-diag seems to work on most cards already? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From Robert.Olsson@data.slu.se Mon Oct 14 04:09:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 04:09:59 -0700 (PDT) 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 g9EB9qtG012384 for ; Mon, 14 Oct 2002 04:09:53 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id NAA13743; Mon, 14 Oct 2002 13:16:46 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15786.42910.601886.468716@robur.slu.se> Date: Mon, 14 Oct 2002 13:16:46 +0200 To: bert hubert Cc: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <20021014103855.GA19962@outpost.ds9a.nl> References: <3DA82269.CBB65E89@isg.de> <20021014103855.GA19962@outpost.ds9a.nl> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 679 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 bert hubert writes: > On Sat, Oct 12, 2002 at 03:23:53PM +0200, Stefan Rompf wrote: > > > +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. > > I know people who would kill for this feature. So powers that be, please > consider merging. > > Is there no quick way of getting all cards using the MII stuff to support > this in one go? mii-diag seems to work on most cards already? Hello! Well it has to be handled with somewhat caution too... Just a little link-flap can cause massive network/routing changes. If you run a routing protocol BGP, OSPF etc it has it's own mechanism with timers for declaring neighbours/link partners down. But yes in some setups it can be useful -- with dampning. --ro PS. Have seen 100 kpps in a Linux production router now. :-) From ahu@outpost.ds9a.nl Mon Oct 14 04:41:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 04:41:28 -0700 (PDT) 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 g9EBfFtG017897 for ; Mon, 14 Oct 2002 04:41:15 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 77B6944D5; Mon, 14 Oct 2002 13:11:55 +0200 (CEST) Date: Mon, 14 Oct 2002 13:11:55 +0200 From: bert hubert To: Robert Olsson Cc: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus Message-ID: <20021014111155.GB20397@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Robert Olsson , netdev@oss.sgi.com References: <3DA82269.CBB65E89@isg.de> <20021014103855.GA19962@outpost.ds9a.nl> <15786.42910.601886.468716@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15786.42910.601886.468716@robur.slu.se> User-Agent: Mutt/1.3.28i X-archive-position: 680 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, Oct 14, 2002 at 01:16:46PM +0200, Robert Olsson wrote: > If you run a routing protocol BGP, OSPF etc it has it's own mechanism > with timers for declaring neighbours/link partners down. But yes in some > setups it can be useful -- with dampning. I bet Zebra would like to use this. I also know people who want to use this to change their own routes to, say, an alternate interface. > PS. Have seen 100 kpps in a Linux production router now. :-) With a bgp full view? 100kpps is not all that impressive in itself isn't it? We benchmarked our nameserver at 120kpps recently and linux seemed unimpressed :-) Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From Robert.Olsson@data.slu.se Mon Oct 14 04:43:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 04:43:57 -0700 (PDT) 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 g9EBhstG018689 for ; Mon, 14 Oct 2002 04:43:55 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id NAA14354; Mon, 14 Oct 2002 13:50:53 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15786.44957.210354.599290@robur.slu.se> Date: Mon, 14 Oct 2002 13:50:53 +0200 To: bert hubert Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <20021014111155.GB20397@outpost.ds9a.nl> References: <3DA82269.CBB65E89@isg.de> <20021014103855.GA19962@outpost.ds9a.nl> <15786.42910.601886.468716@robur.slu.se> <20021014111155.GB20397@outpost.ds9a.nl> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 681 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 bert hubert writes: > With a bgp full view? 100kpps is not all that impressive in itself isn't it? > We benchmarked our nameserver at 120kpps recently and linux seemed > unimpressed :-) For me yes. :-) It connects one the major ftp sites... Box can handle 350 kpps w/o filter and connection tracking. With current traffic pattern we have 160 kpps for wire speed at GIGE. Yes full BGP. Well even full BGP from 2 peers plus some handful prefixes from other BGP peers. ip route | wc -l 115670 Gated has 41 MB of BGP routes. With Zebra this would be ~75 MB. ps aux root 232 0.0 7.9 41392 40876 ? S Aug 15 36:54 gated Cheers. --ro From hadi@cyberus.ca Mon Oct 14 06:09:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 06:09:16 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ED9AtG000943 for ; Mon, 14 Oct 2002 06:09:11 -0700 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 JAA09951; Mon, 14 Oct 2002 09:09:09 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9ED1om28335; Mon, 14 Oct 2002 09:01:50 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 14 Oct 2002 09:01:50 -0400 (EDT) From: jamal To: cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <200210132204.CAA09385@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 682 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, 14 Oct 2002 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > Actually the extra flags are only valid when IFF_RUNNING is not set. > > Even so... > > Well, then I am inclined not to agree to give even one of those valuable > 16 spare bits for this. :-) > > I cannot imagine how much should I drink to consider states descibed > in this rfc as a valid abstraction. Device can be working and can be dead > by thousands of reasons. The best which I can propose is to show a string > somewhere in /proc (well, or as a _string_ attribute in RTM_NEWLINK), > explaining why device is not alive and let snmpd to translate this string > to these bogus states to generate traps. ;-> Believe it or not people use these things to draw nice GUI representations (search for lowerLayerDown at cisco for example); how we represent them shouldnt matter whether its via ifi_flags, /proc etc. Infact it should also be fine if we dont propagate them to user space for now, but the abstraction should stay in the kernel at least. cheers, jamal From hadi@cyberus.ca Mon Oct 14 06:19:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 06:19:04 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9EDJ2tG002909 for ; Mon, 14 Oct 2002 06:19:02 -0700 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 JAA12135; Mon, 14 Oct 2002 09:19:01 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9EDBfe28385; Mon, 14 Oct 2002 09:11:41 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 14 Oct 2002 09:11:41 -0400 (EDT) From: jamal To: Stefan Rompf cc: , Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <3DAABBAE.79E22EB6@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 683 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, 14 Oct 2002, Stefan Rompf wrote: > Alexey, Jamal, > > the first version of this patch just added the feature to distribute > state changes created by netif_carrier_on()/_off() inside the kernel and > to netlink via netdev_state_change(). This is still the part most > important to me - not only in 2.5, but also as a 2.4 backport. > > I don't think RFC2863 state keeping makes much sense if we cannot > forward the results to userspace. So if you are happy with keeping the > current semantics, but using the more sophisticated implementation of > forwarding worked out last weekend, I'll be happy to provide a new patch > (also adressing Jamal's nitpicks). Just agree on one way. the RFC2863 semantics should stay; the thing we havent agreed on is how to do it. Maybe for the first phase patch you dont need to expose them to user space - maybe in the way Alexey suggested as attributes without loosing any of the flag bits... Alexey should make that call. cheers, jamal From hadi@cyberus.ca Mon Oct 14 06:45:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 06:45:29 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9EDjMtG007091 for ; Mon, 14 Oct 2002 06:45:22 -0700 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 JAA17921; Mon, 14 Oct 2002 09:45:21 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9EDc2c28478; Mon, 14 Oct 2002 09:38:02 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 14 Oct 2002 09:38:01 -0400 (EDT) From: jamal To: Stefan Rompf cc: , Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <3DAABBAE.79E22EB6@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 684 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 you think about it NOTPRESENT was always there even without these changes but was never exposed. PRESENT will always somehow get mapped to IFF_RUNNING (0/1). - NOTPRESENT makes sense more from a NMS pov where a hotplug device has been removed and SNMP finds that the device is no longer there. This can be done without any state from the kernel being exposed. - UNKNOWN is when the NMS cant find the state of the device - maybe when they cant reach us. Again we dont need to expose this from the kernel and if it is not useful in the kernel perhaps should be deleted. The remainder seem to make more sense to me. thoughts? cheers, jamal From srompf@isg.de Mon Oct 14 06:46:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 06:46:58 -0700 (PDT) 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 g9EDkjtG007426 for ; Mon, 14 Oct 2002 06:46:45 -0700 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 58821D7B833; Mon, 14 Oct 2002 14:42:22 +0200 (CEST) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id OAA01369; Mon, 14 Oct 2002 14:42:22 +0200 Message-ID: <3DAABBAE.79E22EB6@isg.de> Date: Mon, 14 Oct 2002 14:42:22 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19stefan i686) X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru, jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus References: <200210132204.CAA09385@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 685 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 Alexey, Jamal, the first version of this patch just added the feature to distribute state changes created by netif_carrier_on()/_off() inside the kernel and to netlink via netdev_state_change(). This is still the part most important to me - not only in 2.5, but also as a 2.4 backport. I don't think RFC2863 state keeping makes much sense if we cannot forward the results to userspace. So if you are happy with keeping the current semantics, but using the more sophisticated implementation of forwarding worked out last weekend, I'll be happy to provide a new patch (also adressing Jamal's nitpicks). Just agree on one way. Cheers, Stefan From jgarzik@pobox.com Mon Oct 14 10:43:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 10:43:26 -0700 (PDT) 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 g9EHhJtG011523 for ; Mon, 14 Oct 2002 10:43:20 -0700 Received: from c-24-98-63-64.atl.client2.attbi.com ([24.98.63.64] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 1819FN-0000pX-00; Mon, 14 Oct 2002 18:43:17 +0100 Message-ID: <3DAB0215.5070507@pobox.com> Date: Mon, 14 Oct 2002 13:42:45 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Rompf CC: Donald Becker , netdev@oss.sgi.com Subject: Re: Patch: link state detection for 8139too against 2.5.41 References: <3DA96BCC.B2589AC0@isg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 686 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 Take a look at how 8139cp driver does link state... it should be an also exact copy of 8139cp's code. (8139cp will eventually get GMII/TBI support, but for now this statement is correct) From thockin@sun.com Mon Oct 14 11:08:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 11:08:05 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9EI81tG015643 for ; Mon, 14 Oct 2002 11:08:01 -0700 Received: from phys-ha1mpka.eng.sun.com ([129.146.14.50]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20281; Mon, 14 Oct 2002 12:07:54 -0600 (MDT) Received: from sun.com (scl2.SFBay.Sun.COM [10.6.72.42]) by phys-ha1mpka.eng.sun.com (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id LAA05407; Mon, 14 Oct 2002 11:07:53 -0700 (PDT) Message-ID: <3DAB07F9.1090802@sun.com> Date: Mon, 14 Oct 2002 11:07:53 -0700 From: Tim Hockin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: Stefan Rompf , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: PATCH idea - netlink and link changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thockin@sun.com Precedence: bulk X-list: netdev jamal wrote: > > On Sat, 12 Oct 2002, Stefan Rompf wrote: > > >>IMHO we should merge the patches, taking your one workqueue per device >>approach and my usage of IFF_RUNNING as a mirror bit. What do other >>netdev people think? >> > Only one work queue please, not one per device. What of two devices that lose link at the same time? Say a hub or switch dies.. -- Tim Hockin Systems Software Engineer Sun Microsystems, Linux Kernel Engineering thockin@sun.com From srompf@isg.de Mon Oct 14 11:14:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 11:14:39 -0700 (PDT) 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 g9EIEZtG017123 for ; Mon, 14 Oct 2002 11:14:36 -0700 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 18775D7C728; Mon, 14 Oct 2002 20:14:27 +0200 (CEST) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id UAA02543; Mon, 14 Oct 2002 20:14:26 +0200 Message-ID: <3DAB0982.C0C6E36F@isg.de> Date: Mon, 14 Oct 2002 20:14:26 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19stefan i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, david-b@pacbell.net Subject: Re: Patch: Idea for RFC2863 conform OperStatus References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 688 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 Jamal, > - NOTPRESENT makes sense more from a NMS pov where a hotplug device has > been removed and SNMP finds that the device is no longer there. This > can be done without any state from the kernel being exposed. I want to forward this question mainly to the USB people. David, as you are familiar with this thread, how does an USB driver react when an ethernet device is configured, running and then disconnected from the USB port? From RFC2863, I'd expect the devicename ethx not to be removed at least until it is ifconfigured down, but change from UP to NOTPRESENT until reconnection. So it would be useful to have this state inside the kernel. > - UNKNOWN is when the NMS cant find the state of the device - maybe when > they cant reach us. Again we dont need to expose this from the kernel and > if it is not useful in the kernel perhaps should be deleted. We have two different views here: For an external NMS, it makes perfect sense to change devices of a host from whatever to UNKWOWN if the host becomes unreachable. For the host itself, UNKNOWN can also be a driver that does not know about link state detection. I opt against removal of these states. Cheers, Stefan From srompf@isg.de Mon Oct 14 11:17:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 11:17:57 -0700 (PDT) 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 g9EIHttG017856 for ; Mon, 14 Oct 2002 11:17:55 -0700 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 63276D7C728; Mon, 14 Oct 2002 20:17:49 +0200 (CEST) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id UAA02557; Mon, 14 Oct 2002 20:17:49 +0200 Message-ID: <3DAB0A4D.637F6C30@isg.de> Date: Mon, 14 Oct 2002 20:17:49 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19stefan i686) X-Accept-Language: en MIME-Version: 1.0 To: Tim Hockin Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: PATCH idea - netlink and link changes References: <3DAB07F9.1090802@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 689 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, > > Only one work queue please, not one per device. > > What of two devices that lose link at the same time? Say a hub or > switch dies.. one workqueue != losing notifications. The thread is just growing quite large, best look it up on http://marc.theaimsgroup.com/?l=linux-netdev or some other archive. Cheers, Stefan From david-b@pacbell.net Mon Oct 14 11:53:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 11:53:39 -0700 (PDT) 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 g9EIrbtG023685 for ; Mon, 14 Oct 2002 11:53:37 -0700 Received: from pacbell.net ([67.118.246.141]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H3Z003GAJ5AGL@mta5.snfc21.pbi.net> for netdev@oss.sgi.com; Mon, 14 Oct 2002 11:53:36 -0700 (PDT) Date: Mon, 14 Oct 2002 11:55:01 -0700 From: David Brownell Subject: Re: Patch: Idea for RFC2863 conform OperStatus To: Stefan Rompf Cc: jamal , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Message-id: <3DAB1305.10805@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 References: <3DAB0982.C0C6E36F@isg.de> X-archive-position: 690 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 >>- NOTPRESENT makes sense more from a NMS pov where a hotplug device has >>been removed and SNMP finds that the device is no longer there. This >>can be done without any state from the kernel being exposed. > > > I want to forward this question mainly to the USB people. David, as you > are familiar with this thread, how does an USB driver react when an > ethernet device is configured, running and then disconnected from the > USB port? From RFC2863, I'd expect the devicename ethx not to be removed > at least until it is ifconfigured down, but change from UP to NOTPRESENT > until reconnection. So it would be useful to have this state inside the > kernel. Right now almost all USB networking drivers make the device disappear immediately ... certainly the ones that have made sure they handle the USB disconnect processing correctly (no more I/O to that device!) tend to do that, by calling unregister_netdev(). And they don't try reconnection. The goal of disconnect processing has been to scrub out all the relevant device state; only the usb-storage driver tries to keep a history of devices that have ever been attached, so it can make "/dev/sdg" mean the same thing until reboot. I wouldn't swear that unregistering is the perfect solution, but it's clearly better than the oopses that tended to show up previously. (And oddly enough, the drivers that _don't_ unregister seem to be the ones that still have an EXPERIMENTAL label in the 2.5 kernels.) - Dave (Note that I'm just skimming this thread at the moment, limited time... good that you cc'd me directly.) From david-b@pacbell.net Mon Oct 14 12:02:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 12:02:35 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9EJ2VtG026996 for ; Mon, 14 Oct 2002 12:02:31 -0700 Received: from pacbell.net ([67.118.246.141]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H3Z002A2JK5BJ@mta6.snfc21.pbi.net> for netdev@oss.sgi.com; Mon, 14 Oct 2002 12:02:31 -0700 (PDT) Date: Mon, 14 Oct 2002 12:03:56 -0700 From: David Brownell Subject: Re: Patch: Idea for RFC2863 conform OperStatus To: Stefan Rompf , jamal Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Message-id: <3DAB151C.3030806@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 References: <3DAB0982.C0C6E36F@isg.de> <3DAB1305.10805@pacbell.net> X-archive-position: 691 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 > Right now almost all USB networking drivers make the device disappear > immediately ... certainly the ones that have made sure they handle the > USB disconnect processing correctly (no more I/O to that device!) tend > to do that, by calling unregister_netdev(). ... which would let Linux implement a NotPresent(ifname) test just by seeing if it's registered, unless that RFC demands some more abstruse meaning. (I've not read it lately.) From scott.feldman@intel.com Mon Oct 14 19:20:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 19:20:17 -0700 (PDT) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9F2KEtG023363 for ; Mon, 14 Oct 2002 19:20:15 -0700 Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.47 2002/10/10 20:35:15 dmccart Exp $) with SMTP id g9F2Lfr16996 for ; Tue, 15 Oct 2002 02:21:41 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002101419182532442 ; Mon, 14 Oct 2002 19:18:25 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <4W0V316L>; Mon, 14 Oct 2002 19:20:06 -0700 Message-ID: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> From: "Feldman, Scott" To: "'Ben Greear'" Cc: linux-kernel , "'netdev@oss.sgi.com'" Subject: RE: Update on e1000 troubles (over-heating!) Date: Mon, 14 Oct 2002 19:20:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > Here is the lspci information, both -x and -vv. This is with > two of the e1000 single-port NICS side-by-side. I have also > strapped a P-IV CPU fan on top of the two cards to blow some > air over them....running tests now to see if that actually > helps anything. If it does, I'll be sure to send you a picture :) Ben, I checked the datasheet for the part shown in the lspci dump, and it shows an operating temperature of 0-55 degrees C. You said you measured 50 degrees C, so you're within the safe range. Did the fans help? Here's the datasheet: http://www.intel.com/network/connectivity/resources/doc_library/data_sheets/ pro1000mt_sa.pdf -scott From ak@suse.de Mon Oct 14 19:37:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 19:37:38 -0700 (PDT) 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 g9F2bXtG025304 for ; Mon, 14 Oct 2002 19:37:33 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id BE0FA14B2E; Tue, 15 Oct 2002 04:37:27 +0200 (MEST) Date: Tue, 15 Oct 2002 04:37:23 +0200 From: Andi Kleen To: "Feldman, Scott" Cc: "'Ben Greear'" , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) Message-ID: <20021015043722.A9562@wotan.suse.de> References: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 693 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 Mon, Oct 14, 2002 at 07:20:04PM -0700, Feldman, Scott wrote: > > Here is the lspci information, both -x and -vv. This is with > > two of the e1000 single-port NICS side-by-side. I have also > > strapped a P-IV CPU fan on top of the two cards to blow some > > air over them....running tests now to see if that actually > > helps anything. If it does, I'll be sure to send you a picture :) > > Ben, I checked the datasheet for the part shown in the lspci dump, and it > shows an operating temperature of 0-55 degrees C. You said you measured 50 > degrees C, so you're within the safe range. Did the fans help? The thermometer he used likely showed a much lower temperature than what was actually on the die. 5-10 C more are not unlikely. It's hard to measure chip temperatures accurately without an on die thermal diode or special kit. So I would expect that when an external normal thermometer showed 50C it was already operating out of spec. -Andi From linux@lundell-bros.com Mon Oct 14 19:54:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 19:54:53 -0700 (PDT) Received: from intranet.resilience.com ([12.36.124.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9F2sotG026855 for ; Mon, 14 Oct 2002 19:54:50 -0700 Received: from [207.213.214.37] (unknown [12.36.124.14]) by intranet.resilience.com (Postfix) with ESMTP id 8E4525D87F; Mon, 14 Oct 2002 19:57:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: linux@mail.lundell-bros.com Message-Id: In-Reply-To: <20021015043722.A9562@wotan.suse.de> References: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> <20021015043722.A9562@wotan.suse.de> Date: Mon, 14 Oct 2002 19:54:15 -0700 To: Andi Kleen , "Feldman, Scott" From: Jonathan Lundell Subject: Re: Update on e1000 troubles (over-heating!) Cc: "'Ben Greear'" , linux-kernel , "'netdev@oss.sgi.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-archive-position: 694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux@lundell-bros.com Precedence: bulk X-list: netdev At 4:37am +0200 10/15/02, Andi Kleen wrote: > > Ben, I checked the datasheet for the part shown in the lspci dump, and it >> shows an operating temperature of 0-55 degrees C. You said you measured 50 >> degrees C, so you're within the safe range. Did the fans help? > >The thermometer he used likely showed a much lower temperature than what was >actually on the die. 5-10 C more are not unlikely. It's hard to measure chip >temperatures accurately without an on die thermal diode or special kit. >So I would expect that when an external normal thermometer showed 50C >it was already operating out of spec. The datasheet's for the card, so the operating temperature is surely ambient, not die temperature. "Ambient measured how?" would be a reasonable question, though. -- /Jonathan Lundell. From glee@anakin.wychk.org Mon Oct 14 20:48:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 20:48:42 -0700 (PDT) Received: from anakin.wychk.org (CPE-144-132-192-193.nsw.bigpond.net.au [144.132.192.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9F3mWtG031120 for ; Mon, 14 Oct 2002 20:48:36 -0700 Received: from anakin.wychk.org (localhost [127.0.0.1]) by anakin.wychk.org (8.12.6/8.12.6/Debian-5) with ESMTP id g9F3gZTL015581 for ; Tue, 15 Oct 2002 11:42:35 +0800 Received: (from glee@localhost) by anakin.wychk.org (8.12.6/8.12.6/Debian-5) id g9F3gZWa015580 for netdev@oss.sgi.com; Tue, 15 Oct 2002 11:42:35 +0800 Date: Tue, 15 Oct 2002 11:42:35 +0800 From: Geoffrey Lee To: netdev@oss.sgi.com Subject: Signal interrupt with connect. Message-ID: <20021015034235.GA15574@anakin.wychk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glee@gnupilgrims.org Precedence: bulk X-list: netdev Hi all, A while ago, I have raised the issue of the interruptibility of the connect() function. We decided that a "restartable" connect() if interrupted by a signal is the best solution. I must apologize that I should have looked this up more carefully. According to this document here (IEEE Std 1003.1-2001): http://www.opengroup.org/onlinepubs/007904975/functions/connect.html "If connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to [EINTR], but the connection request shall not be aborted, and the connection shall be established asynchronously." so we must return -EINTR in the kernel. Alexey, will you finally agree that we need to change this? :-) (Yes, that sucks ... but ...) -- G. From haveblue@us.ibm.com Mon Oct 14 22:43:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 14 Oct 2002 22:43:12 -0700 (PDT) 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 g9F5h5tG030931 for ; Mon, 14 Oct 2002 22:43:06 -0700 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9F5gqja199506; Tue, 15 Oct 2002 01:42:52 -0400 Received: from nighthawk.sr71.net (dyn9-47-17-248.beaverton.ibm.com [9.47.17.248]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9F5gnDC072690; Tue, 15 Oct 2002 01:42:50 -0400 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g9F5ge004598; Mon, 14 Oct 2002 22:42:40 -0700 Message-ID: <3DABAACE.9040706@us.ibm.com> Date: Mon, 14 Oct 2002 22:42:38 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: "'Ben Greear'" , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) References: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev Feldman, Scott wrote: >>Here is the lspci information, both -x and -vv. This is with >>two of the e1000 single-port NICS side-by-side. I have also >>strapped a P-IV CPU fan on top of the two cards to blow some >>air over them....running tests now to see if that actually >>helps anything. If it does, I'll be sure to send you a picture :) > > Ben, I checked the datasheet for the part shown in the lspci dump, and it > shows an operating temperature of 0-55 degrees C. You said you measured 50 > degrees C, so you're within the safe range. Did the fans help? > > Here's the datasheet: > http://www.intel.com/network/connectivity/resources/doc_library/data_sheets/ > pro1000mt_sa.pdf I get some strange e1000 failures too. It usually involves the watchdog kicking them back into order, but sometimes they'll stay offline for a while. Heat would explain it, though, because it only happens when I'm actually using the cards for a benchmark. I figured that it was either my cables, or a shoddy switch. The new dual-port e1000 that I have doesn't seem to have this problem, even though I'm running 4 times more traffic than the singles that I had. -- Dave Hansen haveblue@us.ibm.com From greearb@candelatech.com Tue Oct 15 00:01:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 00:01:27 -0700 (PDT) Received: from grok.yi.org (IDENT:vk27Y4N8s2K4Q/OzuEITCx2dpGN28Xyr@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9F71LtG014360 for ; Tue, 15 Oct 2002 00:01:22 -0700 Received: from candelatech.com (IDENT:I3ZANyEFd8DuNh6oFvWo7STPVXtM8zn+@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9F71Eq20300; Tue, 15 Oct 2002 00:01:14 -0700 Message-ID: <3DABBD3A.2000901@candelatech.com> Date: Tue, 15 Oct 2002 00:01:14 -0700 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: "Feldman, Scott" CC: linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) References: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 697 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 Feldman, Scott wrote: >>Here is the lspci information, both -x and -vv. This is with >>two of the e1000 single-port NICS side-by-side. I have also >>strapped a P-IV CPU fan on top of the two cards to blow some >>air over them....running tests now to see if that actually >>helps anything. If it does, I'll be sure to send you a picture :) > > > Ben, I checked the datasheet for the part shown in the lspci dump, and it > shows an operating temperature of 0-55 degrees C. You said you measured 50 > degrees C, so you're within the safe range. Did the fans help? The fan did help, and Andi is right, the chip was much hotter than what my probe read (I was gently pushing it against the top of the chip, cause it was too hot to really press my finger against it to get good contact :)) With the fan blowing on the chips, it has been perfect. This implies to me that if you are going to run the e1000, you need significant air-flow over the chipset, and the generic 2U chassis that I have is definately inadequate, partially because the MB is so big that the fans are too far away from the PCI slots... This is all doubly true if you are running two NICs side-by-side, which is what I was doing. I am also considering glueing heat-sinks onto the main chip, which may make it work in more marginal environments. 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 Oct 15 00:07:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 00:07:51 -0700 (PDT) Received: from grok.yi.org (IDENT:oSwKDrsk1XbivfDxbiesGwD9cObooxH2@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9F77ntG015332 for ; Tue, 15 Oct 2002 00:07:49 -0700 Received: from candelatech.com (IDENT:St1RWp0tZvUtDhVnC8ZgdOWU6WmBNBkN@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9F77bq20478; Tue, 15 Oct 2002 00:07:37 -0700 Message-ID: <3DABBEB9.7040004@candelatech.com> Date: Tue, 15 Oct 2002 00:07:37 -0700 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: Dave Hansen CC: "Feldman, Scott" , linux-kernel , "'netdev@oss.sgi.com'" Subject: Re: Update on e1000 troubles (over-heating!) References: <288F9BF66CD9D5118DF400508B68C44604758B78@orsmsx113.jf.intel.com> <3DABAACE.9040706@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 698 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 Dave Hansen wrote: > > I get some strange e1000 failures too. It usually involves the watchdog > kicking them back into order, but sometimes they'll stay offline for a > while. Heat would explain it, though, because it only happens when I'm > actually using the cards for a benchmark. I figured that it was either > my cables, or a shoddy switch. > > The new dual-port e1000 that I have doesn't seem to have this problem, > even though I'm running 4 times more traffic than the singles that I had. That was exactly the behaviour I noticed. I believe it's because when you run two side-by-side, they cook each other (I'm assuming you didn't run 2 2-ports side-by-side) Try strapping a fan on them somehow and I bet all your troubles go away (and maybe your .ibm email will shame Intel into putting heat-sinks and/or small fans on their NICs... ;) (I ran two Netgear 302t NICs (tigon-3) side-by-side for 4 days at max speed, and they didn't drop a single packet, even though their heat-sinks were too hot to touch!) Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From srompf@isg.de Tue Oct 15 02:53:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 02:53:55 -0700 (PDT) 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 g9F9rmtG030306 for ; Tue, 15 Oct 2002 02:53:49 -0700 Received: from barkeeper.isg.de (barkeeper.is-asp.com [192.168.5.46]) by mail.isg.de (Postfix) with ESMTP id 6D9C5D7F1CF; Tue, 15 Oct 2002 11:53:38 +0200 (CEST) Received: from isg.de (localhost.localdomain [127.0.0.1]) by barkeeper.isg.de (8.9.3/8.9.3) with ESMTP id LAA01042; Tue, 15 Oct 2002 11:53:38 +0200 Message-ID: <3DABE5A2.71542192@isg.de> Date: Tue, 15 Oct 2002 11:53:38 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19stefan i686) X-Accept-Language: en MIME-Version: 1.0 To: jamal Cc: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus References: Content-Type: multipart/mixed; boundary="------------471682B4692DE518292CF7DC" X-archive-position: 699 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. --------------471682B4692DE518292CF7DC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jamal, attached is the latest version of the patch. Changes: -Try to use a static struct lw_event for an event. For systems without slave devices, this will avoid memory allocation in most cases. But, adding code and data it permanently takes as much memory as about ten of the additional pointers you didn't want to have in the net_device structure ;-) -moved the event queue flushing in unregister_netdev() down some lines so that it is not attempted for new style devices with destructor. According to Alexey not wanting to expand the netlink message, the only result of this patch visible to userspace is the IFF_RUNNING emulation. Cheers, Stefan --------------471682B4692DE518292CF7DC Content-Type: text/plain; charset=us-ascii; name="patch-rfc2863-2.5.41-3" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-rfc2863-2.5.41-3" diff -uNrX dontdiff linux-2.5.41/include/linux/netdevice.h linux-2.5.41-stefan/include/linux/netdevice.h --- linux-2.5.41/include/linux/netdevice.h Tue Oct 8 22:18:50 2002 +++ linux-2.5.41-stefan/include/linux/netdevice.h Sun Oct 13 12:47:13 2002 @@ -204,10 +204,23 @@ { __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 @@ * 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 @@ * 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_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 -uNrX dontdiff linux-2.5.41/net/Config.help linux-2.5.41-stefan/net/Config.help --- linux-2.5.41/net/Config.help Tue Oct 1 09:06:18 2002 +++ linux-2.5.41-stefan/net/Config.help Sat Oct 12 00:56:59 2002 @@ -472,6 +472,17 @@ However, do not say Y here if you did not experience any serious problems. +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'. + CONFIG_NET_SCHED When the kernel has several packets to send out over a network device, it has to decide which ones to send first, which ones to diff -uNrX dontdiff linux-2.5.41/net/Config.in linux-2.5.41-stefan/net/Config.in --- linux-2.5.41/net/Config.in Tue Oct 1 09:06:24 2002 +++ linux-2.5.41-stefan/net/Config.in Tue Oct 8 22:44:07 2002 @@ -82,6 +82,7 @@ tristate 'WAN router' CONFIG_WAN_ROUTER bool 'Fast switching (read help!)' CONFIG_NET_FASTROUTE bool 'Forwarding between high speed interfaces' CONFIG_NET_HW_FLOWCONTROL + bool 'Device link state notification (EXPERIMENTAL)' CONFIG_LINKWATCH fi mainmenu_option next_comment diff -uNrX dontdiff linux-2.5.41/net/core/Makefile linux-2.5.41-stefan/net/core/Makefile --- linux-2.5.41/net/core/Makefile Tue Oct 1 09:07:40 2002 +++ linux-2.5.41-stefan/net/core/Makefile Sun Oct 13 12:37:08 2002 @@ -21,4 +21,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 -uNrX dontdiff linux-2.5.41/net/core/dev.c linux-2.5.41-stefan/net/core/dev.c --- linux-2.5.41/net/core/dev.c Tue Oct 8 22:18:51 2002 +++ linux-2.5.41-stefan/net/core/dev.c Mon Oct 14 23:00:00 2002 @@ -198,7 +198,6 @@ int netdev_fastroute_obstacles; #endif - /******************************************************************************* Protocol management and registration routines @@ -261,6 +260,9 @@ br_write_unlock_bh(BR_NETPROTO_LOCK); } +#ifdef CONFIG_LINKWATCH +void linkwatch_run_queue(void); +#endif /** * dev_remove_pack - remove packet handler @@ -2017,7 +2019,7 @@ 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; @@ -2432,6 +2434,10 @@ 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 */ @@ -2457,13 +2463,6 @@ 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); @@ -2641,6 +2640,17 @@ /* 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); @@ -2735,6 +2745,8 @@ #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); @@ -2767,7 +2779,6 @@ if (!dev->rebuild_header) dev->rebuild_header = default_rebuild_header; dev_init_scheduler(dev); - set_bit(__LINK_STATE_PRESENT, &dev->state); } } @@ -2848,3 +2859,5 @@ return call_usermodehelper(argv [0], argv, envp); } #endif + + diff -uNrX dontdiff linux-2.5.41/net/core/link_watch.c linux-2.5.41-stefan/net/core/link_watch.c --- linux-2.5.41/net/core/link_watch.c Thu Jan 1 01:00:00 1970 +++ linux-2.5.41-stefan/net/core/link_watch.c Mon Oct 14 22:51:02 2002 @@ -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 -uNrX dontdiff linux-2.5.41/net/core/rtnetlink.c linux-2.5.41-stefan/net/core/rtnetlink.c --- linux-2.5.41/net/core/rtnetlink.c Tue Oct 1 09:07:57 2002 +++ linux-2.5.41-stefan/net/core/rtnetlink.c Sat Oct 12 14:27:43 2002 @@ -165,7 +165,7 @@ 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 -uNrX dontdiff linux-2.5.41/net/netsyms.c linux-2.5.41-stefan/net/netsyms.c --- linux-2.5.41/net/netsyms.c Tue Oct 8 22:18:53 2002 +++ linux-2.5.41-stefan/net/netsyms.c Sun Oct 13 13:27:40 2002 @@ -596,4 +596,8 @@ 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 */ --------------471682B4692DE518292CF7DC-- From janine_h@aol.com Tue Oct 15 06:46:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 06:46:06 -0700 (PDT) Received: from 61.143.3.130 (IDENT:squid@[211.250.105.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FDjitG021166 for ; Tue, 15 Oct 2002 06:45:52 -0700 Message-Id: <200210151345.g9FDjitG021166@oss.sgi.com> From: Janine To: Hi@oss.sgi.com Cc: Subject: Meld Dich mal wieder Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 15 Oct 2002 15:46:45 +0200 X-Mailer: AOL 7.0 for Windows US sub 118 X-Priority: 1 X-archive-position: 700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janine_h@aol.com Precedence: bulk X-list: netdev Untitled Document

Tut mir leid das ich Dir nicht gleich geschrieben habe, aber
ich war totmüde und bin gleich ins Bett gegangen.
Wie versprochen schicke Dir jetzt mal den Link zu meiner
privaten Homepage. Zu meiner Page

Ps.: Ich hoffe wir sehen uns bald wieder ;-)

Tschau Janine

From jmorris@intercode.com.au Tue Oct 15 07:34:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:34:12 -0700 (PDT) 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 g9FEY4tG026476 for ; Tue, 15 Oct 2002 07:34:06 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA27963; Wed, 16 Oct 2002 00:33:18 +1000 Date: Wed, 16 Oct 2002 00:33:18 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: LSM networking components for 2.5.42 (intro) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev Following this email will be seven patches which provide LSM networking components for the 2.5.42 kernel: 1. Netdevice hooks 2. skb hooks 3. Socket hooks 4. IPv4 hooks 5. Netlink hooks 6. Unix domain hooks 7. TCP hooks These represent all of the current LSM networking features, split into cumulative patches. In a nutshell, LSM (Linux Security Modules) is a general purpose framework for access control, allowing various security projects (e.g. SELinux, LIDS etc.) to be implemented without needing to patch the kernel. The basic concept of LSM is 'mediated access to kernel objects', which roughly translates to placing void pointers into key structs which can be used to store security state, then adding a series of hooks which maintain per-object security state and allow access decisions to be made. It is up to the security module to implement policies for maintaining security state and which access hooks to choose (i.e. LSM aims to be mechanism, not policy). Much more information on LSM and its design can be found at the LSM web site: http://lsm.immunix.org/ , notably the Usenix and OLS papers. The networking components were largely modeled on the requirements of SELinux, which is itself a somewhat generic mandatory access control system. Specific aims for the networking in LSM are to provide support for: general access control, the SELinux extended socket API, and labeled networking. Several additional projects are believed to be under development which make significant use of the networking components, although SELinux is the best currently available example. The performance impact of LSM has been examined using macro (Webstone) and micro (lmbench) benchmarks on a dual SMP system. The last set of data, which was generated around the time of the last kernel summit, indicates that there is no measurable impact on networking at 100Mbps LAN speeds (the variations were basically noise). At 1Gbps, the Webstone throughput figures showed a 1-2% impact, although it's not clear how much of this is the specific result of the networking hooks (i.e. non-networking LSM hooks were probably also contributing). The bw_tcp microbenchmark showed an impact of 0.3-0.6% at gigabit speed. Some changes (notably, the recent addition some TCP hooks) have been made to LSM since these tests, and the tests can be run again if needed. There's also the issue of the new flow cache code, which will probably require changes to some of the LSM networking hooks. The LSM developers are open to suggestions for optimizations and improvements, and can be reached reliably at the lsm address on the cc list above. - James -- James Morris From jmorris@intercode.com.au Tue Oct 15 07:35:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:35:18 -0700 (PDT) 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 g9FEZDtG026896 for ; Tue, 15 Oct 2002 07:35:14 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA27976; Wed, 16 Oct 2002 00:34:31 +1000 Date: Wed, 16 Oct 2002 00:34:31 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: netdevice hooks for 2.5.42 (1/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 702 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 diff -urN -X dontdiff linux-2.5.42.orig/include/linux/netdevice.h linux-2.5.42.w1/include/linux/netdevice.h --- linux-2.5.42.orig/include/linux/netdevice.h Wed Oct 9 22:39:39 2002 +++ linux-2.5.42.w1/include/linux/netdevice.h Tue Oct 15 20:19:42 2002 @@ -437,6 +437,7 @@ /* this will get initialized at each interface type init routine */ struct divert_blk *divert; #endif /* CONFIG_NET_DIVERT */ + void *security; }; diff -urN -X dontdiff linux-2.5.42.orig/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.orig/include/linux/security.h Sat Oct 12 15:09:43 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 20:19:42 2002 @@ -616,6 +616,20 @@ * deallocate security struct for this semaphore * @sma contains the semaphore structure. * + * Security hooks for network devices. + * @netdev_unregister: + * Update the module's state when a network device is unregistered, + * deallocating the dev->security field if it was previously allocated. + * @dev contains the network device + * + * These are the hooks for network device operations. Since it would be quite + * invasive to provide hooks in every location where a network device might be + * probed or initialized, there are no separate hooks for allocation or + * initialization. Security modules can allocate and initialize the + * dev->security field on the first access to the device, but should be careful + * to use nonblocking allocation. + * + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -830,6 +844,8 @@ void (*task_kmod_set_label) (void); void (*task_reparent_to_init) (struct task_struct * p); + void (*netdev_unregister) (struct net_device * dev); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.orig/net/core/dev.c linux-2.5.42.w1/net/core/dev.c --- linux-2.5.42.orig/net/core/dev.c Wed Oct 9 22:39:39 2002 +++ linux-2.5.42.w1/net/core/dev.c Tue Oct 15 20:19:42 2002 @@ -105,6 +105,7 @@ #include #include #include +#include #if defined(CONFIG_NET_RADIO) || defined(CONFIG_NET_PCMCIA_RADIO) #include /* Note : will define WIRELESS_EXT */ #include @@ -2592,6 +2593,8 @@ free_divert_blk(dev); #endif + security_ops->netdev_unregister(dev); + if (dev->features & NETIF_F_DYNALLOC) { #ifdef NET_REFCNT_DEBUG if (atomic_read(&dev->refcnt) != 1) diff -urN -X dontdiff linux-2.5.42.orig/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.orig/security/capability.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 20:19:42 2002 @@ -714,6 +714,11 @@ return; } +static void cap_netdev_unregister (struct net_device *dev) +{ + return; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -828,6 +833,8 @@ .sem_alloc_security = cap_sem_alloc_security, .sem_free_security = cap_sem_free_security, + .netdev_unregister = cap_netdev_unregister, + .register_security = cap_register, .unregister_security = cap_unregister, }; diff -urN -X dontdiff linux-2.5.42.orig/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.orig/security/dummy.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 20:19:42 2002 @@ -529,6 +529,11 @@ return; } +static void dummy_netdev_unregister (struct net_device *dev) +{ + return; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -643,6 +648,8 @@ .sem_alloc_security = dummy_sem_alloc_security, .sem_free_security = dummy_sem_free_security, + .netdev_unregister = dummy_netdev_unregister, + .register_security = dummy_register, .unregister_security = dummy_unregister, }; From jmorris@intercode.com.au Tue Oct 15 07:36:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:36:54 -0700 (PDT) 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 g9FEamtG027429 for ; Tue, 15 Oct 2002 07:36:49 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA27998; Wed, 16 Oct 2002 00:36:06 +1000 Date: Wed, 16 Oct 2002 00:36:06 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 703 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 (note: we'd like to use the existing skb security field, but have not touched yet it as you may want to maintain the padding there). diff -urN -X dontdiff linux-2.5.42.w0/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.w0/include/linux/security.h Tue Oct 15 20:28:55 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 20:25:40 2002 @@ -630,6 +630,50 @@ * to use nonblocking allocation. * * + * Lifecycle hooks for network buffers. + * + * @skb_alloc_security: + * This hook is called by the &sk_buff allocator when a new buffer is + * being allocated. An LSM module may allocate and assign a new security + * blob for the &sk_buff via this hook. + * @skb contains the buffer being allocated. + * @gfp_mask contains the kernel allocation gfp_mask value. + * Return 0 if successful, or -ENOMEM on out of memory condition. + * @skb_clone: + * This hook is called when an &sk_buff is being cloned, and may be used, + * for example, to increment a reference count on the associated security + * blob. The security blob in the @newskb will not have been allocated. + * @newskb contains the newly cloned buffer. + * @oldskb contains the buffer being cloned. + * Returns 0 on success -ENOMEM on failure. + * @skb_copy: + * This hook is called when an &sk_buff header is being copied, which + * occurs during the skb_copy() and pskb_copy() functions in + * + * @newskb contains the newly copied buffer. + * @oldskb contains the buffer being copied. + * @skb_set_owner_w: + * This hook is called when the ownership of an &sk_buff is being assigned + * to a sending socket. Typically, this would be used to copy security + * attributes from the sending socket to the &sk_buff. + * @skb contains the buffer being owned. + * @sk contains sock to which ownership is being assigned. + * @skb_recv_datagram: + * This hook is called when a process is receiving a datagram + * message. At this point, there is an association between the + * current process, the socket, and the skb. + * @skb contains the buffer being returned. + * @sk is the receiving sock. + * @flags contains operational flags. + * @skb_free_security: + * This hook is called when an &sk_buff is being destroyed, and should be + * used to free any associated security blob. + * @skb contains the buffer being destroyed. + * + * These are the lifecycle hooks for network buffers. They are used to help + * manage the lifecycle of security blobs for &sk_buff structures, and are not + * intended to be used for access decisions. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -846,6 +890,16 @@ void (*netdev_unregister) (struct net_device * dev); + int (*skb_alloc_security) (struct sk_buff * skb, int gfp_mask); + int (*skb_clone) (struct sk_buff * newskb, + const struct sk_buff * oldskb); + void (*skb_copy) (struct sk_buff * newskb, + const struct sk_buff * oldskb); + void (*skb_set_owner_w) (struct sk_buff * skb, struct sock * sk); + void (*skb_recv_datagram) (struct sk_buff * skb, struct sock * sk, + unsigned flags); + void (*skb_free_security) (struct sk_buff * skb); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.w0/include/linux/skbuff.h linux-2.5.42.w1/include/linux/skbuff.h --- linux-2.5.42.w0/include/linux/skbuff.h Sun Sep 1 11:34:46 2002 +++ linux-2.5.42.w1/include/linux/skbuff.h Tue Oct 15 20:23:42 2002 @@ -245,6 +245,8 @@ #ifdef CONFIG_NET_SCHED __u32 tc_index; /* traffic control index */ #endif + + void *lsm_security; /* replaces the above security field */ }; #define SK_WMEM_MAX 65535 diff -urN -X dontdiff linux-2.5.42.w0/include/net/sock.h linux-2.5.42.w1/include/net/sock.h --- linux-2.5.42.w0/include/net/sock.h Sat Oct 12 15:09:43 2002 +++ linux-2.5.42.w1/include/net/sock.h Tue Oct 15 20:23:42 2002 @@ -663,6 +663,7 @@ skb->sk = sk; skb->destructor = sock_wfree; atomic_add(skb->truesize, &sk->wmem_alloc); + security_ops->skb_set_owner_w(skb, sk); } static inline void skb_set_owner_r(struct sk_buff *skb, struct sock *sk) diff -urN -X dontdiff linux-2.5.42.w0/net/core/datagram.c linux-2.5.42.w1/net/core/datagram.c --- linux-2.5.42.w0/net/core/datagram.c Sun Aug 11 12:20:40 2002 +++ linux-2.5.42.w1/net/core/datagram.c Tue Oct 15 20:23:42 2002 @@ -176,8 +176,10 @@ } else skb = skb_dequeue(&sk->receive_queue); - if (skb) + if (skb) { + security_ops->skb_recv_datagram(skb, sk, flags); return skb; + } /* User doesn't want to wait */ error = -EAGAIN; diff -urN -X dontdiff linux-2.5.42.w0/net/core/skbuff.c linux-2.5.42.w1/net/core/skbuff.c --- linux-2.5.42.w0/net/core/skbuff.c Sun Sep 1 11:34:46 2002 +++ linux-2.5.42.w1/net/core/skbuff.c Tue Oct 15 20:23:42 2002 @@ -53,6 +53,7 @@ #include #include #include +#include #include #include @@ -194,6 +195,11 @@ if (!data) goto nodata; + if (security_ops->skb_alloc_security(skb, gfp_mask)) { + kfree(data); + goto nodata; + } + /* XXX: does not include slab overhead */ skb->truesize = size + sizeof(struct sk_buff); @@ -252,6 +258,7 @@ #ifdef CONFIG_NET_SCHED skb->tc_index = 0; #endif + skb->lsm_security = NULL; } static void skb_drop_fraglist(struct sk_buff *skb) @@ -328,6 +335,7 @@ #ifdef CONFIG_NETFILTER nf_conntrack_put(skb->nfct); #endif + security_ops->skb_free_security(skb); skb_headerinit(skb, NULL, 0); /* clean state */ kfree_skbmem(skb); } @@ -355,6 +363,11 @@ if (!n) return NULL; } + + if (security_ops->skb_clone(n, skb)) { + skb_head_to_pool(n); + return NULL; + } #define C(x) n->x = skb->x @@ -442,6 +455,7 @@ #ifdef CONFIG_NET_SCHED new->tc_index = old->tc_index; #endif + security_ops->skb_copy(new, old); } /** diff -urN -X dontdiff linux-2.5.42.w0/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.w0/security/capability.c Tue Oct 15 20:28:55 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 20:23:42 2002 @@ -719,6 +719,37 @@ return; } +static int cap_skb_alloc_security (struct sk_buff *skb, int gfp_mask) +{ + return 0; +} + +static int cap_skb_clone (struct sk_buff *newskb, const struct sk_buff *oldskb) +{ + return 0; +} + +static void cap_skb_copy (struct sk_buff *newskb, const struct sk_buff *oldskb) +{ + return; +} + +static void cap_skb_set_owner_w (struct sk_buff *skb, struct sock *sk) +{ + return; +} + +static void cap_skb_recv_datagram (struct sk_buff *skb, struct sock *sk, + unsigned flags) +{ + return; +} + +static void cap_skb_free_security (struct sk_buff *skb) +{ + return; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -822,6 +853,13 @@ .task_kmod_set_label = cap_task_kmod_set_label, .task_reparent_to_init = cap_task_reparent_to_init, + .skb_alloc_security = cap_skb_alloc_security, + .skb_clone = cap_skb_clone, + .skb_copy = cap_skb_copy, + .skb_set_owner_w = cap_skb_set_owner_w, + .skb_recv_datagram = cap_skb_recv_datagram, + .skb_free_security = cap_skb_free_security, + .ipc_permission = cap_ipc_permission, .msg_queue_alloc_security = cap_msg_queue_alloc_security, diff -urN -X dontdiff linux-2.5.42.w0/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.w0/security/dummy.c Tue Oct 15 20:28:55 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 20:23:42 2002 @@ -534,6 +534,39 @@ return; } +static int dummy_skb_alloc_security (struct sk_buff *skb, int gfp_mask) +{ + return 0; +} + +static int dummy_skb_clone (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return 0; +} + +static void dummy_skb_copy (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return; +} + +static void dummy_skb_set_owner_w (struct sk_buff *skb, struct sock *sk) +{ + return; +} + +static void dummy_skb_recv_datagram (struct sk_buff *skb, struct sock *sk, + unsigned flags) +{ + return; +} + +static void dummy_skb_free_security (struct sk_buff *skb) +{ + return; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -637,6 +670,13 @@ .task_kmod_set_label = dummy_task_kmod_set_label, .task_reparent_to_init = dummy_task_reparent_to_init, + .skb_alloc_security = dummy_skb_alloc_security, + .skb_clone = dummy_skb_clone, + .skb_copy = dummy_skb_copy, + .skb_set_owner_w = dummy_skb_set_owner_w, + .skb_recv_datagram = dummy_skb_recv_datagram, + .skb_free_security = dummy_skb_free_security, + .ipc_permission = dummy_ipc_permission, .msg_queue_alloc_security = dummy_msg_queue_alloc_security, From jmorris@intercode.com.au Tue Oct 15 07:38:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:38:08 -0700 (PDT) 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 g9FEbwtG027912 for ; Tue, 15 Oct 2002 07:38:00 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA28042; Wed, 16 Oct 2002 00:37:14 +1000 Date: Wed, 16 Oct 2002 00:37:14 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: socket hooks for 2.5.42 (3/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 704 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 diff -urN -X dontdiff linux-2.5.42.w0/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.w0/include/linux/security.h Tue Oct 15 20:35:19 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 20:45:30 2002 @@ -674,6 +674,126 @@ * manage the lifecycle of security blobs for &sk_buff structures, and are not * intended to be used for access decisions. * + * Security hooks for socket operations. + * + * @socket_create: + * Check permissions prior to creating a new socket. + * @family contains the requested protocol family. + * @type contains the requested communications type. + * @protocol contains the requested protocol. + * Return 0 if permission is granted. + * @socket_post_create: + * This hook allows a module to update or allocate a per-socket security + * structure. Note that the security field was not added directly to the + * socket structure, but rather, the socket security information is stored + * in the associated inode. Typically, the inode alloc_security hook will + * allocate and and attach security information to + * sock->inode->i_security. This hook may be used to update the + * sock->inode->i_security field with additional information that wasn't + * available when the inode was allocated. + * @sock contains the newly created socket structure. + * @family contains the requested protocol family. + * @type contains the requested communications type. + * @protocol contains the requested protocol. + * @socket_bind: + * Check permission before socket protocol layer bind operation is + * performed and the socket @sock is bound to the address specified in the + * @address parameter. + * @sock contains the socket structure. + * @address contains the address to bind to. + * @addrlen contains the length of address. + * Return 0 if permission is granted. + * @socket_connect: + * Check permission before socket protocol layer connect operation + * attempts to connect socket @sock to a remote address, @address. + * @sock contains the socket structure. + * @address contains the address of remote endpoint. + * @addrlen contains the length of address. + * Return 0 if permission is granted. + * @socket_listen: + * Check permission before socket protocol layer listen operation. + * @sock contains the socket structure. + * @backlog contains the maximum length for the pending connection queue. + * Return 0 if permission is granted. + * @socket_accept: + * Check permission before accepting a new connection. Note that the new + * socket, @newsock, has been created and some information copied to it, + * but the accept operation has not actually been performed. + * @sock contains the listening socket structure. + * @newsock contains the newly created server socket for connection. + * Return 0 if permission is granted. + * @socket_post_accept: + * This hook allows a security module to copy security + * information into the newly created socket's inode. + * @sock contains the listening socket structure. + * @newsock contains the newly created server socket for connection. + * @socket_sendmsg: + * Check permission before transmitting a message to another socket. + * @sock contains the socket structure. + * @msg contains the message to be transmitted. + * @size contains the size of message. + * Return 0 if permission is granted. + * @socket_recvmsg: + * Check permission before receiving a message from a socket. + * @sock contains the socket structure. + * @msg contains the message structure. + * @size contains the size of message structure. + * @flags contains the operational flags. + * Return 0 if permission is granted. + * @socket_getsockname: + * Check permission before the local address (name) of the socket object + * @sock is retrieved. + * @sock contains the socket structure. + * Return 0 if permission is granted. + * @socket_getpeername: + * Check permission before the remote address (name) of a socket object + * @sock is retrieved. + * @sock contains the socket structure. + * Return 0 if permission is granted. + * @socket_getsockopt: + * Check permissions before retrieving the options associated with socket + * @sock. + * @sock contains the socket structure. + * @level contains the protocol level to retrieve option from. + * @optname contains the name of option to retrieve. + * Return 0 if permission is granted. + * @socket_setsockopt: + * Check permissions before setting the options associated with socket + * @sock. + * @sock contains the socket structure. + * @level contains the protocol level to set options for. + * @optname contains the name of the option to set. + * Return 0 if permission is granted. + * @socket_shutdown: + * Checks permission before all or part of a connection on the socket + * @sock is shut down. + * @sock contains the socket structure. + * @how contains the flag indicating how future sends and receives are handled. + * Return 0 if permission is granted. + * @socket_sock_alloc_security: + * @sk contains the sock structure. + * @gfp_mask contains the kernel allocation gfp_mask value. + * Allocate and attach a security structure to @sk->security. The + * security field is initialized to NULL when the sock structure is + * allocated. + * Return 0 if operation was successful. + * @socket_sock_free_security: + * @sk contains the sock structure. + * Deallocate and clear the sk->security field. + * @socket_sock_rcv_skb: + * Check permissions on incoming network packets. This hook is distinct + * from the network input hooks of ip_security_ops since it is the first + * time that the incoming sk_buff @skb has been associated with a + * particular socket, @sk. Security modules should not try to dereference + * @sk->socket if the socket is in a time wait state + * (@sk->state == TCP_TIME_WAIT), since the @sk refers to a tcp_tw_bucket + * structure in that case. Also, even if the socket is not in this state, + * @sk->socket may be NULL, e.g. a newly created server socket for a + * connection that has not yet been accepted by a process. + * @sk contains the sock (not socket) associated with the incoming sk_buff. + * @skb contains the incoming network data. + * Return 0 if permission is granted. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -900,6 +1020,30 @@ unsigned flags); void (*skb_free_security) (struct sk_buff * skb); + int (*socket_create) (int family, int type, int protocol); + void (*socket_post_create) (struct socket * sock, int family, + int type, int protocol); + int (*socket_bind) (struct socket * sock, + struct sockaddr * address, int addrlen); + int (*socket_connect) (struct socket * sock, + struct sockaddr * address, int addrlen); + int (*socket_listen) (struct socket * sock, int backlog); + int (*socket_accept) (struct socket * sock, struct socket * newsock); + void (*socket_post_accept) (struct socket * sock, + struct socket * newsock); + int (*socket_sendmsg) (struct socket * sock, + struct msghdr * msg, int size); + int (*socket_recvmsg) (struct socket * sock, + struct msghdr * msg, int size, int flags); + int (*socket_getsockname) (struct socket * sock); + int (*socket_getpeername) (struct socket * sock); + int (*socket_getsockopt) (struct socket * sock, int level, int optname); + int (*socket_setsockopt) (struct socket * sock, int level, int optname); + int (*socket_shutdown) (struct socket * sock, int how); + int (*socket_sock_alloc_security) (struct sock * sk, int gfp_mask); + void (*socket_sock_free_security) (struct sock * sk); + int (*socket_sock_rcv_skb) (struct sock * sk, struct sk_buff * skb); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.w0/include/net/sock.h linux-2.5.42.w1/include/net/sock.h --- linux-2.5.42.w0/include/net/sock.h Tue Oct 15 20:35:19 2002 +++ linux-2.5.42.w1/include/net/sock.h Tue Oct 15 20:36:51 2002 @@ -194,7 +194,10 @@ /* RPC layer private data */ void *user_data; - + + /* LSM security field */ + void *security; + /* Callbacks */ void (*state_change)(struct sock *sk); void (*data_ready)(struct sock *sk,int bytes); @@ -675,15 +678,20 @@ static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) { + int err = 0; + /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces number of warnings when compiling with -W --ANK */ if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) return -ENOMEM; + err = security_ops->socket_sock_rcv_skb(sk, skb); + if (err) + return err; + #ifdef CONFIG_FILTER if (sk->filter) { - int err = 0; struct sk_filter *filter; /* It would be deadlock, if sock_queue_rcv_skb is used diff -urN -X dontdiff linux-2.5.42.w0/net/core/sock.c linux-2.5.42.w1/net/core/sock.c --- linux-2.5.42.w0/net/core/sock.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/core/sock.c Tue Oct 15 20:36:51 2002 @@ -600,6 +600,11 @@ sk->family = family; sock_lock_init(sk); } + sk->security = NULL; + if (security_ops->socket_sock_alloc_security(sk, priority)) { + kmem_cache_free(slab, sk); + return NULL; + } sk->slab = slab; } @@ -626,6 +631,8 @@ if (atomic_read(&sk->omem_alloc)) printk(KERN_DEBUG "sk_free: optmem leakage (%d bytes) detected.\n", atomic_read(&sk->omem_alloc)); + security_ops->socket_sock_free_security(sk); + kmem_cache_free(sk->slab, sk); } diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/tcp_ipv4.c linux-2.5.42.w1/net/ipv4/tcp_ipv4.c --- linux-2.5.42.w0/net/ipv4/tcp_ipv4.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/ipv4/tcp_ipv4.c Tue Oct 15 20:36:51 2002 @@ -1771,6 +1771,9 @@ if (!ipsec_sk_policy(sk, skb)) goto discard_and_relse; + if (security_ops->socket_sock_rcv_skb(sk, skb)) + goto discard_and_relse; + if (sk->state == TCP_TIME_WAIT) goto do_time_wait; diff -urN -X dontdiff linux-2.5.42.w0/net/socket.c linux-2.5.42.w1/net/socket.c --- linux-2.5.42.w0/net/socket.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/socket.c Tue Oct 15 20:36:51 2002 @@ -522,6 +522,10 @@ int err; struct scm_cookie scm; + err = security_ops->socket_sendmsg(sock, msg, size); + if (err) + return err; + err = scm_send(sock, msg, &scm); if (err >= 0) { err = sock->ops->sendmsg(sock, msg, size, &scm); @@ -533,6 +537,11 @@ int sock_recvmsg(struct socket *sock, struct msghdr *msg, int size, int flags) { struct scm_cookie scm; + int err; + + err = security_ops->socket_recvmsg(sock, msg, size, flags); + if (err) + return err; memset(&scm, 0, sizeof(scm)); @@ -867,6 +876,7 @@ int sock_create(int family, int type, int protocol, struct socket **res) { int i; + int err; struct socket *sock; /* @@ -890,6 +900,10 @@ } family = PF_PACKET; } + + err = security_ops->socket_create(family, type, protocol); + if (err) + return err; #if defined(CONFIG_KMOD) && defined(CONFIG_NET) /* Attempt to load a protocol module if the find failed. @@ -936,6 +950,8 @@ *res = sock; + security_ops->socket_post_create(sock, family, type, protocol); + out: net_family_read_unlock(); return i; @@ -1045,8 +1061,14 @@ if((sock = sockfd_lookup(fd,&err))!=NULL) { - if((err=move_addr_to_kernel(umyaddr,addrlen,address))>=0) + if((err=move_addr_to_kernel(umyaddr,addrlen,address))>=0) { + err = security_ops->socket_bind(sock, (struct sockaddr *)address, addrlen); + if (err) { + sockfd_put(sock); + return err; + } err = sock->ops->bind(sock, (struct sockaddr *)address, addrlen); + } sockfd_put(sock); } return err; @@ -1067,6 +1089,13 @@ if ((sock = sockfd_lookup(fd, &err)) != NULL) { if ((unsigned) backlog > SOMAXCONN) backlog = SOMAXCONN; + + err = security_ops->socket_listen(sock, backlog); + if (err) { + sockfd_put(sock); + return err; + } + err=sock->ops->listen(sock, backlog); sockfd_put(sock); } @@ -1103,6 +1132,10 @@ newsock->type = sock->type; newsock->ops = sock->ops; + err = security_ops->socket_accept(sock, newsock); + if (err) + goto out_release; + err = sock->ops->accept(sock, newsock, sock->file->f_flags); if (err < 0) goto out_release; @@ -1122,6 +1155,8 @@ if ((err = sock_map_fd(newsock)) < 0) goto out_release; + security_ops->socket_post_accept(sock, newsock); + out_put: sockfd_put(sock); out: @@ -1157,8 +1192,14 @@ err = move_addr_to_kernel(uservaddr, addrlen, address); if (err < 0) goto out_put; + + err = security_ops->socket_connect(sock, (struct sockaddr *)address, addrlen); + if (err) + goto out_put; + err = sock->ops->connect(sock, (struct sockaddr *) address, addrlen, sock->file->f_flags); + out_put: sockfd_put(sock); out: @@ -1179,6 +1220,11 @@ sock = sockfd_lookup(fd, &err); if (!sock) goto out; + + err = security_ops->socket_getsockname(sock); + if (err) + goto out_put; + err = sock->ops->getname(sock, (struct sockaddr *)address, &len, 0); if (err) goto out_put; @@ -1203,6 +1249,12 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_ops->socket_getpeername(sock); + if (err) { + sockfd_put(sock); + return err; + } + err = sock->ops->getname(sock, (struct sockaddr *)address, &len, 1); if (!err) err=move_addr_to_user(address,len, usockaddr, usockaddr_len); @@ -1331,6 +1383,12 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_ops->socket_setsockopt(sock,level,optname); + if (err) { + sockfd_put(sock); + return err; + } + if (level == SOL_SOCKET) err=sock_setsockopt(sock,level,optname,optval,optlen); else @@ -1352,6 +1410,13 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_ops->socket_getsockopt(sock, level, + optname); + if (err) { + sockfd_put(sock); + return err; + } + if (level == SOL_SOCKET) err=sock_getsockopt(sock,level,optname,optval,optlen); else @@ -1373,6 +1438,12 @@ if ((sock = sockfd_lookup(fd, &err))!=NULL) { + err = security_ops->socket_shutdown(sock, how); + if (err) { + sockfd_put(sock); + return err; + } + err=sock->ops->shutdown(sock, how); sockfd_put(sock); } diff -urN -X dontdiff linux-2.5.42.w0/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.w0/security/capability.c Tue Oct 15 20:35:19 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 20:40:57 2002 @@ -750,6 +750,97 @@ return; } +static int cap_socket_create (int family, int type, int protocol) +{ + return 0; +} + +static void cap_socket_post_create (struct socket *sock, int family, int type, + int protocol) +{ + return; +} + +static int cap_socket_bind (struct socket *sock, struct sockaddr *address, + int addrlen) +{ + return 0; +} + +static int cap_socket_connect (struct socket *sock, struct sockaddr *address, + int addrlen) +{ + return 0; +} + +static int cap_socket_listen (struct socket *sock, int backlog) +{ + return 0; +} + +static int cap_socket_accept (struct socket *sock, struct socket *newsock) +{ + return 0; +} + +static void cap_socket_post_accept (struct socket *sock, + struct socket *newsock) +{ + return; +} + +static int cap_socket_sendmsg (struct socket *sock, struct msghdr *msg, + int size) +{ + return 0; +} + +static int cap_socket_recvmsg (struct socket *sock, struct msghdr *msg, + int size, int flags) +{ + return 0; +} + +static int cap_socket_getsockname (struct socket *sock) +{ + return 0; +} + +static int cap_socket_getpeername (struct socket *sock) +{ + return 0; +} + +static int cap_socket_setsockopt (struct socket *sock, int level, int optname) +{ + return 0; +} + +static int cap_socket_getsockopt (struct socket *sock, int level, int optname) +{ + return 0; +} + +static int cap_socket_shutdown (struct socket *sock, int how) +{ + return 0; +} + +static int cap_socket_sock_alloc_security(struct sock *sk, int gfp_mask) +{ + return 0; +} + +static void cap_socket_sock_free_security(struct sock *sk) +{ + return; +} + +static int cap_socket_sock_rcv_skb (struct sock *sk, struct sk_buff *skb) +{ + return 0; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -860,6 +951,24 @@ .skb_recv_datagram = cap_skb_recv_datagram, .skb_free_security = cap_skb_free_security, + .socket_create = cap_socket_create, + .socket_post_create = cap_socket_post_create, + .socket_bind = cap_socket_bind, + .socket_connect = cap_socket_connect, + .socket_listen = cap_socket_listen, + .socket_accept = cap_socket_accept, + .socket_post_accept = cap_socket_post_accept, + .socket_sendmsg = cap_socket_sendmsg, + .socket_recvmsg = cap_socket_recvmsg, + .socket_getsockname = cap_socket_getsockname, + .socket_getpeername = cap_socket_getpeername, + .socket_getsockopt = cap_socket_getsockopt, + .socket_setsockopt = cap_socket_setsockopt, + .socket_shutdown = cap_socket_shutdown, + .socket_sock_alloc_security = cap_socket_sock_alloc_security, + .socket_sock_free_security = cap_socket_sock_free_security, + .socket_sock_rcv_skb = cap_socket_sock_rcv_skb, + .ipc_permission = cap_ipc_permission, .msg_queue_alloc_security = cap_msg_queue_alloc_security, diff -urN -X dontdiff linux-2.5.42.w0/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.w0/security/dummy.c Tue Oct 15 20:35:19 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 20:55:06 2002 @@ -567,6 +567,97 @@ return; } +static int dummy_socket_create (int family, int type, int protocol) +{ + return 0; +} + +static void dummy_socket_post_create (struct socket *sock, int family, int type, + int protocol) +{ + return; +} + +static int dummy_socket_bind (struct socket *sock, struct sockaddr *address, + int addrlen) +{ + return 0; +} + +static int dummy_socket_connect (struct socket *sock, struct sockaddr *address, + int addrlen) +{ + return 0; +} + +static int dummy_socket_listen (struct socket *sock, int backlog) +{ + return 0; +} + +static int dummy_socket_accept (struct socket *sock, struct socket *newsock) +{ + return 0; +} + +static void dummy_socket_post_accept (struct socket *sock, + struct socket *newsock) +{ + return; +} + +static int dummy_socket_sendmsg (struct socket *sock, struct msghdr *msg, + int size) +{ + return 0; +} + +static int dummy_socket_recvmsg (struct socket *sock, struct msghdr *msg, + int size, int flags) +{ + return 0; +} + +static int dummy_socket_getsockname (struct socket *sock) +{ + return 0; +} + +static int dummy_socket_getpeername (struct socket *sock) +{ + return 0; +} + +static int dummy_socket_setsockopt (struct socket *sock, int level, int optname) +{ + return 0; +} + +static int dummy_socket_getsockopt (struct socket *sock, int level, int optname) +{ + return 0; +} + +static int dummy_socket_shutdown (struct socket *sock, int how) +{ + return 0; +} + +static int dummy_socket_sock_alloc_security(struct sock *sk, int gfp_mask) +{ + return 0; +} + +static void dummy_socket_sock_free_security(struct sock *sk) +{ + return; +} + +static int dummy_socket_sock_rcv_skb (struct sock *sk, struct sk_buff *skb) +{ + return 0; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -677,6 +768,24 @@ .skb_recv_datagram = dummy_skb_recv_datagram, .skb_free_security = dummy_skb_free_security, + .socket_create = dummy_socket_create, + .socket_post_create = dummy_socket_post_create, + .socket_bind = dummy_socket_bind, + .socket_connect = dummy_socket_connect, + .socket_listen = dummy_socket_listen, + .socket_accept = dummy_socket_accept, + .socket_post_accept = dummy_socket_post_accept, + .socket_sendmsg = dummy_socket_sendmsg, + .socket_recvmsg = dummy_socket_recvmsg, + .socket_getsockname = dummy_socket_getsockname, + .socket_getpeername = dummy_socket_getpeername, + .socket_getsockopt = dummy_socket_getsockopt, + .socket_setsockopt = dummy_socket_setsockopt, + .socket_shutdown = dummy_socket_shutdown, + .socket_sock_alloc_security = dummy_socket_sock_alloc_security, + .socket_sock_free_security = dummy_socket_sock_free_security, + .socket_sock_rcv_skb = dummy_socket_sock_rcv_skb, + .ipc_permission = dummy_ipc_permission, .msg_queue_alloc_security = dummy_msg_queue_alloc_security, From jmorris@intercode.com.au Tue Oct 15 07:39:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:39:12 -0700 (PDT) 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 g9FEd6tG028376 for ; Tue, 15 Oct 2002 07:39:07 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA28071; Wed, 16 Oct 2002 00:38:21 +1000 Date: Wed, 16 Oct 2002 00:38:21 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: ipv4 hooks for 2.5.42 (4/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 705 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 diff -urN -X dontdiff linux-2.5.42.w0/include/linux/ip.h linux-2.5.42.w1/include/linux/ip.h --- linux-2.5.42.w0/include/linux/ip.h Fri Aug 2 07:16:17 2002 +++ linux-2.5.42.w1/include/linux/ip.h Tue Oct 15 20:58:32 2002 @@ -58,6 +58,7 @@ #define IPOPT_SEC (2 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_LSRR (3 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_TIMESTAMP (4 |IPOPT_MEASUREMENT) +#define IPOPT_CIPSO (6 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_RR (7 |IPOPT_CONTROL) #define IPOPT_SID (8 |IPOPT_CONTROL|IPOPT_COPY) #define IPOPT_SSRR (9 |IPOPT_CONTROL|IPOPT_COPY) diff -urN -X dontdiff linux-2.5.42.w0/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.w0/include/linux/security.h Tue Oct 15 20:58:10 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 20:58:32 2002 @@ -794,6 +794,48 @@ * @skb contains the incoming network data. * Return 0 if permission is granted. * + * IPv4 networking hooks. + * + * @ip_fragment: + * This is called for each fragment generated when an outgoing packet is + * being fragmented, and may be used to copy security attributes from the + * original packet to each fragment. + * @newskb contains the newly created fragment. + * @oldskb contains the original packet being fragmented. + * @ip_defragment: + * This hook is called when an incoming fragment is about to be inserted + * into a reassembly queue. It's purpose is to enable the validation of + * security attributes for each fragment. An LSM module using this hook + * will likely need to maintain its own fragment queue information, handle + * fragment expiration and implement DoS countermeasures. + * @skb contains the incoming fragment. + * Returns 0 on success. + * @ip_encapsulate: + * This hook is called when an IP packet is encapsulated, and may be used + * to update security attributes prior to reprocessing via the local_out + * or forward hooks. + * @skb contains the encapsulated packet. + * @ip_decapsulate: + * This hook is called when a packet is decapsulated, and may be used to + * process security attributes at each level of encapsulation. An example + * of this would be keeping track of nested security associations for an + * incoming packet. + * @skb contains the decapsulated packet. + * @ip_decode_options: + * This hook is used for processing IP security options at the network + * layer when labeled networking (e.g. CIPSO) is implemented. + * For outgoing packets, IP options passed down from the application or + * transport layers may be verified here prior the packet being built. + * For incoming packets, IP options may be verified and their values + * recorded via the &sk_buff security blob for later processing. + * @skb contains the &sk_buff containing IP packet (usually NULL for outgoing). + * @optptr contains the &ip_options structure. + * @pp_ptr contains the parameter problem pointer. + * Returns 0 on success. + * A non-zero return value will cause an ICMP parameter problem message to + * be generated and transmitted to the sender. The @pp_ptr parameter may + * be used to point to the offending option parameter. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -1044,6 +1086,14 @@ void (*socket_sock_free_security) (struct sock * sk); int (*socket_sock_rcv_skb) (struct sock * sk, struct sk_buff * skb); + void (*ip_fragment) (struct sk_buff * newskb, + const struct sk_buff * oldskb); + int (*ip_defragment) (struct sk_buff * skb); + void (*ip_encapsulate) (struct sk_buff * skb); + void (*ip_decapsulate) (struct sk_buff * skb); + int (*ip_decode_options) (struct sk_buff * skb, + const char *optptr, unsigned char **pp_ptr); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/ip_fragment.c linux-2.5.42.w1/net/ipv4/ip_fragment.c --- linux-2.5.42.w0/net/ipv4/ip_fragment.c Fri Aug 2 07:16:16 2002 +++ linux-2.5.42.w1/net/ipv4/ip_fragment.c Tue Oct 15 20:58:32 2002 @@ -37,6 +37,7 @@ #include #include #include +#include /* NOTE. Logic of IP defragmentation is parallel to corresponding IPv6 * code now. If you change something here, _PLEASE_ update ipv6/reassembly.c @@ -372,7 +373,11 @@ { struct sk_buff *prev, *next; int flags, offset; - int ihl, end; + int ihl, end, ret; + + ret = security_ops->ip_defragment(skb); + if (ret) + goto err; if (qp->last_in & COMPLETE) goto err; diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/ip_gre.c linux-2.5.42.w1/net/ipv4/ip_gre.c --- linux-2.5.42.w0/net/ipv4/ip_gre.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/ipv4/ip_gre.c Tue Oct 15 20:58:32 2002 @@ -653,6 +653,7 @@ skb->nf_debug = 0; #endif #endif + security_ops->ip_decapsulate(skb); ipgre_ecn_decapsulate(iph, skb); netif_rx(skb); read_unlock(&ipgre_lock); @@ -885,6 +886,7 @@ skb->nf_debug = 0; #endif #endif + security_ops->ip_encapsulate(skb); IPTUNNEL_XMIT(); tunnel->recursion--; diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/ip_options.c linux-2.5.42.w1/net/ipv4/ip_options.c --- linux-2.5.42.w0/net/ipv4/ip_options.c Tue Sep 24 19:22:50 2002 +++ linux-2.5.42.w1/net/ipv4/ip_options.c Tue Oct 15 20:58:32 2002 @@ -433,7 +433,11 @@ opt->router_alert = optptr - iph; break; case IPOPT_SEC: + case IPOPT_CIPSO: case IPOPT_SID: + if (security_ops->ip_decode_options(skb, optptr, &pp_ptr)) + goto error; + break; default: if (!skb && !capable(CAP_NET_RAW)) { pp_ptr = optptr; diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/ip_output.c linux-2.5.42.w1/net/ipv4/ip_output.c --- linux-2.5.42.w0/net/ipv4/ip_output.c Wed Oct 9 22:39:39 2002 +++ linux-2.5.42.w1/net/ipv4/ip_output.c Tue Oct 15 20:58:32 2002 @@ -898,6 +898,7 @@ skb2->nf_debug = skb->nf_debug; #endif #endif + security_ops->ip_fragment(skb2, skb); /* * Put this fragment into the sending queue. diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/ipip.c linux-2.5.42.w1/net/ipv4/ipip.c --- linux-2.5.42.w0/net/ipv4/ipip.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/ipv4/ipip.c Tue Oct 15 20:58:32 2002 @@ -500,6 +500,7 @@ skb->nf_debug = 0; #endif #endif + security_ops->ip_decapsulate(skb); ipip_ecn_decapsulate(iph, skb); netif_rx(skb); read_unlock(&ipip_lock); @@ -652,6 +653,8 @@ #endif #endif + security_ops->ip_encapsulate(skb); + IPTUNNEL_XMIT(); tunnel->recursion--; return 0; diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/ipmr.c linux-2.5.42.w1/net/ipv4/ipmr.c --- linux-2.5.42.w0/net/ipv4/ipmr.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/ipv4/ipmr.c Tue Oct 15 20:58:32 2002 @@ -1105,6 +1105,7 @@ nf_conntrack_put(skb->nfct); skb->nfct = NULL; #endif + security_ops->ip_encapsulate(skb); } static inline int ipmr_forward_finish(struct sk_buff *skb) @@ -1450,6 +1451,7 @@ nf_conntrack_put(skb->nfct); skb->nfct = NULL; #endif + security_ops->ip_decapsulate(skb); netif_rx(skb); dev_put(reg_dev); return 0; @@ -1517,6 +1519,7 @@ nf_conntrack_put(skb->nfct); skb->nfct = NULL; #endif + security_ops->ip_decapsulate(skb); netif_rx(skb); dev_put(reg_dev); return 0; diff -urN -X dontdiff linux-2.5.42.w0/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.w0/security/capability.c Tue Oct 15 20:58:10 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 20:58:32 2002 @@ -841,6 +841,37 @@ return 0; } +static void cap_ip_fragment (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return; +} + +static int cap_ip_defragment (struct sk_buff *skb) +{ + return 0; +} + +static void cap_ip_encapsulate (struct sk_buff *skb) +{ + return; +} + +static void cap_ip_decapsulate (struct sk_buff *skb) +{ + return; +} + +static int cap_ip_decode_options (struct sk_buff *skb, const char *optptr, + unsigned char **pp_ptr) +{ + if (!skb && !capable (CAP_NET_RAW)) { + (const unsigned char *) *pp_ptr = optptr; + return -EPERM; + } + return 0; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -969,6 +1000,12 @@ .socket_sock_free_security = cap_socket_sock_free_security, .socket_sock_rcv_skb = cap_socket_sock_rcv_skb, + .ip_fragment = cap_ip_fragment, + .ip_defragment = cap_ip_defragment, + .ip_encapsulate = cap_ip_encapsulate, + .ip_decapsulate = cap_ip_decapsulate, + .ip_decode_options = cap_ip_decode_options, + .ipc_permission = cap_ipc_permission, .msg_queue_alloc_security = cap_msg_queue_alloc_security, diff -urN -X dontdiff linux-2.5.42.w0/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.w0/security/dummy.c Tue Oct 15 20:58:10 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 20:58:32 2002 @@ -658,6 +658,37 @@ return 0; } +static void dummy_ip_fragment (struct sk_buff *newskb, + const struct sk_buff *oldskb) +{ + return; +} + +static int dummy_ip_defragment (struct sk_buff *skb) +{ + return 0; +} + +static void dummy_ip_decapsulate (struct sk_buff *skb) +{ + return; +} + +static void dummy_ip_encapsulate (struct sk_buff *skb) +{ + return; +} + +static int dummy_ip_decode_options (struct sk_buff *skb, const char *optptr, + unsigned char **pp_ptr) +{ + if (!skb && !capable (CAP_NET_RAW)) { + (const unsigned char *) *pp_ptr = optptr; + return -EPERM; + } + return 0; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -786,6 +817,12 @@ .socket_sock_free_security = dummy_socket_sock_free_security, .socket_sock_rcv_skb = dummy_socket_sock_rcv_skb, + .ip_fragment = dummy_ip_fragment, + .ip_defragment = dummy_ip_defragment, + .ip_encapsulate = dummy_ip_encapsulate, + .ip_decapsulate = dummy_ip_decapsulate, + .ip_decode_options = dummy_ip_decode_options, + .ipc_permission = dummy_ipc_permission, .msg_queue_alloc_security = dummy_msg_queue_alloc_security, From jmorris@intercode.com.au Tue Oct 15 07:40:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:40:21 -0700 (PDT) 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 g9FEeGtG028859 for ; Tue, 15 Oct 2002 07:40:17 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA28107; Wed, 16 Oct 2002 00:39:34 +1000 Date: Wed, 16 Oct 2002 00:39:34 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: netlink hooks for 2.5.42 (5/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 706 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 diff -urN -X dontdiff linux-2.5.42.w0/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.w0/include/linux/security.h Tue Oct 15 21:03:06 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 21:03:31 2002 @@ -836,6 +836,20 @@ * be generated and transmitted to the sender. The @pp_ptr parameter may * be used to point to the offending option parameter. * + * @netlink_send: + * Save security information for a netlink message so that permission + * checking can be performed when the message is processed. The security + * information can either be saved using the existing eff_cap field of the + * netlink_skb_parms structure or it can be saved using the skbuff + * lsm_security field. + * @skb contains the sk_buff structure for the netlink message. + * Return 0 if the information was successfully saved. + * @netlink_recv: + * Check permission before processing the received netlink message in + * @skb. + * @skb contains the sk_buff structure for the netlink message. + * Return 0 if permission is granted. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -1094,6 +1108,9 @@ int (*ip_decode_options) (struct sk_buff * skb, const char *optptr, unsigned char **pp_ptr); + int (*netlink_send) (struct sk_buff * skb); + int (*netlink_recv) (struct sk_buff * skb); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.w0/net/core/rtnetlink.c linux-2.5.42.w1/net/core/rtnetlink.c --- linux-2.5.42.w0/net/core/rtnetlink.c Fri Aug 2 07:17:32 2002 +++ linux-2.5.42.w1/net/core/rtnetlink.c Tue Oct 15 21:03:31 2002 @@ -316,7 +316,7 @@ sz_idx = type>>2; kind = type&3; - if (kind != 2 && !cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN)) { + if (kind != 2 && security_ops->netlink_recv(skb)) { *errp = -EPERM; return -1; } diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/netfilter/ip_queue.c linux-2.5.42.w1/net/ipv4/netfilter/ip_queue.c --- linux-2.5.42.w0/net/ipv4/netfilter/ip_queue.c Sun Aug 11 12:20:40 2002 +++ linux-2.5.42.w1/net/ipv4/netfilter/ip_queue.c Tue Oct 15 21:03:31 2002 @@ -496,7 +496,7 @@ if (type <= IPQM_BASE) return; - if(!cap_raised(NETLINK_CB(skb).eff_cap, CAP_NET_ADMIN)) + if (security_ops->netlink_recv(skb)) RCV_SKB_FAIL(-EPERM); write_lock_bh(&queue_lock); diff -urN -X dontdiff linux-2.5.42.w0/net/netlink/af_netlink.c linux-2.5.42.w1/net/netlink/af_netlink.c --- linux-2.5.42.w0/net/netlink/af_netlink.c Sun Aug 11 12:20:40 2002 +++ linux-2.5.42.w1/net/netlink/af_netlink.c Tue Oct 15 21:03:31 2002 @@ -621,7 +621,12 @@ check them, when this message will be delivered to corresponding kernel module. --ANK (980802) */ - NETLINK_CB(skb).eff_cap = current->cap_effective; + + err = security_ops->netlink_send(skb); + if (err) { + kfree_skb(skb); + goto out; + } err = -EFAULT; if (memcpy_fromiovec(skb_put(skb,len), msg->msg_iov, len)) { diff -urN -X dontdiff linux-2.5.42.w0/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.w0/security/capability.c Tue Oct 15 21:03:06 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 21:03:31 2002 @@ -872,6 +872,19 @@ return 0; } +static int cap_netlink_send (struct sk_buff *skb) +{ + NETLINK_CB (skb).eff_cap = current->cap_effective; + return 0; +} + +static int cap_netlink_recv (struct sk_buff *skb) +{ + if (!cap_raised (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN)) + return -EPERM; + return 0; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -1006,6 +1019,9 @@ .ip_decapsulate = cap_ip_decapsulate, .ip_decode_options = cap_ip_decode_options, + .netlink_send = cap_netlink_send, + .netlink_recv = cap_netlink_recv, + .ipc_permission = cap_ipc_permission, .msg_queue_alloc_security = cap_msg_queue_alloc_security, diff -urN -X dontdiff linux-2.5.42.w0/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.w0/security/dummy.c Tue Oct 15 21:03:06 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 21:03:31 2002 @@ -689,6 +689,22 @@ return 0; } +static int dummy_netlink_send (struct sk_buff *skb) +{ + if (current->euid == 0) + cap_raise (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN); + else + NETLINK_CB (skb).eff_cap = 0; + return 0; +} + +static int dummy_netlink_recv (struct sk_buff *skb) +{ + if (!cap_raised (NETLINK_CB (skb).eff_cap, CAP_NET_ADMIN)) + return -EPERM; + return 0; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -823,6 +839,9 @@ .ip_decapsulate = dummy_ip_decapsulate, .ip_decode_options = dummy_ip_decode_options, + .netlink_send = dummy_netlink_send, + .netlink_recv = dummy_netlink_recv, + .ipc_permission = dummy_ipc_permission, .msg_queue_alloc_security = dummy_msg_queue_alloc_security, From jmorris@intercode.com.au Tue Oct 15 07:41:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:41:21 -0700 (PDT) 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 g9FEfHtG029312 for ; Tue, 15 Oct 2002 07:41:18 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA28152; Wed, 16 Oct 2002 00:40:35 +1000 Date: Wed, 16 Oct 2002 00:40:35 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: af_unix hooks for 2.5.42 (6/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 707 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 diff -urN -X dontdiff linux-2.5.42.w0/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.w0/include/linux/security.h Tue Oct 15 21:10:02 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 21:10:26 2002 @@ -850,6 +850,29 @@ * @skb contains the sk_buff structure for the netlink message. * Return 0 if permission is granted. * + * @unix_stream_connect: + * Check permissions before establishing a Unix domain stream connection + * between @sock and @other. + * @sock contains the socket structure. + * @other contains the peer socket structure. + * Return 0 if permission is granted. + * @unix_may_send: + * Check permissions before connecting or sending datagrams from @sock to + * @other. + * @sock contains the socket structure. + * @sock contains the peer socket structure. + * Return 0 if permission is granted. + * + * The @unix_stream_connect and @unix_may_send hooks were necessary because + * Linux provides an alternative to the conventional file name space for Unix + * domain sockets. Whereas binding and connecting to sockets in the file name + * space is mediated by the typical file permissions (and caught by the mknod + * and permission hooks in inode_security_ops), binding and connecting to + * sockets in the abstract name space is completely unmediated. Sufficient + * control of Unix domain sockets in the abstract name space isn't possible + * using only the socket layer hooks, since we need to know the actual target + * socket, which is not looked up until we are inside the af_unix code. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -1111,6 +1134,10 @@ int (*netlink_send) (struct sk_buff * skb); int (*netlink_recv) (struct sk_buff * skb); + int (*unix_stream_connect) (struct socket * sock, + struct socket * other, struct sock * newsk); + int (*unix_may_send) (struct socket * sock, struct socket * other); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.w0/net/unix/af_unix.c linux-2.5.42.w1/net/unix/af_unix.c --- linux-2.5.42.w0/net/unix/af_unix.c Wed Aug 28 13:24:30 2002 +++ linux-2.5.42.w1/net/unix/af_unix.c Tue Oct 15 21:10:26 2002 @@ -111,6 +111,7 @@ #include #include #include +#include int sysctl_unix_max_dgram_qlen = 10; @@ -812,6 +813,11 @@ err = -EPERM; if (!unix_may_send(sk, other)) goto out_unlock; + + err = security_ops->unix_may_send(sk->socket, other->socket); + if (err) + goto out_unlock; + } else { /* * 1003.1g breaking connected state with AF_UNSPEC @@ -977,6 +983,12 @@ goto restart; } + err = security_ops->unix_stream_connect(sock, other->socket, newsk); + if (err) { + unix_state_wunlock(sk); + goto out_unlock; + } + /* The way is open! Fastly set all the necessary fields... */ sock_hold(sk); @@ -1274,6 +1286,10 @@ if (other->shutdown&RCV_SHUTDOWN) goto out_unlock; + err = security_ops->unix_may_send(sk->socket, other->socket); + if (err) + goto out_unlock; + if (unix_peer(other) != sk && skb_queue_len(&other->receive_queue) > other->max_ack_backlog) { if (!timeo) { diff -urN -X dontdiff linux-2.5.42.w0/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.w0/security/capability.c Tue Oct 15 21:10:02 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 21:10:26 2002 @@ -885,6 +885,18 @@ return 0; } +static int cap_socket_unix_stream_connect (struct socket *sock, + struct socket *other, + struct sock *newsk) +{ + return 0; +} + +static int cap_socket_unix_may_send (struct socket *sock, struct socket *other) +{ + return 0; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -1022,6 +1034,9 @@ .netlink_send = cap_netlink_send, .netlink_recv = cap_netlink_recv, + .unix_stream_connect = cap_socket_unix_stream_connect, + .unix_may_send = cap_socket_unix_may_send, + .ipc_permission = cap_ipc_permission, .msg_queue_alloc_security = cap_msg_queue_alloc_security, diff -urN -X dontdiff linux-2.5.42.w0/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.w0/security/dummy.c Tue Oct 15 21:10:02 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 21:10:26 2002 @@ -705,6 +705,19 @@ return 0; } +static int dummy_socket_unix_stream_connect (struct socket *sock, + struct socket *other, + struct sock *newsk) +{ + return 0; +} + +static int dummy_socket_unix_may_send (struct socket *sock, + struct socket *other) +{ + return 0; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -842,6 +855,9 @@ .netlink_send = dummy_netlink_send, .netlink_recv = dummy_netlink_recv, + .unix_stream_connect = dummy_socket_unix_stream_connect, + .unix_may_send = dummy_socket_unix_may_send, + .ipc_permission = dummy_ipc_permission, .msg_queue_alloc_security = dummy_msg_queue_alloc_security, From jmorris@intercode.com.au Tue Oct 15 07:42:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 07:42:23 -0700 (PDT) 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 g9FEgHtG029823 for ; Tue, 15 Oct 2002 07:42:19 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id AAA28193; Wed, 16 Oct 2002 00:41:35 +1000 Date: Wed, 16 Oct 2002 00:41:35 +1000 (EST) From: James Morris To: "David S. Miller" , cc: netdev@oss.sgi.com, Subject: [PATCH] LSM networking: tcp hooks for 2.5.42 (7/7) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 708 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 diff -urN -X dontdiff linux-2.5.42.w0/include/linux/security.h linux-2.5.42.w1/include/linux/security.h --- linux-2.5.42.w0/include/linux/security.h Tue Oct 15 21:13:49 2002 +++ linux-2.5.42.w1/include/linux/security.h Tue Oct 15 21:21:51 2002 @@ -54,6 +54,7 @@ struct nfsctl_arg; struct sched_param; struct swap_info_struct; +struct open_request; /** * struct security_operations - main security structure @@ -873,6 +874,38 @@ * using only the socket layer hooks, since we need to know the actual target * socket, which is not looked up until we are inside the af_unix code. * + * TCP hooks. + * + * @open_request_alloc_security: + * Allocate the security blob for an open_request structure. The + * req->security field is initialized to NULL when the structure is + * allocated. + * @req Pointer to the open_request structure. + * Return 0 if successful, or -ENOMEM on out of memory condition. + * @open_request_free_security: + * Free the security blob for an open_request structure. + * @req Pointer to the open_request structure. + * @tcp_connection_request: + * A new connection is being requested on a server. This hook allows + * security information to be attached to the new connection request. + * @sk contains the listening sock. + * @skb contains the incoming network packet. + * @req contains the open_request structure. + * @tcp_synack: + * A TCP SYN-ACK packet is being sent out, the second part of the TCP + * three-way handshake for a new connection. + * @sk contains the listening sock. + * @skb contains the outgoing network packet. + * @req contains the open_request structure. + * @tcp_create_openreq_child: + * A new connection is being established on a TCP sock. This hook allows + * the association of security information with the new sock as it is + * being created. + * @sk contains the listening sock. + * @newsk contains the sock associated with the new connection. + * @skb contains the incoming network packet that finalized the connection. + * @req contains the open_request structure. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -1138,6 +1171,16 @@ struct socket * other, struct sock * newsk); int (*unix_may_send) (struct socket * sock, struct socket * other); + int (*open_request_alloc_security) (struct open_request * req); + void (*open_request_free_security) (struct open_request * req); + void (*tcp_connection_request) (struct sock * sk, struct sk_buff * skb, + struct open_request * req); + void (*tcp_synack) (struct sock * sk, struct sk_buff * skb, + struct open_request * req); + void (*tcp_create_openreq_child) (struct sock * sk, struct sock * newsk, + struct sk_buff * skb, + struct open_request * req); + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); int (*msg_queue_alloc_security) (struct msg_queue * msq); diff -urN -X dontdiff linux-2.5.42.w0/include/linux/tcp.h linux-2.5.42.w1/include/linux/tcp.h --- linux-2.5.42.w0/include/linux/tcp.h Sun Sep 1 11:34:46 2002 +++ linux-2.5.42.w1/include/linux/tcp.h Tue Oct 15 21:28:28 2002 @@ -381,4 +381,14 @@ #define tcp_sk(__sk) (&((struct tcp_sock *)__sk)->tcp) +/* + * Save/restore the LSM security pointer around the copy. + */ +static inline void clone_tcp_sk(struct sock *newsk, struct sock *sk) +{ + void *sptr = newsk->security; + memcpy(newsk, sk, sizeof(struct tcp_sock)); + newsk->security = sptr; +} + #endif /* _LINUX_TCP_H */ diff -urN -X dontdiff linux-2.5.42.w0/include/net/tcp.h linux-2.5.42.w1/include/net/tcp.h --- linux-2.5.42.w0/include/net/tcp.h Sat Oct 12 15:09:43 2002 +++ linux-2.5.42.w1/include/net/tcp.h Tue Oct 15 21:14:39 2002 @@ -531,13 +531,33 @@ struct tcp_v6_open_req v6_req; #endif } af; + /* LSM security field */ + void *security; }; /* SLAB cache for open requests. */ extern kmem_cache_t *tcp_openreq_cachep; -#define tcp_openreq_alloc() kmem_cache_alloc(tcp_openreq_cachep, SLAB_ATOMIC) -#define tcp_openreq_fastfree(req) kmem_cache_free(tcp_openreq_cachep, req) +static inline struct open_request *tcp_openreq_alloc(void) +{ + struct open_request *req = + kmem_cache_alloc(tcp_openreq_cachep, SLAB_ATOMIC); + + if (req != NULL) { + req->security = NULL; + if (security_ops->open_request_alloc_security(req)) { + kmem_cache_free(tcp_openreq_cachep, req); + return NULL; + } + } + return req; +} + +static inline void tcp_openreq_fastfree(struct open_request *req) +{ + security_ops->open_request_free_security(req); + kmem_cache_free(tcp_openreq_cachep, req); +} static inline void tcp_openreq_free(struct open_request *req) { diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/syncookies.c linux-2.5.42.w1/net/ipv4/syncookies.c --- linux-2.5.42.w0/net/ipv4/syncookies.c Fri Aug 2 07:16:02 2002 +++ linux-2.5.42.w1/net/ipv4/syncookies.c Tue Oct 15 21:14:39 2002 @@ -181,6 +181,8 @@ goto out; } + security_ops->tcp_connection_request(sk, skb, req); + /* Try to redo what tcp_v4_send_synack did. */ req->window_clamp = rt->u.dst.window; tcp_select_initial_window(tcp_full_space(sk), req->mss, diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/tcp_ipv4.c linux-2.5.42.w1/net/ipv4/tcp_ipv4.c --- linux-2.5.42.w0/net/ipv4/tcp_ipv4.c Tue Oct 15 20:58:10 2002 +++ linux-2.5.42.w1/net/ipv4/tcp_ipv4.c Tue Oct 15 21:14:39 2002 @@ -1302,6 +1302,8 @@ if (skb) { struct tcphdr *th = skb->h.th; + security_ops->tcp_synack(sk, skb, req); + th->check = tcp_v4_check(th, skb->len, req->af.v4_req.loc_addr, req->af.v4_req.rmt_addr, @@ -1518,6 +1520,8 @@ } req->snt_isn = isn; + security_ops->tcp_connection_request(sk, skb, req); + if (tcp_v4_send_synack(sk, req, dst)) goto drop_and_free; diff -urN -X dontdiff linux-2.5.42.w0/net/ipv4/tcp_minisocks.c linux-2.5.42.w1/net/ipv4/tcp_minisocks.c --- linux-2.5.42.w0/net/ipv4/tcp_minisocks.c Sat Oct 12 15:09:44 2002 +++ linux-2.5.42.w1/net/ipv4/tcp_minisocks.c Tue Oct 15 21:29:19 2002 @@ -652,7 +652,7 @@ struct sk_filter *filter; #endif - memcpy(newsk, sk, sizeof(struct tcp_sock)); + clone_tcp_sk(newsk, sk); newsk->state = TCP_SYN_RECV; /* SANITY */ @@ -789,6 +789,7 @@ newsk->no_largesend = 1; TCP_INC_STATS_BH(TcpPassiveOpens); + security_ops->tcp_create_openreq_child(sk, newsk, skb, req); } return newsk; } diff -urN -X dontdiff linux-2.5.42.w0/security/capability.c linux-2.5.42.w1/security/capability.c --- linux-2.5.42.w0/security/capability.c Tue Oct 15 21:13:49 2002 +++ linux-2.5.42.w1/security/capability.c Tue Oct 15 21:25:05 2002 @@ -897,6 +897,35 @@ return 0; } +static int cap_open_request_alloc_security(struct open_request * req) +{ + return 0; +} + +static void cap_open_request_free_security(struct open_request * req) +{ + return; +} + +static void cap_tcp_connection_request(struct sock *sk, struct sk_buff * skb, + struct open_request *req) +{ + return; +} + +static void cap_tcp_synack(struct sock *sk, struct sk_buff * skb, + struct open_request *req) +{ + return; +} + +static void cap_tcp_create_openreq_child(struct sock *sk, struct sock *newsk, + struct sk_buff *skb, + struct open_request *req) +{ + return; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -1037,6 +1066,12 @@ .unix_stream_connect = cap_socket_unix_stream_connect, .unix_may_send = cap_socket_unix_may_send, + .open_request_alloc_security = cap_open_request_alloc_security, + .open_request_free_security = cap_open_request_free_security, + .tcp_connection_request = cap_tcp_connection_request, + .tcp_synack = cap_tcp_synack, + .tcp_create_openreq_child = cap_tcp_create_openreq_child, + .ipc_permission = cap_ipc_permission, .msg_queue_alloc_security = cap_msg_queue_alloc_security, diff -urN -X dontdiff linux-2.5.42.w0/security/dummy.c linux-2.5.42.w1/security/dummy.c --- linux-2.5.42.w0/security/dummy.c Tue Oct 15 21:13:49 2002 +++ linux-2.5.42.w1/security/dummy.c Tue Oct 15 21:27:24 2002 @@ -718,6 +718,35 @@ return 0; } +static int dummy_open_request_alloc_security(struct open_request * req) +{ + return 0; +} + +static void dummy_open_request_free_security(struct open_request * req) +{ + return; +} + +static void dummy_tcp_connection_request(struct sock *sk, struct sk_buff * skb, + struct open_request *req) +{ + return; +} + +static void dummy_tcp_synack(struct sock *sk, struct sk_buff * skb, + struct open_request *req) +{ + return; +} + +static void dummy_tcp_create_openreq_child(struct sock *sk, struct sock *newsk, + struct sk_buff *skb, + struct open_request *req) +{ + return; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -858,6 +887,12 @@ .unix_stream_connect = dummy_socket_unix_stream_connect, .unix_may_send = dummy_socket_unix_may_send, + .open_request_alloc_security = dummy_open_request_alloc_security, + .open_request_free_security = dummy_open_request_free_security, + .tcp_connection_request = dummy_tcp_connection_request, + .tcp_synack = dummy_tcp_synack, + .tcp_create_openreq_child = dummy_tcp_create_openreq_child, + .ipc_permission = dummy_ipc_permission, .msg_queue_alloc_security = dummy_msg_queue_alloc_security, From davem@redhat.com Tue Oct 15 10:48:08 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 10:48:11 -0700 (PDT) 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 g9FHm8tG024113 for ; Tue, 15 Oct 2002 10:48:08 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA08084; Tue, 15 Oct 2002 10:40:14 -0700 Date: Tue, 15 Oct 2002 10:40:14 -0700 (PDT) Message-Id: <20021015.104014.34145167.davem@redhat.com> To: jmorris@intercode.com.au Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) 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: 709 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 There is no way in hell that you are going to add a function call for every time we set the socket owner of a SKB. That is a critical path and it happens millions upon millions of times a second on a busy server. Performance will be penalized by changes like this. I want all this junk #ifdef'd if it is necessary, in particular the new member added to sk_buff et al. There is no way this stuff is going to happen in the default build, at least not in my networking tree :-) From davem@redhat.com Tue Oct 15 10:49:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 10:49:33 -0700 (PDT) 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 g9FHnVtG024435 for ; Tue, 15 Oct 2002 10:49:31 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA08139; Tue, 15 Oct 2002 10:41:46 -0700 Date: Tue, 15 Oct 2002 10:41:46 -0700 (PDT) Message-Id: <20021015.104146.112719962.davem@redhat.com> To: jmorris@intercode.com.au Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: tcp hooks for 2.5.42 (7/7) 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: 710 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 I totally reject all of these LSM networking patches. The more I read of them the more I hate them. You have to hide this stuff away so that: 1) I don't read it when I read the normal networking code 2) It doesn't get built into my tree because there is no way we're going to add all of these nop function calls all over the stack in the most critical of places From becker@scyld.com Tue Oct 15 11:15:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 11:15:18 -0700 (PDT) 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 g9FIFGtG028893 for ; Tue, 15 Oct 2002 11:15:16 -0700 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id g9FIE2I29874; Tue, 15 Oct 2002 14:14:02 -0400 Date: Tue, 15 Oct 2002 14:14:01 -0400 (EDT) From: Donald Becker To: "David S. Miller" cc: jmorris@intercode.com.au, , , Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) In-Reply-To: <20021015.104014.34145167.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 711 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 Tue, 15 Oct 2002, David S. Miller wrote: > That is a critical path and it happens millions upon > millions of times a second on a busy server. Performance > will be penalized by changes like this. This is a good place to point out why this patch is bogus. The topic is adding "hooks". The proposed method always calls a function, which must exist. The default function is a no-op. This is just about the worst way of doing things. - It is optimizing for the unlikely and already expensive case where there is a hook. - It makes the code difficult to follow - It has horrible code path and cache footprint behavior. - Your method adds a bunch of hooks when just one would do. The usual approach is if (obj->hookfun) obj->hookfun(obj, method_index, other_params); Even this makes the code less readable, but at least doesn't jump all over the instruction space. The impact is a dereference and a test for zero, and then a jump over a push/mov instructions for values that should already be in registers. > There is no way in hell that you are going to > add a function call for every time we set the > socket owner of a SKB. I already bitch about how cost and cache impact of allocating and manipulating skbuffs. This definitely falls into the category of "adding more junk". -- 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 greg@kroah.com Tue Oct 15 12:16:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 12:16:25 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FJGMtG003793 for ; Tue, 15 Oct 2002 12:16:22 -0700 Received: (qmail 15679 invoked by uid 500); 15 Oct 2002 19:16:26 -0000 Date: Tue, 15 Oct 2002 12:16:26 -0700 From: Greg KH To: Donald Becker Cc: "David S. Miller" , jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Message-ID: <20021015191626.GD15420@kroah.com> References: <20021015.104014.34145167.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 02:14:01PM -0400, Donald Becker wrote: > - Your method adds a bunch of hooks when just one would do. How would you propose a single hook? Specify the action in the hook? Linus has already rejected this idea :) > The usual approach is > if (obj->hookfun) obj->hookfun(obj, method_index, other_params); > > Even this makes the code less readable, but at least doesn't jump all > over the instruction space. The impact is a dereference and a test for > zero, and then a jump over a push/mov instructions for values that > should already be in registers. Linus has stated that he didn't want the check and then jump, but an unconditional jump (even if the function is nothing but a return.) I guess this is faster as the processor doesn't have to guess at branch prediction. That's why we built these calls in this way. That being said, a number of people have asked that the networking hooks be able to "be compiled away", so we will be glad to do this. thanks, greg k-h From davem@redhat.com Tue Oct 15 12:43:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 12:43:30 -0700 (PDT) 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 g9FJhRtG006491 for ; Tue, 15 Oct 2002 12:43:28 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id MAA10355; Tue, 15 Oct 2002 12:34:44 -0700 Date: Tue, 15 Oct 2002 12:34:43 -0700 (PDT) Message-Id: <20021015.123443.62397799.davem@redhat.com> To: greg@kroah.com Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) From: "David S. Miller" In-Reply-To: <20021015191626.GD15420@kroah.com> References: <20021015.104014.34145167.davem@redhat.com> <20021015191626.GD15420@kroah.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: 713 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: Greg KH Date: Tue, 15 Oct 2002 12:16:26 -0700 That being said, a number of people have asked that the networking hooks be able to "be compiled away", so we will be glad to do this. That's the only big beef I have with the LSM stuff, on a whole. I want to be able to say CONFIG_SECURITY=n and all of this stuff totally disappears. So use macros that expand to the security_ops->foo() when it's enabled, and compile into do { } while (0) when it is disabled. And yes, as much as the LSM folks may hate it, I want distribution makes to be able to turn this stuff off at their discretion as well. Some may decide that supporting a mechanism like this in their kernel is just too much. From greg@kroah.com Tue Oct 15 12:45:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 12:45:44 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FJjftG007003 for ; Tue, 15 Oct 2002 12:45:42 -0700 Received: (qmail 15998 invoked by uid 500); 15 Oct 2002 19:45:45 -0000 Date: Tue, 15 Oct 2002 12:45:45 -0700 From: Greg KH To: "David S. Miller" Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Message-ID: <20021015194545.GC15864@kroah.com> References: <20021015.104014.34145167.davem@redhat.com> <20021015191626.GD15420@kroah.com> <20021015.123443.62397799.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015.123443.62397799.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 12:34:43PM -0700, David S. Miller wrote: > From: Greg KH > Date: Tue, 15 Oct 2002 12:16:26 -0700 > > That being said, a number of people have asked that the networking hooks > be able to "be compiled away", so we will be glad to do this. > > That's the only big beef I have with the LSM stuff, > on a whole. > > I want to be able to say CONFIG_SECURITY=n and all of > this stuff totally disappears. So use macros that expand > to the security_ops->foo() when it's enabled, and compile > into do { } while (0) when it is disabled. Fair enough, mind if I create a CONFIG_SECURITY_NETWORK that we can use for this? The other LSM hooks seem to be working just fine compiled in, but I can understand the network speed issues. thanks, greg k-h From davem@redhat.com Tue Oct 15 12:53:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 12:53:48 -0700 (PDT) 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 g9FJrjtG008122 for ; Tue, 15 Oct 2002 12:53:46 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id MAA10584; Tue, 15 Oct 2002 12:45:03 -0700 Date: Tue, 15 Oct 2002 12:45:02 -0700 (PDT) Message-Id: <20021015.124502.130514745.davem@redhat.com> To: greg@kroah.com Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) From: "David S. Miller" In-Reply-To: <20021015194545.GC15864@kroah.com> References: <20021015191626.GD15420@kroah.com> <20021015.123443.62397799.davem@redhat.com> <20021015194545.GC15864@kroah.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: 715 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: Greg KH Date: Tue, 15 Oct 2002 12:45:45 -0700 Fair enough, mind if I create a CONFIG_SECURITY_NETWORK that we can use for this? Why special case networking? Do it for everything. 2.5.x can use all the help it can get in the debloating department. It's currently busting at the seams. security/*.o takes up space in my kernel and achieves ABSOLUTELY NOTHING but take up space, the same goes for all the security_ops->() invocations all over the place. You must allow the user to config this stuff out of their tree. From greg@kroah.com Tue Oct 15 13:12:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 13:12:09 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FKC6tG010404 for ; Tue, 15 Oct 2002 13:12:06 -0700 Received: (qmail 16206 invoked by uid 500); 15 Oct 2002 20:12:09 -0000 Date: Tue, 15 Oct 2002 13:12:09 -0700 From: Greg KH To: "David S. Miller" Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Message-ID: <20021015201209.GE15864@kroah.com> References: <20021015191626.GD15420@kroah.com> <20021015.123443.62397799.davem@redhat.com> <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015.124502.130514745.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 12:45:02PM -0700, David S. Miller wrote: > From: Greg KH > Date: Tue, 15 Oct 2002 12:45:45 -0700 > > Fair enough, mind if I create a CONFIG_SECURITY_NETWORK that we can use > for this? > > Why special case networking? Do it for everything. > > 2.5.x can use all the help it can get in the debloating > department. It's currently busting at the seams. > > security/*.o takes up space in my kernel and achieves ABSOLUTELY > NOTHING but take up space, the same goes for all the security_ops->() > invocations all over the place. Those invocations also take up no measurable time :) Yes, the size of the *.o files in the security directory can be shrunk a bit: text data bss dec hex filename 6765 776 8 7549 1d7d built-in.o 3280 392 4 3676 e5c capability.o 1772 384 0 2156 86c dummy.o 1713 0 4 1717 6b5 security.o The majority of this size is the multiple "NULL" hook functions. The developers have had a few ideas on how to fix this issue, and will be worked on. I can also shrink security.o by fixing a function that doesn't need to be inlined. But most of the logic in capability.o previously used to be in kernel/capability.c, and that file has shrunk a bit. > You must allow the user to config this stuff out of their tree. No, I only think the network stuff should be allowed to be compiled away, not the other hooks (ipc and vfs). We will work on this, and submit a network patch that is able to be compiled away. BTW, is the existing security value in struct skbuff used for anything? I see where it is set to zero, and then copied a few times, but never set. Am I missing something? thanks, greg k-h From davem@redhat.com Tue Oct 15 13:19:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 13:19:29 -0700 (PDT) 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 g9FKJMtG011494 for ; Tue, 15 Oct 2002 13:19:23 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id NAA10818; Tue, 15 Oct 2002 13:10:38 -0700 Date: Tue, 15 Oct 2002 13:10:37 -0700 (PDT) Message-Id: <20021015.131037.96602290.davem@redhat.com> To: greg@kroah.com Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) From: "David S. Miller" In-Reply-To: <20021015201209.GE15864@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.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: 717 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: Greg KH Date: Tue, 15 Oct 2002 13:12:09 -0700 Those invocations also take up no measurable time :) I simply don't care. They take up space in my kernel. Yes, the size of the *.o files in the security directory can be shrunk a bit: text data bss dec hex filename 6765 776 8 7549 1d7d built-in.o 3280 392 4 3676 e5c capability.o 1772 384 0 2156 86c dummy.o 1713 0 4 1717 6b5 security.o It's a whopping 32K on sparc64, and that is only counting the security/*.o objects. Have you added up the text taken up comparing having the security_ops->foo() stuff there and having it removed in the rest of the entire tree? Have you considered the different register and stack allocations and code generations differences that occur because this nop function call invocation is there? It is not FREE, it has overhead, and this is a fact. I'm so surprised the embedded people aren't all over this. If I was an embedded person, CONFIG_SECURITY=n would be one of the top things on my list. > You must allow the user to config this stuff out of their tree. No, I only think the network stuff should be allowed to be compiled away, not the other hooks (ipc and vfs). I totally disagree, CONFIG_SECURITY=n is mandatory. If you don't work on this change, then I will get someone else to do it. I will not even look at the networking LSM bits until CONFIG_SECURITY=n is available. From greg@kroah.com Tue Oct 15 13:28:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 13:28:27 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FKSOtG012787 for ; Tue, 15 Oct 2002 13:28:25 -0700 Received: (qmail 16338 invoked by uid 500); 15 Oct 2002 20:28:28 -0000 Date: Tue, 15 Oct 2002 13:28:28 -0700 From: Greg KH To: "David S. Miller" Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Message-ID: <20021015202828.GG15864@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015.131037.96602290.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 01:10:37PM -0700, David S. Miller wrote: > > I will not even look at the networking LSM bits until > CONFIG_SECURITY=n is available. Good enough reason for me, I'll start working on this. Help from the other LSM developers is appreciated :) thanks, greg k-h From davem@redhat.com Tue Oct 15 13:32:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 13:33:00 -0700 (PDT) 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 g9FKWwtG013635 for ; Tue, 15 Oct 2002 13:32:58 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id NAA11167; Tue, 15 Oct 2002 13:24:14 -0700 Date: Tue, 15 Oct 2002 13:24:14 -0700 (PDT) Message-Id: <20021015.132414.43181324.davem@redhat.com> To: greg@kroah.com Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) From: "David S. Miller" In-Reply-To: <20021015202828.GG15864@kroah.com> References: <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.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: 719 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: Greg KH Date: Tue, 15 Oct 2002 13:28:28 -0700 Good enough reason for me, I'll start working on this. Help from the other LSM developers is appreciated :) Thank you. :-) From linux-netdev@gmane.org Tue Oct 15 16:53:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 16:53:24 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9FNrKtG003244 for ; Tue, 15 Oct 2002 16:53:21 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 181bUF-0004n4-00 for ; Wed, 16 Oct 2002 01:52:31 +0200 To: netdev@oss.sgi.com X-Injected-Via-Gmane: http://gmane.org/ Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 181bUE-0004mu-00 for ; Wed, 16 Oct 2002 01:52:30 +0200 Path: not-for-mail From: Jason Lunz Subject: cheap 4-port tulip-based cards available Date: Tue, 15 Oct 2002 23:52:30 +0000 (UTC) Organization: PBR Streetgang Lines: 25 Message-ID: NNTP-Posting-Host: dsl-65-188-226-101.telocity.com X-Trace: main.gmane.org 1034725950 14298 65.188.226.101 (15 Oct 2002 23:52:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 15 Oct 2002 23:52:30 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev I figure a few people on this list will be interested in this: http://www.softwareandstuff.com/h_comp_inet4.html The site says almost nothing about the cards, but on a tip from a coworker I bought one the last time this site had them for sale, and have been extremely happy with it. lspci shows: 02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 02:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 02:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) This card is similar to the d-link 570-TX, though it actually seems to be of higher quality when you have it in hand. Rumor has it that a bunch of these cards were made for a dot-bomb company and they're now just surplus. anyway, knowing the problems people are having with the sundance 580-TX and the unavailability of other cheap 4-port nic options, i though I'd let folks here know. A good 4-port tulip card for $30 is a nice deal. sorry for the spam. Jason From greg@kroah.com Tue Oct 15 17:07:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 17:07:07 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G074tG004940 for ; Tue, 15 Oct 2002 17:07:04 -0700 Received: (qmail 18140 invoked by uid 500); 16 Oct 2002 00:07:06 -0000 Date: Tue, 15 Oct 2002 17:07:06 -0700 From: Greg KH To: "David S. Miller" Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: [RFC] change format of LSM hooks Message-ID: <20021016000706.GI16966@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015202828.GG15864@kroah.com> User-Agent: Mutt/1.4i X-archive-position: 721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 01:28:28PM -0700, Greg KH wrote: > On Tue, Oct 15, 2002 at 01:10:37PM -0700, David S. Miller wrote: > > > > I will not even look at the networking LSM bits until > > CONFIG_SECURITY=n is available. > > Good enough reason for me, I'll start working on this. Help from the > other LSM developers is appreciated :) Ok, this wasn't that tough... Here's a first cut at what will need to be changed. It's a patch against Linus's latest BK tree. I only converted one hook (the ptrace one), and this will not link, but will build and gives people an idea of where I'm heading. David, does something like this look acceptable? With it, and CONFIG_SECURITY=n the size of the security/*.o files are now: text data bss dec hex filename 138 0 0 138 8a security/built-in.o which I hope are a bit more to your liking :) I still need an empty sys_security stub in order to link properly, that's the only function needed. The extra #includes are needed as some files were getting security.h picked up from shed.h in the past. I'll work on fixing up the rest of the hooks, and removing the external reference to security_ops, and actually test this thing, later this evening. thanks, greg k-h diff -Naur -X ../dontdiff bleeding_edge-2.5/arch/i386/kernel/ptrace.c lsm-2.5/arch/i386/kernel/ptrace.c --- bleeding_edge-2.5/arch/i386/kernel/ptrace.c Tue Oct 15 16:47:14 2002 +++ lsm-2.5/arch/i386/kernel/ptrace.c Tue Oct 15 16:41:44 2002 @@ -160,8 +160,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; diff -Naur -X ../dontdiff bleeding_edge-2.5/drivers/base/fs/class.c lsm-2.5/drivers/base/fs/class.c --- bleeding_edge-2.5/drivers/base/fs/class.c Tue Oct 15 16:47:37 2002 +++ lsm-2.5/drivers/base/fs/class.c Tue Oct 15 16:13:11 2002 @@ -7,6 +7,8 @@ #include #include #include +#include +#include #include "fs.h" static struct driver_dir_entry class_dir; diff -Naur -X ../dontdiff bleeding_edge-2.5/drivers/base/fs/intf.c lsm-2.5/drivers/base/fs/intf.c --- bleeding_edge-2.5/drivers/base/fs/intf.c Tue Oct 15 16:47:37 2002 +++ lsm-2.5/drivers/base/fs/intf.c Tue Oct 15 16:14:27 2002 @@ -4,6 +4,8 @@ #include #include +#include +#include #include "fs.h" /** diff -Naur -X ../dontdiff bleeding_edge-2.5/fs/exec.c lsm-2.5/fs/exec.c --- bleeding_edge-2.5/fs/exec.c Tue Oct 15 16:48:19 2002 +++ lsm-2.5/fs/exec.c Tue Oct 15 16:09:05 2002 @@ -43,6 +43,7 @@ #include #include #include +#include #include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/fs/locks.c lsm-2.5/fs/locks.c --- bleeding_edge-2.5/fs/locks.c Tue Oct 15 16:48:19 2002 +++ lsm-2.5/fs/locks.c Tue Oct 15 16:10:52 2002 @@ -122,6 +122,7 @@ #include #include #include +#include #include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/fs/namespace.c lsm-2.5/fs/namespace.c --- bleeding_edge-2.5/fs/namespace.c Tue Oct 15 16:48:19 2002 +++ lsm-2.5/fs/namespace.c Tue Oct 15 16:12:00 2002 @@ -19,6 +19,7 @@ #include #include #include +#include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/fs/proc/base.c lsm-2.5/fs/proc/base.c --- bleeding_edge-2.5/fs/proc/base.c Tue Oct 15 16:48:26 2002 +++ lsm-2.5/fs/proc/base.c Tue Oct 15 16:21:45 2002 @@ -28,6 +28,7 @@ #include #include #include +#include /* * For hysterical raisins we keep the same inumbers as in the old procfs. diff -Naur -X ../dontdiff bleeding_edge-2.5/fs/readdir.c lsm-2.5/fs/readdir.c --- bleeding_edge-2.5/fs/readdir.c Tue Oct 15 16:48:19 2002 +++ lsm-2.5/fs/readdir.c Tue Oct 15 16:09:51 2002 @@ -11,6 +11,7 @@ #include #include #include +#include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/fs/xattr.c lsm-2.5/fs/xattr.c --- bleeding_edge-2.5/fs/xattr.c Tue Oct 15 16:48:19 2002 +++ lsm-2.5/fs/xattr.c Tue Oct 15 16:13:59 2002 @@ -13,6 +13,7 @@ #include #include #include +#include #include /* diff -Naur -X ../dontdiff bleeding_edge-2.5/include/linux/sched.h lsm-2.5/include/linux/sched.h --- bleeding_edge-2.5/include/linux/sched.h Tue Oct 15 16:48:49 2002 +++ lsm-2.5/include/linux/sched.h Tue Oct 15 15:59:24 2002 @@ -600,9 +600,11 @@ unsigned long, const char *, void *); extern void free_irq(unsigned int, void *); + +#ifdef CONFIG_SECURITY /* capable prototype and code moved to security.[hc] */ #include -#if 0 +#else static inline int capable(int cap) { if (cap_raised(current->cap_effective, cap)) { @@ -611,7 +613,7 @@ } return 0; } -#endif /* if 0 */ +#endif /* * Routines for handling mm_structs diff -Naur -X ../dontdiff bleeding_edge-2.5/include/linux/security.h lsm-2.5/include/linux/security.h --- bleeding_edge-2.5/include/linux/security.h Wed Oct 9 08:51:48 2002 +++ lsm-2.5/include/linux/security.h Tue Oct 15 16:40:09 2002 @@ -22,8 +22,6 @@ #ifndef __LINUX_SECURITY_H #define __LINUX_SECURITY_H -#ifdef __KERNEL__ - #include #include #include @@ -33,6 +31,7 @@ #include #include + /* * Values used in the task_security_ops calls */ @@ -848,6 +847,16 @@ struct security_operations *ops); }; +#ifdef CONFIG_SECURITY + +/* global variables */ +extern struct security_operations *security_ops; + +/* inline stuff */ +static inline int security_ptrace (struct task_struct * parent, struct task_struct * child) +{ + return security_ops->ptrace (parent, child); +} /* prototypes */ extern int security_scaffolding_startup (void); @@ -857,11 +866,17 @@ extern int mod_unreg_security (const char *name, struct security_operations *ops); extern int capable (int cap); -/* global variables */ + +#endif /* CONFIG_SECURITY */ + +static inline int security_scaffolding_startup (void) { return 0; } extern struct security_operations *security_ops; +static inline int security_ptrace (struct task_struct *parent, struct task_struct * child) +{ + return 0; +} -#endif /* __KERNEL__ */ #endif /* ! __LINUX_SECURITY_H */ diff -Naur -X ../dontdiff bleeding_edge-2.5/init/do_mounts.c lsm-2.5/init/do_mounts.c --- bleeding_edge-2.5/init/do_mounts.c Mon Oct 7 13:46:56 2002 +++ lsm-2.5/init/do_mounts.c Tue Oct 15 16:05:18 2002 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/kernel/capability.c lsm-2.5/kernel/capability.c --- bleeding_edge-2.5/kernel/capability.c Tue Oct 15 16:48:52 2002 +++ lsm-2.5/kernel/capability.c Tue Oct 15 16:08:08 2002 @@ -8,6 +8,7 @@ */ #include +#include #include unsigned securebits = SECUREBITS_DEFAULT; /* systemwide security settings */ diff -Naur -X ../dontdiff bleeding_edge-2.5/kernel/kmod.c lsm-2.5/kernel/kmod.c --- bleeding_edge-2.5/kernel/kmod.c Tue Oct 15 16:48:52 2002 +++ lsm-2.5/kernel/kmod.c Tue Oct 15 16:10:50 2002 @@ -29,6 +29,7 @@ #include #include #include +#include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/kernel/ptrace.c lsm-2.5/kernel/ptrace.c --- bleeding_edge-2.5/kernel/ptrace.c Tue Oct 15 16:48:52 2002 +++ lsm-2.5/kernel/ptrace.c Tue Oct 15 16:09:07 2002 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/kernel/signal.c lsm-2.5/kernel/signal.c --- bleeding_edge-2.5/kernel/signal.c Tue Oct 15 16:48:52 2002 +++ lsm-2.5/kernel/signal.c Tue Oct 15 16:09:55 2002 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include diff -Naur -X ../dontdiff bleeding_edge-2.5/security/Config.in lsm-2.5/security/Config.in --- bleeding_edge-2.5/security/Config.in Tue Oct 15 16:49:00 2002 +++ lsm-2.5/security/Config.in Tue Oct 15 15:41:13 2002 @@ -3,5 +3,8 @@ # mainmenu_option next_comment comment 'Security options' -define_bool CONFIG_SECURITY_CAPABILITIES y +bool 'Enable different security models' CONFIG_SECURITY +if [ "$CONFIG_SECURITY" = "y" ]; then + dep_tristate ' Default Linux Capabilities' CONFIG_SECURITY_CAPABILITIES $CONFIG_SECURITY +fi endmenu diff -Naur -X ../dontdiff bleeding_edge-2.5/security/Makefile lsm-2.5/security/Makefile --- bleeding_edge-2.5/security/Makefile Tue Oct 15 16:49:00 2002 +++ lsm-2.5/security/Makefile Tue Oct 15 16:34:21 2002 @@ -6,8 +6,8 @@ export-objs := security.o # Object file lists -obj-y := security.o dummy.o - +obj-y += sys_security.o +obj-$(CONFIG_SECURITY) += security.o dummy.o obj-$(CONFIG_SECURITY_CAPABILITIES) += capability.o include $(TOPDIR)/Rules.make diff -Naur -X ../dontdiff bleeding_edge-2.5/security/sys_security.c lsm-2.5/security/sys_security.c --- bleeding_edge-2.5/security/sys_security.c Wed Dec 31 16:00:00 1969 +++ lsm-2.5/security/sys_security.c Tue Oct 15 16:34:03 2002 @@ -0,0 +1,45 @@ +/* + * Security plug functions + * + * Copyright (C) 2001 WireX Communications, Inc + * Copyright (C) 2001 Greg Kroah-Hartman + * Copyright (C) 2001 Networks Associates Technology, Inc + * + * 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 + +/** + * sys_security - security syscall multiplexor. + * @id: module id + * @call: call identifier + * @args: arg list for call + * + * Similar to sys_socketcall. Can use id to help identify which module user + * app is talking to. The recommended convention for creating the + * hexadecimal id value is: + * 'echo "Name_of_module" | md5sum | cut -c -8'. + * By following this convention, there's no need for a central registry. + */ +#ifdef CONFIG_SECURITY +asmlinkage long sys_security (unsigned int id, unsigned int call, + unsigned long *args) +{ + return security_ops->sys_security (id, call, args); +} +#else +asmlinkage long sys_security (unsigned int id, unsigned int call, + unsigned long *args) +{ + return -ENOSYS; +} +#endif + From davem@redhat.com Tue Oct 15 17:11:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 17:11:54 -0700 (PDT) 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 g9G0BqtG005737 for ; Tue, 15 Oct 2002 17:11:52 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA13453; Tue, 15 Oct 2002 17:03:07 -0700 Date: Tue, 15 Oct 2002 17:03:06 -0700 (PDT) Message-Id: <20021015.170306.46455933.davem@redhat.com> To: greg@kroah.com Cc: becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks From: "David S. Miller" In-Reply-To: <20021016000706.GI16966@kroah.com> References: <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.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: 722 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: Greg KH Date: Tue, 15 Oct 2002 17:07:06 -0700 David, does something like this look acceptable? Yes. which I hope are a bit more to your liking :) It is :-) The extra #includes are needed as some files were getting security.h picked up from shed.h in the past. Ok, I was about to ask about that. Franks a lot, David S. Miller davem@redhat.com From hadi@cyberus.ca Tue Oct 15 19:56:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 19:57:06 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G2uwtG017827 for ; Tue, 15 Oct 2002 19:56:58 -0700 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 WAA08916; Tue, 15 Oct 2002 22:56:57 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9G2nai03267; Tue, 15 Oct 2002 22:49:37 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 15 Oct 2002 22:49:36 -0400 (EDT) From: jamal To: Stefan Rompf cc: Subject: Re: Patch: Idea for RFC2863 conform OperStatus In-Reply-To: <3DABE5A2.71542192@isg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 723 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, 15 Oct 2002, Stefan Rompf wrote: > Hi Jamal, > > attached is the latest version of the patch. Changes: > > -Try to use a static struct lw_event for an event. For systems without > slave devices, this will avoid memory allocation in most cases. But, > adding code and data it permanently takes as much memory as about ten of > the additional pointers you didn't want to have in the net_device > structure ;-) > That lw_event is still bothering me ;-> But i dont wanna push it any further ;-> I think we got some good stuff. Dave and Alexey should make the call now. cheers, jamal From rgooch@vindaloo.ras.ucalgary.ca Tue Oct 15 21:29:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 21:30:26 -0700 (PDT) Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G4TwtG023737 for ; Tue, 15 Oct 2002 21:29:58 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g9G4Tnn14232; Tue, 15 Oct 2002 22:29:49 -0600 Date: Tue, 15 Oct 2002 22:29:49 -0600 Message-Id: <200210160429.g9G4Tnn14232@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Jason Lunz Cc: netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available In-Reply-To: References: X-archive-position: 724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgooch@ras.ucalgary.ca Precedence: bulk X-list: netdev Jason Lunz writes: > I figure a few people on this list will be interested in this: > > http://www.softwareandstuff.com/h_comp_inet4.html Bastards won't ship out of the U.S.A. if the order is less than $500. I want 2 cards, not 17 :-( > anyway, knowing the problems people are having with the sundance > 580-TX and the unavailability of other cheap 4-port nic options, i > though I'd let folks here know. A good 4-port tulip card for $30 is > a nice deal. Indeed. Pity about the shipping restriction, though. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From pekkas@netcore.fi Tue Oct 15 22:51:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 15 Oct 2002 22:51:37 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G5pTtG029127 for ; Tue, 15 Oct 2002 22:51:30 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9G5pNX09800 for ; Wed, 16 Oct 2002 08:51:23 +0300 Date: Wed, 16 Oct 2002 08:51:23 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: Re: Implementation worries about default address selection (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 725 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 There were some worries about default address selection performance. This is one person's (BSD implementer) has noticed, and it doesn't look *too* bad for now. -- 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 ---------- Forwarded message ---------- Date: Wed, 16 Oct 2002 14:27:03 +0900 From: "JINMEI Tatuya / [ISO-2022-JP] 神明達哉" To: Pekka Savola Cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Implementation worries about default address selection >>>>> On Fri, 11 Oct 2002 09:54:55 +0300 (EEST), >>>>> Pekka Savola said: > Perhaps we should have been more careful when discussing "how/when" to use > caching. > But well, 'htsearch' on RFC's for "cache" at http://rfc.eunet.fi (for > example) returns 520 RFC's. > I think there are examples of some caching specification, as well (e.g. > neighbor discovery, multicast, ...). The level of detail is of course > imporant. At least, very many specifications say, like "this and this > part is critical and should [or SHOULD] be cached". > One of my main worries was that it seemed that nobody even bothered to > mention that the steps could be complex and some caching mechanism > (possibly with some examples) should be implemented. IMO, it is not necessarily a problem that nobody bothered. I've not bothered (though I've made some comments on the draft) about the complexity because I didn't think it was a problem of the document based on my experiences on implementing and operating with the specification. In general, whether or not we need a cache depends on how severe the related performance issue is. And the performance in this case depends on several parameters such as the number of addresses and how many times each selection rule applies. Please let me explain my own environments. My laptop usually has quite a large number of addresses, and the property of the addresses varies much; it has 12 (unicast) addresses as of writing this, including the loopback, link-local, site-local, and global ones. It also has temporary addresses for privacy extension, and some of the temporary addresses are often deprecated due to the short lifetimes. (note: the number "12" will be much increased in a few days. I rebooted my laptop last night, so it has only one temporary address for each autoconfigured prefix. More and more new temporary addresses will come.) A few days ago, I checked statistics on the source address selection on the laptop. By then it had been running for 6.5 days. According to the statistics, about 76.8% of the pair-wise address comparisons had been broken by the rule 2 (Prefer appropriate scope) and the rule 3 (Avoid deprecated addresses). IMO, the rules 1-3 are quite simple and light, and do not affect the performance much. I don't have a quantitative result on the performance, but at least I've never felt untolerable performance degradation that can be considered due to the complexity of the source address selection. I can expect counterarguments against the analysis above; "it is just a single, personal, and limited environment." "perhaps your laptop has a fast CPU. Think about poor devices." "just because you don't feel degradation does not mean the performance issue is not a problem", etc... I understand all of them. But I'd say this comes from a *real* experiences on implementation and operation, not just from reading the specification. If you want to make the document include caching, please show us how the selection rules badly affect the performance and how the caching improves the performance degradation *with a working implementation*. (However, I must also say that it is not always the case that the requirement to implement caching comes from actual experiences with working implementations. So I may be a bit unfair here.) As a result, I don't think it is necessary to require (either SHOULD or MUST) caching in the address selection draft. I don't oppose to mentioning the fact that caching may improve the performance, though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From greearb@candelatech.com Wed Oct 16 00:13:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 00:13:22 -0700 (PDT) Received: from grok.yi.org (IDENT:Savg3q52ZV1wZxPYzWtPSsXhuB3jGBBc@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G7DFtG001613 for ; Wed, 16 Oct 2002 00:13:16 -0700 Received: from candelatech.com (IDENT:kDMrwHWvpqVWAP0f1jcqgq7alOJqtbqr@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9G7DEq00478 for ; Wed, 16 Oct 2002 00:13:14 -0700 Message-ID: <3DAD118A.6090000@candelatech.com> Date: Wed, 16 Oct 2002 00:13:14 -0700 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: packet sockets and dev_get_by_name Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 726 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 It appears that the the static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg, int len, struct scm_cookie *scm) method in net/packet/af_packet.c does a dev_get_by_name on each packet sent. ... /* * Find the device first to size check it */ saddr->spkt_device[13] = 0; dev = dev_get_by_name(saddr->spkt_device); err = -ENODEV; if (dev == NULL) goto out_unlock; The packet_sendmsg does a dev_get_by_index, which is also a linear walk... Think it would be worth optimizing this? Seems if we hashed devices on their index, and then (for packet_sendmsg_spkt) cached the last device we found for a name in the socket, we could make this more like O(1). Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From greg@kroah.com Wed Oct 16 01:15:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 01:15:49 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9G8FgtG007033 for ; Wed, 16 Oct 2002 01:15:42 -0700 Received: (qmail 21091 invoked by uid 500); 16 Oct 2002 08:15:40 -0000 Date: Wed, 16 Oct 2002 01:15:40 -0700 From: Greg KH To: netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks Message-ID: <20021016081539.GF20421@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016000706.GI16966@kroah.com> User-Agent: Mutt/1.4i X-archive-position: 727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 05:07:06PM -0700, Greg KH wrote: > > I'll work on fixing up the rest of the hooks, and removing the external > reference to security_ops, and actually test this thing, later this > evening. Here's all the hooks converted over to function calls. Chris Wright pointed out I need to do some extra work with the existing capabilities hooks, but I'll do that in the morning. Thanks to John Levon for pointing out cond_syscall() to me, very cool function. That removes the need to have a sys_security.c file. Patch is against 2.5.43, and builds for me, both with and without CONFIG_SECURITY set. Haven't booted it yet though... thanks, greg k-h ===== arch/arm/kernel/ptrace.c 1.14 vs edited ===== --- 1.14/arch/arm/kernel/ptrace.c Sun Oct 13 07:32:28 2002 +++ edited/arch/arm/kernel/ptrace.c Wed Oct 16 00:46:07 2002 @@ -719,8 +719,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/i386/kernel/ptrace.c 1.13 vs edited ===== --- 1.13/arch/i386/kernel/ptrace.c Fri Jul 19 16:00:55 2002 +++ edited/arch/i386/kernel/ptrace.c Tue Oct 15 22:24:45 2002 @@ -160,8 +160,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ia64/kernel/ptrace.c 1.12 vs edited ===== --- 1.12/arch/ia64/kernel/ptrace.c Tue Sep 17 23:22:09 2002 +++ edited/arch/ia64/kernel/ptrace.c Wed Oct 16 00:45:53 2002 @@ -1101,8 +1101,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; current->ptrace |= PT_PTRACED; ret = 0; ===== arch/ppc/kernel/ptrace.c 1.10 vs edited ===== --- 1.10/arch/ppc/kernel/ptrace.c Sun Sep 15 21:51:59 2002 +++ edited/arch/ppc/kernel/ptrace.c Wed Oct 16 00:45:41 2002 @@ -166,8 +166,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ppc64/kernel/ptrace.c 1.3 vs edited ===== --- 1.3/arch/ppc64/kernel/ptrace.c Wed Aug 28 23:42:43 2002 +++ edited/arch/ppc64/kernel/ptrace.c Wed Oct 16 00:45:16 2002 @@ -59,8 +59,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ppc64/kernel/ptrace32.c 1.5 vs edited ===== --- 1.5/arch/ppc64/kernel/ptrace32.c Wed Aug 28 23:42:43 2002 +++ edited/arch/ppc64/kernel/ptrace32.c Wed Oct 16 00:45:29 2002 @@ -48,8 +48,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ppc64/kernel/sys_ppc32.c 1.24 vs edited ===== --- 1.24/arch/ppc64/kernel/sys_ppc32.c Fri Oct 11 19:04:17 2002 +++ edited/arch/ppc64/kernel/sys_ppc32.c Wed Oct 16 00:15:31 2002 @@ -53,6 +53,7 @@ #include #include #include +#include #include #include @@ -3519,8 +3520,7 @@ if ((retval = bprm.envc) < 0) goto out_mm; - retval = security_ops->bprm_alloc_security(&bprm); - if (retval) + if ((retval = security_bprm_alloc(&bprm))) goto out; retval = prepare_binprm(&bprm); @@ -3543,7 +3543,7 @@ retval = search_binary_handler(&bprm,regs); if (retval >= 0) { /* execve success */ - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); return retval; } @@ -3556,7 +3556,7 @@ } if (bprm.security) - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); out_mm: mmdrop(bprm.mm); ===== arch/s390/kernel/ptrace.c 1.9 vs edited ===== --- 1.9/arch/s390/kernel/ptrace.c Fri Oct 4 09:16:18 2002 +++ edited/arch/s390/kernel/ptrace.c Wed Oct 16 00:44:51 2002 @@ -330,8 +330,7 @@ ret = -EPERM; if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/s390x/kernel/ptrace.c 1.8 vs edited ===== --- 1.8/arch/s390x/kernel/ptrace.c Fri Oct 4 09:16:18 2002 +++ edited/arch/s390x/kernel/ptrace.c Wed Oct 16 00:44:40 2002 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -568,8 +569,7 @@ ret = -EPERM; if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/sparc/kernel/ptrace.c 1.11 vs edited ===== --- 1.11/arch/sparc/kernel/ptrace.c Sat Aug 24 04:08:41 2002 +++ edited/arch/sparc/kernel/ptrace.c Wed Oct 16 00:44:06 2002 @@ -291,8 +291,7 @@ pt_error_return(regs, EPERM); goto out; } - ret = security_ops->ptrace(current->parent, current); - if (ret) { + if ((ret = security_ptrace(current->parent, current))) { pt_error_return(regs, -ret); goto out; } ===== arch/sparc64/kernel/ptrace.c 1.16 vs edited ===== --- 1.16/arch/sparc64/kernel/ptrace.c Sat Aug 24 03:59:14 2002 +++ edited/arch/sparc64/kernel/ptrace.c Wed Oct 16 00:43:53 2002 @@ -140,8 +140,7 @@ pt_error_return(regs, EPERM); goto out; } - ret = security_ops->ptrace(current->parent, current); - if (ret) { + if ((ret = security_ptrace(current->parent, current))) { pt_error_return(regs, -ret); goto out; } ===== arch/sparc64/kernel/sys_sparc32.c 1.39 vs edited ===== --- 1.39/arch/sparc64/kernel/sys_sparc32.c Mon Oct 14 05:17:46 2002 +++ edited/arch/sparc64/kernel/sys_sparc32.c Wed Oct 16 00:14:27 2002 @@ -2972,8 +2972,7 @@ if ((retval = bprm.envc) < 0) goto out_mm; - retval = security_ops->bprm_alloc_security(&bprm); - if (retval) + if ((retval = security_bprm_alloc(&bprm))) goto out; retval = prepare_binprm(&bprm); @@ -2996,7 +2995,7 @@ retval = search_binary_handler(&bprm, regs); if (retval >= 0) { /* execve success */ - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); return retval; } @@ -3009,7 +3008,7 @@ } if (bprm.security) - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); out_mm: mmdrop(bprm.mm); ===== arch/um/kernel/ptrace.c 1.1 vs edited ===== --- 1.1/arch/um/kernel/ptrace.c Fri Sep 6 10:50:31 2002 +++ edited/arch/um/kernel/ptrace.c Wed Oct 16 00:43:41 2002 @@ -33,8 +33,7 @@ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if(ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ ===== arch/x86_64/kernel/ptrace.c 1.4 vs edited ===== --- 1.4/arch/x86_64/kernel/ptrace.c Fri Oct 11 16:52:38 2002 +++ edited/arch/x86_64/kernel/ptrace.c Wed Oct 16 00:43:30 2002 @@ -178,8 +178,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== drivers/base/fs/class.c 1.2 vs edited ===== --- 1.2/drivers/base/fs/class.c Mon Aug 26 08:39:22 2002 +++ edited/drivers/base/fs/class.c Tue Oct 15 22:24:45 2002 @@ -7,6 +7,8 @@ #include #include #include +#include +#include #include "fs.h" static struct driver_dir_entry class_dir; ===== drivers/base/fs/intf.c 1.2 vs edited ===== --- 1.2/drivers/base/fs/intf.c Mon Aug 26 09:24:18 2002 +++ edited/drivers/base/fs/intf.c Tue Oct 15 22:24:45 2002 @@ -4,6 +4,8 @@ #include #include +#include +#include #include "fs.h" /** ===== fs/attr.c 1.10 vs edited ===== --- 1.10/fs/attr.c Mon Jul 22 03:12:48 2002 +++ edited/fs/attr.c Tue Oct 15 23:50:23 2002 @@ -153,13 +153,12 @@ } if (inode->i_op && inode->i_op->setattr) { - error = security_ops->inode_setattr(dentry, attr); - if (!error) + if (!(error = security_inode_setattr(dentry, attr))) error = inode->i_op->setattr(dentry, attr); } else { error = inode_change_ok(inode, attr); if (!error) - error = security_ops->inode_setattr(dentry, attr); + error = security_inode_setattr(dentry, attr); if (!error) { if ((ia_valid & ATTR_UID && attr->ia_uid != inode->i_uid) || (ia_valid & ATTR_GID && attr->ia_gid != inode->i_gid)) ===== fs/dquot.c 1.48 vs edited ===== --- 1.48/fs/dquot.c Sun Oct 13 08:39:23 2002 +++ edited/fs/dquot.c Tue Oct 15 22:55:27 2002 @@ -69,6 +69,7 @@ #include #include #include +#include #include @@ -1305,8 +1306,7 @@ error = -EIO; if (!f->f_op || !f->f_op->read || !f->f_op->write) goto out_f; - error = security_ops->quota_on(f); - if (error) + if ((error = security_quota_on(f))) goto out_f; inode = f->f_dentry->d_inode; error = -EACCES; ===== fs/exec.c 1.51 vs edited ===== --- 1.51/fs/exec.c Sun Oct 13 09:32:22 2002 +++ edited/fs/exec.c Tue Oct 15 23:03:20 2002 @@ -43,6 +43,7 @@ #include #include #include +#include #include #include @@ -818,8 +819,7 @@ } /* fill in binprm security blob */ - retval = security_ops->bprm_set_security(bprm); - if (retval) + if ((retval = security_bprm_set(bprm))) return retval; memset(bprm->buf,0,BINPRM_BUF_SIZE); @@ -867,7 +867,7 @@ if(do_unlock) unlock_kernel(); - security_ops->bprm_compute_creds(bprm); + security_bprm_compute_creds(bprm); } void remove_arg_zero(struct linux_binprm *bprm) @@ -936,8 +936,7 @@ } } #endif - retval = security_ops->bprm_check_security(bprm); - if (retval) + if ((retval = security_bprm_check(bprm))) return retval; /* kernel module loader fixup */ @@ -1033,8 +1032,7 @@ if ((retval = bprm.envc) < 0) goto out_mm; - retval = security_ops->bprm_alloc_security(&bprm); - if (retval) + if ((retval = security_bprm_alloc(&bprm))) goto out; retval = prepare_binprm(&bprm); @@ -1057,7 +1055,7 @@ retval = search_binary_handler(&bprm,regs); if (retval >= 0) { /* execve success */ - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); return retval; } @@ -1070,7 +1068,7 @@ } if (bprm.security) - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); out_mm: mmdrop(bprm.mm); ===== fs/fcntl.c 1.20 vs edited ===== --- 1.20/fs/fcntl.c Sun Oct 13 08:39:40 2002 +++ edited/fs/fcntl.c Wed Oct 16 00:04:50 2002 @@ -274,8 +274,7 @@ { int err; - err = security_ops->file_set_fowner(filp); - if (err) + if ((err = security_file_set_fowner(filp))) return err; f_modown(filp, arg, current->uid, current->euid, force); @@ -368,8 +367,7 @@ if (!filp) goto out; - err = security_ops->file_fcntl(filp, cmd, arg); - if (err) { + if ((err = security_file_fcntl(filp, cmd, arg))) { fput(filp); return err; } @@ -392,8 +390,7 @@ if (!filp) goto out; - err = security_ops->file_fcntl(filp, cmd, arg); - if (err) { + if ((err = security_file_fcntl(filp, cmd, arg))) { fput(filp); return err; } @@ -444,7 +441,7 @@ if (!sigio_perm(p, fown)) return; - if (security_ops->file_send_sigiotask(p, fown, fd, reason)) + if (security_file_send_sigiotask(p, fown, fd, reason)) return; switch (fown->signum) { ===== fs/file_table.c 1.13 vs edited ===== --- 1.13/fs/file_table.c Sun Oct 13 08:39:40 2002 +++ edited/fs/file_table.c Wed Oct 16 00:04:27 2002 @@ -46,7 +46,7 @@ files_stat.nr_free_files--; new_one: memset(f, 0, sizeof(*f)); - if (security_ops->file_alloc_security(f)) { + if (security_file_alloc(f)) { list_add(&f->f_list, &free_list); files_stat.nr_free_files++; file_list_unlock(); @@ -127,7 +127,7 @@ if (file->f_op && file->f_op->release) file->f_op->release(inode, file); - security_ops->file_free_security(file); + security_file_free(file); fops_put(file->f_op); if (file->f_mode & FMODE_WRITE) put_write_access(inode); @@ -160,7 +160,7 @@ void put_filp(struct file *file) { if(atomic_dec_and_test(&file->f_count)) { - security_ops->file_free_security(file); + security_file_free(file); file_list_lock(); list_del(&file->f_list); list_add(&file->f_list, &free_list); ===== fs/inode.c 1.74 vs edited ===== --- 1.74/fs/inode.c Sun Oct 13 08:39:23 2002 +++ edited/fs/inode.c Tue Oct 15 23:49:49 2002 @@ -120,7 +120,7 @@ inode->i_bdev = NULL; inode->i_cdev = NULL; inode->i_security = NULL; - if (security_ops->inode_alloc_security(inode)) { + if (security_inode_alloc(inode)) { if (inode->i_sb->s_op->destroy_inode) inode->i_sb->s_op->destroy_inode(inode); else @@ -146,7 +146,7 @@ { if (inode_has_buffers(inode)) BUG(); - security_ops->inode_free_security(inode); + security_inode_free(inode); if (inode->i_sb->s_op->destroy_inode) { inode->i_sb->s_op->destroy_inode(inode); } else { @@ -922,7 +922,7 @@ if (inode->i_data.nrpages) truncate_inode_pages(&inode->i_data, 0); - security_ops->inode_delete(inode); + security_inode_delete(inode); if (op && op->delete_inode) { void (*delete)(struct inode *) = op->delete_inode; ===== fs/ioctl.c 1.5 vs edited ===== --- 1.5/fs/ioctl.c Mon Jul 22 03:12:48 2002 +++ edited/fs/ioctl.c Wed Oct 16 00:06:16 2002 @@ -59,8 +59,7 @@ goto out; error = 0; - error = security_ops->file_ioctl(filp, cmd, arg); - if (error) { + if ((error = security_file_ioctl(filp, cmd, arg))) { fput(filp); goto out; } ===== fs/locks.c 1.30 vs edited ===== --- 1.30/fs/locks.c Thu Sep 26 10:36:16 2002 +++ edited/fs/locks.c Wed Oct 16 00:06:00 2002 @@ -122,6 +122,7 @@ #include #include #include +#include #include #include @@ -1170,8 +1171,7 @@ return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; - error = security_ops->file_lock(filp, arg); - if (error) + if ((error = security_file_lock(filp, arg))) return error; lock_kernel(); @@ -1284,8 +1284,7 @@ if (error) goto out_putf; - error = security_ops->file_lock(filp, cmd); - if (error) + if ((error = security_file_lock(filp, cmd))) goto out_free; for (;;) { @@ -1434,8 +1433,7 @@ goto out; } - error = security_ops->file_lock(filp, file_lock->fl_type); - if (error) + if ((error = security_file_lock(filp, file_lock->fl_type))) goto out; if (filp->f_op && filp->f_op->lock != NULL) { @@ -1574,8 +1572,7 @@ goto out; } - error = security_ops->file_lock(filp, file_lock->fl_type); - if (error) + if ((error = security_file_lock(filp, file_lock->fl_type))) goto out; if (filp->f_op && filp->f_op->lock != NULL) { ===== fs/namei.c 1.56 vs edited ===== --- 1.56/fs/namei.c Tue Sep 17 12:52:27 2002 +++ edited/fs/namei.c Tue Oct 15 23:47:28 2002 @@ -218,7 +218,7 @@ if (retval) return retval; - return security_ops->inode_permission(inode, mask); + return security_inode_permission(inode, mask); } /* @@ -340,7 +340,7 @@ return -EACCES; ok: - return security_ops->inode_permission_lite(inode, MAY_EXEC); + return security_inode_permission_lite(inode, MAY_EXEC); } /* @@ -374,7 +374,7 @@ dput(dentry); else { result = dentry; - security_ops->inode_post_lookup(dir, result); + security_inode_post_lookup(dir, result); } } up(&dir->i_sem); @@ -413,8 +413,7 @@ current->state = TASK_RUNNING; schedule(); } - err = security_ops->inode_follow_link(dentry, nd); - if (err) + if ((err = security_inode_follow_link(dentry, nd))) goto loop; current->link_count++; current->total_link_count++; @@ -918,7 +917,7 @@ dentry = inode->i_op->lookup(inode, new); if (!dentry) { dentry = new; - security_ops->inode_post_lookup(inode, dentry); + security_inode_post_lookup(inode, dentry); } else dput(new); } @@ -1125,14 +1124,13 @@ return -EACCES; /* shouldn't it be ENOSYS? */ mode &= S_IALLUGO; mode |= S_IFREG; - error = security_ops->inode_create(dir, dentry, mode); - if (error) + if ((error = security_inode_create(dir, dentry, mode))) return error; DQUOT_INIT(dir); error = dir->i_op->create(dir, dentry, mode); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_create(dir, dentry, mode); + security_inode_post_create(dir, dentry, mode); } return error; } @@ -1344,8 +1342,7 @@ * stored in nd->last.name and we will have to putname() it when we * are done. Procfs-like symlinks just set LAST_BIND. */ - error = security_ops->inode_follow_link(dentry, nd); - if (error) + if ((error = security_inode_follow_link(dentry, nd))) goto exit_dput; UPDATE_ATIME(dentry->d_inode); error = dentry->d_inode->i_op->follow_link(dentry, nd); @@ -1410,15 +1407,14 @@ if (!dir->i_op || !dir->i_op->mknod) return -EPERM; - error = security_ops->inode_mknod(dir, dentry, mode, dev); - if (error) + if ((error = security_inode_mknod(dir, dentry, mode, dev))) return error; DQUOT_INIT(dir); error = dir->i_op->mknod(dir, dentry, mode, dev); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_mknod(dir, dentry, mode, dev); + security_inode_post_mknod(dir, dentry, mode, dev); } return error; } @@ -1478,15 +1474,14 @@ return -EPERM; mode &= (S_IRWXUGO|S_ISVTX); - error = security_ops->inode_mkdir(dir, dentry, mode); - if (error) + if ((error = security_inode_mkdir(dir, dentry, mode))) return error; DQUOT_INIT(dir); error = dir->i_op->mkdir(dir, dentry, mode); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_mkdir(dir,dentry, mode); + security_inode_post_mkdir(dir,dentry, mode); } return error; } @@ -1570,8 +1565,7 @@ if (d_mountpoint(dentry)) error = -EBUSY; else { - error = security_ops->inode_rmdir(dir, dentry); - if (!error) { + if (!(error = security_inode_rmdir(dir, dentry))) { error = dir->i_op->rmdir(dir, dentry); if (!error) dentry->d_inode->i_flags |= S_DEAD; @@ -1644,10 +1638,8 @@ if (d_mountpoint(dentry)) error = -EBUSY; else { - error = security_ops->inode_unlink(dir, dentry); - if (!error) { + if (!(error = security_inode_unlink(dir, dentry))) error = dir->i_op->unlink(dir, dentry); - } } up(&dentry->d_inode->i_sem); if (!error) { @@ -1709,15 +1701,14 @@ if (!dir->i_op || !dir->i_op->symlink) return -EPERM; - error = security_ops->inode_symlink(dir, dentry, oldname); - if (error) + if ((error = security_inode_symlink(dir, dentry, oldname))) return error; DQUOT_INIT(dir); error = dir->i_op->symlink(dir, dentry, oldname); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_symlink(dir, dentry, oldname); + security_inode_post_symlink(dir, dentry, oldname); } return error; } @@ -1780,8 +1771,7 @@ if (S_ISDIR(old_dentry->d_inode->i_mode)) return -EPERM; - error = security_ops->inode_link(old_dentry, dir, new_dentry); - if (error) + if ((error = security_inode_link(old_dentry, dir, new_dentry))) return error; down(&old_dentry->d_inode->i_sem); @@ -1790,7 +1780,7 @@ up(&old_dentry->d_inode->i_sem); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_link(old_dentry, dir, new_dentry); + security_inode_post_link(old_dentry, dir, new_dentry); } return error; } @@ -1889,8 +1879,7 @@ return error; } - error = security_ops->inode_rename(old_dir, old_dentry, new_dir, new_dentry); - if (error) + if ((error = security_inode_rename(old_dir, old_dentry, new_dir, new_dentry))) return error; target = new_dentry->d_inode; @@ -1912,8 +1901,8 @@ } if (!error) { d_move(old_dentry,new_dentry); - security_ops->inode_post_rename(old_dir, old_dentry, - new_dir, new_dentry); + security_inode_post_rename(old_dir, old_dentry, + new_dir, new_dentry); } return error; } @@ -1924,8 +1913,7 @@ struct inode *target; int error; - error = security_ops->inode_rename(old_dir, old_dentry, new_dir, new_dentry); - if (error) + if ((error = security_inode_rename(old_dir, old_dentry, new_dir, new_dentry))) return error; dget(new_dentry); @@ -1940,7 +1928,7 @@ /* The following d_move() should become unconditional */ if (!(old_dir->i_sb->s_type->fs_flags & FS_ODD_RENAME)) d_move(old_dentry, new_dentry); - security_ops->inode_post_rename(old_dir, old_dentry, new_dir, new_dentry); + security_inode_post_rename(old_dir, old_dentry, new_dir, new_dentry); } if (target) up(&target->i_sem); ===== fs/namespace.c 1.29 vs edited ===== --- 1.29/fs/namespace.c Tue Sep 17 12:52:27 2002 +++ edited/fs/namespace.c Tue Oct 15 23:17:32 2002 @@ -19,6 +19,7 @@ #include #include #include +#include #include @@ -288,8 +289,7 @@ struct super_block * sb = mnt->mnt_sb; int retval = 0; - retval = security_ops->sb_umount(mnt, flags); - if (retval) + if ((retval = security_sb_umount(mnt, flags))) return retval; /* @@ -341,7 +341,7 @@ DQUOT_OFF(sb); acct_auto_close(sb); unlock_kernel(); - security_ops->sb_umount_close(mnt); + security_sb_umount_close(mnt); spin_lock(&dcache_lock); } retval = -EBUSY; @@ -352,7 +352,7 @@ } spin_unlock(&dcache_lock); if (retval) - security_ops->sb_umount_busy(mnt); + security_sb_umount_busy(mnt); up_write(¤t->namespace->sem); return retval; } @@ -470,8 +470,7 @@ if (IS_DEADDIR(nd->dentry->d_inode)) goto out_unlock; - err = security_ops->sb_check_sb(mnt, nd); - if (err) + if ((err = security_sb_check_sb(mnt, nd))) goto out_unlock; spin_lock(&dcache_lock); @@ -487,7 +486,7 @@ out_unlock: up(&nd->dentry->d_inode->i_sem); if (!err) - security_ops->sb_post_addmount(mnt, nd); + security_sb_post_addmount(mnt, nd); return err; } @@ -558,7 +557,7 @@ nd->mnt->mnt_flags=mnt_flags; up_write(&sb->s_umount); if (!err) - security_ops->sb_post_remount(nd->mnt, flags, data); + security_sb_post_remount(nd->mnt, flags, data); return err; } @@ -741,8 +740,7 @@ if (retval) return retval; - retval = security_ops->sb_mount(dev_name, &nd, type_page, flags, data_page); - if (retval) + if ((retval = security_sb_mount(dev_name, &nd, type_page, flags, data_page))) goto dput_out; if (flags & MS_REMOUNT) @@ -939,8 +937,7 @@ if (error) goto out1; - error = security_ops->sb_pivotroot(&old_nd, &new_nd); - if (error) { + if ((error = security_sb_pivotroot(&old_nd, &new_nd))) { path_release(&old_nd); goto out1; } @@ -989,7 +986,7 @@ attach_mnt(new_nd.mnt, &root_parent); spin_unlock(&dcache_lock); chroot_fs_refs(&user_nd, &new_nd); - security_ops->sb_post_pivotroot(&user_nd, &new_nd); + security_sb_post_pivotroot(&user_nd, &new_nd); error = 0; path_release(&root_parent); path_release(&parent_nd); ===== fs/open.c 1.28 vs edited ===== --- 1.28/fs/open.c Sun Oct 13 08:39:40 2002 +++ edited/fs/open.c Tue Oct 15 23:19:46 2002 @@ -30,8 +30,7 @@ retval = -ENOSYS; if (sb->s_op && sb->s_op->statfs) { memset(buf, 0, sizeof(struct statfs)); - retval = security_ops->sb_statfs(sb); - if (retval) + if ((retval = security_sb_statfs(sb))) return retval; retval = sb->s_op->statfs(sb, buf); } ===== fs/quota.c 1.8 vs edited ===== --- 1.8/fs/quota.c Mon Jul 22 03:12:48 2002 +++ edited/fs/quota.c Tue Oct 15 22:54:46 2002 @@ -98,7 +98,7 @@ if (!capable(CAP_SYS_ADMIN)) return -EPERM; - return security_ops->quotactl (cmd, type, id, sb); + return security_quotactl (cmd, type, id, sb); } /* Resolve device pathname to superblock */ ===== fs/read_write.c 1.19 vs edited ===== --- 1.19/fs/read_write.c Thu Oct 10 14:36:26 2002 +++ edited/fs/read_write.c Wed Oct 16 00:08:14 2002 @@ -121,8 +121,7 @@ if (!file) goto bad; - retval = security_ops->file_llseek(file); - if (retval) { + if ((retval = security_file_llseek(file))) { fput(file); goto bad; } @@ -153,8 +152,7 @@ if (!file) goto bad; - retval = security_ops->file_llseek(file); - if (retval) + if ((retval = security_file_llseek(file))) goto out_putf; retval = -EINVAL; @@ -203,8 +201,7 @@ ret = locks_verify_area(FLOCK_VERIFY_READ, inode, file, *pos, count); if (!ret) { - ret = security_ops->file_permission (file, MAY_READ); - if (!ret) { + if (!(ret = security_file_permission (file, MAY_READ))) { if (file->f_op->read) ret = file->f_op->read(file, buf, count, pos); else @@ -243,8 +240,7 @@ ret = locks_verify_area(FLOCK_VERIFY_WRITE, inode, file, *pos, count); if (!ret) { - ret = security_ops->file_permission (file, MAY_WRITE); - if (!ret) { + if (!(ret = security_file_permission (file, MAY_WRITE))) { if (file->f_op->write) ret = file->f_op->write(file, buf, count, pos); else @@ -475,8 +471,7 @@ goto bad_file; if (file->f_op && (file->f_mode & FMODE_READ) && (file->f_op->readv || file->f_op->read)) { - ret = security_ops->file_permission (file, MAY_READ); - if (!ret) + if (!(ret = security_file_permission (file, MAY_READ))) ret = do_readv_writev(READ, file, vector, nr_segs); } fput(file); @@ -498,8 +493,7 @@ goto bad_file; if (file->f_op && (file->f_mode & FMODE_WRITE) && (file->f_op->writev || file->f_op->write)) { - ret = security_ops->file_permission (file, MAY_WRITE); - if (!ret) + if (!(ret = security_file_permission (file, MAY_WRITE))) ret = do_readv_writev(WRITE, file, vector, nr_segs); } fput(file); ===== fs/readdir.c 1.9 vs edited ===== --- 1.9/fs/readdir.c Mon Jul 22 03:12:48 2002 +++ edited/fs/readdir.c Wed Oct 16 00:06:40 2002 @@ -11,6 +11,7 @@ #include #include #include +#include #include @@ -21,8 +22,7 @@ if (!file->f_op || !file->f_op->readdir) goto out; - res = security_ops->file_permission(file, MAY_READ); - if (res) + if ((res = security_file_permission(file, MAY_READ))) goto out; down(&inode->i_sem); ===== fs/stat.c 1.13 vs edited ===== --- 1.13/fs/stat.c Mon Jul 22 03:12:48 2002 +++ edited/fs/stat.c Tue Oct 15 23:49:19 2002 @@ -39,8 +39,7 @@ struct inode *inode = dentry->d_inode; int retval; - retval = security_ops->inode_getattr(mnt, dentry); - if (retval) + if ((retval = security_inode_getattr(mnt, dentry))) return retval; if (inode->i_op->getattr) @@ -238,8 +237,7 @@ error = -EINVAL; if (inode->i_op && inode->i_op->readlink) { - error = security_ops->inode_readlink(nd.dentry); - if (!error) { + if (!(error = security_inode_readlink(nd.dentry))) { UPDATE_ATIME(inode); error = inode->i_op->readlink(nd.dentry, buf, bufsiz); } ===== fs/super.c 1.83 vs edited ===== --- 1.83/fs/super.c Mon Sep 9 14:00:57 2002 +++ edited/fs/super.c Tue Oct 15 23:18:44 2002 @@ -29,9 +29,9 @@ #include #include #include /* for fsync_super() */ +#include #include -#include void get_filesystem(struct file_system_type *fs); void put_filesystem(struct file_system_type *fs); @@ -51,7 +51,7 @@ struct super_block *s = kmalloc(sizeof(struct super_block), GFP_USER); if (s) { memset(s, 0, sizeof(struct super_block)); - if (security_ops->sb_alloc_security(s)) { + if (security_sb_alloc(s)) { kfree(s); s = NULL; goto out; @@ -85,7 +85,7 @@ */ static inline void destroy_super(struct super_block *s) { - security_ops->sb_free_security(s); + security_sb_free(s); kfree(s); } ===== fs/xattr.c 1.7 vs edited ===== --- 1.7/fs/xattr.c Mon Jul 22 03:12:48 2002 +++ edited/fs/xattr.c Tue Oct 15 23:51:34 2002 @@ -13,6 +13,7 @@ #include #include #include +#include #include /* @@ -85,9 +86,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->setxattr) { - error = security_ops->inode_setxattr(d, kname, kvalue, - size, flags); - if (error) + if ((error = security_inode_setxattr(d, kname, kvalue, size, flags))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags); @@ -163,8 +162,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->getxattr) { - error = security_ops->inode_getxattr(d, kname); - if (error) + if ((error = security_inode_getxattr(d, kname))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->getxattr(d, kname, kvalue, size); @@ -236,8 +234,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->listxattr) { - error = security_ops->inode_listxattr(d); - if (error) + if ((error = security_inode_listxattr(d))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->listxattr(d, klist, size); @@ -311,8 +308,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->removexattr) { - error = security_ops->inode_removexattr(d, kname); - if (error) + if ((error = security_inode_removexattr(d, kname))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->removexattr(d, kname); ===== fs/proc/base.c 1.31 vs edited ===== --- 1.31/fs/proc/base.c Sat Sep 28 08:36:29 2002 +++ edited/fs/proc/base.c Tue Oct 15 23:22:02 2002 @@ -28,6 +28,7 @@ #include #include #include +#include /* * For hysterical raisins we keep the same inumbers as in the old procfs. @@ -394,7 +395,7 @@ }; #define MAY_PTRACE(p) \ -(p==current||(p->parent==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED&&security_ops->ptrace(current,p)==0)) +(p==current||(p->parent==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED&&security_ptrace(current,p)==0)) static int mem_open(struct inode* inode, struct file* file) ===== include/linux/sched.h 1.107 vs edited ===== --- 1.107/include/linux/sched.h Tue Oct 15 15:32:40 2002 +++ edited/include/linux/sched.h Tue Oct 15 22:24:46 2002 @@ -596,9 +596,11 @@ unsigned long, const char *, void *); extern void free_irq(unsigned int, void *); + +#ifdef CONFIG_SECURITY /* capable prototype and code moved to security.[hc] */ #include -#if 0 +#else static inline int capable(int cap) { if (cap_raised(current->cap_effective, cap)) { @@ -607,7 +609,7 @@ } return 0; } -#endif /* if 0 */ +#endif /* * Routines for handling mm_structs ===== include/linux/security.h 1.4 vs edited ===== --- 1.4/include/linux/security.h Tue Oct 8 02:20:18 2002 +++ edited/include/linux/security.h Wed Oct 16 01:03:50 2002 @@ -22,8 +22,6 @@ #ifndef __LINUX_SECURITY_H #define __LINUX_SECURITY_H -#ifdef __KERNEL__ - #include #include #include @@ -33,6 +31,7 @@ #include #include + /* * Values used in the task_security_ops calls */ @@ -848,6 +847,533 @@ struct security_operations *ops); }; +#ifdef CONFIG_SECURITY + +/* global variables */ +extern struct security_operations *security_ops; + +/* inline stuff */ +static inline int security_ptrace (struct task_struct * parent, struct task_struct * child) +{ + return security_ops->ptrace (parent, child); +} + +static inline int security_capget (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return security_ops->capget (target, effective, inheritable, permitted); +} + +static inline int security_capset_check (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return security_ops->capset_check (target, effective, inheritable, permitted); +} + +static inline void security_capset_set (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + security_ops->capset_set (target, effective, inheritable, permitted); +} + +static inline int security_acct (struct file *file) +{ + return security_ops->acct (file); +} + +static inline int security_quotactl (int cmds, int type, int id, + struct super_block *sb) +{ + return security_ops->quotactl (cmds, type, id, sb); +} + +static inline int security_quota_on (struct file * file) +{ + return security_ops->quota_on (file); +} + +static inline int security_bprm_alloc (struct linux_binprm *bprm) +{ + return security_ops->bprm_alloc_security (bprm); +} +static inline void security_bprm_free (struct linux_binprm *bprm) +{ + security_ops->bprm_free_security (bprm); +} +static inline void security_bprm_compute_creds (struct linux_binprm *bprm) +{ + security_ops->bprm_compute_creds (bprm); +} +static inline int security_bprm_set (struct linux_binprm *bprm) +{ + return security_ops->bprm_set_security (bprm); +} +static inline int security_bprm_check (struct linux_binprm *bprm) +{ + return security_ops->bprm_check_security (bprm); +} + +static inline int security_sb_alloc (struct super_block *sb) +{ + return security_ops->sb_alloc_security (sb); +} + +static inline void security_sb_free (struct super_block *sb) +{ + security_ops->sb_free_security (sb); +} + +static inline int security_sb_statfs (struct super_block *sb) +{ + return security_ops->sb_statfs (sb); +} + +static inline int security_sb_mount (char *dev_name, struct nameidata *nd, + char *type, unsigned long flags, + void *data) +{ + return security_ops->sb_mount (dev_name, nd, type, flags, data); +} + +static inline int security_sb_check_sb (struct vfsmount *mnt, + struct nameidata *nd) +{ + return security_ops->sb_check_sb (mnt, nd); +} + +static inline int security_sb_umount (struct vfsmount *mnt, int flags) +{ + return security_ops->sb_umount (mnt, flags); +} + +static inline void security_sb_umount_close (struct vfsmount *mnt) +{ + security_ops->sb_umount_close (mnt); +} + +static inline void security_sb_umount_busy (struct vfsmount *mnt) +{ + security_ops->sb_umount_busy (mnt); +} + +static inline void security_sb_post_remount (struct vfsmount *mnt, + unsigned long flags, void *data) +{ + security_ops->sb_post_remount (mnt, flags, data); +} + +static inline void security_sb_post_mountroot (void) +{ + security_ops->sb_post_mountroot (); +} + +static inline void security_sb_post_addmount (struct vfsmount *mnt, + struct nameidata *mountpoint_nd) +{ + security_ops->sb_post_addmount (mnt, mountpoint_nd); +} + +static inline int security_sb_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ + return security_ops->sb_pivotroot (old_nd, new_nd); +} + +static inline void security_sb_post_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ + security_ops->sb_post_pivotroot (old_nd, new_nd); +} + +static inline int security_inode_alloc (struct inode *inode) +{ + return security_ops->inode_alloc_security (inode); +} + +static inline void security_inode_free (struct inode *inode) +{ + security_ops->inode_free_security (inode); +} + +static inline int security_inode_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return security_ops->inode_create (dir, dentry, mode); +} + +static inline void security_inode_post_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ + security_ops->inode_post_create (dir, dentry, mode); +} + +static inline int security_inode_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ + return security_ops->inode_link (old_dentry, dir, new_dentry); +} + +static inline void security_inode_post_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ + security_ops->inode_post_link (old_dentry, dir, new_dentry); +} + +static inline int security_inode_unlink (struct inode *dir, + struct dentry *dentry) +{ + return security_ops->inode_unlink (dir, dentry); +} + +static inline int security_inode_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ + return security_ops->inode_symlink (dir, dentry, old_name); +} + +static inline void security_inode_post_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ + security_ops->inode_post_symlink (dir, dentry, old_name); +} + +static inline int security_inode_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return security_ops->inode_mkdir (dir, dentry, mode); +} + +static inline void security_inode_post_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ + security_ops->inode_post_mkdir (dir, dentry, mode); +} + +static inline int security_inode_rmdir (struct inode *dir, + struct dentry *dentry) +{ + return security_ops->inode_rmdir (dir, dentry); +} + +static inline int security_inode_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ + return security_ops->inode_mknod (dir, dentry, mode, dev); +} + +static inline void security_inode_post_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ + security_ops->inode_post_mknod (dir, dentry, mode, dev); +} + +static inline int security_inode_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ + return security_ops->inode_rename (old_dir, old_dentry, + new_dir, new_dentry); +} + +static inline void security_inode_post_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ + security_ops->inode_post_rename (old_dir, old_dentry, + new_dir, new_dentry); +} + +static inline int security_inode_readlink (struct dentry *dentry) +{ + return security_ops->inode_readlink (dentry); +} + +static inline int security_inode_follow_link (struct dentry *dentry, + struct nameidata *nd) +{ + return security_ops->inode_follow_link (dentry, nd); +} + +static inline int security_inode_permission (struct inode *inode, int mask) +{ + return security_ops->inode_permission (inode, mask); +} + +static inline int security_inode_permission_lite (struct inode *inode, + int mask) +{ + return security_ops->inode_permission_lite (inode, mask); +} + +static inline int security_inode_setattr (struct dentry *dentry, + struct iattr *attr) +{ + return security_ops->inode_setattr (dentry, attr); +} + +static inline int security_inode_getattr (struct vfsmount *mnt, + struct dentry *dentry) +{ + return security_ops->inode_getattr (mnt, dentry); +} + +static inline void security_inode_post_lookup (struct inode *inode, + struct dentry *dentry) +{ + security_ops->inode_post_lookup (inode, dentry); +} + +static inline void security_inode_delete (struct inode *inode) +{ + security_ops->inode_delete (inode); +} + +static inline int security_inode_setxattr (struct dentry *dentry, char *name, + void *value, size_t size, int flags) +{ + return security_ops->inode_setxattr (dentry, name, value, size, flags); +} + +static inline int security_inode_getxattr (struct dentry *dentry, char *name) +{ + return security_ops->inode_getxattr (dentry, name); +} + +static inline int security_inode_listxattr (struct dentry *dentry) +{ + return security_ops->inode_listxattr (dentry); +} + +static inline int security_inode_removexattr (struct dentry *dentry, char *name) +{ + return security_ops->inode_removexattr (dentry, name); +} + +static inline int security_file_permission (struct file *file, int mask) +{ + return security_ops->file_permission (file, mask); +} + +static inline int security_file_alloc (struct file *file) +{ + return security_ops->file_alloc_security (file); +} + +static inline void security_file_free (struct file *file) +{ + security_ops->file_free_security (file); +} + +static inline int security_file_llseek (struct file *file) +{ + return security_ops->file_llseek (file); +} + +static inline int security_file_ioctl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return security_ops->file_ioctl (file, cmd, arg); +} + +static inline int security_file_mmap (struct file *file, unsigned long prot, + unsigned long flags) +{ + return security_ops->file_mmap (file, prot, flags); +} + +static inline int security_file_mprotect (struct vm_area_struct *vma, + unsigned long prot) +{ + return security_ops->file_mprotect (vma, prot); +} + +static inline int security_file_lock (struct file *file, unsigned int cmd) +{ + return security_ops->file_lock (file, cmd); +} + +static inline int security_file_fcntl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return security_ops->file_fcntl (file, cmd, arg); +} + +static inline int security_file_set_fowner (struct file *file) +{ + return security_ops->file_set_fowner (file); +} + +static inline int security_file_send_sigiotask (struct task_struct *tsk, + struct fown_struct *fown, + int fd, int reason) +{ + return security_ops->file_send_sigiotask (tsk, fown, fd, reason); +} + +static inline int security_file_receive (struct file *file) +{ + return security_ops->file_receive (file); +} + +static inline int security_task_create (unsigned long clone_flags) +{ + return security_ops->task_create (clone_flags); +} + +static inline int security_task_alloc (struct task_struct *p) +{ + return security_ops->task_alloc_security (p); +} + +static inline void security_task_free (struct task_struct *p) +{ + security_ops->task_free_security (p); +} + +static inline int security_task_setuid (uid_t id0, uid_t id1, uid_t id2, + int flags) +{ + return security_ops->task_setuid (id0, id1, id2, flags); +} + +static inline int security_task_post_setuid (uid_t old_ruid, uid_t old_euid, + uid_t old_suid, int flags) +{ + return security_ops->task_post_setuid (old_ruid, old_euid, old_suid, flags); +} + +static inline int security_task_setgid (gid_t id0, gid_t id1, gid_t id2, + int flags) +{ + return security_ops->task_setgid (id0, id1, id2, flags); +} + +static inline int security_task_setpgid (struct task_struct *p, pid_t pgid) +{ + return security_ops->task_setpgid (p, pgid); +} + +static inline int security_task_getpgid (struct task_struct *p) +{ + return security_ops->task_getpgid (p); +} + +static inline int security_task_getsid (struct task_struct *p) +{ + return security_ops->task_getsid (p); +} + +static inline int security_task_setgroups (int gidsetsize, gid_t *grouplist) +{ + return security_ops->task_setgroups (gidsetsize, grouplist); +} + +static inline int security_task_setnice (struct task_struct *p, int nice) +{ + return security_ops->task_setnice (p, nice); +} + +static inline int security_task_setrlimit (unsigned int resource, + struct rlimit *new_rlim) +{ + return security_ops->task_setrlimit (resource, new_rlim); +} + +static inline int security_task_setscheduler (struct task_struct *p, + int policy, + struct sched_param *lp) +{ + return security_ops->task_setscheduler (p, policy, lp); +} + +static inline int security_task_getscheduler (struct task_struct *p) +{ + return security_ops->task_getscheduler (p); +} + +static inline int security_task_kill (struct task_struct *p, + struct siginfo *info, int sig) +{ + return security_ops->task_kill (p, info, sig); +} + +static inline int security_task_wait (struct task_struct *p) +{ + return security_ops->task_wait (p); +} + +static inline int security_task_prctl (int option, unsigned long arg2, + unsigned long arg3, + unsigned long arg4, + unsigned long arg5) +{ + return security_ops->task_prctl (option, arg2, arg3, arg4, arg5); +} + +static inline void security_task_kmod_set_label (void) +{ + security_ops->task_kmod_set_label (); +} + +static inline void security_task_reparent_to_init (struct task_struct *p) +{ + security_ops->task_reparent_to_init (p); +} + +static inline int security_ipc_permission (struct kern_ipc_perm *ipcp, + short flag) +{ + return security_ops->ipc_permission (ipcp, flag); +} + +static inline int security_msg_queue_alloc (struct msg_queue *msq) +{ + return security_ops->msg_queue_alloc_security (msq); +} + +static inline void security_msg_queue_free (struct msg_queue *msq) +{ + security_ops->msg_queue_free_security (msq); +} + +static inline int security_shm_alloc (struct shmid_kernel *shp) +{ + return security_ops->shm_alloc_security (shp); +} + +static inline void security_shm_free (struct shmid_kernel *shp) +{ + security_ops->shm_free_security (shp); +} + +static inline int security_sem_alloc (struct sem_array *sma) +{ + return security_ops->sem_alloc_security (sma); +} + +static inline void security_sem_free (struct sem_array *sma) +{ + security_ops->sem_free_security (sma); +} + /* prototypes */ extern int security_scaffolding_startup (void); @@ -857,11 +1383,481 @@ extern int mod_unreg_security (const char *name, struct security_operations *ops); extern int capable (int cap); -/* global variables */ -extern struct security_operations *security_ops; +#else /* CONFIG_SECURITY */ + +static inline int security_scaffolding_startup (void) { return 0; } + +static inline int security_ptrace (struct task_struct *parent, struct task_struct * child) +{ + return 0; +} + +static inline int security_capget (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return 0; +} + +static inline int security_capset_check (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return 0; +} + +static inline void security_capset_set (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ } + +static inline int security_acct (struct file *file) +{ + return 0; +} + +static inline int security_quotactl (int cmds, int type, int id, + struct super_block * sb) +{ + return 0; +} + +static inline int security_quota_on (struct file * file) +{ + return 0; +} + +static inline int security_bprm_alloc (struct linux_binprm *bprm) +{ + return 0; +} +static inline void security_bprm_free (struct linux_binprm *bprm) +{ } +static inline void security_bprm_compute_creds (struct linux_binprm *bprm) +{ } +static inline int security_bprm_set (struct linux_binprm *bprm) +{ + return 0; +} +static inline int security_bprm_check (struct linux_binprm *bprm) +{ + return 0; +} + +static inline int security_sb_alloc (struct super_block *sb) +{ + return 0; +} + +static inline void security_sb_free (struct super_block *sb) +{ } + +static inline int security_sb_statfs (struct super_block *sb) +{ + return 0; +} + +static inline int security_sb_mount (char *dev_name, struct nameidata *nd, + char *type, unsigned long flags, + void *data) +{ + return 0; +} + +static inline int security_sb_check_sb (struct vfsmount *mnt, + struct nameidata *nd) +{ + return 0; +} + +static inline int security_sb_umount (struct vfsmount *mnt, int flags) +{ + return 0; +} + +static inline void security_sb_umount_close (struct vfsmount *mnt) +{ } + +static inline void security_sb_umount_busy (struct vfsmount *mnt) +{ } + +static inline void security_sb_post_remount (struct vfsmount *mnt, + unsigned long flags, void *data) +{ } + +static inline void security_sb_post_mountroot (void) +{ } + +static inline void security_sb_post_addmount (struct vfsmount *mnt, + struct nameidata *mountpoint_nd) +{ } + +static inline int security_sb_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ + return 0; +} + +static inline void security_sb_post_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ } + +static inline int security_inode_alloc (struct inode *inode) +{ + return 0; +} + +static inline void security_inode_free (struct inode *inode) +{ } + +static inline int security_inode_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return 0; +} + +static inline void security_inode_post_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ } + +static inline int security_inode_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ + return 0; +} + +static inline void security_inode_post_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ } + +static inline int security_inode_unlink (struct inode *dir, + struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ + return 0; +} + +static inline void security_inode_post_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ } + +static inline int security_inode_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return 0; +} + +static inline void security_inode_post_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ } + +static inline int security_inode_rmdir (struct inode *dir, + struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ + return 0; +} + +static inline void security_inode_post_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ } + +static inline int security_inode_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ + return 0; +} + +static inline void security_inode_post_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ } + +static inline int security_inode_readlink (struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_follow_link (struct dentry *dentry, + struct nameidata *nd) +{ + return 0; +} + +static inline int security_inode_permission (struct inode *inode, int mask) +{ + return 0; +} + +static inline int security_inode_permission_lite (struct inode *inode, + int mask) +{ + return 0; +} + +static inline int security_inode_setattr (struct dentry *dentry, + struct iattr *attr) +{ + return 0; +} + +static inline int security_inode_getattr (struct vfsmount *mnt, + struct dentry *dentry) +{ + return 0; +} + +static inline void security_inode_post_lookup (struct inode *inode, + struct dentry *dentry) +{ } + +static inline void security_inode_delete (struct inode *inode) +{ } + +static inline int security_inode_setxattr (struct dentry *dentry, char *name, + void *value, size_t size, int flags) +{ + return 0; +} + +static inline int security_inode_getxattr (struct dentry *dentry, char *name) +{ + return 0; +} + +static inline int security_inode_listxattr (struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_removexattr (struct dentry *dentry, char *name) +{ + return 0; +} + +static inline int security_file_permission (struct file *file, int mask) +{ + return 0; +} + +static inline int security_file_alloc (struct file *file) +{ + return 0; +} + +static inline void security_file_free (struct file *file) +{ } + +static inline int security_file_llseek (struct file *file) +{ + return 0; +} + +static inline int security_file_ioctl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return 0; +} + +static inline int security_file_mmap (struct file *file, unsigned long prot, + unsigned long flags) +{ + return 0; +} + +static inline int security_file_mprotect (struct vm_area_struct *vma, + unsigned long prot) +{ + return 0; +} + +static inline int security_file_lock (struct file *file, unsigned int cmd) +{ + return 0; +} + +static inline int security_file_fcntl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return 0; +} + +static inline int security_file_set_fowner (struct file *file) +{ + return 0; +} + +static inline int security_file_send_sigiotask (struct task_struct *tsk, + struct fown_struct *fown, + int fd, int reason) +{ + return 0; +} + +static inline int security_file_receive (struct file *file) +{ + return 0; +} + +static inline int security_task_create (unsigned long clone_flags) +{ + return 0; +} + +static inline int security_task_alloc (struct task_struct *p) +{ + return 0; +} + +static inline void security_task_free (struct task_struct *p) +{ } + +static inline int security_task_setuid (uid_t id0, uid_t id1, uid_t id2, + int flags) +{ + return 0; +} + +static inline int security_task_post_setuid (uid_t old_ruid, uid_t old_euid, + uid_t old_suid, int flags) +{ + return 0; +} + +static inline int security_task_setgid (gid_t id0, gid_t id1, gid_t id2, + int flags) +{ + return 0; +} + +static inline int security_task_setpgid (struct task_struct *p, pid_t pgid) +{ + return 0; +} + +static inline int security_task_getpgid (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_getsid (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_setgroups (int gidsetsize, gid_t *grouplist) +{ + return 0; +} + +static inline int security_task_setnice (struct task_struct *p, int nice) +{ + return 0; +} + +static inline int security_task_setrlimit (unsigned int resource, + struct rlimit *new_rlim) +{ + return 0; +} + +static inline int security_task_setscheduler (struct task_struct *p, + int policy, + struct sched_param *lp) +{ + return 0; +} + +static inline int security_task_getscheduler (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_kill (struct task_struct *p, + struct siginfo *info, int sig) +{ + return 0; +} + +static inline int security_task_wait (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_prctl (int option, unsigned long arg2, + unsigned long arg3, + unsigned long arg4, + unsigned long arg5) +{ + return 0; +} + +static inline void security_task_kmod_set_label (void) +{ } + +static inline void security_task_reparent_to_init (struct task_struct *p) +{ } + +static inline int security_ipc_permission (struct kern_ipc_perm *ipcp, + short flag) +{ + return 0; +} + +static inline int security_msg_queue_alloc (struct msg_queue *msq) +{ + return 0; +} + +static inline void security_msg_queue_free (struct msg_queue *msq) +{ } + +static inline int security_shm_alloc (struct shmid_kernel *shp) +{ + return 0; +} + +static inline void security_shm_free (struct shmid_kernel *shp) +{ } + +static inline int security_sem_alloc (struct sem_array *sma) +{ + return 0; +} + +static inline void security_sem_free (struct sem_array *sma) +{ } + + +#endif /* CONFIG_SECURITY */ -#endif /* __KERNEL__ */ #endif /* ! __LINUX_SECURITY_H */ ===== init/do_mounts.c 1.25 vs edited ===== --- 1.25/init/do_mounts.c Fri Oct 4 13:51:37 2002 +++ edited/init/do_mounts.c Wed Oct 16 00:36:15 2002 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -799,7 +800,7 @@ sys_umount("/dev", 0); sys_mount(".", "/", NULL, MS_MOVE, NULL); sys_chroot("."); - security_ops->sb_post_mountroot(); + security_sb_post_mountroot(); mount_devfs_fs (); } ===== ipc/msg.c 1.7 vs edited ===== --- 1.7/ipc/msg.c Tue Oct 8 02:20:42 2002 +++ edited/ipc/msg.c Wed Oct 16 00:37:48 2002 @@ -101,15 +101,14 @@ msq->q_perm.key = key; msq->q_perm.security = NULL; - retval = security_ops->msg_queue_alloc_security(msq); - if (retval) { + if ((retval = security_msg_queue_alloc(msq))) { kfree(msq); return retval; } id = ipc_addid(&msg_ids, &msq->q_perm, msg_ctlmni); if(id == -1) { - security_ops->msg_queue_free_security(msq); + security_msg_queue_free(msq); kfree(msq); return -ENOSPC; } @@ -281,7 +280,7 @@ free_msg(msg); } atomic_sub(msq->q_cbytes, &msg_bytes); - security_ops->msg_queue_free_security(msq); + security_msg_queue_free(msq); kfree(msq); } ===== ipc/sem.c 1.12 vs edited ===== --- 1.12/ipc/sem.c Tue Oct 8 02:20:46 2002 +++ edited/ipc/sem.c Wed Oct 16 00:38:28 2002 @@ -136,15 +136,14 @@ sma->sem_perm.key = key; sma->sem_perm.security = NULL; - retval = security_ops->sem_alloc_security(sma); - if (retval) { + if ((retval = security_sem_alloc(sma))) { ipc_free(sma, size); return retval; } id = ipc_addid(&sem_ids, &sma->sem_perm, sc_semmni); if(id == -1) { - security_ops->sem_free_security(sma); + security_sem_free(sma); ipc_free(sma, size); return -ENOSPC; } @@ -427,7 +426,7 @@ used_sems -= sma->sem_nsems; size = sizeof (*sma) + sma->sem_nsems * sizeof (struct sem); - security_ops->sem_free_security(sma); + security_sem_free(sma); ipc_free(sma, size); } ===== ipc/shm.c 1.18 vs edited ===== --- 1.18/ipc/shm.c Tue Oct 8 02:29:20 2002 +++ edited/ipc/shm.c Wed Oct 16 00:39:00 2002 @@ -116,7 +116,7 @@ shm_unlock(shp->id); shmem_lock(shp->shm_file, 0); fput (shp->shm_file); - security_ops->shm_free_security(shp); + security_shm_free(shp); kfree (shp); } @@ -188,8 +188,7 @@ shp->shm_flags = (shmflg & S_IRWXUGO); shp->shm_perm.security = NULL; - error = security_ops->shm_alloc_security(shp); - if (error) { + if ((error = security_shm_alloc(shp))) { kfree(shp); return error; } @@ -222,7 +221,7 @@ no_id: fput(file); no_file: - security_ops->shm_free_security(shp); + security_shm_free(shp); kfree(shp); return error; } ===== ipc/util.c 1.6 vs edited ===== --- 1.6/ipc/util.c Tue Oct 8 02:01:30 2002 +++ edited/ipc/util.c Wed Oct 16 00:39:12 2002 @@ -264,7 +264,7 @@ !capable(CAP_IPC_OWNER)) return -1; - return security_ops->ipc_permission(ipcp, flag); + return security_ipc_permission(ipcp, flag); } /* ===== kernel/acct.c 1.12 vs edited ===== --- 1.12/kernel/acct.c Mon Jul 22 03:12:48 2002 +++ edited/kernel/acct.c Tue Oct 15 22:53:28 2002 @@ -49,6 +49,7 @@ #include #include #include +#include #include /* @@ -222,8 +223,7 @@ } } - error = security_ops->acct(file); - if (error) + if ((error = security_acct(file))) return error; spin_lock(&acct_globals.lock); ===== kernel/capability.c 1.6 vs edited ===== --- 1.6/kernel/capability.c Sat Sep 14 06:18:49 2002 +++ edited/kernel/capability.c Tue Oct 15 22:34:12 2002 @@ -8,6 +8,7 @@ */ #include +#include #include unsigned securebits = SECUREBITS_DEFAULT; /* systemwide security settings */ @@ -63,7 +64,7 @@ data.permitted = cap_t(target->cap_permitted); data.inheritable = cap_t(target->cap_inheritable); data.effective = cap_t(target->cap_effective); - ret = security_ops->capget(target, &data.effective, &data.inheritable, &data.permitted); + ret = security_capget(target, &data.effective, &data.inheritable, &data.permitted); out: read_unlock(&tasklist_lock); @@ -88,7 +89,7 @@ do_each_thread(g, target) { if (target->pgrp != pgrp) continue; - security_ops->capset_set(target, effective, inheritable, permitted); + security_capset_set(target, effective, inheritable, permitted); } while_each_thread(g, target); } @@ -105,7 +106,7 @@ do_each_thread(g, target) { if (target == current || target->pid == 1) continue; - security_ops->capset_set(target, effective, inheritable, permitted); + security_capset_set(target, effective, inheritable, permitted); } while_each_thread(g, target); } @@ -163,7 +164,7 @@ ret = -EPERM; - if (security_ops->capset_check(target, &effective, &inheritable, &permitted)) + if (security_capset_check(target, &effective, &inheritable, &permitted)) goto out; if (!cap_issubset(inheritable, cap_combine(target->cap_inheritable, @@ -190,7 +191,7 @@ else /* all procs in process group */ cap_set_pg(-pid, &effective, &inheritable, &permitted); } else { - security_ops->capset_set(target, &effective, &inheritable, &permitted); + security_capset_set(target, &effective, &inheritable, &permitted); } out: ===== kernel/exit.c 1.72 vs edited ===== --- 1.72/kernel/exit.c Tue Oct 15 15:08:06 2002 +++ edited/kernel/exit.c Wed Oct 16 00:35:10 2002 @@ -67,7 +67,7 @@ wait_task_inactive(p); atomic_dec(&p->user->processes); - security_ops->task_free_security(p); + security_task_free(p); free_uid(p->user); write_lock_irq(&tasklist_lock); if (unlikely(p->ptrace)) @@ -248,7 +248,7 @@ /* cpus_allowed? */ /* rt_priority? */ /* signals? */ - security_ops->task_reparent_to_init(current); + security_task_reparent_to_init(current); memcpy(current->rlim, init_task.rlim, sizeof(*(current->rlim))); current->user = INIT_USER; @@ -774,7 +774,7 @@ if (current->tgid != p->tgid && delay_group_leader(p)) return 2; - if (security_ops->task_wait(p)) + if (security_task_wait(p)) return 0; return 1; ===== kernel/fork.c 1.87 vs edited ===== --- 1.87/kernel/fork.c Mon Oct 7 15:17:19 2002 +++ edited/kernel/fork.c Wed Oct 16 00:28:30 2002 @@ -682,8 +682,7 @@ if ((clone_flags & CLONE_DETACHED) && !(clone_flags & CLONE_THREAD)) return ERR_PTR(-EINVAL); - retval = security_ops->task_create(clone_flags); - if (retval) + if ((retval = security_task_create(clone_flags))) goto fork_out; retval = -ENOMEM; @@ -772,7 +771,7 @@ INIT_LIST_HEAD(&p->local_pages); retval = -ENOMEM; - if (security_ops->task_alloc_security(p)) + if (security_task_alloc(p)) goto bad_fork_cleanup; /* copy all the process information */ if (copy_semundo(clone_flags, p)) @@ -922,7 +921,7 @@ bad_fork_cleanup_semundo: exit_semundo(p); bad_fork_cleanup_security: - security_ops->task_free_security(p); + security_task_free(p); bad_fork_cleanup: if (p->pid > 0) free_pidmap(p->pid); ===== kernel/kmod.c 1.15 vs edited ===== --- 1.15/kernel/kmod.c Tue Oct 1 01:54:49 2002 +++ edited/kernel/kmod.c Wed Oct 16 00:28:59 2002 @@ -29,6 +29,7 @@ #include #include #include +#include #include @@ -134,7 +135,7 @@ /* Give kmod all effective privileges.. */ curtask->euid = curtask->fsuid = 0; curtask->egid = curtask->fsgid = 0; - security_ops->task_kmod_set_label(); + security_task_kmod_set_label(); /* Allow execve args to be in kernel space. */ set_fs(KERNEL_DS); ===== kernel/ptrace.c 1.18 vs edited ===== --- 1.18/kernel/ptrace.c Sun Sep 15 19:57:15 2002 +++ edited/kernel/ptrace.c Wed Oct 16 00:11:10 2002 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -100,8 +101,7 @@ /* the same process cannot be attached many times */ if (task->ptrace & PT_PTRACED) goto bad; - retval = security_ops->ptrace(current, task); - if (retval) + if ((retval = security_ptrace(current, task))) goto bad; /* Go */ ===== kernel/sched.c 1.140 vs edited ===== --- 1.140/kernel/sched.c Mon Oct 14 05:30:06 2002 +++ edited/kernel/sched.c Wed Oct 16 00:29:50 2002 @@ -1329,8 +1329,7 @@ if (nice > 19) nice = 19; - retval = security_ops->task_setnice(current, nice); - if (retval) + if ((retval = security_task_setnice(current, nice))) return retval; set_user_nice(current, nice); @@ -1451,8 +1450,7 @@ !capable(CAP_SYS_NICE)) goto out_unlock; - retval = security_ops->task_setscheduler(p, policy, &lp); - if (retval) + if ((retval = security_task_setscheduler(p, policy, &lp))) goto out_unlock; array = p->array; @@ -1515,8 +1513,7 @@ read_lock(&tasklist_lock); p = find_process_by_pid(pid); if (p) { - retval = security_ops->task_getscheduler(p); - if (!retval) + if (!(retval = security_task_getscheduler(p))) retval = p->policy; } read_unlock(&tasklist_lock); @@ -1545,8 +1542,7 @@ if (!p) goto out_unlock; - retval = security_ops->task_getscheduler(p); - if (retval) + if ((retval = security_task_getscheduler(p))) goto out_unlock; lp.sched_priority = p->rt_priority; @@ -1778,8 +1774,7 @@ if (!p) goto out_unlock; - retval = security_ops->task_getscheduler(p); - if (retval) + if ((retval = security_task_getscheduler(p))) goto out_unlock; jiffies_to_timespec(p->policy & SCHED_FIFO ? ===== kernel/signal.c 1.48 vs edited ===== --- 1.48/kernel/signal.c Thu Oct 3 02:26:00 2002 +++ edited/kernel/signal.c Wed Oct 16 00:30:19 2002 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -706,8 +707,7 @@ ret = -EPERM; if (bad_signal(sig, info, t)) goto out; - ret = security_ops->task_kill(t, info, sig); - if (ret) + if ((ret = security_task_kill(t, info, sig))) goto out; /* The null signal is a permissions and process existence probe. ===== kernel/sys.c 1.30 vs edited ===== --- 1.30/kernel/sys.c Tue Oct 15 14:45:52 2002 +++ edited/kernel/sys.c Wed Oct 16 00:33:50 2002 @@ -204,6 +204,7 @@ cond_syscall(sys_quotactl) cond_syscall(sys_acct) cond_syscall(sys_lookup_dcookie) +cond_syscall(sys_security) static int set_one_prio(struct task_struct *p, int niceval, int error) { @@ -479,8 +480,7 @@ int new_egid = old_egid; int retval; - retval = security_ops->task_setgid(rgid, egid, (gid_t)-1, LSM_SETID_RE); - if (retval) + if ((retval = security_task_setgid(rgid, egid, (gid_t)-1, LSM_SETID_RE))) return retval; if (rgid != (gid_t) -1) { @@ -525,8 +525,7 @@ int old_egid = current->egid; int retval; - retval = security_ops->task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_ID); - if (retval) + if ((retval = security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_ID))) return retval; if (capable(CAP_SETGID)) @@ -599,8 +598,7 @@ int old_ruid, old_euid, old_suid, new_ruid, new_euid; int retval; - retval = security_ops->task_setuid(ruid, euid, (uid_t)-1, LSM_SETID_RE); - if (retval) + if ((retval = security_task_setuid(ruid, euid, (uid_t)-1, LSM_SETID_RE))) return retval; new_ruid = old_ruid = current->uid; @@ -638,7 +636,7 @@ current->suid = current->euid; current->fsuid = current->euid; - return security_ops->task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RE); + return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RE); } @@ -660,8 +658,7 @@ int old_ruid, old_suid, new_ruid, new_suid; int retval; - retval = security_ops->task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_ID); - if (retval) + if ((retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_ID))) return retval; old_ruid = new_ruid = current->uid; @@ -683,7 +680,7 @@ current->fsuid = current->euid = uid; current->suid = new_suid; - return security_ops->task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_ID); + return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_ID); } @@ -698,8 +695,7 @@ int old_suid = current->suid; int retval; - retval = security_ops->task_setuid(ruid, euid, suid, LSM_SETID_RES); - if (retval) + if ((retval = security_task_setuid(ruid, euid, suid, LSM_SETID_RES))) return retval; if (!capable(CAP_SETUID)) { @@ -729,7 +725,7 @@ if (suid != (uid_t) -1) current->suid = suid; - return security_ops->task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RES); + return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RES); } asmlinkage long sys_getresuid(uid_t *ruid, uid_t *euid, uid_t *suid) @@ -750,8 +746,7 @@ { int retval; - retval = security_ops->task_setgid(rgid, egid, sgid, LSM_SETID_RES); - if (retval) + if ((retval = security_task_setgid(rgid, egid, sgid, LSM_SETID_RES))) return retval; if (!capable(CAP_SETGID)) { @@ -804,8 +799,7 @@ int old_fsuid; int retval; - retval = security_ops->task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS); - if (retval) + if ((retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS))) return retval; old_fsuid = current->fsuid; @@ -821,8 +815,7 @@ current->fsuid = uid; } - retval = security_ops->task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS); - if (retval) + if ((retval = security_task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS))) return retval; return old_fsuid; @@ -836,8 +829,7 @@ int old_fsgid; int retval; - retval = security_ops->task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS); - if (retval) + if ((retval = security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS))) return retval; old_fsgid = current->fsgid; @@ -962,8 +954,7 @@ retval = -ESRCH; if (p) { - retval = security_ops->task_getpgid(p); - if (!retval) + if (!(retval = security_task_getpgid(p))) retval = p->pgrp; } read_unlock(&tasklist_lock); @@ -990,8 +981,7 @@ retval = -ESRCH; if(p) { - retval = security_ops->task_getsid(p); - if (!retval) + if (!(retval = security_task_getsid(p))) retval = p->session; } read_unlock(&tasklist_lock); @@ -1072,8 +1062,7 @@ return -EINVAL; if(copy_from_user(groups, grouplist, gidsetsize * sizeof(gid_t))) return -EFAULT; - retval = security_ops->task_setgroups(gidsetsize, groups); - if (retval) + if ((retval = security_task_setgroups(gidsetsize, groups))) return retval; memcpy(current->groups, groups, gidsetsize * sizeof(gid_t)); current->ngroups = gidsetsize; @@ -1236,8 +1225,7 @@ return -EPERM; } - retval = security_ops->task_setrlimit(resource, &new_rlim); - if (retval) + if ((retval = security_task_setrlimit(resource, &new_rlim))) return retval; *old_rlim = new_rlim; @@ -1311,8 +1299,7 @@ int error = 0; int sig; - error = security_ops->task_prctl(option, arg2, arg3, arg4, arg5); - if (error) + if ((error = security_task_prctl(option, arg2, arg3, arg4, arg5))) return error; switch (option) { ===== kernel/uid16.c 1.2 vs edited ===== --- 1.2/kernel/uid16.c Fri Jul 19 16:00:55 2002 +++ edited/kernel/uid16.c Wed Oct 16 00:30:43 2002 @@ -140,8 +140,7 @@ return -EFAULT; for (i = 0 ; i < gidsetsize ; i++) new_groups[i] = (gid_t)groups[i]; - i = security_ops->task_setgroups(gidsetsize, new_groups); - if (i) + if ((i = security_task_setgroups(gidsetsize, new_groups))) return i; memcpy(current->groups, new_groups, gidsetsize * sizeof(gid_t)); current->ngroups = gidsetsize; ===== mm/mmap.c 1.53 vs edited ===== --- 1.53/mm/mmap.c Tue Oct 15 15:08:06 2002 +++ edited/mm/mmap.c Wed Oct 16 00:36:48 2002 @@ -498,8 +498,7 @@ } } - error = security_ops->file_mmap(file, prot, flags); - if (error) + if ((error = security_file_mmap(file, prot, flags))) return error; /* Clear old maps */ ===== mm/mprotect.c 1.19 vs edited ===== --- 1.19/mm/mprotect.c Tue Oct 1 16:43:14 2002 +++ edited/mm/mprotect.c Wed Oct 16 00:36:58 2002 @@ -262,8 +262,7 @@ goto out; } - error = security_ops->file_mprotect(vma, prot); - if (error) + if ((error = security_file_mprotect(vma, prot))) goto out; if (vma->vm_end > end) { ===== net/core/scm.c 1.3 vs edited ===== --- 1.3/net/core/scm.c Mon Jul 22 03:12:48 2002 +++ edited/net/core/scm.c Wed Oct 16 00:41:37 2002 @@ -217,8 +217,7 @@ for (i=0, cmfptr=(int*)CMSG_DATA(cm); ifile_receive(fp[i]); - if (err) + if ((err = security_file_receive(fp[i]))) break; err = get_unused_fd(); if (err < 0) ===== net/decnet/af_decnet.c 1.18 vs edited ===== --- 1.18/net/decnet/af_decnet.c Tue Oct 8 07:02:41 2002 +++ edited/net/decnet/af_decnet.c Wed Oct 16 00:42:30 2002 @@ -113,6 +113,7 @@ #include #include #include +#include #include #include #include @@ -794,7 +795,7 @@ * dn_prot_sock ? Would be nice if the capable call would go there * too. */ - if (security_ops->dn_prot_sock(saddr) && + if (security_dn_prot_sock(saddr) && !capable(CAP_NET_BIND_SERVICE) || saddr->sdn_objnum || (saddr->sdn_flags & SDF_WILD)) return -EACCES; ===== security/Config.in 1.3 vs edited ===== --- 1.3/security/Config.in Sat Jul 20 12:05:09 2002 +++ edited/security/Config.in Tue Oct 15 22:24:46 2002 @@ -3,5 +3,8 @@ # mainmenu_option next_comment comment 'Security options' -define_bool CONFIG_SECURITY_CAPABILITIES y +bool 'Enable different security models' CONFIG_SECURITY +if [ "$CONFIG_SECURITY" = "y" ]; then + dep_tristate ' Default Linux Capabilities' CONFIG_SECURITY_CAPABILITIES $CONFIG_SECURITY +fi endmenu ===== security/Makefile 1.1 vs edited ===== --- 1.1/security/Makefile Fri Jul 19 15:55:56 2002 +++ edited/security/Makefile Tue Oct 15 22:26:19 2002 @@ -6,8 +6,7 @@ export-objs := security.o # Object file lists -obj-y := security.o dummy.o - +obj-$(CONFIG_SECURITY) += security.o dummy.o obj-$(CONFIG_SECURITY_CAPABILITIES) += capability.o include $(TOPDIR)/Rules.make From greg@kroah.com Wed Oct 16 11:59:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 11:59:50 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GIxZtG010496 for ; Wed, 16 Oct 2002 11:59:36 -0700 Received: (qmail 25527 invoked by uid 500); 16 Oct 2002 18:59:28 -0000 Date: Wed, 16 Oct 2002 11:59:28 -0700 From: Greg KH To: netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks Message-ID: <20021016185927.GA25475@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.com> <20021016081539.GF20421@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016081539.GF20421@kroah.com> User-Agent: Mutt/1.4i X-archive-position: 728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Wed, Oct 16, 2002 at 01:15:40AM -0700, Greg KH wrote: > On Tue, Oct 15, 2002 at 05:07:06PM -0700, Greg KH wrote: > > > > I'll work on fixing up the rest of the hooks, and removing the external > > reference to security_ops, and actually test this thing, later this > > evening. > > Here's all the hooks converted over to function calls. Chris Wright > pointed out I need to do some extra work with the existing capabilities > hooks, but I'll do that in the morning. Ok, here's a working version (I'm typing from it right now), with all of the capability logic working again. This does make the security/built-in.o file this size with CONFIG_SECURITY=y text data bss dec hex filename 1611 0 0 1611 64b security/built-in.o But this is due to the code there being moved from other parts of the kernel in the initial LSM merge, so there is no real increased code size. It's also now pretty easy to tweak things to drop capability support alltogether, which should save the above space, and make the embedded people happy. If we ever end up with a CONFIG_REALLY_SMALL option, I'll make those changes. Could people please look this over and offer any comments? I'm especially interested in comments regarding the changes I've made to security/Config.in, security/Makefile, include/linux/security.h and security/capability.c. Again, this is against 2.5.43. If no one has any problems with this, I'll send it on to Linus later this evening. thanks, greg k-h ===== arch/arm/kernel/ptrace.c 1.14 vs edited ===== --- 1.14/arch/arm/kernel/ptrace.c Sun Oct 13 07:32:28 2002 +++ edited/arch/arm/kernel/ptrace.c Wed Oct 16 00:46:07 2002 @@ -719,8 +719,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/i386/kernel/ptrace.c 1.13 vs edited ===== --- 1.13/arch/i386/kernel/ptrace.c Fri Jul 19 16:00:55 2002 +++ edited/arch/i386/kernel/ptrace.c Tue Oct 15 22:24:45 2002 @@ -160,8 +160,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ia64/kernel/ptrace.c 1.12 vs edited ===== --- 1.12/arch/ia64/kernel/ptrace.c Tue Sep 17 23:22:09 2002 +++ edited/arch/ia64/kernel/ptrace.c Wed Oct 16 00:45:53 2002 @@ -1101,8 +1101,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; current->ptrace |= PT_PTRACED; ret = 0; ===== arch/ppc/kernel/ptrace.c 1.10 vs edited ===== --- 1.10/arch/ppc/kernel/ptrace.c Sun Sep 15 21:51:59 2002 +++ edited/arch/ppc/kernel/ptrace.c Wed Oct 16 00:45:41 2002 @@ -166,8 +166,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ppc64/kernel/ptrace.c 1.3 vs edited ===== --- 1.3/arch/ppc64/kernel/ptrace.c Wed Aug 28 23:42:43 2002 +++ edited/arch/ppc64/kernel/ptrace.c Wed Oct 16 00:45:16 2002 @@ -59,8 +59,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ppc64/kernel/ptrace32.c 1.5 vs edited ===== --- 1.5/arch/ppc64/kernel/ptrace32.c Wed Aug 28 23:42:43 2002 +++ edited/arch/ppc64/kernel/ptrace32.c Wed Oct 16 00:45:29 2002 @@ -48,8 +48,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/ppc64/kernel/sys_ppc32.c 1.24 vs edited ===== --- 1.24/arch/ppc64/kernel/sys_ppc32.c Fri Oct 11 19:04:17 2002 +++ edited/arch/ppc64/kernel/sys_ppc32.c Wed Oct 16 00:15:31 2002 @@ -53,6 +53,7 @@ #include #include #include +#include #include #include @@ -3519,8 +3520,7 @@ if ((retval = bprm.envc) < 0) goto out_mm; - retval = security_ops->bprm_alloc_security(&bprm); - if (retval) + if ((retval = security_bprm_alloc(&bprm))) goto out; retval = prepare_binprm(&bprm); @@ -3543,7 +3543,7 @@ retval = search_binary_handler(&bprm,regs); if (retval >= 0) { /* execve success */ - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); return retval; } @@ -3556,7 +3556,7 @@ } if (bprm.security) - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); out_mm: mmdrop(bprm.mm); ===== arch/s390/kernel/ptrace.c 1.9 vs edited ===== --- 1.9/arch/s390/kernel/ptrace.c Fri Oct 4 09:16:18 2002 +++ edited/arch/s390/kernel/ptrace.c Wed Oct 16 00:44:51 2002 @@ -330,8 +330,7 @@ ret = -EPERM; if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/s390x/kernel/ptrace.c 1.8 vs edited ===== --- 1.8/arch/s390x/kernel/ptrace.c Fri Oct 4 09:16:18 2002 +++ edited/arch/s390x/kernel/ptrace.c Wed Oct 16 00:44:40 2002 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -568,8 +569,7 @@ ret = -EPERM; if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== arch/sparc/kernel/ptrace.c 1.11 vs edited ===== --- 1.11/arch/sparc/kernel/ptrace.c Sat Aug 24 04:08:41 2002 +++ edited/arch/sparc/kernel/ptrace.c Wed Oct 16 00:44:06 2002 @@ -291,8 +291,7 @@ pt_error_return(regs, EPERM); goto out; } - ret = security_ops->ptrace(current->parent, current); - if (ret) { + if ((ret = security_ptrace(current->parent, current))) { pt_error_return(regs, -ret); goto out; } ===== arch/sparc64/kernel/ptrace.c 1.16 vs edited ===== --- 1.16/arch/sparc64/kernel/ptrace.c Sat Aug 24 03:59:14 2002 +++ edited/arch/sparc64/kernel/ptrace.c Wed Oct 16 00:43:53 2002 @@ -140,8 +140,7 @@ pt_error_return(regs, EPERM); goto out; } - ret = security_ops->ptrace(current->parent, current); - if (ret) { + if ((ret = security_ptrace(current->parent, current))) { pt_error_return(regs, -ret); goto out; } ===== arch/sparc64/kernel/sys_sparc32.c 1.39 vs edited ===== --- 1.39/arch/sparc64/kernel/sys_sparc32.c Mon Oct 14 05:17:46 2002 +++ edited/arch/sparc64/kernel/sys_sparc32.c Wed Oct 16 00:14:27 2002 @@ -2972,8 +2972,7 @@ if ((retval = bprm.envc) < 0) goto out_mm; - retval = security_ops->bprm_alloc_security(&bprm); - if (retval) + if ((retval = security_bprm_alloc(&bprm))) goto out; retval = prepare_binprm(&bprm); @@ -2996,7 +2995,7 @@ retval = search_binary_handler(&bprm, regs); if (retval >= 0) { /* execve success */ - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); return retval; } @@ -3009,7 +3008,7 @@ } if (bprm.security) - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); out_mm: mmdrop(bprm.mm); ===== arch/um/kernel/ptrace.c 1.1 vs edited ===== --- 1.1/arch/um/kernel/ptrace.c Fri Sep 6 10:50:31 2002 +++ edited/arch/um/kernel/ptrace.c Wed Oct 16 00:43:41 2002 @@ -33,8 +33,7 @@ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if(ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ ===== arch/x86_64/kernel/ptrace.c 1.4 vs edited ===== --- 1.4/arch/x86_64/kernel/ptrace.c Fri Oct 11 16:52:38 2002 +++ edited/arch/x86_64/kernel/ptrace.c Wed Oct 16 00:43:30 2002 @@ -178,8 +178,7 @@ /* are we already being traced? */ if (current->ptrace & PT_PTRACED) goto out; - ret = security_ops->ptrace(current->parent, current); - if (ret) + if ((ret = security_ptrace(current->parent, current))) goto out; /* set the ptrace bit in the process flags. */ current->ptrace |= PT_PTRACED; ===== drivers/base/fs/class.c 1.2 vs edited ===== --- 1.2/drivers/base/fs/class.c Mon Aug 26 08:39:22 2002 +++ edited/drivers/base/fs/class.c Tue Oct 15 22:24:45 2002 @@ -7,6 +7,8 @@ #include #include #include +#include +#include #include "fs.h" static struct driver_dir_entry class_dir; ===== drivers/base/fs/intf.c 1.2 vs edited ===== --- 1.2/drivers/base/fs/intf.c Mon Aug 26 09:24:18 2002 +++ edited/drivers/base/fs/intf.c Tue Oct 15 22:24:45 2002 @@ -4,6 +4,8 @@ #include #include +#include +#include #include "fs.h" /** ===== fs/attr.c 1.10 vs edited ===== --- 1.10/fs/attr.c Mon Jul 22 03:12:48 2002 +++ edited/fs/attr.c Tue Oct 15 23:50:23 2002 @@ -153,13 +153,12 @@ } if (inode->i_op && inode->i_op->setattr) { - error = security_ops->inode_setattr(dentry, attr); - if (!error) + if (!(error = security_inode_setattr(dentry, attr))) error = inode->i_op->setattr(dentry, attr); } else { error = inode_change_ok(inode, attr); if (!error) - error = security_ops->inode_setattr(dentry, attr); + error = security_inode_setattr(dentry, attr); if (!error) { if ((ia_valid & ATTR_UID && attr->ia_uid != inode->i_uid) || (ia_valid & ATTR_GID && attr->ia_gid != inode->i_gid)) ===== fs/dquot.c 1.48 vs edited ===== --- 1.48/fs/dquot.c Sun Oct 13 08:39:23 2002 +++ edited/fs/dquot.c Tue Oct 15 22:55:27 2002 @@ -69,6 +69,7 @@ #include #include #include +#include #include @@ -1305,8 +1306,7 @@ error = -EIO; if (!f->f_op || !f->f_op->read || !f->f_op->write) goto out_f; - error = security_ops->quota_on(f); - if (error) + if ((error = security_quota_on(f))) goto out_f; inode = f->f_dentry->d_inode; error = -EACCES; ===== fs/exec.c 1.51 vs edited ===== --- 1.51/fs/exec.c Sun Oct 13 09:32:22 2002 +++ edited/fs/exec.c Tue Oct 15 23:03:20 2002 @@ -43,6 +43,7 @@ #include #include #include +#include #include #include @@ -818,8 +819,7 @@ } /* fill in binprm security blob */ - retval = security_ops->bprm_set_security(bprm); - if (retval) + if ((retval = security_bprm_set(bprm))) return retval; memset(bprm->buf,0,BINPRM_BUF_SIZE); @@ -867,7 +867,7 @@ if(do_unlock) unlock_kernel(); - security_ops->bprm_compute_creds(bprm); + security_bprm_compute_creds(bprm); } void remove_arg_zero(struct linux_binprm *bprm) @@ -936,8 +936,7 @@ } } #endif - retval = security_ops->bprm_check_security(bprm); - if (retval) + if ((retval = security_bprm_check(bprm))) return retval; /* kernel module loader fixup */ @@ -1033,8 +1032,7 @@ if ((retval = bprm.envc) < 0) goto out_mm; - retval = security_ops->bprm_alloc_security(&bprm); - if (retval) + if ((retval = security_bprm_alloc(&bprm))) goto out; retval = prepare_binprm(&bprm); @@ -1057,7 +1055,7 @@ retval = search_binary_handler(&bprm,regs); if (retval >= 0) { /* execve success */ - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); return retval; } @@ -1070,7 +1068,7 @@ } if (bprm.security) - security_ops->bprm_free_security(&bprm); + security_bprm_free(&bprm); out_mm: mmdrop(bprm.mm); ===== fs/fcntl.c 1.20 vs edited ===== --- 1.20/fs/fcntl.c Sun Oct 13 08:39:40 2002 +++ edited/fs/fcntl.c Wed Oct 16 00:04:50 2002 @@ -274,8 +274,7 @@ { int err; - err = security_ops->file_set_fowner(filp); - if (err) + if ((err = security_file_set_fowner(filp))) return err; f_modown(filp, arg, current->uid, current->euid, force); @@ -368,8 +367,7 @@ if (!filp) goto out; - err = security_ops->file_fcntl(filp, cmd, arg); - if (err) { + if ((err = security_file_fcntl(filp, cmd, arg))) { fput(filp); return err; } @@ -392,8 +390,7 @@ if (!filp) goto out; - err = security_ops->file_fcntl(filp, cmd, arg); - if (err) { + if ((err = security_file_fcntl(filp, cmd, arg))) { fput(filp); return err; } @@ -444,7 +441,7 @@ if (!sigio_perm(p, fown)) return; - if (security_ops->file_send_sigiotask(p, fown, fd, reason)) + if (security_file_send_sigiotask(p, fown, fd, reason)) return; switch (fown->signum) { ===== fs/file_table.c 1.13 vs edited ===== --- 1.13/fs/file_table.c Sun Oct 13 08:39:40 2002 +++ edited/fs/file_table.c Wed Oct 16 00:04:27 2002 @@ -46,7 +46,7 @@ files_stat.nr_free_files--; new_one: memset(f, 0, sizeof(*f)); - if (security_ops->file_alloc_security(f)) { + if (security_file_alloc(f)) { list_add(&f->f_list, &free_list); files_stat.nr_free_files++; file_list_unlock(); @@ -127,7 +127,7 @@ if (file->f_op && file->f_op->release) file->f_op->release(inode, file); - security_ops->file_free_security(file); + security_file_free(file); fops_put(file->f_op); if (file->f_mode & FMODE_WRITE) put_write_access(inode); @@ -160,7 +160,7 @@ void put_filp(struct file *file) { if(atomic_dec_and_test(&file->f_count)) { - security_ops->file_free_security(file); + security_file_free(file); file_list_lock(); list_del(&file->f_list); list_add(&file->f_list, &free_list); ===== fs/inode.c 1.74 vs edited ===== --- 1.74/fs/inode.c Sun Oct 13 08:39:23 2002 +++ edited/fs/inode.c Tue Oct 15 23:49:49 2002 @@ -120,7 +120,7 @@ inode->i_bdev = NULL; inode->i_cdev = NULL; inode->i_security = NULL; - if (security_ops->inode_alloc_security(inode)) { + if (security_inode_alloc(inode)) { if (inode->i_sb->s_op->destroy_inode) inode->i_sb->s_op->destroy_inode(inode); else @@ -146,7 +146,7 @@ { if (inode_has_buffers(inode)) BUG(); - security_ops->inode_free_security(inode); + security_inode_free(inode); if (inode->i_sb->s_op->destroy_inode) { inode->i_sb->s_op->destroy_inode(inode); } else { @@ -922,7 +922,7 @@ if (inode->i_data.nrpages) truncate_inode_pages(&inode->i_data, 0); - security_ops->inode_delete(inode); + security_inode_delete(inode); if (op && op->delete_inode) { void (*delete)(struct inode *) = op->delete_inode; ===== fs/ioctl.c 1.5 vs edited ===== --- 1.5/fs/ioctl.c Mon Jul 22 03:12:48 2002 +++ edited/fs/ioctl.c Wed Oct 16 00:06:16 2002 @@ -59,8 +59,7 @@ goto out; error = 0; - error = security_ops->file_ioctl(filp, cmd, arg); - if (error) { + if ((error = security_file_ioctl(filp, cmd, arg))) { fput(filp); goto out; } ===== fs/locks.c 1.30 vs edited ===== --- 1.30/fs/locks.c Thu Sep 26 10:36:16 2002 +++ edited/fs/locks.c Wed Oct 16 00:06:00 2002 @@ -122,6 +122,7 @@ #include #include #include +#include #include #include @@ -1170,8 +1171,7 @@ return -EACCES; if (!S_ISREG(inode->i_mode)) return -EINVAL; - error = security_ops->file_lock(filp, arg); - if (error) + if ((error = security_file_lock(filp, arg))) return error; lock_kernel(); @@ -1284,8 +1284,7 @@ if (error) goto out_putf; - error = security_ops->file_lock(filp, cmd); - if (error) + if ((error = security_file_lock(filp, cmd))) goto out_free; for (;;) { @@ -1434,8 +1433,7 @@ goto out; } - error = security_ops->file_lock(filp, file_lock->fl_type); - if (error) + if ((error = security_file_lock(filp, file_lock->fl_type))) goto out; if (filp->f_op && filp->f_op->lock != NULL) { @@ -1574,8 +1572,7 @@ goto out; } - error = security_ops->file_lock(filp, file_lock->fl_type); - if (error) + if ((error = security_file_lock(filp, file_lock->fl_type))) goto out; if (filp->f_op && filp->f_op->lock != NULL) { ===== fs/namei.c 1.56 vs edited ===== --- 1.56/fs/namei.c Tue Sep 17 12:52:27 2002 +++ edited/fs/namei.c Tue Oct 15 23:47:28 2002 @@ -218,7 +218,7 @@ if (retval) return retval; - return security_ops->inode_permission(inode, mask); + return security_inode_permission(inode, mask); } /* @@ -340,7 +340,7 @@ return -EACCES; ok: - return security_ops->inode_permission_lite(inode, MAY_EXEC); + return security_inode_permission_lite(inode, MAY_EXEC); } /* @@ -374,7 +374,7 @@ dput(dentry); else { result = dentry; - security_ops->inode_post_lookup(dir, result); + security_inode_post_lookup(dir, result); } } up(&dir->i_sem); @@ -413,8 +413,7 @@ current->state = TASK_RUNNING; schedule(); } - err = security_ops->inode_follow_link(dentry, nd); - if (err) + if ((err = security_inode_follow_link(dentry, nd))) goto loop; current->link_count++; current->total_link_count++; @@ -918,7 +917,7 @@ dentry = inode->i_op->lookup(inode, new); if (!dentry) { dentry = new; - security_ops->inode_post_lookup(inode, dentry); + security_inode_post_lookup(inode, dentry); } else dput(new); } @@ -1125,14 +1124,13 @@ return -EACCES; /* shouldn't it be ENOSYS? */ mode &= S_IALLUGO; mode |= S_IFREG; - error = security_ops->inode_create(dir, dentry, mode); - if (error) + if ((error = security_inode_create(dir, dentry, mode))) return error; DQUOT_INIT(dir); error = dir->i_op->create(dir, dentry, mode); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_create(dir, dentry, mode); + security_inode_post_create(dir, dentry, mode); } return error; } @@ -1344,8 +1342,7 @@ * stored in nd->last.name and we will have to putname() it when we * are done. Procfs-like symlinks just set LAST_BIND. */ - error = security_ops->inode_follow_link(dentry, nd); - if (error) + if ((error = security_inode_follow_link(dentry, nd))) goto exit_dput; UPDATE_ATIME(dentry->d_inode); error = dentry->d_inode->i_op->follow_link(dentry, nd); @@ -1410,15 +1407,14 @@ if (!dir->i_op || !dir->i_op->mknod) return -EPERM; - error = security_ops->inode_mknod(dir, dentry, mode, dev); - if (error) + if ((error = security_inode_mknod(dir, dentry, mode, dev))) return error; DQUOT_INIT(dir); error = dir->i_op->mknod(dir, dentry, mode, dev); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_mknod(dir, dentry, mode, dev); + security_inode_post_mknod(dir, dentry, mode, dev); } return error; } @@ -1478,15 +1474,14 @@ return -EPERM; mode &= (S_IRWXUGO|S_ISVTX); - error = security_ops->inode_mkdir(dir, dentry, mode); - if (error) + if ((error = security_inode_mkdir(dir, dentry, mode))) return error; DQUOT_INIT(dir); error = dir->i_op->mkdir(dir, dentry, mode); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_mkdir(dir,dentry, mode); + security_inode_post_mkdir(dir,dentry, mode); } return error; } @@ -1570,8 +1565,7 @@ if (d_mountpoint(dentry)) error = -EBUSY; else { - error = security_ops->inode_rmdir(dir, dentry); - if (!error) { + if (!(error = security_inode_rmdir(dir, dentry))) { error = dir->i_op->rmdir(dir, dentry); if (!error) dentry->d_inode->i_flags |= S_DEAD; @@ -1644,10 +1638,8 @@ if (d_mountpoint(dentry)) error = -EBUSY; else { - error = security_ops->inode_unlink(dir, dentry); - if (!error) { + if (!(error = security_inode_unlink(dir, dentry))) error = dir->i_op->unlink(dir, dentry); - } } up(&dentry->d_inode->i_sem); if (!error) { @@ -1709,15 +1701,14 @@ if (!dir->i_op || !dir->i_op->symlink) return -EPERM; - error = security_ops->inode_symlink(dir, dentry, oldname); - if (error) + if ((error = security_inode_symlink(dir, dentry, oldname))) return error; DQUOT_INIT(dir); error = dir->i_op->symlink(dir, dentry, oldname); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_symlink(dir, dentry, oldname); + security_inode_post_symlink(dir, dentry, oldname); } return error; } @@ -1780,8 +1771,7 @@ if (S_ISDIR(old_dentry->d_inode->i_mode)) return -EPERM; - error = security_ops->inode_link(old_dentry, dir, new_dentry); - if (error) + if ((error = security_inode_link(old_dentry, dir, new_dentry))) return error; down(&old_dentry->d_inode->i_sem); @@ -1790,7 +1780,7 @@ up(&old_dentry->d_inode->i_sem); if (!error) { inode_dir_notify(dir, DN_CREATE); - security_ops->inode_post_link(old_dentry, dir, new_dentry); + security_inode_post_link(old_dentry, dir, new_dentry); } return error; } @@ -1889,8 +1879,7 @@ return error; } - error = security_ops->inode_rename(old_dir, old_dentry, new_dir, new_dentry); - if (error) + if ((error = security_inode_rename(old_dir, old_dentry, new_dir, new_dentry))) return error; target = new_dentry->d_inode; @@ -1912,8 +1901,8 @@ } if (!error) { d_move(old_dentry,new_dentry); - security_ops->inode_post_rename(old_dir, old_dentry, - new_dir, new_dentry); + security_inode_post_rename(old_dir, old_dentry, + new_dir, new_dentry); } return error; } @@ -1924,8 +1913,7 @@ struct inode *target; int error; - error = security_ops->inode_rename(old_dir, old_dentry, new_dir, new_dentry); - if (error) + if ((error = security_inode_rename(old_dir, old_dentry, new_dir, new_dentry))) return error; dget(new_dentry); @@ -1940,7 +1928,7 @@ /* The following d_move() should become unconditional */ if (!(old_dir->i_sb->s_type->fs_flags & FS_ODD_RENAME)) d_move(old_dentry, new_dentry); - security_ops->inode_post_rename(old_dir, old_dentry, new_dir, new_dentry); + security_inode_post_rename(old_dir, old_dentry, new_dir, new_dentry); } if (target) up(&target->i_sem); ===== fs/namespace.c 1.29 vs edited ===== --- 1.29/fs/namespace.c Tue Sep 17 12:52:27 2002 +++ edited/fs/namespace.c Tue Oct 15 23:17:32 2002 @@ -19,6 +19,7 @@ #include #include #include +#include #include @@ -288,8 +289,7 @@ struct super_block * sb = mnt->mnt_sb; int retval = 0; - retval = security_ops->sb_umount(mnt, flags); - if (retval) + if ((retval = security_sb_umount(mnt, flags))) return retval; /* @@ -341,7 +341,7 @@ DQUOT_OFF(sb); acct_auto_close(sb); unlock_kernel(); - security_ops->sb_umount_close(mnt); + security_sb_umount_close(mnt); spin_lock(&dcache_lock); } retval = -EBUSY; @@ -352,7 +352,7 @@ } spin_unlock(&dcache_lock); if (retval) - security_ops->sb_umount_busy(mnt); + security_sb_umount_busy(mnt); up_write(¤t->namespace->sem); return retval; } @@ -470,8 +470,7 @@ if (IS_DEADDIR(nd->dentry->d_inode)) goto out_unlock; - err = security_ops->sb_check_sb(mnt, nd); - if (err) + if ((err = security_sb_check_sb(mnt, nd))) goto out_unlock; spin_lock(&dcache_lock); @@ -487,7 +486,7 @@ out_unlock: up(&nd->dentry->d_inode->i_sem); if (!err) - security_ops->sb_post_addmount(mnt, nd); + security_sb_post_addmount(mnt, nd); return err; } @@ -558,7 +557,7 @@ nd->mnt->mnt_flags=mnt_flags; up_write(&sb->s_umount); if (!err) - security_ops->sb_post_remount(nd->mnt, flags, data); + security_sb_post_remount(nd->mnt, flags, data); return err; } @@ -741,8 +740,7 @@ if (retval) return retval; - retval = security_ops->sb_mount(dev_name, &nd, type_page, flags, data_page); - if (retval) + if ((retval = security_sb_mount(dev_name, &nd, type_page, flags, data_page))) goto dput_out; if (flags & MS_REMOUNT) @@ -939,8 +937,7 @@ if (error) goto out1; - error = security_ops->sb_pivotroot(&old_nd, &new_nd); - if (error) { + if ((error = security_sb_pivotroot(&old_nd, &new_nd))) { path_release(&old_nd); goto out1; } @@ -989,7 +986,7 @@ attach_mnt(new_nd.mnt, &root_parent); spin_unlock(&dcache_lock); chroot_fs_refs(&user_nd, &new_nd); - security_ops->sb_post_pivotroot(&user_nd, &new_nd); + security_sb_post_pivotroot(&user_nd, &new_nd); error = 0; path_release(&root_parent); path_release(&parent_nd); ===== fs/open.c 1.28 vs edited ===== --- 1.28/fs/open.c Sun Oct 13 08:39:40 2002 +++ edited/fs/open.c Tue Oct 15 23:19:46 2002 @@ -30,8 +30,7 @@ retval = -ENOSYS; if (sb->s_op && sb->s_op->statfs) { memset(buf, 0, sizeof(struct statfs)); - retval = security_ops->sb_statfs(sb); - if (retval) + if ((retval = security_sb_statfs(sb))) return retval; retval = sb->s_op->statfs(sb, buf); } ===== fs/quota.c 1.8 vs edited ===== --- 1.8/fs/quota.c Mon Jul 22 03:12:48 2002 +++ edited/fs/quota.c Tue Oct 15 22:54:46 2002 @@ -98,7 +98,7 @@ if (!capable(CAP_SYS_ADMIN)) return -EPERM; - return security_ops->quotactl (cmd, type, id, sb); + return security_quotactl (cmd, type, id, sb); } /* Resolve device pathname to superblock */ ===== fs/read_write.c 1.19 vs edited ===== --- 1.19/fs/read_write.c Thu Oct 10 14:36:26 2002 +++ edited/fs/read_write.c Wed Oct 16 00:08:14 2002 @@ -121,8 +121,7 @@ if (!file) goto bad; - retval = security_ops->file_llseek(file); - if (retval) { + if ((retval = security_file_llseek(file))) { fput(file); goto bad; } @@ -153,8 +152,7 @@ if (!file) goto bad; - retval = security_ops->file_llseek(file); - if (retval) + if ((retval = security_file_llseek(file))) goto out_putf; retval = -EINVAL; @@ -203,8 +201,7 @@ ret = locks_verify_area(FLOCK_VERIFY_READ, inode, file, *pos, count); if (!ret) { - ret = security_ops->file_permission (file, MAY_READ); - if (!ret) { + if (!(ret = security_file_permission (file, MAY_READ))) { if (file->f_op->read) ret = file->f_op->read(file, buf, count, pos); else @@ -243,8 +240,7 @@ ret = locks_verify_area(FLOCK_VERIFY_WRITE, inode, file, *pos, count); if (!ret) { - ret = security_ops->file_permission (file, MAY_WRITE); - if (!ret) { + if (!(ret = security_file_permission (file, MAY_WRITE))) { if (file->f_op->write) ret = file->f_op->write(file, buf, count, pos); else @@ -475,8 +471,7 @@ goto bad_file; if (file->f_op && (file->f_mode & FMODE_READ) && (file->f_op->readv || file->f_op->read)) { - ret = security_ops->file_permission (file, MAY_READ); - if (!ret) + if (!(ret = security_file_permission (file, MAY_READ))) ret = do_readv_writev(READ, file, vector, nr_segs); } fput(file); @@ -498,8 +493,7 @@ goto bad_file; if (file->f_op && (file->f_mode & FMODE_WRITE) && (file->f_op->writev || file->f_op->write)) { - ret = security_ops->file_permission (file, MAY_WRITE); - if (!ret) + if (!(ret = security_file_permission (file, MAY_WRITE))) ret = do_readv_writev(WRITE, file, vector, nr_segs); } fput(file); ===== fs/readdir.c 1.9 vs edited ===== --- 1.9/fs/readdir.c Mon Jul 22 03:12:48 2002 +++ edited/fs/readdir.c Wed Oct 16 00:06:40 2002 @@ -11,6 +11,7 @@ #include #include #include +#include #include @@ -21,8 +22,7 @@ if (!file->f_op || !file->f_op->readdir) goto out; - res = security_ops->file_permission(file, MAY_READ); - if (res) + if ((res = security_file_permission(file, MAY_READ))) goto out; down(&inode->i_sem); ===== fs/stat.c 1.13 vs edited ===== --- 1.13/fs/stat.c Mon Jul 22 03:12:48 2002 +++ edited/fs/stat.c Tue Oct 15 23:49:19 2002 @@ -39,8 +39,7 @@ struct inode *inode = dentry->d_inode; int retval; - retval = security_ops->inode_getattr(mnt, dentry); - if (retval) + if ((retval = security_inode_getattr(mnt, dentry))) return retval; if (inode->i_op->getattr) @@ -238,8 +237,7 @@ error = -EINVAL; if (inode->i_op && inode->i_op->readlink) { - error = security_ops->inode_readlink(nd.dentry); - if (!error) { + if (!(error = security_inode_readlink(nd.dentry))) { UPDATE_ATIME(inode); error = inode->i_op->readlink(nd.dentry, buf, bufsiz); } ===== fs/super.c 1.83 vs edited ===== --- 1.83/fs/super.c Mon Sep 9 14:00:57 2002 +++ edited/fs/super.c Tue Oct 15 23:18:44 2002 @@ -29,9 +29,9 @@ #include #include #include /* for fsync_super() */ +#include #include -#include void get_filesystem(struct file_system_type *fs); void put_filesystem(struct file_system_type *fs); @@ -51,7 +51,7 @@ struct super_block *s = kmalloc(sizeof(struct super_block), GFP_USER); if (s) { memset(s, 0, sizeof(struct super_block)); - if (security_ops->sb_alloc_security(s)) { + if (security_sb_alloc(s)) { kfree(s); s = NULL; goto out; @@ -85,7 +85,7 @@ */ static inline void destroy_super(struct super_block *s) { - security_ops->sb_free_security(s); + security_sb_free(s); kfree(s); } ===== fs/xattr.c 1.7 vs edited ===== --- 1.7/fs/xattr.c Mon Jul 22 03:12:48 2002 +++ edited/fs/xattr.c Tue Oct 15 23:51:34 2002 @@ -13,6 +13,7 @@ #include #include #include +#include #include /* @@ -85,9 +86,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->setxattr) { - error = security_ops->inode_setxattr(d, kname, kvalue, - size, flags); - if (error) + if ((error = security_inode_setxattr(d, kname, kvalue, size, flags))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags); @@ -163,8 +162,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->getxattr) { - error = security_ops->inode_getxattr(d, kname); - if (error) + if ((error = security_inode_getxattr(d, kname))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->getxattr(d, kname, kvalue, size); @@ -236,8 +234,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->listxattr) { - error = security_ops->inode_listxattr(d); - if (error) + if ((error = security_inode_listxattr(d))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->listxattr(d, klist, size); @@ -311,8 +308,7 @@ error = -EOPNOTSUPP; if (d->d_inode->i_op && d->d_inode->i_op->removexattr) { - error = security_ops->inode_removexattr(d, kname); - if (error) + if ((error = security_inode_removexattr(d, kname))) goto out; down(&d->d_inode->i_sem); error = d->d_inode->i_op->removexattr(d, kname); ===== fs/proc/base.c 1.31 vs edited ===== --- 1.31/fs/proc/base.c Sat Sep 28 08:36:29 2002 +++ edited/fs/proc/base.c Tue Oct 15 23:22:02 2002 @@ -28,6 +28,7 @@ #include #include #include +#include /* * For hysterical raisins we keep the same inumbers as in the old procfs. @@ -394,7 +395,7 @@ }; #define MAY_PTRACE(p) \ -(p==current||(p->parent==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED&&security_ops->ptrace(current,p)==0)) +(p==current||(p->parent==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED&&security_ptrace(current,p)==0)) static int mem_open(struct inode* inode, struct file* file) ===== include/linux/sched.h 1.107 vs edited ===== --- 1.107/include/linux/sched.h Tue Oct 15 15:32:40 2002 +++ edited/include/linux/sched.h Tue Oct 15 22:24:46 2002 @@ -596,9 +596,11 @@ unsigned long, const char *, void *); extern void free_irq(unsigned int, void *); + +#ifdef CONFIG_SECURITY /* capable prototype and code moved to security.[hc] */ #include -#if 0 +#else static inline int capable(int cap) { if (cap_raised(current->cap_effective, cap)) { @@ -607,7 +609,7 @@ } return 0; } -#endif /* if 0 */ +#endif /* * Routines for handling mm_structs ===== include/linux/security.h 1.4 vs edited ===== --- 1.4/include/linux/security.h Tue Oct 8 02:20:18 2002 +++ edited/include/linux/security.h Wed Oct 16 10:44:28 2002 @@ -22,8 +22,6 @@ #ifndef __LINUX_SECURITY_H #define __LINUX_SECURITY_H -#ifdef __KERNEL__ - #include #include #include @@ -33,6 +31,20 @@ #include #include + +/* These functions are in security/capability.c and are used + * as the default capabilities functions */ +extern int cap_capable (struct task_struct *tsk, int cap); +extern int cap_ptrace (struct task_struct *parent, struct task_struct *child); +extern int cap_capget (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); +extern int cap_capset_check (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); +extern void cap_capset_set (struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted); +extern int cap_bprm_set_security (struct linux_binprm *bprm); +extern void cap_bprm_compute_creds (struct linux_binprm *bprm); +extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, int flags); +extern void cap_task_kmod_set_label (void); +extern void cap_task_reparent_to_init (struct task_struct *p); + /* * Values used in the task_security_ops calls */ @@ -48,6 +60,9 @@ /* setfsuid or setfsgid, id0 == fsuid or fsgid */ #define LSM_SETID_FS 8 + +#ifdef CONFIG_SECURITY + /* forward declares to avoid warnings */ struct sk_buff; struct net_device; @@ -848,6 +863,531 @@ struct security_operations *ops); }; +/* global variables */ +extern struct security_operations *security_ops; + +/* inline stuff */ +static inline int security_ptrace (struct task_struct * parent, struct task_struct * child) +{ + return security_ops->ptrace (parent, child); +} + +static inline int security_capget (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return security_ops->capget (target, effective, inheritable, permitted); +} + +static inline int security_capset_check (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return security_ops->capset_check (target, effective, inheritable, permitted); +} + +static inline void security_capset_set (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + security_ops->capset_set (target, effective, inheritable, permitted); +} + +static inline int security_acct (struct file *file) +{ + return security_ops->acct (file); +} + +static inline int security_quotactl (int cmds, int type, int id, + struct super_block *sb) +{ + return security_ops->quotactl (cmds, type, id, sb); +} + +static inline int security_quota_on (struct file * file) +{ + return security_ops->quota_on (file); +} + +static inline int security_bprm_alloc (struct linux_binprm *bprm) +{ + return security_ops->bprm_alloc_security (bprm); +} +static inline void security_bprm_free (struct linux_binprm *bprm) +{ + security_ops->bprm_free_security (bprm); +} +static inline void security_bprm_compute_creds (struct linux_binprm *bprm) +{ + security_ops->bprm_compute_creds (bprm); +} +static inline int security_bprm_set (struct linux_binprm *bprm) +{ + return security_ops->bprm_set_security (bprm); +} +static inline int security_bprm_check (struct linux_binprm *bprm) +{ + return security_ops->bprm_check_security (bprm); +} + +static inline int security_sb_alloc (struct super_block *sb) +{ + return security_ops->sb_alloc_security (sb); +} + +static inline void security_sb_free (struct super_block *sb) +{ + security_ops->sb_free_security (sb); +} + +static inline int security_sb_statfs (struct super_block *sb) +{ + return security_ops->sb_statfs (sb); +} + +static inline int security_sb_mount (char *dev_name, struct nameidata *nd, + char *type, unsigned long flags, + void *data) +{ + return security_ops->sb_mount (dev_name, nd, type, flags, data); +} + +static inline int security_sb_check_sb (struct vfsmount *mnt, + struct nameidata *nd) +{ + return security_ops->sb_check_sb (mnt, nd); +} + +static inline int security_sb_umount (struct vfsmount *mnt, int flags) +{ + return security_ops->sb_umount (mnt, flags); +} + +static inline void security_sb_umount_close (struct vfsmount *mnt) +{ + security_ops->sb_umount_close (mnt); +} + +static inline void security_sb_umount_busy (struct vfsmount *mnt) +{ + security_ops->sb_umount_busy (mnt); +} + +static inline void security_sb_post_remount (struct vfsmount *mnt, + unsigned long flags, void *data) +{ + security_ops->sb_post_remount (mnt, flags, data); +} + +static inline void security_sb_post_mountroot (void) +{ + security_ops->sb_post_mountroot (); +} + +static inline void security_sb_post_addmount (struct vfsmount *mnt, + struct nameidata *mountpoint_nd) +{ + security_ops->sb_post_addmount (mnt, mountpoint_nd); +} + +static inline int security_sb_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ + return security_ops->sb_pivotroot (old_nd, new_nd); +} + +static inline void security_sb_post_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ + security_ops->sb_post_pivotroot (old_nd, new_nd); +} + +static inline int security_inode_alloc (struct inode *inode) +{ + return security_ops->inode_alloc_security (inode); +} + +static inline void security_inode_free (struct inode *inode) +{ + security_ops->inode_free_security (inode); +} + +static inline int security_inode_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return security_ops->inode_create (dir, dentry, mode); +} + +static inline void security_inode_post_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ + security_ops->inode_post_create (dir, dentry, mode); +} + +static inline int security_inode_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ + return security_ops->inode_link (old_dentry, dir, new_dentry); +} + +static inline void security_inode_post_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ + security_ops->inode_post_link (old_dentry, dir, new_dentry); +} + +static inline int security_inode_unlink (struct inode *dir, + struct dentry *dentry) +{ + return security_ops->inode_unlink (dir, dentry); +} + +static inline int security_inode_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ + return security_ops->inode_symlink (dir, dentry, old_name); +} + +static inline void security_inode_post_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ + security_ops->inode_post_symlink (dir, dentry, old_name); +} + +static inline int security_inode_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return security_ops->inode_mkdir (dir, dentry, mode); +} + +static inline void security_inode_post_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ + security_ops->inode_post_mkdir (dir, dentry, mode); +} + +static inline int security_inode_rmdir (struct inode *dir, + struct dentry *dentry) +{ + return security_ops->inode_rmdir (dir, dentry); +} + +static inline int security_inode_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ + return security_ops->inode_mknod (dir, dentry, mode, dev); +} + +static inline void security_inode_post_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ + security_ops->inode_post_mknod (dir, dentry, mode, dev); +} + +static inline int security_inode_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ + return security_ops->inode_rename (old_dir, old_dentry, + new_dir, new_dentry); +} + +static inline void security_inode_post_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ + security_ops->inode_post_rename (old_dir, old_dentry, + new_dir, new_dentry); +} + +static inline int security_inode_readlink (struct dentry *dentry) +{ + return security_ops->inode_readlink (dentry); +} + +static inline int security_inode_follow_link (struct dentry *dentry, + struct nameidata *nd) +{ + return security_ops->inode_follow_link (dentry, nd); +} + +static inline int security_inode_permission (struct inode *inode, int mask) +{ + return security_ops->inode_permission (inode, mask); +} + +static inline int security_inode_permission_lite (struct inode *inode, + int mask) +{ + return security_ops->inode_permission_lite (inode, mask); +} + +static inline int security_inode_setattr (struct dentry *dentry, + struct iattr *attr) +{ + return security_ops->inode_setattr (dentry, attr); +} + +static inline int security_inode_getattr (struct vfsmount *mnt, + struct dentry *dentry) +{ + return security_ops->inode_getattr (mnt, dentry); +} + +static inline void security_inode_post_lookup (struct inode *inode, + struct dentry *dentry) +{ + security_ops->inode_post_lookup (inode, dentry); +} + +static inline void security_inode_delete (struct inode *inode) +{ + security_ops->inode_delete (inode); +} + +static inline int security_inode_setxattr (struct dentry *dentry, char *name, + void *value, size_t size, int flags) +{ + return security_ops->inode_setxattr (dentry, name, value, size, flags); +} + +static inline int security_inode_getxattr (struct dentry *dentry, char *name) +{ + return security_ops->inode_getxattr (dentry, name); +} + +static inline int security_inode_listxattr (struct dentry *dentry) +{ + return security_ops->inode_listxattr (dentry); +} + +static inline int security_inode_removexattr (struct dentry *dentry, char *name) +{ + return security_ops->inode_removexattr (dentry, name); +} + +static inline int security_file_permission (struct file *file, int mask) +{ + return security_ops->file_permission (file, mask); +} + +static inline int security_file_alloc (struct file *file) +{ + return security_ops->file_alloc_security (file); +} + +static inline void security_file_free (struct file *file) +{ + security_ops->file_free_security (file); +} + +static inline int security_file_llseek (struct file *file) +{ + return security_ops->file_llseek (file); +} + +static inline int security_file_ioctl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return security_ops->file_ioctl (file, cmd, arg); +} + +static inline int security_file_mmap (struct file *file, unsigned long prot, + unsigned long flags) +{ + return security_ops->file_mmap (file, prot, flags); +} + +static inline int security_file_mprotect (struct vm_area_struct *vma, + unsigned long prot) +{ + return security_ops->file_mprotect (vma, prot); +} + +static inline int security_file_lock (struct file *file, unsigned int cmd) +{ + return security_ops->file_lock (file, cmd); +} + +static inline int security_file_fcntl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return security_ops->file_fcntl (file, cmd, arg); +} + +static inline int security_file_set_fowner (struct file *file) +{ + return security_ops->file_set_fowner (file); +} + +static inline int security_file_send_sigiotask (struct task_struct *tsk, + struct fown_struct *fown, + int fd, int reason) +{ + return security_ops->file_send_sigiotask (tsk, fown, fd, reason); +} + +static inline int security_file_receive (struct file *file) +{ + return security_ops->file_receive (file); +} + +static inline int security_task_create (unsigned long clone_flags) +{ + return security_ops->task_create (clone_flags); +} + +static inline int security_task_alloc (struct task_struct *p) +{ + return security_ops->task_alloc_security (p); +} + +static inline void security_task_free (struct task_struct *p) +{ + security_ops->task_free_security (p); +} + +static inline int security_task_setuid (uid_t id0, uid_t id1, uid_t id2, + int flags) +{ + return security_ops->task_setuid (id0, id1, id2, flags); +} + +static inline int security_task_post_setuid (uid_t old_ruid, uid_t old_euid, + uid_t old_suid, int flags) +{ + return security_ops->task_post_setuid (old_ruid, old_euid, old_suid, flags); +} + +static inline int security_task_setgid (gid_t id0, gid_t id1, gid_t id2, + int flags) +{ + return security_ops->task_setgid (id0, id1, id2, flags); +} + +static inline int security_task_setpgid (struct task_struct *p, pid_t pgid) +{ + return security_ops->task_setpgid (p, pgid); +} + +static inline int security_task_getpgid (struct task_struct *p) +{ + return security_ops->task_getpgid (p); +} + +static inline int security_task_getsid (struct task_struct *p) +{ + return security_ops->task_getsid (p); +} + +static inline int security_task_setgroups (int gidsetsize, gid_t *grouplist) +{ + return security_ops->task_setgroups (gidsetsize, grouplist); +} + +static inline int security_task_setnice (struct task_struct *p, int nice) +{ + return security_ops->task_setnice (p, nice); +} + +static inline int security_task_setrlimit (unsigned int resource, + struct rlimit *new_rlim) +{ + return security_ops->task_setrlimit (resource, new_rlim); +} + +static inline int security_task_setscheduler (struct task_struct *p, + int policy, + struct sched_param *lp) +{ + return security_ops->task_setscheduler (p, policy, lp); +} + +static inline int security_task_getscheduler (struct task_struct *p) +{ + return security_ops->task_getscheduler (p); +} + +static inline int security_task_kill (struct task_struct *p, + struct siginfo *info, int sig) +{ + return security_ops->task_kill (p, info, sig); +} + +static inline int security_task_wait (struct task_struct *p) +{ + return security_ops->task_wait (p); +} + +static inline int security_task_prctl (int option, unsigned long arg2, + unsigned long arg3, + unsigned long arg4, + unsigned long arg5) +{ + return security_ops->task_prctl (option, arg2, arg3, arg4, arg5); +} + +static inline void security_task_kmod_set_label (void) +{ + security_ops->task_kmod_set_label (); +} + +static inline void security_task_reparent_to_init (struct task_struct *p) +{ + security_ops->task_reparent_to_init (p); +} + +static inline int security_ipc_permission (struct kern_ipc_perm *ipcp, + short flag) +{ + return security_ops->ipc_permission (ipcp, flag); +} + +static inline int security_msg_queue_alloc (struct msg_queue *msq) +{ + return security_ops->msg_queue_alloc_security (msq); +} + +static inline void security_msg_queue_free (struct msg_queue *msq) +{ + security_ops->msg_queue_free_security (msq); +} + +static inline int security_shm_alloc (struct shmid_kernel *shp) +{ + return security_ops->shm_alloc_security (shp); +} + +static inline void security_shm_free (struct shmid_kernel *shp) +{ + security_ops->shm_free_security (shp); +} + +static inline int security_sem_alloc (struct sem_array *sma) +{ + return security_ops->sem_alloc_security (sma); +} + +static inline void security_sem_free (struct sem_array *sma) +{ + security_ops->sem_free_security (sma); +} + /* prototypes */ extern int security_scaffolding_startup (void); @@ -857,11 +1397,501 @@ extern int mod_unreg_security (const char *name, struct security_operations *ops); extern int capable (int cap); -/* global variables */ -extern struct security_operations *security_ops; +#else /* CONFIG_SECURITY */ + +/* + * This is the default capabilities functionality. Most of these functions + * are just stubbed out, but a few must call the proper capable code. + */ + +static inline int security_scaffolding_startup (void) +{ + return 0; +} + +static inline int security_ptrace (struct task_struct *parent, struct task_struct * child) +{ + return cap_ptrace (parent, child); +} + +static inline int security_capget (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return cap_capget (target, effective, inheritable, permitted); +} + +static inline int security_capset_check (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + return cap_capset_check (target, effective, inheritable, permitted); +} + +static inline void security_capset_set (struct task_struct *target, + kernel_cap_t *effective, + kernel_cap_t *inheritable, + kernel_cap_t *permitted) +{ + cap_capset_set (target, effective, inheritable, permitted); +} + +static inline int security_acct (struct file *file) +{ + return 0; +} + +static inline int security_quotactl (int cmds, int type, int id, + struct super_block * sb) +{ + return 0; +} + +static inline int security_quota_on (struct file * file) +{ + return 0; +} + +static inline int security_bprm_alloc (struct linux_binprm *bprm) +{ + return 0; +} + +static inline void security_bprm_free (struct linux_binprm *bprm) +{ } + +static inline void security_bprm_compute_creds (struct linux_binprm *bprm) +{ + cap_bprm_compute_creds (bprm); +} + +static inline int security_bprm_set (struct linux_binprm *bprm) +{ + return cap_bprm_set_security (bprm); +} + +static inline int security_bprm_check (struct linux_binprm *bprm) +{ + return 0; +} + +static inline int security_sb_alloc (struct super_block *sb) +{ + return 0; +} + +static inline void security_sb_free (struct super_block *sb) +{ } + +static inline int security_sb_statfs (struct super_block *sb) +{ + return 0; +} + +static inline int security_sb_mount (char *dev_name, struct nameidata *nd, + char *type, unsigned long flags, + void *data) +{ + return 0; +} + +static inline int security_sb_check_sb (struct vfsmount *mnt, + struct nameidata *nd) +{ + return 0; +} + +static inline int security_sb_umount (struct vfsmount *mnt, int flags) +{ + return 0; +} + +static inline void security_sb_umount_close (struct vfsmount *mnt) +{ } + +static inline void security_sb_umount_busy (struct vfsmount *mnt) +{ } + +static inline void security_sb_post_remount (struct vfsmount *mnt, + unsigned long flags, void *data) +{ } + +static inline void security_sb_post_mountroot (void) +{ } + +static inline void security_sb_post_addmount (struct vfsmount *mnt, + struct nameidata *mountpoint_nd) +{ } + +static inline int security_sb_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ + return 0; +} + +static inline void security_sb_post_pivotroot (struct nameidata *old_nd, + struct nameidata *new_nd) +{ } + +static inline int security_inode_alloc (struct inode *inode) +{ + return 0; +} + +static inline void security_inode_free (struct inode *inode) +{ } + +static inline int security_inode_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return 0; +} + +static inline void security_inode_post_create (struct inode *dir, + struct dentry *dentry, + int mode) +{ } + +static inline int security_inode_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ + return 0; +} + +static inline void security_inode_post_link (struct dentry *old_dentry, + struct inode *dir, + struct dentry *new_dentry) +{ } + +static inline int security_inode_unlink (struct inode *dir, + struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ + return 0; +} + +static inline void security_inode_post_symlink (struct inode *dir, + struct dentry *dentry, + const char *old_name) +{ } + +static inline int security_inode_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ + return 0; +} + +static inline void security_inode_post_mkdir (struct inode *dir, + struct dentry *dentry, + int mode) +{ } + +static inline int security_inode_rmdir (struct inode *dir, + struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ + return 0; +} + +static inline void security_inode_post_mknod (struct inode *dir, + struct dentry *dentry, + int mode, dev_t dev) +{ } + +static inline int security_inode_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ + return 0; +} + +static inline void security_inode_post_rename (struct inode *old_dir, + struct dentry *old_dentry, + struct inode *new_dir, + struct dentry *new_dentry) +{ } + +static inline int security_inode_readlink (struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_follow_link (struct dentry *dentry, + struct nameidata *nd) +{ + return 0; +} + +static inline int security_inode_permission (struct inode *inode, int mask) +{ + return 0; +} + +static inline int security_inode_permission_lite (struct inode *inode, + int mask) +{ + return 0; +} + +static inline int security_inode_setattr (struct dentry *dentry, + struct iattr *attr) +{ + return 0; +} + +static inline int security_inode_getattr (struct vfsmount *mnt, + struct dentry *dentry) +{ + return 0; +} + +static inline void security_inode_post_lookup (struct inode *inode, + struct dentry *dentry) +{ } + +static inline void security_inode_delete (struct inode *inode) +{ } + +static inline int security_inode_setxattr (struct dentry *dentry, char *name, + void *value, size_t size, int flags) +{ + return 0; +} + +static inline int security_inode_getxattr (struct dentry *dentry, char *name) +{ + return 0; +} + +static inline int security_inode_listxattr (struct dentry *dentry) +{ + return 0; +} + +static inline int security_inode_removexattr (struct dentry *dentry, char *name) +{ + return 0; +} + +static inline int security_file_permission (struct file *file, int mask) +{ + return 0; +} + +static inline int security_file_alloc (struct file *file) +{ + return 0; +} + +static inline void security_file_free (struct file *file) +{ } + +static inline int security_file_llseek (struct file *file) +{ + return 0; +} + +static inline int security_file_ioctl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return 0; +} + +static inline int security_file_mmap (struct file *file, unsigned long prot, + unsigned long flags) +{ + return 0; +} + +static inline int security_file_mprotect (struct vm_area_struct *vma, + unsigned long prot) +{ + return 0; +} + +static inline int security_file_lock (struct file *file, unsigned int cmd) +{ + return 0; +} + +static inline int security_file_fcntl (struct file *file, unsigned int cmd, + unsigned long arg) +{ + return 0; +} + +static inline int security_file_set_fowner (struct file *file) +{ + return 0; +} + +static inline int security_file_send_sigiotask (struct task_struct *tsk, + struct fown_struct *fown, + int fd, int reason) +{ + return 0; +} + +static inline int security_file_receive (struct file *file) +{ + return 0; +} + +static inline int security_task_create (unsigned long clone_flags) +{ + return 0; +} + +static inline int security_task_alloc (struct task_struct *p) +{ + return 0; +} + +static inline void security_task_free (struct task_struct *p) +{ } + +static inline int security_task_setuid (uid_t id0, uid_t id1, uid_t id2, + int flags) +{ + return 0; +} + +static inline int security_task_post_setuid (uid_t old_ruid, uid_t old_euid, + uid_t old_suid, int flags) +{ + return cap_task_post_setuid (old_ruid, old_euid, old_suid, flags); +} + +static inline int security_task_setgid (gid_t id0, gid_t id1, gid_t id2, + int flags) +{ + return 0; +} + +static inline int security_task_setpgid (struct task_struct *p, pid_t pgid) +{ + return 0; +} + +static inline int security_task_getpgid (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_getsid (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_setgroups (int gidsetsize, gid_t *grouplist) +{ + return 0; +} + +static inline int security_task_setnice (struct task_struct *p, int nice) +{ + return 0; +} + +static inline int security_task_setrlimit (unsigned int resource, + struct rlimit *new_rlim) +{ + return 0; +} + +static inline int security_task_setscheduler (struct task_struct *p, + int policy, + struct sched_param *lp) +{ + return 0; +} + +static inline int security_task_getscheduler (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_kill (struct task_struct *p, + struct siginfo *info, int sig) +{ + return 0; +} + +static inline int security_task_wait (struct task_struct *p) +{ + return 0; +} + +static inline int security_task_prctl (int option, unsigned long arg2, + unsigned long arg3, + unsigned long arg4, + unsigned long arg5) +{ + return 0; +} + +static inline void security_task_kmod_set_label (void) +{ + cap_task_kmod_set_label (); +} + +static inline void security_task_reparent_to_init (struct task_struct *p) +{ + cap_task_reparent_to_init (p); +} + +static inline int security_ipc_permission (struct kern_ipc_perm *ipcp, + short flag) +{ + return 0; +} + +static inline int security_msg_queue_alloc (struct msg_queue *msq) +{ + return 0; +} + +static inline void security_msg_queue_free (struct msg_queue *msq) +{ } + +static inline int security_shm_alloc (struct shmid_kernel *shp) +{ + return 0; +} + +static inline void security_shm_free (struct shmid_kernel *shp) +{ } + +static inline int security_sem_alloc (struct sem_array *sma) +{ + return 0; +} + +static inline void security_sem_free (struct sem_array *sma) +{ } + + +#endif /* CONFIG_SECURITY */ -#endif /* __KERNEL__ */ #endif /* ! __LINUX_SECURITY_H */ ===== init/do_mounts.c 1.25 vs edited ===== --- 1.25/init/do_mounts.c Fri Oct 4 13:51:37 2002 +++ edited/init/do_mounts.c Wed Oct 16 00:36:15 2002 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -799,7 +800,7 @@ sys_umount("/dev", 0); sys_mount(".", "/", NULL, MS_MOVE, NULL); sys_chroot("."); - security_ops->sb_post_mountroot(); + security_sb_post_mountroot(); mount_devfs_fs (); } ===== ipc/msg.c 1.7 vs edited ===== --- 1.7/ipc/msg.c Tue Oct 8 02:20:42 2002 +++ edited/ipc/msg.c Wed Oct 16 00:37:48 2002 @@ -101,15 +101,14 @@ msq->q_perm.key = key; msq->q_perm.security = NULL; - retval = security_ops->msg_queue_alloc_security(msq); - if (retval) { + if ((retval = security_msg_queue_alloc(msq))) { kfree(msq); return retval; } id = ipc_addid(&msg_ids, &msq->q_perm, msg_ctlmni); if(id == -1) { - security_ops->msg_queue_free_security(msq); + security_msg_queue_free(msq); kfree(msq); return -ENOSPC; } @@ -281,7 +280,7 @@ free_msg(msg); } atomic_sub(msq->q_cbytes, &msg_bytes); - security_ops->msg_queue_free_security(msq); + security_msg_queue_free(msq); kfree(msq); } ===== ipc/sem.c 1.12 vs edited ===== --- 1.12/ipc/sem.c Tue Oct 8 02:20:46 2002 +++ edited/ipc/sem.c Wed Oct 16 00:38:28 2002 @@ -136,15 +136,14 @@ sma->sem_perm.key = key; sma->sem_perm.security = NULL; - retval = security_ops->sem_alloc_security(sma); - if (retval) { + if ((retval = security_sem_alloc(sma))) { ipc_free(sma, size); return retval; } id = ipc_addid(&sem_ids, &sma->sem_perm, sc_semmni); if(id == -1) { - security_ops->sem_free_security(sma); + security_sem_free(sma); ipc_free(sma, size); return -ENOSPC; } @@ -427,7 +426,7 @@ used_sems -= sma->sem_nsems; size = sizeof (*sma) + sma->sem_nsems * sizeof (struct sem); - security_ops->sem_free_security(sma); + security_sem_free(sma); ipc_free(sma, size); } ===== ipc/shm.c 1.18 vs edited ===== --- 1.18/ipc/shm.c Tue Oct 8 02:29:20 2002 +++ edited/ipc/shm.c Wed Oct 16 00:39:00 2002 @@ -116,7 +116,7 @@ shm_unlock(shp->id); shmem_lock(shp->shm_file, 0); fput (shp->shm_file); - security_ops->shm_free_security(shp); + security_shm_free(shp); kfree (shp); } @@ -188,8 +188,7 @@ shp->shm_flags = (shmflg & S_IRWXUGO); shp->shm_perm.security = NULL; - error = security_ops->shm_alloc_security(shp); - if (error) { + if ((error = security_shm_alloc(shp))) { kfree(shp); return error; } @@ -222,7 +221,7 @@ no_id: fput(file); no_file: - security_ops->shm_free_security(shp); + security_shm_free(shp); kfree(shp); return error; } ===== ipc/util.c 1.6 vs edited ===== --- 1.6/ipc/util.c Tue Oct 8 02:01:30 2002 +++ edited/ipc/util.c Wed Oct 16 00:39:12 2002 @@ -264,7 +264,7 @@ !capable(CAP_IPC_OWNER)) return -1; - return security_ops->ipc_permission(ipcp, flag); + return security_ipc_permission(ipcp, flag); } /* ===== kernel/acct.c 1.12 vs edited ===== --- 1.12/kernel/acct.c Mon Jul 22 03:12:48 2002 +++ edited/kernel/acct.c Tue Oct 15 22:53:28 2002 @@ -49,6 +49,7 @@ #include #include #include +#include #include /* @@ -222,8 +223,7 @@ } } - error = security_ops->acct(file); - if (error) + if ((error = security_acct(file))) return error; spin_lock(&acct_globals.lock); ===== kernel/capability.c 1.6 vs edited ===== --- 1.6/kernel/capability.c Sat Sep 14 06:18:49 2002 +++ edited/kernel/capability.c Tue Oct 15 22:34:12 2002 @@ -8,6 +8,7 @@ */ #include +#include #include unsigned securebits = SECUREBITS_DEFAULT; /* systemwide security settings */ @@ -63,7 +64,7 @@ data.permitted = cap_t(target->cap_permitted); data.inheritable = cap_t(target->cap_inheritable); data.effective = cap_t(target->cap_effective); - ret = security_ops->capget(target, &data.effective, &data.inheritable, &data.permitted); + ret = security_capget(target, &data.effective, &data.inheritable, &data.permitted); out: read_unlock(&tasklist_lock); @@ -88,7 +89,7 @@ do_each_thread(g, target) { if (target->pgrp != pgrp) continue; - security_ops->capset_set(target, effective, inheritable, permitted); + security_capset_set(target, effective, inheritable, permitted); } while_each_thread(g, target); } @@ -105,7 +106,7 @@ do_each_thread(g, target) { if (target == current || target->pid == 1) continue; - security_ops->capset_set(target, effective, inheritable, permitted); + security_capset_set(target, effective, inheritable, permitted); } while_each_thread(g, target); } @@ -163,7 +164,7 @@ ret = -EPERM; - if (security_ops->capset_check(target, &effective, &inheritable, &permitted)) + if (security_capset_check(target, &effective, &inheritable, &permitted)) goto out; if (!cap_issubset(inheritable, cap_combine(target->cap_inheritable, @@ -190,7 +191,7 @@ else /* all procs in process group */ cap_set_pg(-pid, &effective, &inheritable, &permitted); } else { - security_ops->capset_set(target, &effective, &inheritable, &permitted); + security_capset_set(target, &effective, &inheritable, &permitted); } out: ===== kernel/exit.c 1.72 vs edited ===== --- 1.72/kernel/exit.c Tue Oct 15 15:08:06 2002 +++ edited/kernel/exit.c Wed Oct 16 00:35:10 2002 @@ -67,7 +67,7 @@ wait_task_inactive(p); atomic_dec(&p->user->processes); - security_ops->task_free_security(p); + security_task_free(p); free_uid(p->user); write_lock_irq(&tasklist_lock); if (unlikely(p->ptrace)) @@ -248,7 +248,7 @@ /* cpus_allowed? */ /* rt_priority? */ /* signals? */ - security_ops->task_reparent_to_init(current); + security_task_reparent_to_init(current); memcpy(current->rlim, init_task.rlim, sizeof(*(current->rlim))); current->user = INIT_USER; @@ -774,7 +774,7 @@ if (current->tgid != p->tgid && delay_group_leader(p)) return 2; - if (security_ops->task_wait(p)) + if (security_task_wait(p)) return 0; return 1; ===== kernel/fork.c 1.87 vs edited ===== --- 1.87/kernel/fork.c Mon Oct 7 15:17:19 2002 +++ edited/kernel/fork.c Wed Oct 16 00:28:30 2002 @@ -682,8 +682,7 @@ if ((clone_flags & CLONE_DETACHED) && !(clone_flags & CLONE_THREAD)) return ERR_PTR(-EINVAL); - retval = security_ops->task_create(clone_flags); - if (retval) + if ((retval = security_task_create(clone_flags))) goto fork_out; retval = -ENOMEM; @@ -772,7 +771,7 @@ INIT_LIST_HEAD(&p->local_pages); retval = -ENOMEM; - if (security_ops->task_alloc_security(p)) + if (security_task_alloc(p)) goto bad_fork_cleanup; /* copy all the process information */ if (copy_semundo(clone_flags, p)) @@ -922,7 +921,7 @@ bad_fork_cleanup_semundo: exit_semundo(p); bad_fork_cleanup_security: - security_ops->task_free_security(p); + security_task_free(p); bad_fork_cleanup: if (p->pid > 0) free_pidmap(p->pid); ===== kernel/kmod.c 1.15 vs edited ===== --- 1.15/kernel/kmod.c Tue Oct 1 01:54:49 2002 +++ edited/kernel/kmod.c Wed Oct 16 00:28:59 2002 @@ -29,6 +29,7 @@ #include #include #include +#include #include @@ -134,7 +135,7 @@ /* Give kmod all effective privileges.. */ curtask->euid = curtask->fsuid = 0; curtask->egid = curtask->fsgid = 0; - security_ops->task_kmod_set_label(); + security_task_kmod_set_label(); /* Allow execve args to be in kernel space. */ set_fs(KERNEL_DS); ===== kernel/ptrace.c 1.18 vs edited ===== --- 1.18/kernel/ptrace.c Sun Sep 15 19:57:15 2002 +++ edited/kernel/ptrace.c Wed Oct 16 00:11:10 2002 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -100,8 +101,7 @@ /* the same process cannot be attached many times */ if (task->ptrace & PT_PTRACED) goto bad; - retval = security_ops->ptrace(current, task); - if (retval) + if ((retval = security_ptrace(current, task))) goto bad; /* Go */ ===== kernel/sched.c 1.140 vs edited ===== --- 1.140/kernel/sched.c Mon Oct 14 05:30:06 2002 +++ edited/kernel/sched.c Wed Oct 16 00:29:50 2002 @@ -1329,8 +1329,7 @@ if (nice > 19) nice = 19; - retval = security_ops->task_setnice(current, nice); - if (retval) + if ((retval = security_task_setnice(current, nice))) return retval; set_user_nice(current, nice); @@ -1451,8 +1450,7 @@ !capable(CAP_SYS_NICE)) goto out_unlock; - retval = security_ops->task_setscheduler(p, policy, &lp); - if (retval) + if ((retval = security_task_setscheduler(p, policy, &lp))) goto out_unlock; array = p->array; @@ -1515,8 +1513,7 @@ read_lock(&tasklist_lock); p = find_process_by_pid(pid); if (p) { - retval = security_ops->task_getscheduler(p); - if (!retval) + if (!(retval = security_task_getscheduler(p))) retval = p->policy; } read_unlock(&tasklist_lock); @@ -1545,8 +1542,7 @@ if (!p) goto out_unlock; - retval = security_ops->task_getscheduler(p); - if (retval) + if ((retval = security_task_getscheduler(p))) goto out_unlock; lp.sched_priority = p->rt_priority; @@ -1778,8 +1774,7 @@ if (!p) goto out_unlock; - retval = security_ops->task_getscheduler(p); - if (retval) + if ((retval = security_task_getscheduler(p))) goto out_unlock; jiffies_to_timespec(p->policy & SCHED_FIFO ? ===== kernel/signal.c 1.48 vs edited ===== --- 1.48/kernel/signal.c Thu Oct 3 02:26:00 2002 +++ edited/kernel/signal.c Wed Oct 16 00:30:19 2002 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -706,8 +707,7 @@ ret = -EPERM; if (bad_signal(sig, info, t)) goto out; - ret = security_ops->task_kill(t, info, sig); - if (ret) + if ((ret = security_task_kill(t, info, sig))) goto out; /* The null signal is a permissions and process existence probe. ===== kernel/sys.c 1.30 vs edited ===== --- 1.30/kernel/sys.c Tue Oct 15 14:45:52 2002 +++ edited/kernel/sys.c Wed Oct 16 00:33:50 2002 @@ -204,6 +204,7 @@ cond_syscall(sys_quotactl) cond_syscall(sys_acct) cond_syscall(sys_lookup_dcookie) +cond_syscall(sys_security) static int set_one_prio(struct task_struct *p, int niceval, int error) { @@ -479,8 +480,7 @@ int new_egid = old_egid; int retval; - retval = security_ops->task_setgid(rgid, egid, (gid_t)-1, LSM_SETID_RE); - if (retval) + if ((retval = security_task_setgid(rgid, egid, (gid_t)-1, LSM_SETID_RE))) return retval; if (rgid != (gid_t) -1) { @@ -525,8 +525,7 @@ int old_egid = current->egid; int retval; - retval = security_ops->task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_ID); - if (retval) + if ((retval = security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_ID))) return retval; if (capable(CAP_SETGID)) @@ -599,8 +598,7 @@ int old_ruid, old_euid, old_suid, new_ruid, new_euid; int retval; - retval = security_ops->task_setuid(ruid, euid, (uid_t)-1, LSM_SETID_RE); - if (retval) + if ((retval = security_task_setuid(ruid, euid, (uid_t)-1, LSM_SETID_RE))) return retval; new_ruid = old_ruid = current->uid; @@ -638,7 +636,7 @@ current->suid = current->euid; current->fsuid = current->euid; - return security_ops->task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RE); + return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RE); } @@ -660,8 +658,7 @@ int old_ruid, old_suid, new_ruid, new_suid; int retval; - retval = security_ops->task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_ID); - if (retval) + if ((retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_ID))) return retval; old_ruid = new_ruid = current->uid; @@ -683,7 +680,7 @@ current->fsuid = current->euid = uid; current->suid = new_suid; - return security_ops->task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_ID); + return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_ID); } @@ -698,8 +695,7 @@ int old_suid = current->suid; int retval; - retval = security_ops->task_setuid(ruid, euid, suid, LSM_SETID_RES); - if (retval) + if ((retval = security_task_setuid(ruid, euid, suid, LSM_SETID_RES))) return retval; if (!capable(CAP_SETUID)) { @@ -729,7 +725,7 @@ if (suid != (uid_t) -1) current->suid = suid; - return security_ops->task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RES); + return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_RES); } asmlinkage long sys_getresuid(uid_t *ruid, uid_t *euid, uid_t *suid) @@ -750,8 +746,7 @@ { int retval; - retval = security_ops->task_setgid(rgid, egid, sgid, LSM_SETID_RES); - if (retval) + if ((retval = security_task_setgid(rgid, egid, sgid, LSM_SETID_RES))) return retval; if (!capable(CAP_SETGID)) { @@ -804,8 +799,7 @@ int old_fsuid; int retval; - retval = security_ops->task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS); - if (retval) + if ((retval = security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS))) return retval; old_fsuid = current->fsuid; @@ -821,8 +815,7 @@ current->fsuid = uid; } - retval = security_ops->task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS); - if (retval) + if ((retval = security_task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS))) return retval; return old_fsuid; @@ -836,8 +829,7 @@ int old_fsgid; int retval; - retval = security_ops->task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS); - if (retval) + if ((retval = security_task_setgid(gid, (gid_t)-1, (gid_t)-1, LSM_SETID_FS))) return retval; old_fsgid = current->fsgid; @@ -962,8 +954,7 @@ retval = -ESRCH; if (p) { - retval = security_ops->task_getpgid(p); - if (!retval) + if (!(retval = security_task_getpgid(p))) retval = p->pgrp; } read_unlock(&tasklist_lock); @@ -990,8 +981,7 @@ retval = -ESRCH; if(p) { - retval = security_ops->task_getsid(p); - if (!retval) + if (!(retval = security_task_getsid(p))) retval = p->session; } read_unlock(&tasklist_lock); @@ -1072,8 +1062,7 @@ return -EINVAL; if(copy_from_user(groups, grouplist, gidsetsize * sizeof(gid_t))) return -EFAULT; - retval = security_ops->task_setgroups(gidsetsize, groups); - if (retval) + if ((retval = security_task_setgroups(gidsetsize, groups))) return retval; memcpy(current->groups, groups, gidsetsize * sizeof(gid_t)); current->ngroups = gidsetsize; @@ -1236,8 +1225,7 @@ return -EPERM; } - retval = security_ops->task_setrlimit(resource, &new_rlim); - if (retval) + if ((retval = security_task_setrlimit(resource, &new_rlim))) return retval; *old_rlim = new_rlim; @@ -1311,8 +1299,7 @@ int error = 0; int sig; - error = security_ops->task_prctl(option, arg2, arg3, arg4, arg5); - if (error) + if ((error = security_task_prctl(option, arg2, arg3, arg4, arg5))) return error; switch (option) { ===== kernel/uid16.c 1.2 vs edited ===== --- 1.2/kernel/uid16.c Fri Jul 19 16:00:55 2002 +++ edited/kernel/uid16.c Wed Oct 16 00:30:43 2002 @@ -140,8 +140,7 @@ return -EFAULT; for (i = 0 ; i < gidsetsize ; i++) new_groups[i] = (gid_t)groups[i]; - i = security_ops->task_setgroups(gidsetsize, new_groups); - if (i) + if ((i = security_task_setgroups(gidsetsize, new_groups))) return i; memcpy(current->groups, new_groups, gidsetsize * sizeof(gid_t)); current->ngroups = gidsetsize; ===== mm/mmap.c 1.53 vs edited ===== --- 1.53/mm/mmap.c Tue Oct 15 15:08:06 2002 +++ edited/mm/mmap.c Wed Oct 16 00:36:48 2002 @@ -498,8 +498,7 @@ } } - error = security_ops->file_mmap(file, prot, flags); - if (error) + if ((error = security_file_mmap(file, prot, flags))) return error; /* Clear old maps */ ===== mm/mprotect.c 1.19 vs edited ===== --- 1.19/mm/mprotect.c Tue Oct 1 16:43:14 2002 +++ edited/mm/mprotect.c Wed Oct 16 00:36:58 2002 @@ -262,8 +262,7 @@ goto out; } - error = security_ops->file_mprotect(vma, prot); - if (error) + if ((error = security_file_mprotect(vma, prot))) goto out; if (vma->vm_end > end) { ===== net/core/scm.c 1.3 vs edited ===== --- 1.3/net/core/scm.c Mon Jul 22 03:12:48 2002 +++ edited/net/core/scm.c Wed Oct 16 00:41:37 2002 @@ -217,8 +217,7 @@ for (i=0, cmfptr=(int*)CMSG_DATA(cm); ifile_receive(fp[i]); - if (err) + if ((err = security_file_receive(fp[i]))) break; err = get_unused_fd(); if (err < 0) ===== net/decnet/af_decnet.c 1.18 vs edited ===== --- 1.18/net/decnet/af_decnet.c Tue Oct 8 07:02:41 2002 +++ edited/net/decnet/af_decnet.c Wed Oct 16 00:42:30 2002 @@ -113,6 +113,7 @@ #include #include #include +#include #include #include #include @@ -794,7 +795,7 @@ * dn_prot_sock ? Would be nice if the capable call would go there * too. */ - if (security_ops->dn_prot_sock(saddr) && + if (security_dn_prot_sock(saddr) && !capable(CAP_NET_BIND_SERVICE) || saddr->sdn_objnum || (saddr->sdn_flags & SDF_WILD)) return -EACCES; ===== security/Config.in 1.3 vs edited ===== --- 1.3/security/Config.in Sat Jul 20 12:05:09 2002 +++ edited/security/Config.in Tue Oct 15 22:24:46 2002 @@ -3,5 +3,8 @@ # mainmenu_option next_comment comment 'Security options' -define_bool CONFIG_SECURITY_CAPABILITIES y +bool 'Enable different security models' CONFIG_SECURITY +if [ "$CONFIG_SECURITY" = "y" ]; then + dep_tristate ' Default Linux Capabilities' CONFIG_SECURITY_CAPABILITIES $CONFIG_SECURITY +fi endmenu ===== security/Makefile 1.1 vs edited ===== --- 1.1/security/Makefile Fri Jul 19 15:55:56 2002 +++ edited/security/Makefile Wed Oct 16 11:28:47 2002 @@ -3,11 +3,15 @@ # # Objects that export symbols -export-objs := security.o +export-objs := security.o capability.o -# Object file lists -obj-y := security.o dummy.o +# if we don't select a security model, use the default capabilities +ifneq ($(CONFIG_SECURITY),y) +obj-y += capability.o +endif +# Object file lists +obj-$(CONFIG_SECURITY) += security.o dummy.o obj-$(CONFIG_SECURITY_CAPABILITIES) += capability.o include $(TOPDIR)/Rules.make ===== security/capability.c 1.6 vs edited ===== --- 1.6/security/capability.c Tue Oct 8 02:01:30 2002 +++ edited/security/capability.c Wed Oct 16 11:30:04 2002 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -19,10 +20,7 @@ #include #include -/* flag to keep track of how we were registered */ -static int secondary; - -static int cap_capable (struct task_struct *tsk, int cap) +int cap_capable (struct task_struct *tsk, int cap) { /* Derived from include/linux/sched.h:capable. */ if (cap_raised (tsk->cap_effective, cap)) @@ -31,23 +29,7 @@ return -EPERM; } -static int cap_sys_security (unsigned int id, unsigned int call, - unsigned long *args) -{ - return -ENOSYS; -} - -static int cap_quotactl (int cmds, int type, int id, struct super_block *sb) -{ - return 0; -} - -static int cap_quota_on (struct file *f) -{ - return 0; -} - -static int cap_ptrace (struct task_struct *parent, struct task_struct *child) +int cap_ptrace (struct task_struct *parent, struct task_struct *child) { /* Derived from arch/i386/kernel/ptrace.c:sys_ptrace. */ if (!cap_issubset (child->cap_permitted, current->cap_permitted) && @@ -57,8 +39,8 @@ return 0; } -static int cap_capget (struct task_struct *target, kernel_cap_t * effective, - kernel_cap_t * inheritable, kernel_cap_t * permitted) +int cap_capget (struct task_struct *target, kernel_cap_t *effective, + kernel_cap_t *inheritable, kernel_cap_t *permitted) { /* Derived from kernel/capability.c:sys_capget. */ *effective = cap_t (target->cap_effective); @@ -67,10 +49,8 @@ return 0; } -static int cap_capset_check (struct task_struct *target, - kernel_cap_t * effective, - kernel_cap_t * inheritable, - kernel_cap_t * permitted) +int cap_capset_check (struct task_struct *target, kernel_cap_t *effective, + kernel_cap_t *inheritable, kernel_cap_t *permitted) { /* Derived from kernel/capability.c:sys_capset. */ /* verify restrictions on target's new Inheritable set */ @@ -95,27 +75,15 @@ return 0; } -static void cap_capset_set (struct task_struct *target, - kernel_cap_t * effective, - kernel_cap_t * inheritable, - kernel_cap_t * permitted) +void cap_capset_set (struct task_struct *target, kernel_cap_t *effective, + kernel_cap_t *inheritable, kernel_cap_t *permitted) { target->cap_effective = *effective; target->cap_inheritable = *inheritable; target->cap_permitted = *permitted; } -static int cap_acct (struct file *file) -{ - return 0; -} - -static int cap_bprm_alloc_security (struct linux_binprm *bprm) -{ - return 0; -} - -static int cap_bprm_set_security (struct linux_binprm *bprm) +int cap_bprm_set_security (struct linux_binprm *bprm) { /* Copied from fs/exec.c:prepare_binprm. */ @@ -143,23 +111,13 @@ return 0; } -static int cap_bprm_check_security (struct linux_binprm *bprm) -{ - return 0; -} - -static void cap_bprm_free_security (struct linux_binprm *bprm) -{ - return; -} - /* Copied from fs/exec.c */ static inline int must_not_trace_exec (struct task_struct *p) { return (p->ptrace & PT_PTRACED) && !(p->ptrace & PT_PTRACE_CAP); } -static void cap_bprm_compute_creds (struct linux_binprm *bprm) +void cap_bprm_compute_creds (struct linux_binprm *bprm) { /* Derived from fs/exec.c:compute_creds. */ kernel_cap_t new_permitted, working; @@ -204,6 +162,160 @@ current->keep_capabilities = 0; } +/* moved from kernel/sys.c. */ +/* + * cap_emulate_setxuid() fixes the effective / permitted capabilities of + * a process after a call to setuid, setreuid, or setresuid. + * + * 1) When set*uiding _from_ one of {r,e,s}uid == 0 _to_ all of + * {r,e,s}uid != 0, the permitted and effective capabilities are + * cleared. + * + * 2) When set*uiding _from_ euid == 0 _to_ euid != 0, the effective + * capabilities of the process are cleared. + * + * 3) When set*uiding _from_ euid != 0 _to_ euid == 0, the effective + * capabilities are set to the permitted capabilities. + * + * fsuid is handled elsewhere. fsuid == 0 and {r,e,s}uid!= 0 should + * never happen. + * + * -astor + * + * cevans - New behaviour, Oct '99 + * A process may, via prctl(), elect to keep its capabilities when it + * calls setuid() and switches away from uid==0. Both permitted and + * effective sets will be retained. + * Without this change, it was impossible for a daemon to drop only some + * of its privilege. The call to setuid(!=0) would drop all privileges! + * Keeping uid 0 is not an option because uid 0 owns too many vital + * files.. + * Thanks to Olaf Kirch and Peter Benie for spotting this. + */ +static inline void cap_emulate_setxuid (int old_ruid, int old_euid, + int old_suid) +{ + if ((old_ruid == 0 || old_euid == 0 || old_suid == 0) && + (current->uid != 0 && current->euid != 0 && current->suid != 0) && + !current->keep_capabilities) { + cap_clear (current->cap_permitted); + cap_clear (current->cap_effective); + } + if (old_euid == 0 && current->euid != 0) { + cap_clear (current->cap_effective); + } + if (old_euid != 0 && current->euid == 0) { + current->cap_effective = current->cap_permitted; + } +} + +int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, + int flags) +{ + switch (flags) { + case LSM_SETID_RE: + case LSM_SETID_ID: + case LSM_SETID_RES: + /* Copied from kernel/sys.c:setreuid/setuid/setresuid. */ + if (!issecure (SECURE_NO_SETUID_FIXUP)) { + cap_emulate_setxuid (old_ruid, old_euid, old_suid); + } + break; + case LSM_SETID_FS: + { + uid_t old_fsuid = old_ruid; + + /* Copied from kernel/sys.c:setfsuid. */ + + /* + * FIXME - is fsuser used for all CAP_FS_MASK capabilities? + * if not, we might be a bit too harsh here. + */ + + if (!issecure (SECURE_NO_SETUID_FIXUP)) { + if (old_fsuid == 0 && current->fsuid != 0) { + cap_t (current->cap_effective) &= + ~CAP_FS_MASK; + } + if (old_fsuid != 0 && current->fsuid == 0) { + cap_t (current->cap_effective) |= + (cap_t (current->cap_permitted) & + CAP_FS_MASK); + } + } + break; + } + default: + return -EINVAL; + } + + return 0; +} + +void cap_task_kmod_set_label (void) +{ + cap_set_full (current->cap_effective); + return; +} + +void cap_task_reparent_to_init (struct task_struct *p) +{ + p->cap_effective = CAP_INIT_EFF_SET; + p->cap_inheritable = CAP_INIT_INH_SET; + p->cap_permitted = CAP_FULL_SET; + p->keep_capabilities = 0; + return; +} + +EXPORT_SYMBOL(cap_capable); +EXPORT_SYMBOL(cap_ptrace); +EXPORT_SYMBOL(cap_capget); +EXPORT_SYMBOL(cap_capset_check); +EXPORT_SYMBOL(cap_capset_set); +EXPORT_SYMBOL(cap_bprm_set_security); +EXPORT_SYMBOL(cap_bprm_compute_creds); +EXPORT_SYMBOL(cap_task_post_setuid); +EXPORT_SYMBOL(cap_task_kmod_set_label); +EXPORT_SYMBOL(cap_task_reparent_to_init); + +#ifdef CONFIG_SECURITY + +static int cap_sys_security (unsigned int id, unsigned int call, + unsigned long *args) +{ + return -ENOSYS; +} + +static int cap_quotactl (int cmds, int type, int id, struct super_block *sb) +{ + return 0; +} + +static int cap_quota_on (struct file *f) +{ + return 0; +} + +static int cap_acct (struct file *file) +{ + return 0; +} + +static int cap_bprm_alloc_security (struct linux_binprm *bprm) +{ + return 0; +} + +static int cap_bprm_check_security (struct linux_binprm *bprm) +{ + return 0; +} + +static void cap_bprm_free_security (struct linux_binprm *bprm) +{ + return; +} + static int cap_sb_alloc_security (struct super_block *sb) { return 0; @@ -512,96 +624,6 @@ return 0; } -/* moved from kernel/sys.c. */ -/* - * cap_emulate_setxuid() fixes the effective / permitted capabilities of - * a process after a call to setuid, setreuid, or setresuid. - * - * 1) When set*uiding _from_ one of {r,e,s}uid == 0 _to_ all of - * {r,e,s}uid != 0, the permitted and effective capabilities are - * cleared. - * - * 2) When set*uiding _from_ euid == 0 _to_ euid != 0, the effective - * capabilities of the process are cleared. - * - * 3) When set*uiding _from_ euid != 0 _to_ euid == 0, the effective - * capabilities are set to the permitted capabilities. - * - * fsuid is handled elsewhere. fsuid == 0 and {r,e,s}uid!= 0 should - * never happen. - * - * -astor - * - * cevans - New behaviour, Oct '99 - * A process may, via prctl(), elect to keep its capabilities when it - * calls setuid() and switches away from uid==0. Both permitted and - * effective sets will be retained. - * Without this change, it was impossible for a daemon to drop only some - * of its privilege. The call to setuid(!=0) would drop all privileges! - * Keeping uid 0 is not an option because uid 0 owns too many vital - * files.. - * Thanks to Olaf Kirch and Peter Benie for spotting this. - */ -static inline void cap_emulate_setxuid (int old_ruid, int old_euid, - int old_suid) -{ - if ((old_ruid == 0 || old_euid == 0 || old_suid == 0) && - (current->uid != 0 && current->euid != 0 && current->suid != 0) && - !current->keep_capabilities) { - cap_clear (current->cap_permitted); - cap_clear (current->cap_effective); - } - if (old_euid == 0 && current->euid != 0) { - cap_clear (current->cap_effective); - } - if (old_euid != 0 && current->euid == 0) { - current->cap_effective = current->cap_permitted; - } -} - -static int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, - int flags) -{ - switch (flags) { - case LSM_SETID_RE: - case LSM_SETID_ID: - case LSM_SETID_RES: - /* Copied from kernel/sys.c:setreuid/setuid/setresuid. */ - if (!issecure (SECURE_NO_SETUID_FIXUP)) { - cap_emulate_setxuid (old_ruid, old_euid, old_suid); - } - break; - case LSM_SETID_FS: - { - uid_t old_fsuid = old_ruid; - - /* Copied from kernel/sys.c:setfsuid. */ - - /* - * FIXME - is fsuser used for all CAP_FS_MASK capabilities? - * if not, we might be a bit too harsh here. - */ - - if (!issecure (SECURE_NO_SETUID_FIXUP)) { - if (old_fsuid == 0 && current->fsuid != 0) { - cap_t (current->cap_effective) &= - ~CAP_FS_MASK; - } - if (old_fsuid != 0 && current->fsuid == 0) { - cap_t (current->cap_effective) |= - (cap_t (current->cap_permitted) & - CAP_FS_MASK); - } - } - break; - } - default: - return -EINVAL; - } - - return 0; -} - static int cap_task_setgid (gid_t id0, gid_t id1, gid_t id2, int flags) { return 0; @@ -664,21 +686,6 @@ return 0; } -static void cap_task_kmod_set_label (void) -{ - cap_set_full (current->cap_effective); - return; -} - -static void cap_task_reparent_to_init (struct task_struct *p) -{ - p->cap_effective = CAP_INIT_EFF_SET; - p->cap_inheritable = CAP_INIT_INH_SET; - p->cap_permitted = CAP_FULL_SET; - p->keep_capabilities = 0; - return; -} - static int cap_ipc_permission (struct kern_ipc_perm *ipcp, short flag) { return 0; @@ -838,6 +845,10 @@ #define MY_NAME "capability" #endif +/* flag to keep track of how we were registered */ +static int secondary; + + static int __init capability_init (void) { /* register ourselves with the security framework */ @@ -877,3 +888,5 @@ MODULE_DESCRIPTION("Standard Linux Capabilities Security Module"); MODULE_LICENSE("GPL"); + +#endif /* CONFIG_SECURITY */ From greg@kroah.com Wed Oct 16 12:07:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 12:07:36 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GJ7VtG011603 for ; Wed, 16 Oct 2002 12:07:31 -0700 Received: (qmail 25568 invoked by uid 500); 16 Oct 2002 19:07:24 -0000 Date: Wed, 16 Oct 2002 12:07:24 -0700 From: Greg KH To: netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks Message-ID: <20021016190724.GB25475@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.com> <20021016081539.GF20421@kroah.com> <20021016185927.GA25475@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021016185927.GA25475@kroah.com> User-Agent: Mutt/1.4i X-archive-position: 729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Wed, Oct 16, 2002 at 11:59:28AM -0700, Greg KH wrote: > > Ok, here's a working version (I'm typing from it right now), with all of > the capability logic working again. This does make the > security/built-in.o file this size with CONFIG_SECURITY=y > > text data bss dec hex filename > 1611 0 0 1611 64b security/built-in.o That should have said CONFIG_SECURITY=n Sorry for any confusion. greg k-h From Ian_Thompson@adaptec.com Wed Oct 16 15:54:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 15:54:35 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GMsXtG010907 for ; Wed, 16 Oct 2002 15:54:33 -0700 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11] (may be forged)) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g9GMsSw23682 for ; Wed, 16 Oct 2002 15:54:28 -0700 (PDT) Received: from aimexc07.adaptec.com (aimexc07.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA22619 for ; Wed, 16 Oct 2002 15:54:28 -0700 (PDT) Received: by aimexc07.adaptec.com with Internet Mail Service (5.5.2653.19) id <4ZZPS2W7>; Wed, 16 Oct 2002 15:54:28 -0700 Message-ID: From: "Thompson, Ian" To: "'netdev@oss.sgi.com'" Subject: ARP problem? Date: Wed, 16 Oct 2002 15:54:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Ian_Thompson@adaptec.com Precedence: bulk X-list: netdev Hi, I'm seeing some odd behavior in RedHat 7.3 when handling ARP packets. I have two Intel NIC cards, eth0 and eth1, in one machine, connected to the same switch. eth0 is set to IP0 and has MAC addr M0, and eth1 is at IP1 and MAC M1. Now, if another machine connected to the switch sends an ARP broadcast asking who is at IP0, I see two replies on the wire -- IP0 is at M0, and IP0 is at M1. This result seems contradictory to me; could it be some sort of feature that I'm not aware of? If so, can I disable it? I am trying to devlop some code to support an active failover case, so I want two seperate devices on the same physical network. I have seen the same result even if IP0 and IP1 are on different subnets, or even if one is a class A and the other is a class C address. I'm sorry if this has already been discussed -- I haven't seen much relating to it in the archives. TIA, -ian --- Ian Thompson Firmware Engineer Adaptec, Inc Storage Networking Group 408.957.4909 408.957.6800 (fax) ian_thompson@adaptec.com From greearb@candelatech.com Wed Oct 16 16:07:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 16:07:07 -0700 (PDT) Received: from grok.yi.org (IDENT:bVo1Y2epr4M5vASFifHz6Et5sH0CJCNr@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GN74tG012666 for ; Wed, 16 Oct 2002 16:07:05 -0700 Received: from candelatech.com (IDENT:jcjVkTjYBuc78XK23zpYIc85PMUh3ii6@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9GN6pq09411; Wed, 16 Oct 2002 16:06:51 -0700 Message-ID: <3DADF10B.3080804@candelatech.com> Date: Wed, 16 Oct 2002 16:06:51 -0700 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: "Thompson, Ian" CC: "'netdev@oss.sgi.com'" Subject: Re: ARP problem? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 731 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 Thompson, Ian wrote: > Hi, > > I'm seeing some odd behavior in RedHat 7.3 when handling ARP packets. I > have two Intel NIC cards, eth0 and eth1, in one machine, connected to the > same switch. eth0 is set to IP0 and has MAC addr M0, and eth1 is at IP1 and > MAC M1. Now, if another machine connected to the switch sends an ARP > broadcast asking who is at IP0, I see two replies on the wire -- IP0 is at > M0, and IP0 is at M1. This result seems contradictory to me; could it be > some sort of feature that I'm not aware of? If so, can I disable it? > > I am trying to devlop some code to support an active failover case, so I > want two seperate devices on the same physical network. I have seen the > same result even if IP0 and IP1 are on different subnets, or even if one is > a class A and the other is a class C address. > > I'm sorry if this has already been discussed -- I haven't seen much relating > to it in the archives. You need arp-filtering: # Set up arp-filter magic. This, with source-based routing allows us # to have multiple NICs on the same subnet, on the same machine, connected # to the same switch... if [ -f /proc/sys/net/ipv4/conf/all/arp_filter ]; then echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter else echo "ERROR: kernel does not support arp_filter. Don't put more than" echo " one interface on the same subnet on the same machine." echo "" fi > > TIA, > -ian > > --- > Ian Thompson Firmware Engineer > Adaptec, Inc Storage Networking Group > 408.957.4909 408.957.6800 (fax) > ian_thompson@adaptec.com > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From Ian_Thompson@adaptec.com Wed Oct 16 16:17:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 16:17:33 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GNHWtG014576 for ; Wed, 16 Oct 2002 16:17:32 -0700 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11] (may be forged)) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g9GNHQw27646; Wed, 16 Oct 2002 16:17:26 -0700 (PDT) Received: from aimexc07.adaptec.com (aimexc07.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA26813; Wed, 16 Oct 2002 16:17:26 -0700 (PDT) Received: by aimexc07.adaptec.com with Internet Mail Service (5.5.2653.19) id <4ZZPS25Z>; Wed, 16 Oct 2002 16:17:26 -0700 Message-ID: From: "Thompson, Ian" To: "'Ben Greear'" Cc: "'netdev@oss.sgi.com'" Subject: RE: ARP problem? Date: Wed, 16 Oct 2002 16:17:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Ian_Thompson@adaptec.com Precedence: bulk X-list: netdev > > You need arp-filtering: > > # Set up arp-filter magic. This, with source-based > routing allows us > # to have multiple NICs on the same subnet, on the same > machine, connected > # to the same switch... > if [ -f /proc/sys/net/ipv4/conf/all/arp_filter ]; > then > echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter > else > echo "ERROR: kernel does not support arp_filter. Don't > put more than" > echo " one interface on the same subnet on the > same machine." > echo "" > fi > I tried this, and now I'm getting only one ARP response. However, I get the same MAC address for ARP broadcasts for either IP address. Does ARP filtering turn off all but the first interface when processing ARP packets? Can I get each interface to answer ARP packets only for its specific IP address? Thanks, -ian From greearb@candelatech.com Wed Oct 16 16:56:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 16:56:39 -0700 (PDT) Received: from grok.yi.org (IDENT:WE89jHMWjrEQL/zZWm4vOZgnV8xYF9Nl@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9GNubtG019326 for ; Wed, 16 Oct 2002 16:56:37 -0700 Received: from candelatech.com (IDENT:rlU2t+NLowCIRP6enetUKB5CUVBKM5zr@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9GNuZq09814; Wed, 16 Oct 2002 16:56:35 -0700 Message-ID: <3DADFCB3.6010206@candelatech.com> Date: Wed, 16 Oct 2002 16:56:35 -0700 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: "Thompson, Ian" CC: "'netdev@oss.sgi.com'" Subject: Re: ARP problem? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 733 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 Thompson, Ian wrote: >>You need arp-filtering: >> >> # Set up arp-filter magic. This, with source-based >>routing allows us >> # to have multiple NICs on the same subnet, on the same >>machine, connected >> # to the same switch... >> if [ -f /proc/sys/net/ipv4/conf/all/arp_filter ]; >> then >> echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter >> else >> echo "ERROR: kernel does not support arp_filter. Don't >>put more than" >> echo " one interface on the same subnet on the >>same machine." >> echo "" >> fi >> > > > I tried this, and now I'm getting only one ARP response. However, I get the > same MAC address for ARP broadcasts for either IP address. Does ARP > filtering turn off all but the first interface when processing ARP packets? > Can I get each interface to answer ARP packets only for its specific IP > address? Try setting up source-based routing. Here is a snippet of perl code that does that, but it will be difficult for you to decipher out of context: e_if is a list of interfaces (ie eth2) e_ip is the IP for this interface sigb is the significant bits, ie the 24 in 192.168.2.0/24 e_tbl is the table name, you need a table for each interface. print "# Setup for device: $e_if[$i] IP: $e_ip[$i] sig-bits: $e_sigb[$i]\n"; printAndExec("ip link set $e_if[$i] down"); printAndExec("ip link set $e_if[$i] up"); printAndExec("ip addr flush dev $e_if[$i]"); if ($e_ip[$i] ne "0.0.0.0") { printAndExec("ip address add $e_ip[$i]/$e_sigb[$i] broadcast $e_bcast[$i] dev $e_if[$i]"); } printAndExec("ip link set dev $e_if[$i] up"); if ($e_ip[$i] ne "0.0.0.0") { printAndExec("ip ru add from $e_ip[$i]/32 table $e_tbl[$i]"); printAndExec("ip route add $e_sub[$i]/$e_sigb[$i] via $e_ip[$i] table $e_tbl[$i]"); } if ($e_gw[$i] ne "0.0.0.0") { printAndExec("ip route add 0/0 via $e_gw[$i] dev $e_if[$i] table $e_tbl[$i]"); } You can use this to give you ideas of what to look for as you read one of the advanced-routing HOWTOs. With source-based routing and arp-filtering, I have gotten many interfaces on the same subnet to work as you would expect, so it can be done :) Ben > > Thanks, > -ian > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From ngall@lycos.com Wed Oct 16 17:07:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 17:07:04 -0700 (PDT) Received: from 16.04.25.17 (node-c-1074.a2000.nl [62.194.16.116]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H04UtG021127 for ; Wed, 16 Oct 2002 17:04:48 -0700 Message-Id: <200210170004.g9H04UtG021127@oss.sgi.com> From: "JEFF MUBANGA." To: netdev@oss.sgi.com Reply-To: jeffmubanga2001@hotmail.com Subject: Please,I need your entire support and co-operation Date: Thu, 17 Oct 2002 02:04:49 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="a28d7614-9edf-4268-b355-6f4c952135be" X-archive-position: 734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ngall@lycos.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format --a28d7614-9edf-4268-b355-6f4c952135be Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sir, I am JEFF MUBANGA, the secetary of Africa White Farmers Co-operation(AWFC) = of=0D Harare, Zimbabwe. After the last general elections in my country where the incumbent president, Mr.Robert Mugabe won the presidential election, the government h= as=0D adopted a very aggressive land reforms programme. This programme is solely = aimed at taking the land owned by white African farmers for redistribution to bla= ck=0D africans. This programme has attracted worldwide condemnation from world leaders incl= uding British prime minister, Mr Tony Blair and also forced several white farmers= to flee the country for fear of victimization and physical abuse. Just some few weeks ago, our headquarters in Harare was attacked and looted= by black protesters and in the process burnt down the whole building. Fortunately,they did not get access to the huge funds kept in the strong ro= om=0D which belong to the co-operative body. This cash amounting to US$10.5 milli= on was kept at the secretariat rather than in the bank for fear of seizure by the government agencies. Now I have the money lodged in a local security company which was discretionary tagged 'GEMSTONES' and would need to get it invested in a via= ble business venture in Europe. Once I can get your commitment and sincerity of investing this funds on our behalf then I would proceed to get the funds freighted to Europe by the security company without any detection by the oppresive government, from where you would be required to pick it up for investment for us. You do not have anything to worry about as I would undertake all charges involved in freighting the funds to europe, and the business proposal is le= gal and risk free. You would be adequately compensated for all your effort once we complete th= is=0D transaction by availing you 25% of the funds or alternatively you will be a partner in whatever investment we will go into. Please get back to me if you can be of assistance and I would want our correspondence to be via email as most phone lines of white farmers are presently bugged by the government. I expect your confidentiality and your prompt response to this mail so as to proceed. Kind regards, MR. JEFF MUBANGA. --a28d7614-9edf-4268-b355-6f4c952135be Content-Type: application/octet-stream; charset=iso-8859-1; file=den2.txt Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=den2.txt Y3dpbmtsZXJAbWFpbC5heGxleS5jb20NCmpjaXNuZXJvc0BrcmVpbmRsZXIu Y29tDQpob2ZmbWFubWVyZWRpdGhAaG93cmV5LmNvbQ0KamJtb2JlcmdAbWJm LWxhdy5jb20NCmNvbnJhZHNAd2luc3RpbS5jb20NCnNoaXJsZXkuYXJvbnNv bkBjb3VydHMuc3RhdGUubWQudXMNCmxsc2NpbmNAYW9sLmNvbQ0KbWFubmlu Z2pAd2luc3RpbS5jb20NCnN1c2FuLmNoZXNzZXJAYmFrZXJuZXQuY29tDQpq bW9vcmVAZnJvZi5jb20NCnNtZWxsaW5AamVubmVyLmNvbQ0Kc3dlaW50cmF1 YkB1c3dlc3QubmV0DQphZGFub3dza0Bjb2xzaGFuLmNvbQ0KbHN0b3J5QHBn Zm0uY29tDQpkZWJvcmFoX2hhcnR3ZWxsQGJha2VyYm90dHMuY29tDQp6ZXJt YXR0QHdhbGxpcy5jaA0KZWNvbGtpbkBjbXAuY29tDQpkdWNhYW1lZGVvQGNh bXBpbmcuaXQNCmluZm9AdmlsbGFnZ2lvaWxnYWJiaWFuby5jb20NCmluZm9A dmlsbGFnZ2lvdG9ycmVzYXJhY2VuYS5pdA0KaW5mb0BsYWZyYW5jZXNjYS5p dA0KaW5mb0BjYW1waW5nbGVmb250aS5jb20NCmluZm9AY2FtcGluZ2RlaWZp b3JpLml0DQppbmZvZnJhbkB2aWxsYWdnaWxhZnJhbmNlc2NhLml0DQpjYW1w cm9zYUB0aW4uaXQNCmluZm9AY2FtcGluZ3BlcnRpY2FyYS5jb20NCmluZm9A Y2FtcGluZ3BpbmV0YW1hcmUuY29tDQppbmZvQHRlcnJhenphc3VsbWFyZS5p dA0KaW5mb0B2aWxsYWdnaW90aXppYW5hLml0DQpiYWlhZmFsY29uZUBndGZh bGNvbmUuaXQNCmRlbWF0dGlhQHJlc2lkZW5jZWF0bGFudGlkZS5pdA0KZm9u dGFuYWRlbGxlcm9zZUB5YWhvby5pdA0KaW5mb0Bpc3VsZWRkYS5pdA0KY2Ft cGluZ0B0aXNjYWxpbmV0Lml0DQppbmZvQGNhbXBpbmdzYXJhZ29zYS5pdA0K cGFub3ZlcmRlQHRpc2NhbGluZXQuaXQNCmNhbXBpbmd2ZXJzaWxpYUB0aXNj YWxpbmV0Lml0DQpjYW1waW5ncmVhbGVAdGluLml0DQptYi5wZW5uZXJAbGli ZXJvLml0DQppdmJlbHRyYUB0aW4uaXQNCmluZm9AdW5pb25saWRvLmNvbQ0K Y2FtcGluZ2FsbGFnb0BsaWJlcm8uaXQNCmxhY29uY2hpZ2xpYUBmcmVlbWFp bC5pdA0KZ2VzdGlvbmVAY2FtcGVnZ2l0YWxpYS5jb20NCmluZm9AZmVycmEu cnUNCmluZm9AcGNoYXJkd2FyZS5ybw0KaW5mb0BhcnRpZ2lhbmVvbmxpbmUu aXQNCmxvcnlfZ21AbGliZXJvLml0DQpjaW56aWFAYXhpYS5pdA0KY2luemlh Y29AYXhpYS5pdA0Ka2lhbWFAaG90bWFpbC5jb20NCm1hcmNvYm9tYmV0dGFA aG90bWFpbC5jb20NCmFkYXJyZWRhQGlvbC5pdA0KZXZvbHVjZUB0aXNjYWxp bmV0Lml0DQplbnJpY28ubGVnbm9AaW53aW5kLml0DQp0b21hc2lubzIwMDFA eWFob28uaXQNCm1hb3ZpbkBpbmZpbml0by5pdA0KZ2hlcmFyZGlyaXRhQHN1 cGVyZXZhLml0DQpsb3J5LWdtQGxpYmVyby5pdA0Kcm9ieTM3OEB5YWhvby5p dA0KY3V6emlsbGFAdGlzY2FsaS5pdA0KYmF0aTY2QGxpYmVyby5pdA0KbHVj aXNhc3NpQGxpYmVyby5pdA0Kemlhcm9zeUB0aXNjYWxpLml0DQp0aW5hamFj a0BpbndpbmQuaXQNCmluZm9zaW1vbmVnZW5uaUBpbndpbmQuaXQNCmlhY2Vu dGVyZGNAeWFob28uY29tDQpldWdlbmVjODgzQGFvbC5jb20NCmV1Z2VuZWNA ZnJvbnRpZXJuZXQubmV0DQppYWNlbnRlckBpYWNlbnRlci5vZw0KZGlhbmUu Z2F0ZXNAbHcuY29tDQptYXJnYXJldGFfcy5fa25hdWZmQGRzbWxscC5jb20N CmFuaXRhYUBsYWZiLmFnLnN0YXRlLm1uLnVzDQphYWxscGFyZW50QGFvbC5j b20NCmV1Z2VuZWNAZnJvbnRpZXJuZXQuY29tDQpwZWFjZWZpcnN0QGFvbC5j b20NCmptc25ld3MxQGFvbC5jb20NCmFtby5kdnNlbWFpbEB1dW5ldC51dS5u ZXQNCnNla2xlckBsYWJyaWRnZS5jb20NCnNjYXdkaUBob3RtYWlsLmNvbQ0K bXZhbGxlbkBwcmltZW5ldC5jb20NCm5vcmFzbHNAcGFja2V0Lm5ldA0KY2Jh bWJAYW9sLmNvbQ0KdGFpZ2VuQHNpcml1cy5jb20NCmJhYm9kbGliQG9ucmFt cC5uZXQNCnF1ZXBodW9uZ0BkZWxwaGkuY29tDQpkZ3JpZ3N0QGFncGxhdy5j b20NCmdlcnlhcm1zYnlAYW9sLmNvbQ0KYnNrYkBsamV4dHJhLmNvbQ0KcnBh cnNvbnNAZnJvbnRpZXIubmV0DQpsd29sZkBzaGVwYXJkcy5jb20NCmRhbGxl ZGl0b3JAYW9sLmNvbQ0Kc2FibGliQGNybC5jb20NCmxiZ29sZHN0QG13YmIu Y29tDQppbmZvQG1hcmluYS1hbGVyaWEuY29tDQpyaXZhLWJlbGxhQHdhbmFk b28uZnINCnJlY2VwdGlvbkByb25kaW5hcmEuZnINCnBkdXJoYW1Acmlhc210 cC5yaWF0YXguY29tDQpsaWRlYW5AZGVscGhpLmNvbQ0Kcm9uYWxkX0B0cmFj ZS5jb20udHcNCnBpYW4uZGVsLmZvc3NlQHdhbmFkb28uZnINCmFuZ2llLmRv bGwuZm9sZXlAbHcuY29tDQptY29zQHNpdGVjLmZyDQppbmZvQGxhLXBpbmVk ZS5uZXQNCnRob21wc29uQGludHIubmV0DQpjYW1waW5nX2xhX3ZhbGxlZUBu ZXRjb3Vycmllci5jb20NCmNhbXBpbmdtdWxpbmFjY2l1QHdhaWthOS5jb20N CmluZm9AdmlsbGFnZS1vc3RyaWNvbmkuY29tDQppbmZvQGNhbXBpbmdsYXZl dHRhLmNvbQ0KY3Jhc2hsaXN0QGxpc3RzLnd3cHVibGlzaC5jb20NCmEtcXVp bm5AbWluZHNwcmluZy5jb20NCnN1YnNjcmliZUB0b3BpY2EuY29tDQpyLml4 ZXJAYnRpbnRlcm5ldC5jb20NCnJvbndpbHNvbkBibHVleW9uZGVyLmNvLnVr DQplbmdlbGNoZW42OUBuZXhnby5kZQ0KamFtZXNAdGF5bG9yZWRzb2x1dGlv bnMuY28udWsNCmdob2ZmQG9ubGluZS5ubw0Kc3Rld2FydF9vbGdhQHlhaG9v LmNvbQ0KZGJtQGFya2Fuc2FzLm5ldA0Kc3RlcGhAZ3Jhbm55Z2Vlay5mcmVl c2VydmUuY28udWsNCm5jYWRlc2lnbnNAY29tcHVzZXJ2ZS5jb20NCmRhdmlk bG91aXNhdG9tQGFvbC5jb20NCnBhZ2Vib3lAbnRsd29ybGQuY29tDQp3cml0 ZW9ud29tYW5Ac2suc3ltcGF0aWNvLmNhDQpsaXR0bGV3b2xmXzYyQG1zbi5j b20NCnBldGpveUBzeW1wYXRpY28uY2ENCnNoZWxsc0BrdWRkbGVla2xvd25z LmZyZWVzZXJ2ZS5jby51aw0KZ2FyZmllbGQwODA4QGFvbi5hdA0KZ3V5LmVh c3RlcmJyb29rQGVxdWFudC5jb20NCmJvYmJpZTIwQG1pbmRzcHJpbmcuY29t DQpzaGVzc2VAd2xyay5jb20NCmpvbmVzbUBob3dyZXkuY29tDQpnbGVuZGEu ZmFycmVsbEBiYW5rb2ZhbWVyaWNhLmNvbQ0KYWxncmVlbkBoa2xhdy5jb20N Cmpja2lsZXlAbWJmLWxhdy5jb20NCnBhdHJpY2lhZWxsaW5nc29uQG5vcnRo d2VzdGVybm11dHVhbC5jb20NCnJwdXJhc0BjcmF2YXRoLmNvbQ0Kam9lLmsu c3RlcGhlbnNAb2pkLnN0YXRlLm9yLnVzDQpjYXJvbC5yb2dlcnNAbHcuY29t DQpsY2hvaUBwZ2ZtLmNvbQ0KbGluZGFfZmllbGRzQGFwb3J0ZXIuY29tDQpt YXJpZS5jYW5hZGFAYmFrZXJib3R0cy5jb20NCmFsZXRhX2JlbmphbWluQGNh cGdyb3VwLmNvbQ0KdHZpdG5lbGxAZ3RsYXcuY29tLmF1DQpkYm9ldHRAY3Au ZHVsdXRoLm1uLnVzDQptaGF3a2luc0Boa2xhdy5jb20NCmpsdXN0aWdlckBu bW1sYXcuY29tDQprYXRobGVlbi5icnVuZXJAYmZrcG4uY29tDQpwZ3JlZW5l QHdzZ3IuY29tDQpsaGFycmluZ3RvbkBoa2xhdy5jb20NCm1oZWluZW5Ac2Fo LmNvbQ0KbGlicmFyeUBoa2xhdy5jb20NCmN3aW5rbGVyQGF4bGV5LmNvbQ0K ZWdyZWVuZmllbGRAcGhrcy5jb20NCmNoZWZvZGFmdXRhQGhvdG1haWwuY29t DQpwYXJyb3RoZWFkbnlAZWFydGhsaW5rLm5ldA0Kc3RldmVAbWVkaWFvbmUu bmV0DQpqb25hdGhhbmpoQG1zbi5jb20NCmV0YW5uZXJAZ2F0ZS5uZXQNCmsz ZXNueWRlckBhb2wuY29tDQpjbGFwc2FkZGxlLnRleEBwcm9kaWd5Lm5ldA0K ZWxpemFiZXRoLmJlcnJ5QHdlaWwuY29tDQo3NDIyMi4yNzU0QGNvbXB1c2Vy dmUuY29tDQphYWxsam9uQGFvbC5jb20NCmJrbGF3ckBwYWNpZmljbmV0Lm5l dA0Kcm1zaGVhQGRlbHBoaS5jb20NCmpvb2Yuc2Nob3BwaW5nQGZhY2J1cmZk ci5ydWxpbWJ1cmcubmwNCm1pa2VjQGJhbmNyb2Z0LmNvbQ0KY2tvcmttYXNA ZGlhbC5zaGVsbC5jb20NCmpkc2hlZXRzQGFvbC5jb20NCnN3aGl0bmV5QG1h aWxiYWcuY29tDQpzdWJyb3F1ZUBjb25uaXguY29tDQpjaGluYTNAYW9sLmNv bQ0Ka2Fzb3dpdHJAZW1pLmNvbQ0KcnN0ZWVyZUBkZWxwaGkuY29tDQplbGl6 YWJldGhfbGVkb3V4QGRzbWxscC5jb20NCmtlbmJiMUBhb2wuY29tDQpodXRj aHNAZGVscGhpLmNvbQ0Ka3NpbGJlckBibmEuY29tDQpiZ3JlZW5maWVsZEBj YmNsZWdhbC5jb20NCnZpY3Rvci5saXBza2lAdnV3LmFjLm56DQpjYXJvbC5i cm9za0BiZmtwbi5jb20NCmthZ2Vuc2FAbnkuc2V5ZmFydGguY29tDQpzY2hp bGxlckBhdHQubmV0DQpzcGlsc29uNTQ1QGFvbC5jb20NCnZidXJrZUBzY2Js YXcuY29tDQpkbGliZW5ndUBmY2xhdy5jb20NCmdpdWxpYW5vLmNoaWNjb0Bt b25zYW50by5jb20NCmVkb2xhbkBrcmFtZXJsZXZpbi5jb20NCmRwZWxsZXRp ZXJAa3JhbWVybGV2aW4uY29tDQphbm5lbWFyaWVfbG9yZW56ZW5Ac2hzbC5j b20NCnRpZ2dlckBvbmVtb3JlbW9ua2V5LmNvbQ0KZ29ubmFraWxseWFAcGxh bmV0cXVha2UuY29tDQpyb2JfcEBhbHRhdmlzdGEuY29tDQpkZXRoMnVhbGxA aG90bWFpbC5jb20NCmFuaWthLnZhbi53eWtAY2FsZ2FyeXN1bi5jb20NCm1h aWxpbmdsaXN0QHBlc2NhaW5tYXJlLmNvbQ0KcHViYmxpY2l0YUBwZXNjYWlu bWFyZS5jb20NCjMyY3NtLmxvbmRvbkBhbXNlcnZlLm5ldA0Kbm9tZXJjeUBv bGRwbGF5ZXJzLmRlDQpvcGFzQG9sZHBsYXllcnMuZGUNCmFsYWRpbkBvbGRw bGF5ZXJzLmRlDQpzdGF0dXNub3dAeWFob28uY28udWsNCmJhYnNAb2xkcGxh eWVycy5kZQ0KY29vbGpAb2xkcGxheWVycy5kZQ0KaXJzcEBob3RtYWlsLmNv bQ0KY3JhYmJlQG9sZHBsYXllcnMuZGUNCmNyYXNob3ZlckBvbGRwbGF5ZXJz LmRlDQppcnNwQG5ldHdpei5uZXQNCmRlZ2dlckBvbGRwbGF5ZXJzLmRlDQpk cmRlYXRoQG9sZHBsYXllcnMuZGUNCmZhZ29Ab2xkcGxheWVycy5kZQ0Kc3Vu d3l0Y2hAaG90bWFpbC5jb20NCmZhdHpvQG9sZHBsYXllcnMuZGUNCmZvZ0Bv bGRwbGF5ZXJzLmRlDQpmZW5pYW5fZmFpdGhAeWFob28uY29tDQpndW5oZWRA b2xkcGxheWVycy5kZQ0KanVhbmNob0BvbGRwbGF5ZXJzLmRlDQpjdWJhX2ll QGhvdG1haWwuY29tDQpraW5nQG9sZHBsYXllcnMuZGUNCm1hdmVyaWNrQG9s ZHBsYXllcnMuZGUNCm1ldHpAb2xkcGxheWVycy5kZQ0KbWlrQG9sZHBsYXll cnMuZGUNCnJlYXBlckBvbGRwbGF5ZXJzLmRlDQpzdWJ6ZXJvQG9sZHBsYXll cnMuZGUNCnRvbWVrQG9sZHBsYXllcnMuZGUNCm1oYWxsNzU4MTlAYW9sLmNv bQ0KY29udGVudEBsaXZlZ2lnZ3VpZGUuY29tDQpraWxnb3JlQGVkZW4uY29t DQpraWxnb3JlQHQxLTcxLmVkZW4uY29tDQpyYWxseUBoZXJvbi5jYmxpbmsu bmV0DQp2Y0BkaWFsdXBzLTExOS5rZXRjaGlrYW4ucHRpYWxhc2thLm5ldA0K aGF6cm9kQGEzLTIuaXRpcy5jb20NCmlyY2xlQGRpYWx1cHMtMTE5LmtldGNo aWthbi5wdGlhbGFza2EubmV0DQpqbWthbGthQHdscmsuY29tDQpzcnN0ZWFk bWFuQHRyb3lnb3VsZC5jb20NCmVja2xAd2lsZG1hbmhhcnJvbGQuY29tDQpq aGFyYmlzb25AY29sbGllcnNoYW5ub24uY29tDQphYmxhbmttYW5AbW5leWxh dy5jb20NCmtiYmFyc2thaXRpa2lAbWJmLWxhdy5jb20NCnBub3lkQGV4ZWNw Yy5jb20NCm1tb3JyaTY4NjZAYW9sLmNvbQ0KbGVzbGllX2JvbmFjdW1AY2No LmNvbQ0KYW5uX2NsaWZmb3JkX2dyZWVuQHNvbm5lbnNjaGVpbi5jb20NCmNn dWVycmllcm9AcGhrcy5jb20NCmFicm9iZXJ0QG13YmIuY29tDQpiY29sb25A aG9kZ3NvbnJ1c3MuY29tDQp0cmFjZXlfc21pdGhAY2NoLmNvbQ0Kc2NoYXJr ZXNAZGVjaGVydC5jb20NCmRhbTExMjBAYW9sLmNvbQ0KbGVvcGF0QGR1bHV0 aC5pbmZpLm5ldA0KcGVhcmxwQHdpbnN0aW0uY29tDQphc2xlb25hcmRAYW9s LmNvbQ0KYmVybnNqQGFvbC5jb20NCmJ1cnJob3VzZUBhb2wuY29tDQprcnVw a2FAd2lsZG1hbmhhcnJvbGQuY29tDQpkYXZpZGFyZmluQGFvbC5jb20NCmVs bXNtaXRoMUBhb2wuY29tDQpqc3Rld2FydEBib2dsZS5jb20NCmhvZGdlQG1h aWwudGVsZXBvcnQuY29tDQprYXRvQGN0cy5jb20NCmxleGF0b3pAYW9sLmNv bQ0Ka2FtQHRleG9tYS5uZXQNCm1pbGVzdG9AY2hhcm0ubmV0DQptaXRjaGt3 QGFvbC5jb20NCmltcHRyZXNzYmVsbGFAYW9sLmNvbQ0KbWx1Y2VAYm9nbGUu Y29tDQpwdHJha3RtYW5AZGVscGhpLmNvbQ0KYmJveWxlQGtyYW1lcmxldmlu LmNvbQ0KcmljaG5vd3dAcG9waGFtLmNvbQ0Kc2hlbmRfYXRfYmUyQGJlLmJy aWNrZXIuY29tDQphamFycjg2NzJAYW9sLmNvbQ0Kc2NvdHQubmFyb3dldHpA YmFrZXJib3R0cy5jb20NCnZpdmllbkBnbm4uY29tDQppbmZvYWR2aXMyQGFv bC5jb20NCmt0YWdnYXJ0QGxvd2Vuc3RlaW4uY29tDQp3dGhvbXBzb25AZGNk MDA3NDIuc2xpcC5kaWdleC5uZXQNCmhhbWJvbmpyQGl4Lm5ldGNvbS5jb20N CnNoaXJlZW4ua3VtYXJAY2xpZmZvcmRjaGFuY2UuY29tDQpjbGFpcmUuY2Ft cGJlbGxAYmFrZXJib3R0cy5jb20NCnJhemxlYm9sZGVhdUB5YWhvby5jb20u YXUNCm1pbGVzQHJlbW92ZS50aGlzLm1haWwuY29tDQpuZXJyYWR5YXJAaG90 bWFpbC5jb20NCnRkdW5jYW5AcGFjaWZpZXIuY29tDQptZWFuc3Bpcml0ZWRq Y0Bob3RtYWlsLmNvbQ0KbGVzZnJlcmVzcGV0YXJkc0B5YWhvby5mcg0Kc2ln bi11cC1ub3dAbWF4MjAwMW1sbS5jb20NCmVyb21hbm9Ac210cC5sb3dlbnN0 ZWluLmNvbQ0KZHVmZkBmaWVsZC5jb20NCmhlcm95QGl4Lm5ldGNvbS5jb20N CmxoaUBtdG9seW1wdXMuYXJpLm5ldA0KcmViZWNjYV9nYWxsYWhlckBub3Rl cy5wdy5jb20NCmthdGVfYnVycmFzdG9uQG1zai5jb20uYXUNCm90dGU3Mzc1 QG1sYi5jb20NCnRoZXNsdXRoQG1zbi5jb20NCnJvYmVydHNvbkBtYmMuY29t DQptbWF0dHNvbkB3bHNsYXcuY29tDQpzcGlsc29uQG1pbGJhbmsuY29tDQpp bmZvQG5sdmEuY29tDQpzY2huZWlkZXJwQG55by5jb3VkZXJ0LmNvbQ0KYW5k ZXJzb25AbWV0cm9saW5rLmNvbQ0KZGFuc29uQGxnYy5jb20NCmFra2VybWFu QGR1dGliYS50d2kudHVkZWxmdC5ubA0KaGFpYmxlQGl6Zm0udW5pLXN0dXR0 Z2FydC5kZQ0KbWF0dGhpZXUuaGVycmJAbGFhcy5mcg0KZGF2aWRoQHVzZS5j b20NCmFsYW5oQGZhaXJsaXRlLmRlbW9uLmNvLnVrDQptZWxsb25AbmNkLmNv bQ0KbmFzdGVuQGV2ZXJ5d2FyZS5zZQ0KbWFya0BzZ2NzLmNvbQ0KdmVyc3Rv QGNzLnZ1Lm5sDQpwYXVsQHZpeC5jb20NCnBoaWxpcC53aGVhdGxleUBjb2x1 bWJpYXNjLm5jci5jb20NCndvbGZAcHJ6LnR1LWJlcmxpbi5kZQ0Kb3Jlc3R6 QGVza2ltby5jb20NCm1hdHRoaWV1LmhlcnJiLkBsYWFzLmZyDQpoYXN0eUBu ZXRjb20uY29tDQpkYXZpZG1Ac3RhbGxpb24ub3ouYXUNCnBoaWxpcEBjcy52 dS5ubA0KbWljaGFlbC5yb2hsZWRlckBzdGFkdC1mcmFua2Z1cnQuZGUNCmhv bGdlci52ZWl0QGdtZC5kZQ0KczUyMTkzNkBhaXgxLnVvdHRhd2EuY2ENCnRv eW9AaWJic2FsLm9yLmpwDQphaXp1QGphaXN0LmFjLmpwDQprYWtlZnVkYUB0 YWcuaWlqbmV0Lm9yLmpwDQp0c3VrYUBsaW5rdC5pbWFzeS5vci5qcA0Ka2F0 c3VyYUBwcmMudHN1a3ViYS5hYy5qcA0Kcy11cmF0YUBubWl0LnRtZy5uZWMu Y28uanANCnlhc3V5dWtpQGFjYWV0czAuYW5yaXRzdS5jby5qcA0Ka2FybEBz cG5ldC5uZS5qcA0Ka29pa2V0QGZvY3VzLnJpbS5vci5qcA0Kcy1rb2ljaGlA bmltcy5uZWMuY28uanANCnRhbWFraUBzYWlsLnQudS10b2t5by5hYy5qcA0K b2hpc2hpQGhmLnJpbS5vci5qcA0KYXRlbmFAbmprLmNvLmpwDQpxenIwMDUy MkBuaWZ0eS5uZS5qcA0KZnQ0ay1pdHVAYXNhaGktbmV0Lm9yLmpwDQppOTMx MzYxQGprcy5pcy50c3VrdWJhLmFjLmpwDQp1ZW5vc0BwcHAuYmVra29hbWUu b3IuanANCmlzaGlkYWt6QG9icC5jbC5uZWMuY28uanANCmFtYWRldXNAeWsu cmltLm9yLmpwDQptbm9kYUBjdi50b3R0b3JpLXUuYWMuanANCmhvbmRhQGt1 cnVydS5tYXRoLmhva3VkYWkuYWMuanANCmFtb3JpdGFAYmlyZC5zY3BoeXMu a3lvdG8tdS5hYy5qcA0Kc2FrYW1vdG9AeWFqaW1hLmt1aXMua3lvdG8tdS5h Yy5qcA0KY3M5NDAwNkBtYm94LnNpc3QuYWMuanANCmphZ2FybEBjcmVhdG9y LmNsdWIub3IuanANCnN1ekBkMi5iczEuZmMubmVjLmNvLmpwDQprZmIwMzYz M0BuaWZ0eS5uZS5qcA0Ka2F6dWhpa28udW5vQHNvZnR2aXNpb24uY28uanAN CnRha2lnYW1pQGVsc2QubXQubmVjLmNvLmpwDQpzdXp1a2lAZ3JlbG90LmVs ZWMucnl1a29rdS5hYy5qcA0KajIyOTcyMjJAZWQua2FndS5zdXQuYWMuanAN CmguaGFuZW1hYXllckBpbnRlci5ubC5uZXQNCmtvZW5pZ0B0YXQucGh5c2lr LnVuaS10dWViaW5nZW4uZGUNCm5vcmJlcnQuZGlzdGxlckBwaHlzaWsudHUt bXVlbmNoZW4uZGUNCmxuekBkYW5kZWxpb24uY29tDQpickBlbHNhLm1ocy5j b21wdXNlcnZlLmNvbQ0KY29icmFAY29tcHVzZXJ2ZS5jb20NCndicG92ZXJ0 eWZvcnVtQHRvcGljYS5jb20NCnRha2lzQGRwbW1zLmNhbS5hYy51aw0KcXpy MDA1MjJAbmlmdHlzZXJ2ZS5vci5qcA0Ka2ZiMDM2MzNAbmlmdHlzZXJ2ZS5v ci5qcA0KY2FtZXJvbkB1bmJlYXRlbnBhdGgubmV0DQpodXlzdXpzZWtzQG15 bmV0LmNvbQ0KbWF0ZXZ6Lmpla292ZWNAZ3Vlc3QuYXJuZXMuc2kNCmZ2aWxs YW51c3RyZUB5YWhvby5jb20NCmphenp5QG5ld21haWwzMzQuY29tDQp3d3dA bG9naW5kbnMuY29tDQpwZWRpZG9zQGNvbXB1b2Nhc2lvbi5jb20NCmVtYWls aGFydmVzdEBlbWFpbC5jb20NCmh4ZHRydWNrcmVtb3ZlQGV4Y2l0ZS5jb20N CmNocmlzQGhvcmxlci5kZW1vbi5uZXQNCnBhdWwubWNjYW5uQHZlcml6b24u bmV0DQp1cGRhdGVzQGdvdGxhdWdocy5jb20NCmJlcmdyZW5AZHRnbmV0LmNv bQ0KYXByX25pY19mYW1pbHlAM21haWwuM2NvbS5jb20NCnNmdEBlY3AuZnIN Cmpvc2VtaWd1ZWxAbWFjLmNvbQ0Kd2JhdHJAY3Mucg0KZ2luc2VuZ3JlbW92 ZUAxNjMuY29tDQppbmV0QG1pY3Jvc29mdC5jb20NCnNhbGVzQHdlc3R3aW5k LmJjLmNhDQphaXRvcjExQGhvdG1haWwuY29tDQpidWxsZXRwcm9vZkBidWxs ZXRwcm9vZi5jb20uc2cNCmluZm9Ac21va2VzZnJvbXNwYWluLmNvbQ0KeWVt ZWt6ZXZraUBjZWxpa25ldC5jb20NCmluZm9ybWFjaW9uQHdhbmFkb28uZXMN CnJhZWRzYWJhd2lAcHJpbXVzLmNvbS5hdQ0KaW5mb0BzbW9rZXNkaXJlY3Qu Y29tDQpteWtwcXhvYWFAcHJvZGlneS5jb20NCmF0ZWdlbkBpYWZyaWNhLmNv bQ0KaGFueGlhbzMyODYxQHNpbmEuY29tDQpkbXVsbGV0MjVAaG90bWFpbC5j b20NCm5lbGlAZ3RlLm5ldA0KZGF2aWQubHVmZkBub3R0aW5naGFtLmFjLnVr DQpncmVlbkBhYmR5ZXNpbGthcnQuY29tDQpmdXNpb25iYXNlQGF0YmZhbnMu Y28udWsNCm1lcmlkaWFub185N0BtZXhpY29zdWIuY29tDQphaWE5NkBzb2Z0 Y29tLm5ldA0KamFtZXMyMDAwQGV0YW5nLmNvbQ0KYWlhcy5uZXdzQHdvcmxk b2ZhbmltYWxzY2llbmNlLmNvbQ0KdGF5bG9yQHdpcmVkLmNvbQ0KbWF0dGhl d19iYWlyZEB3YXlmYXJlci5jb20NCnJob2xsYW5kQG1haWwucGxhbmV0cGF0 Y2h3b3JrLmNvbQ0KamFuaWNlLmUuaGVuZGVyc29uQGJha2VybmV0LmNvbQ0K Y2NhbXBiZWxAcGF0dG9uYm9nZ3MuY29tDQpiYXJib25nZUBjcy5jb20NCmJ0 ZWFtQG10Y28uY29tDQpwcGVhcmxAcGlsbHNidXJ5d2ludGhyb3AuY29tDQpz aXVoaW5AYW9sLmNvbQ0KbWlyaXphcnJ5QGNyYXZhdGguY29tDQppbmZvNHRy YWNAY3MuY29tDQp2bGFkaW1pckB5YWhvby50eHQNCmVuYXN1c0BjZWxwYWdl Lm5ldC5sbmsNCnBlYWNld2Fsa2VyczIwMDFAeWFob28uY29tDQphc2h1bG1h bkBubW1sYXcuY29tDQp2YW5jZWtAbWpzYy5jb20NCmludGVsbGlnZW5jZUB5 b3VyLmxhdy5saWJyYXJ5DQpnZWJhdWVybUBndGxhdy5jb20NCmF2bGFzYWtA ZXhjaXRlLmNvbQ0KcmljaGFyZF93aWViZWxoYXVzQGNhcmdpbGwuY29tDQpz dGFhdHNAaXgubmV0Y29tLmNvbQ0KcmVuY2VAaG90bWFpbC5jb20NCmdpdGVs bGVfc2VlckBkZXdleWJhbGxhbnRpbmUuY29tDQpoYW5kc29uZ0BwYWNiZWxs Lm5ldA0Kc2NvbnJhZEBwaWxsc2J1cnl3aW50aHJvcC5jb20NCnBhcmtodXJz QG94eS5lDQp3YWdlcGVhY2UyMDAxQHlhaG9vLmNvbQ0KcGVhY2UyMDAxQHlh aG9vLmNvbQ0KbG1ubzRwQHlhaG9vLmNvbQ0KcmliZUBsaXN0cy5yaXN1cC5u ZXQNCm1hcmlhLnNvc25vd3NraUBjby5jbGFyay53YS51cw0Kc3RpeHdvbGZl QGFvbC5jb20NCmxhdXJhcmF5bW9uZEBtaW5kc3ByaW5nLmNvbQ0KamFtZXNf d2FzaWNla0BkZXdleWJhbGxhbnRpbmUuY29tDQpvbmVlYXJ0aDFuYXRpb25A YW9sLmNvbQ0KbmVlYXJ0aDFuYXRpb25AYW9sLmNvbQ0Kc3lwZWFjZWFjdEBq cHMubmV0DQpyX2Fuc2hlbGxAeWFob28uY29tDQpqaW1oYWJlcnNmQHlhaG9v LmNvbQ0KYWN0aW9uNGp1c3RpY2VAb25lYm94LmNvbQ0KdGFrYW9ubzVAeWFo b28uY29tDQpudGl3YXJfY29uZmVyZW5jZUBob3RtYWlsLmNvbQ0KYmFhbWNv YWxpdGlvbkBob3RtYWlsLmNvbQ0KdHdhckB5YWhvby5jb20NCmdmaXNrZUBz aGVwYXJkcy5jb20NCmt0aGVpc0ByZXNlYXJjaC53ZXN0bGF3LmNvbQ0KbWV0 Y2FsZnBnQGRlbHBoaS5jb20NCnZlbGlicmFyeUBhb2wuY29tDQp5dGpubGQu YS52NWUubWRrXzhAbXVycGh5DQpwb25pa0Bwcm92ZXIuc2sNCmEucm90dG1h bm5AZ214LmF0DQpkZWFpMkBkay1oYS5jb20NCmxvYW5AYXBpbG9hbnMuY29t DQpqb2huLncuaG9mZm1hbkBiYWtlcm5ldC5jb20NCmhjb29rQGplbmtlbnMu Y29tDQpkZXNlbGRlbkBvcnItcmVuby5jb20NCnBjMTY2MEBlbWFpbC5sZW9u YXJkLmNvbQ0KcGFya21AcGVwcGVybGF3LmNvbQ0KYnJvZXNrZUBrbXouY29t DQpjcm9iYmluc0Bib2dsZS5jb20NCm10d2pzZ0Blc2NhcGUuY29tDQprYmlA Z3JvbGVuLmNvbQ0KYmZtanJtQGFvbC5jb20NCmVsbWhpbmVzQGFvbC5jb20N CmpvbGFpbkBwcm9kaWd5LmNvbQ0KbmNhbXBiZWxsQHBlYWJvZHlicm93bi5j b20NCmRhcmxhX2FfaGFuZXlAd2luc3RpbS5jb20NCnJ4aEBmcm9udGllcm5l dC5uZXQNCnJhbmRhbGxfZV93aWxjb3hAd2luc3RpbS5jb20NCm13aWxsaWFt c29uQGhvbGxlYi1sYXcuY29tDQpudGh1cnN0b25AZXhwcmVzcy1uZXdzLm5l dA0KYWltMTEuYWltdXNhQGp1bm8uY29tDQpibmo0ZWFlQGl4Lm5ldGNvbS5j b20NCmNncmFlc3NlckBnb29kd2luLmNvbQ0KY29ubmlja3BAb25lYmFuZS5j b20NCmRpYW5uZS50Lmxld2lzQGNyb21vci5jb20NCmVtYWhvbmV5QGp1bm8u Y29tDQplbWlseS5jLmhvd2llQGNyb21vci5jb20NCmdkYXZpczEwMjRAYW9s LmNvbQ0KZ3ZpbmNlQGxhd3llcm5ldC5jb20NCmpob2xsYW5kQGZ1bGJyaWdo dC5jb20NCmptY2NvbXAzQGFvbC5jb20NCmpvZW1hdHRlcmFAYW9sLmNvbQ0K anZvZWxrZXJAaXgubmV0Y29tLmNvbQ0Kanh5bG8xQGFvbC5jb20NCmxpYnJh cnlAdWtzLmNvbQ0KbGlicmlzY2F0QGFvbC5jb20NCmxpc2Ffc291dGhhbGxA Y29ycnMuY29tLmF1DQptYWJAbmV0c3Rha2VzLmNvbQ0KbWFyeS5mb3JtYW5A dXNhYS5jb20NCnBtY2dyYXRoQGJlbGxib3lkLmNvbQ0Kcm9uX2NpbW9AY2Eu Y2NoLmNvbQ0Kc2FuZHlkZWFuZUBhb2wuY29tDQpzYnMtbGliQGFjY2Vzcy5k aWdleC5uZXQNCnNnb2Vua2FAaG90bWFpbC5jb20NCnNpZGVsbG1lQHdrZy5j b20NCm1pY2hhZWwud3ltYW5uQHVic3cuY29tDQphcmphbi5wYWlqcmFsYmVA d2lmYWcuY2gNCndhZGRvQGRnbGF3LmNvbQ0KY3N0ZXBoZW5Aa2F5ZXNjaG9s ZXIuY29tDQpiYXJ0LnBvb3RAaWN0Lm5sDQp0aG9tYXMubGVobWFubkBwYXJh d29ybGQuY29tDQpkb3h5Z2VuQGVsZW1lbnRhbC5jb20NCmJhcmJhcmEucC50 YXJ2aW5AYmFrZXJuZXQuY29tDQp0cm9vYnN0ZXJAYW9sLmNvbQ0KdWNsYXct bGliQGxqeC5jb20NCmplZmZAY3J5c3RhbGNsZWFyc29mdHdhcmUuY29tDQpq dWxpZW4ua29lbmVuQHBhcmF3b3JsZC5jb20NCmxodW1waHJpZXNAc2Nod2Fi ZS5jb20NCmtsZWluLnRob21hc0BlYWUuY29tDQpzdGVmYW4uZ3VzdGF2c3Nv bkBtZWNlbC5zZQ0KYWJpdmVuX21hcmNAZW1jLmNvbQ0KdmlydXNzY2FubmVy QGVxdWlsaWJyaXVtLmNvbQ0KNDN2QGNvZGFuLmRrDQpzZW1tbGVyQGVvcy1n bWJoLmRlDQpiZXRzeV9zdHVwc2tpQG9hZy5zdGF0ZS5mbC51cw0KbWFya19z dF9qYWNxdWVzQHRheC5zdGF0ZS5ueS51cw0Kbm9yYWxldmluZUBtaW5kc3By aW5nLmNvbQ0Kc3NuYWdnc0BrcmFtZXJsZXZpbi5jb20NCmthdGh5LmdyZWNv QHJpdmtpbi5jb20NCmNnaWJzb25AbG9ja2VsaWRkZWxsLmNvbQ0KZWxlbmEu Z29yb2RldHNreUBsdy5jb20NCmhkZXV0Y2hAcHJlc3Nyb29tLmNvbQ0KaGVz c2VzQHBmaXplci5jb20NCmhhZGRhZHZAbnlvLmNvdWRlcnQuY29tDQpsaWJA bGFib3JsYXd5ZXJzLmNvbQ0KbG9yaS5iYXJuaWNrZUBsdy5jb20NCnJlc3Vs dHMxQGVhcnRobGluay5uZXQNCnJlbGl2cmNmQGFvbC5jb20NCnNoYXJvbi5m cmVuY2hAcGFjdGVsLmNvbQ0KN2U2NGZlMzZhMDZAdmljbGFicy5jby51aw0K MjYwM2E4YzBAYXZhMy5sb2NhbG5ldA0Kcm9ic0B2aWNsYWJzLmNvLnVrDQpy aWNoYXJkQHNoZWZsdWcuY28udWsNCnRoZWVuZ2xpc2htYW5AZWNvc3NlLm5l dA0KbmtudWRzb25AcmVzZWFyY2gud2VzdGxhdy5jb20NCjM5OWJlNThlLmMz NjZkMmRiQHNoZWZsdWcuY28udWsNCjJuM3g0bGFuY2VtNWV3cndAY2xpZmZl c3RvbmVzLmRlbW9uLmNvLnVrDQpzaW1vbkBjbGlmZmVzdG9uZXMuZGVtb24u Y28udWsNCmFsZGVhckBhb2wuY29tDQpicnVob2Jva2VuQGRlbHBoaS5jb20N CmNodWJiMDJAZGVscGhpLmNvbQ0KZG1hcnZpbjEwMEBhb2wuY29tDQpndGh3 aWxsQGdhdGUubmV0DQpodXJ0bkB0ZXhhcy5uZXQNCmxhd2JrZXhjQGhhdmVu Lmlvcy5jb20NCmxlZ2Fsd2tzQGFvbC5jb20NCm1hdHRicmFuQGRlbHBoaS5j b20NCnJleW5vbGRzQGtta2xhdy5jb20NCnNycmhAYmluYy5uZXQNCndlc3Rt ZWRpYUB3ZXN0cHViLmNvbQ0Kd21zYW5kcnNuQGFvbC5jb20NCnByZXNzb2Zm aWNlQGJvaWptYW5zLnJvdHRlcmRhbS5ubA0Kc3VicmFtYW5pLnBvbm51c2Ft eUBpY29zLmJlDQpyb2RvbGZvLmNhemFib25AYXV0b2Rlc2suY29tDQpqZW5z LnNlaWRlbEBocnoudHUtY2hlbW5pdHouZGUNCmRhbmllbC5rYXNtZXJvZ2x1 QGRhaW1sZXJjaHJ5c2xlci5jb20NCmFtY2tlbnppZUBicm9iZWNrLmNvbQ0K YW15LmEuaGFybWFsYUBpbnRlcm5ldC5ucHMudXNhY2UuYXJteS5taWwNCmFu bmVAbGlicmFyeS1zb2x1dGlvbnMuY29tDQpiYWlyZGhvbG1AbmV0aW5zLm5l dA0KZGVubmlzczQ5NEBhb2wuY29tDQpkZ3JpZ3N0QGlibS5uZXQNCmRvdHRp ZW1AYW9sLmNvbQ0KZXBvbGVyQG1haWwudHBwLmNvbQ0KZmpjQHRyaXRvbi5i ZXJjb2wuYm0NCmhzaW1tb25zQGNtc2EuZ21yLmNvbQ0KamVyQHBsY21jLmxp Yi5uYy51cw0KamZyZWVtYW5AcGFzc3BvcnQuY2ENCmthdGVzbW9tQGRlbHBo aS5jb20NCmtpcGthdWthQGFsb2hhLmNvbQ0KbG1hY21vcnJpc0B3c2dyLmNv bQ0KbmV0MjE2QGFvbC5jb20NCm5ld2Jvb2syQGFvbC5jb20NCm9yZWdhbm9A ZGVscGhpLmNvbQ0KcGFxdWV0dGVqQGRlbHBoaS5jb20NCnByZ21AaW50ZXJw b3J0Lm5ldA0KcmNpbW9AbWFpbC50cHAuY29tDQpyY29ucmFkQHNlbWlub2xl LmlhZy5uZXQNCnJldGhlcmVkZ0BuY3NjLmRuaS51cw0Kcm1vbmFjb0Bicm9i ZWNrLmNvbQ0Kd2VpbWVyQGNlcnQudW5pLXN0dXR0Z2FydC5kZQ0KYXJuc3Rl aW5AbWNzLm5ldA0KYWxpZmFub2FAc3VsbGNyb20uY29tDQprbWNjbGFpbkBh dGcuc3RhdGUuaW4udXMNCmRieXJuZUBoYW5jb2NrbGF3LmNvbQ0KcmRhaG1l bkBjdnJsYXcuY29tDQpjZGlhbW9uZEBuYXZpZ2FudGNvbnN1bHRpbmcuY29t DQpzdGFmZm9yZGJAZ3RsYXcuY29tDQpjeWd3aW5AY3lnd2luLmNvbQ0KYmFy YmFyYS5taWNnaWVsQGx3LmNvbQ0KZGdlcmJlckBrYXllc2Nob2xlci5jb20N CmZtY2V2aWxseUB3c2dyLmNvbQ0KZ2JhaWxleUBjb2xsaWVyc2hhbm5vbi5j b20NCmdvY29ubm9yQGN5YmVyc2xldXRoZXIuY29tDQpob2RnZUB0ZWxlcG9y dC5jb20NCmpnYXJyMzc0OTZAYW9sLmNvbQ0Kam5vdmFrQGNsZWxhdy5saWIu b2gudXMNCmpvZGVuQGtta2xhdy5jb20NCmtjb2xsaW5zQGJhc2gubGludXgt c2hlbGwubmV0DQptZWRAcmlvcmRhbi5jb20NCnBtYkBqZXR6d2ViLmRlDQpp bnRlcm5hdGlvbmlsc0BnbXgubmV0DQpuZmFpcmxlc0BzYWguY29tDQpkYXZp ZEBkYXZzb2Z0LmNvbS5hdQ0KYWNnbmFAZWFydGhsaW5rLm5ldA0KZGF2aWRA bWVnZ2luc29uLmNvbQ0KZ2l0YS5ndXB0YUBzYWljLmNvbQ0KcmN1cnZhQGNy YXZhdGguY29tDQpyZ2FydG5lckBwaWxsc2J1cnl3aW50aHJvcC5jb20NCm1z aGltb2RhQHNlcmNvbXRlbC5jb20uYnINCnJpY2hhcmQuYnl0aGV3YXlAYmVk ZS5jby51aw0KbWFpbEBjaHJpc3RpYW5tYXllci5kZQ0Kc3N0ZWFkbWFuM0Bl eGNpdGUuY29tDQpzdGV2ZW4uY29oZW5Acml2a2luLmNvbQ0KZXJpa0BlaG9m bWFuLmNvbQ0KY2FzdGxlQG1taW50ZXJuZXQuY29tDQpuaHZAY2FwZS5jb20N CmRvbnNpbW9uQGZpcnN0dmEuY29tDQplcV9maWRnZXRAbWFjLmNvbQ0Kcmxh cnNvbkBzcGVha2Vhc3kubmV0DQpqNHN0cm5nc0Byb2NrZmlzaC5uZXQNCmdv cmRhbi5zQG1haWwuaW5ldC5ocg0KZnJib3V2aUB3YW5hZG9vLmZyDQphcm50 QGMyaS5uZXQNCmFwZWRlbkBlYXJ0aGxpbmsubmV0DQpib2Iub2Frc0Bsdy5j b20NCmVzcGVuY2VyQG5vdGVzbWFpbC5nZGFybS5jb20NCmdob2xsb3dhQHBn Zm0uY29tDQpqcGNAY2FycGJlbi5jb20NCm1hcnRoYS5hcnRob3NAY2kuYXVz dGluLnR4LnVzDQpvZXNfbGliQGNvdXJ0cy5zdGF0ZS52YS51cw0KeW91QHlv dXJzaXRlLmNvbQ0KMzgzMDQ4NWIuY2U3NDJmY2FAYWdhbWVzLmNvbQ0KMzgz MDA2MGQuZjUyMWMxYzZAYWdhbWVzLmNvbQ0KYmxhY2ttYW5AZmluZHN2cC5j b20NCm5lb25rZWhuQGFvbC5jb20NCm1jcmV5bm9sZHNtQGRlbHBoaS5jb20N CmpvaG5sQGlibS5uZXQNCnJtY2xhcmVuQGFvbC5jb20NCmpqczExMEBhb2wu Y29tDQpyYW5keXMxMDAwQGFvbC5jb20NCmxvcmltMjI2N0Bhb2wuY29tDQpq aW12b2Vsa2VyQGRlbHBoaS5jb20NCm1pa2VsaWIxMjNAYW9sLmNvbQ0KcGF1 bGEuZS5ob3dlQGV4eG9uLnNwcmludC5jb20NCmNoZW5tQHF1Y2RuLnF1ZWVu c3UuY2ENCnBhc3NsYW5lQGFvbC5jb20NCmJyaXRuYWVAYW9sLmNvbQ0Kcm1m cmF6aWVyQGFvbC5jb20NCm1vbmljZS5rYWN6b3Jvd3NraUByb3NzaGFyZGll cy5jb20NCmJhdmVyeUBsZXhpcy1uZXhpc21haWwuY29tDQpyaW9sYXcwMUBl bWJyYXRlbC5uZXQuYnINCmxhdy1hbmQtanVzdGljZUBqdW5vLmNvbQ0KbWls YXBlbm55QGFvbC5jb20NCnZhcm5vbGRAZnVsYnJpZ2h0LmNvbQ0KbWFyeV9k YWxlX3dhbHRlcnNAY2EuY2NoLmNvbQ0Kam9tZWFyYUBwcm9za2F1ZXIuY29t DQphZGNAbXdiaGwuY29tDQp3ZWVrbHlAY29sdW1uaXN0LmNvbQ0KdGVvc3RA anVuby5jb20NCmpoa2VsbGV5QGl4Lm5ldGNvbS5jb20NCmRwZWxsZXRpZXJA a3JhbWVyLWxldmluLmNvbQ0Kb2xpdmVybUBwZXBwZXJsYXcuY29tDQpjb2xv bkBob2Rnc29uLmNjbWFpbC5jb21wdXNlcnZlLmNvbQ0KbWxldnlAZnVsYnJp Z2h0LmNvbQ0KcGF1bC5taXRjaGVsbDAzQGV5LmNvbQ0KbXNjb3R0QHBlcGVo YXphcmQuY29tDQpta2FybEB3cmYuY29tDQpzYWxhbmN5QHR5Y29vcC5jb20N CnRlcm00QGNhcGNvbi5uZXQNCm1lY2hlY2tzQGFvbC5jb20NCnBvbmlrQHBv Ym94LnNrDQpwb25pa0B0b3VnaGd1eS5uZXQNCmpjdW5uaW5naGFtQGVuZ2lu ZTguY29tDQpzamNhcmJvbkBlc2tpbW8uY29tDQpkZWVtQHdkbS5jb20NCmZl cnJldEBwaG9uZXdhdmUubmV0DQpsaXNhcnJAYmF0aC5hYy51aw0KcmVnQGR3 Zi5jb20NCmNoaXAud2llZ2FuZEBzaW1yYWQuY29tDQpzdGV2ZW5AbWluZmlu aXR5LmNvbQ0Kam9lbC5jb2xsZXRAZnJlZS5mcg0KcGF1bC5uZXdtYW5AcGdl bi5jb20NCmpvbi5ld2luZ0BtZWRpYXN1cmZhY2UuY29tDQpqaW1tb3JyaXNv bm93bnN1QGFvbC5jb20NCm0ubWlkYXZhaW5lQHBsYW5ldC5ubA0KYmpjb3Ju ZUBhb2wuY29tDQpidWNrbmVraWR4QGFvbC5jb20NCmplc3VzLmRlbGFvQGVq Z2FsbG8uY29tDQpmb3BlcmV6QGFvbC5jb20NCm0uZS5ncmF5QHN0dWRlbnQu c2FsZm9yZC5hYy51aw0KZHpqb29zdEBob3RtYWlsLmNvbQ0KbWF1ZkBlbW1l c3cuaXQNCmRvY2phdmFfaW5kaWFAaG90bWFpbC5jb20NCmpvdXJuZXlAZG9t YWluLmhpZGRlbg0KY3JvbmRAb25saW5lLm5vDQpqb3VybmV5QGpwcy5uZXQN CmRhdmlkLmhpbmVzQGJha2VybmV0LmNvbQ0KbGpoQHNjaHdhYmUuY29tDQpn cmFoYW1fZm93bGVyQHN0cGF1bC5jb20NCnJ1YmVuc2pAbnlvLmNvdWRlcnQu Y29tDQpuYW5ldHRlX2xvZG9sY2VAYmFrZXJib3R0cy5jb20NCnNzcnNsYXdA YW9sLmNvbQ0KbWFyaWFAbGFsYXcubGliLmNhLnVzDQptcHJvbnRAYW9sLmNv bQ0Kd2JlcnJpbWFuQHdtY2QuY29tDQpwYW1AZndwYS5jb20NCnBlbm5pbmd0 b25AZ2xvYmUuY29tDQpwYXVsYWdAaXgubmV0Y29tLmNvbQ0KeHRhbHNpbmdl ckB5YWhvby5jb20NCm1yeWFuQHdzZ3IuY29tDQptYXJrLnN0ZXdhcnRAYmFj cy5jby51aw0KYW1uQHViaWsuZGVtb24uY28udWsNCmlhbkBjYW5kZi5jb20N CmFhbGxocUBhb2wuY29tDQpnamJhdHRlckBuZXRheGlzLmNvbQ0Kanh3QGRh dmhhZy5jb20NCnZtY25pdHRAY2FwY29uLm5ldA0KYWxhbl9qYWNvYnNAY2Jj bGVnYWwuY29tDQpqbHN1dGVyQGFvbC5jb20NCmphYnJpc3NAc2F1bC5jb20N CmVsaW9mbHBAYW9sLmNvbQ0KcGF1bF9odXJsZXlAbWhhbGF3LmNvbQ0KZGF5 YmhAYW9sLmNvbQ0KYXBhdHRpQGxvY2FsbmV0LmNvbQ0KbWFybGFqbUB2cnNo Lm1ocy5jb21wdXNlcnZlLmNvbQ0KamRhcmJ5QGRvdy5jb20NCm9saXZlcm1t QGFvbC5jb20NCmVyb2JlcnRzQHNoZXBhcmRzLmNvbQ0Kc2NjQGJlbGxzb3V0 aC5uZXQNCmhkbGxpYnJhcnlAYW9sLmNvbQ0Kc2hlbGxhd0BtYWlsLnBob2Vu aXgubmV0DQpnZW5sY25zbEBnbzUwLmNvbXAucGdlLmNvbQ0KYXJsZWVza2lu QGFvbC5jb20NCmJyZWl0YmJuQHJ1YmMucnoucnVoci11bmktYm9jaHVtLmRl DQpicm93bmV3d0B2dG5ldC5jb20NCm5hYmFnQGFvbC5jb20NCmMuaW5nZWxz ZUBpci5ydWxpbWJ1cmcubmwNCnNoaXJsZXljYW51cEBkZWxwaGkuY29tDQpj YXJvbHluLnZlZ2FAbHcuY29tDQpkd2FpckBhb2wuY29tDQoxMDAwMDBAb3V0 YmFjay5lc2NhcGUuZGUNCnJpc3RsYXdAaWRzLm5ldA0KcHBmcmVtbWVyQGFv bC5jb20NCjNjNDM2MDA3LmM1MmM3ZjIwQHNhY2twZmV5ZmZlcg0Ka2lsaUBk b21haW4uaGlkZGVuDQozYzQzNjAwNy5jNTJjN2YyMEBzYWNrcGZleWZmZXIt enUtbGluZGVuLmRlDQpra2VlZmVyQG1haWwudHBwLmNvbQ0KbWFyeV8tX3J5 YW5AY3VwLnBvcnRhbC5jb20NCnJldmJvYm9AYW9sLmNvbQ0Kc3VnYXJtYW5A aHlwZXJsYXcuY29tDQpoZXJvY3NoQGFvbC5jb20NCmx5bm5lLmRhdmlzLWdh YnJpZWxAaGQ2Mi5oYWxlZG9yci5jb20NCmNhbGlnb0Bkb21haW4uaGlkZGVu DQppbmZvQG9zZG4uY29tDQpyb2FrbGV5MTA2QGFvbC5jb20NCm13QG5pY2hl cHViLmNvbQ0KbGluY29sbmxhd0Bhb2wuY29tDQpscHRlY3N0ZXZlQGFvbC5j b20NCmNyYXRhY0Bhb2wuY29tDQpmcHVnaHNsZXlAYWxzdG9uLmNvbQ0KYmls bGxlODhAYW9sLmNvbQ0Kc3VzYW4uY2xvdXRpZXJAd2VpbC5jb20NCnRraWxn b3JlQHNoZXBhcmRzLmNvbQ0KcnZhbmV0dGVAYW9sLmNvbQ0KaXN0dmFuLnNp bW9uQGFwc3MuYXQNCmthcmxtbmVsc29uQG5ldHplcm8uY29tDQpkcHJvY0Bk b2wubmV0DQpiYWdnaWh1bmdAaG9uZ2tvbmcuY29tDQpjbGFyZ2VAZ2l6bW8u bWFjbi5iYy5jYQ0Kbmljay5sZXJveUBub3JsYW5kLmNvbQ0Kc3VkaGVlckBl YXNpLnNvZnQubmV0DQpzY2hsaWNodEBjaGFmZmVlLm5ldA0KbWFya2N1cnJ5 QGJpZ2Zvb3QuY29tDQp6d2FuQHN0cm9udGl1bS5jaGVtLnZ1Lm5sDQphZ3Vh dmFjYUByZXRlbWFpbC5lcw0Kbmlja0ByYXkucnUNCmxpbnV4MUB3b3JsZG5l dC5hdHQubmV0DQphbGFtb0BlbGVjdHJvd2F5LmNvbQ0Ka2NlbmdAZnVzaW9u LmNvbS5zZw0KbGludXhAa3ViZWNraS5jb20NCmpqLW1haWxAZWFzdHNpdGUu bmwNCmVyaWMua2F6YW5qaWFuQG9zZG4uY29tDQptYXJrLmJhcnJlY2FAb3Nk bi5jb20NCmFteS5waGFsZW5Ab3Nkbi5jb20NCmNhcnRlci5zbWl0aEBvc2Ru LmNvbQ0KZGFub0BwaHJlYWtlci5uZXQNCmNyb2FrQHNoYWR5cG9uZC5jb20N CmNvbWZyZXlAYXR0YmkuY29tDQptYXRpanMudmFuLnp1aWpsZW5AeHM0YWxs Lm5sDQpvYWtlbnNoaWVsZEBnbXgubmV0DQpzdGVwaGVuQGNhc3MtbHRkLmNv LnVrDQpnZ3J1YmJpc2hAd2ViLmRlDQpncmFoYW0ud2lsbGlhbXNAY21pcy5j c2lyby5hdQ0KZXNjYWxhbnRlQGNhbmFkYS5jb20NCmpvZXlAa2l0ZW5ldC5u ZXQNCmtlNnNsc0Bjb3gubmV0DQpmbG9yZW50aW5faW9uZXNjdUB5YWhvby5j b20NCmRhbGVAbWVyaWRpYW4tZWxlY3RyaWMuY29tDQpzdXBvcnRlQGxpbnV4 c29sdXRpb25zLmNvbS5icg0Ka2s1c3RAc3diZWxsLm5ldA0KdG9tYmxlQHVz ZXJtYWlsLmNvbQ0KYW9nYUBtYWdnaWUubGludXgtY29uc3VsdGluZy5jb20N CmpzbGlAaWN0LmFjLmNuDQpzaW1vbkBmb3JtYXNpYy5jb20NCmpyYWNrc2py QGJlbGxhdGxhbnRpYy5uZXQNCnJvbi5sLmpvaG5zb25AY294Lm5ldA0KamNv cHBvY2sxQGF0dGJpLmNvbQ0Kc2hhbGVocGVycnlAYXR0YmkuY29tDQpkZWJp YW4tdXNlckB2aXJ0dWFsLmRvb3JzdG9wLm5ldA0Kc2ZhbGtlbkBkdW1wc3Rl cmRpdmVycy5uZXQNCnRvbWdAc3FsY2xpbmljLm5ldA0KbWF0dGhld0BzYWNr bWFuLmNvLnVrDQpjaHJpc0Bsb2NrZXJnbm9tZS5jb20NCmFkdmVydGlzZUBs b2NrZXJnbm9tZS5jb20NCmNsdXN0ZXJpbmdAYWxpbmthLmNvbQ0Kd2lsbGlh bV9sb2l0ZXJtYW5AbGFjY2QuY2MuY2EudXMNCmFhbmRicHViQGFvbC5jb20N CmtqNDNxQG1zbi5jb20NCmxvcmRfYmVrbGFuYXplQGhvdG1haWwuY29tDQpz dGFua292aWM2QGhvdG1haWwuY29tDQprb2hsbW9ycmlzb25AaG90bWFpbC5j b20NCnB3dW50Y2hAZGFsbGFzbmV3cy5jb20NCm1obWxsckBhb2wuY29tDQpw aG90b2pvZTEwMUBjb21jYXN0Lm5ldA0Kc2JhbGR3aW5Ac21oLmNvbS5hdQ0K am9udXNfbGFfYW5nZWx1c0Bob3RtYWlsLmNvbQ0Kb25lX3N0ZXBfY2xvc2Vy QG1zbi5jb20NCnlvdWtub3d3aG95b3VyZ29kaXNAaG90bWFpbC5jb20NCndp cmVvY3RhbmVAYW9sLmNvbQ0KZHphcGZmZTE5QGhvdG1haWwuY29tDQpkZW9u X3JvdXhAeWFob28uY29tDQpzaW1vbl9jcmVlZHlAYmlncG9uZC5jb20NCndh dHNvbkBub3doZXJlLmNvbQ0Kam1heWVzQGVhcnRobGluay5uZXQNCmx1ZGRl bnNtQHlhaG9vLmNvbQ0KbGF0b3JyZUB0cmFzaW5ldC5jb20NCnRyYXNpbmV0 QHRyYXNpbmV0LmNvbQ0KZ2F6ZXR0ZUBzc2MuY29tDQpsZXRoYWxieXRlQGhv dG1haWwuY29tDQpnYXJ5MDUyNkBtczIuaGluZXQubmV0DQpndXJ1Z2FyemFo QG5vdmFnYXRlLmNvbQ0KcmF5azJAYmVsbHNvdXRoLm5ldA0KbGFmZXR0ZUBp bnRlcmFjY2Vzcy5jb20NCmN2cC5yb2JAc3ltcGF0aWNvLmNheA0Kcm9tYW5A dGJiLnNrDQp0c2FyQGVkaXRncm91cC5hdW56LmNvbQ0KZHJpZGVyQG1haWwu ZGNzaS5uZXQuYXUNCm5vcm1hbi53b3J0aEBzaWluZXQudHJ3LmNvbQ0KbWFs bWJlcmdAY29sdW1iaWEudG90YWwtd2ViLm5ldA0KZGd3aGl6QGVhcnRobGlu Zy5uZXQNCnRoZW9jQHVzLmlibS5jb20NCnN0YXJyQGxzLm5ldA0KZ2VtaUBi bHVld2luLmNoDQppbmZvQHNmcy1zb2Z0d2FyZS5jb20NCmthdGhhcmluZV9o YW5sZXlAbWFnaWMtc3cuY29tDQppbmZvQG10aS5jb20NCmluZm9AY3lnbnVz LmNvbQ0KYnNuZXRoZW5Acm1yLmNvbQ0KaW5mb0Bwcm92ZW5hY2N0LmNvbQ0K bGludXh1cHBvcnRAaW5kZWxpYmxlLWJsdWUuY29tDQpyYXdnQGMwZGUubmV0 DQptYmFsbGVuQGVyb2xzLmNvbQ0KbGhfMUBob3RtYWlsLmNvbQ0KcGFAYmMu c3ltcGF0aWNvLmNhDQpzdGV0dGVyQGlzd2kubmV0DQppYW5AZW1pdC5wbA0K bWFzc2ltby5jYXJib25pQGxuZi5pbmZuLml0DQpoYW5zLmphbnNlbkBlaHYu Y2UucGhpbGlwcy5jb20NCmNsYXdzb25AaG9tZS5jb20NCmFzbGVAc2VudGlu ZWwubm8NCmRzdGFmZkBlY2hlbG9uLmNhDQpkeW9ya0Bsb2Rlc3RhcjIuY29t DQpldmFuQHN0YXJuaXguY29tDQpib2JuaGxpbnV4QGFvbC5jb20NCnB1bHlr YUB1b2wuY29tLmJyDQptYWl0cmV5YUB1b2wuY29tLmJyDQpuYWxhbmRhQGxl dHRlcmJveC5jb20NCnl1aG9fcnlva2V5QGhvdG1haWwuY29tDQptaWtsb3NA c3VwZXIxMS5uZXQNCm1pa2xvc0BpZy5jb20uYnINCm1haGF5YW5hQHVvbC5j b20uYnINCm1haGF5YW5hQGlnLmNvbS5icg0KZmNhcGxsb25jaEB1b2wuY29t LmJyDQplbG9AY3Bvdm8ubmV0DQp1bWdtQHlhaG9vLmNvbQ0KdmlhemVuQHZp YS1ycy5uZXQNCmNnZ3VlcnJhQGNlZC51ZnNjLmJyDQpoZXJiZXJ0QHN1bm5l dC5jb20uYnINCmRyb2xtYUBidXJpdGkuY29tLmJyDQpwcmFqbmFwYXJtaXR0 YUBob3RtYWlsLmNvbQ0KZG9yamVsaW5nQG9uZGEuY29tLmJyDQpwYXJhbWl0 dGFAemlwbWFpbC5jb20uYnINCmppc2hvQHVvbC5jb20uYnINCm5vbmluZG9A dW9sLmNvbS5icg0Kc2dvdXZlYXNAdW9sLmNvbS5icg0KaW5mb0BjaGVzYXBl YWtlcGxhbnRzLmNvbQ0KY3JvY25hcmF3Y291bnRyeWhzZUBlaXJjb20ubmV0 DQpjb21tZXJjaWFsQHBjbWF5b3IuY29tDQpmYXZlcmVAcGNtYXlvci5jb20N CnNvcGhpZUBwY21heW9yLmNvbQ0KYmVuQHBjbWF5b3IuY29tDQpzZWJhc0Bw Y21heW9yLmNvbQ0KaGVscEBrYXJpYmFob3VzZWJvYXRzLmNvbQ0KcHJlbnNh QGludGVybGF0aW5jb3JwLmNvbQ0KaW5mb0BvbGRib2F0LmNvbQ0KY29saW5A bnl4Lm5ldA0KZGFuaWVsQGZ1dHVybml0dXJlLnNlDQpkYXZlbUByZWRoYXQu Y29tDQprYW9zQG9jcy5jb20uYXUNCm1hdHRpLmFhcm5pb0Bzb25lcmEuZmkN CndpbGx5QHRoZXB1ZmZpbmdyb3VwLmNvbQ0KcF9nb3J0bWFrZXJAeWFob28u Y29tDQpyZ29vY2hAYXRuZi5jc2lyby5hdQ0Kci5lLndvbGZmQGJpdHdpemFy ZC5ubA0KdGNvcnRAc292ZXIubmV0DQp0cmV2b3JAanBqLm5ldA0KbmV0ZGV2 QG9zcy5zZ2kuY29tDQptYWpvcmRvbW9Ab3NzLnNnaS5jb20NCmNoZXh1bUBz aGFkb3cuYmFua2kuaHUNCnRvcnZhbGRzQHRyYW5zbWV0YS5jb20NCmFsYW5A cmVkaGF0LmNvbQ0KdGFvQGFjYy51bXUuc2UNCm1hcmNlbG9AY29uZWN0aXZh LmNvbS5icg0KZWRtb25kQGNlZGFyLXJlcHVibGljLmNvbQ0KdGh1bmRlcjdA eHM0YWxsLm5sDQpjYWJydXRhbkBkZWxwaGkuY29tDQpjZHVud29ydGhAcmVl ZHJlZi5jb20NCmRtZWRjYWxmQGRlbHBoaS5jb20NCmVwb2xlcm5uQG1haWwu dHBwLmNvbQ0KcGxjaC5saWIub2gudXNAcGxjaC5saWIub2gudXMNCmpoYW1i bGVAb25yYW1wLm5ldA0KamltbXlpQGFvbC5jb20NCmppbXBlbGxAYW9sLmNv bQ0Kamx3QGhhcjEuaHVqaS5hYy5pbA0Kam9obi5yb3NzQHN1cGVyc3RvcmUu Y29tDQpsYXdsaWJyQGFvbC5jb20NCm1henpvbmlAc210cGxpbmsuYmFuZGIu Y29tDQptbHVjZUB3bG4uY29tDQpvY2FsaTJAdHJhbnNpdC5ueXNlci5uZXQN Cm1hcnQxNTZAaG9tZS5jb20NCmpsaW5kMjk0NTNAYW9sLmNvbQ0Kc2FsZXNA ZmlyZS1wb3dlci5jby51aw0Kc2FsZXNAZHVubmF2YW50cy5jb20NCmFzc29j aWFjaW9AbWF0YXJyYW55YS5jb20NCmluZm9AbGFrZXNpZGVyZXN0b3JhdGlv bnMuY29tDQpjaHJpc2Jyb29rczJAbGluZW9uZS5uZXQNCmNvbnRhY3R1c0Bw cmVtaWVyeWFjaHRzaW5jLmNvbQ0Kc2FsZXNAaG5mZmxvcmlzdC5jb20NCnpz YXNpY0BvcGVuLmhyDQp6c2FzaWNAZXRuLmhyDQpldG5AZXRuLmhyDQphZHJp YWJvYXRAaWJtLm5ldA0KaW5mb0BhbmV0dGEuaHINCmF0bGFzZGJrQGF0bGFz LnRlbC5ocg0KYXRsYXNAYXRsYXMudGVsLmhyDQphZHZlbnR1cmVzQGF0bGFz LnRlbC5ocg0KYXJnb3N5dG91cnNAZHUudGVsLmhyDQpwYWxtYUBsb3Npbmou Y29tDQplZG9AcHVsYS5uZXQNCmtvbXBhc19yYWJhY0Bob3RtYWlsLmNvbQ0K YXJuaWthQGFwcGxlYnkubmV0DQp0dWNlcGktcmF0b3Vyc0BzdC50ZWwuaHIN CmF1cm9yYS10b3Vyc0B6Zy50ZWwuaHINCmF1cm9yYUB3d3cucmluZy5uZXQN CmtvbXBhcy16YWdyZWJAemcudGVsLmhyDQpwb3RhZWxlbmlAYW9sLmNvbQ0K a2Fpcm9zNjI5QGFvbC5jb20NCmZsb3JhZEB6ZWVsYW5kbmV0Lm5sDQpsdWRp azIwMDBAbGliZXJvLml0DQphaWRlQGlwcm9waS5jb20NCnh4QHl5Lnp6DQpt aXRAaW50ZXJsaW5lLml0DQpodWdoLm1pbGxlckBudHUuYWMudWsNCmppbGwu YXJub2xkQG50dS5hYy51aw0KMjJqaWxsLmFybm9sZEBudHUuYWMudWsNCm11 bWlhQGFvbC5jb20NCnBmLXJlcXVlc3RAYmVuemVkcmluZS5jeA0KbnBjYm9z dG9uQHlhaG9vLmNvbQ0KYXpkYWNAaG90bWFpbC5jb20NCmZyZWVtdW1pYTQ1 QGhvdG1haWwuY29tDQpub3Rpb243QGFvbC5jb20NCmplcmljaG9zZmJheUBo b3RtYWlsLmNvbQ0KZWx2cnViYWxAYW9sLmNvbQ0KbHVjdW1pQGN3by5jb20N CnRoaXJkZXllXzUxMEBob3RtYWlsLmNvbQ0KeGljYWpAaG90bWFpbC5jb20N CmxlZGVybWFuQHNpcml1cy5jb20NCmRyZW1lcnlAbWVkaWFvbmUubmV0DQpq bWFja2xlckBzaXJpdXMuY29tDQprYWxpX3dpbGxpYW1zQGhvdG1haWwuY29t DQp0aXllc2hhQGhvdG1haWwuY29tDQp3cml0ZTJuYW11QGFvbC5jb20NCmRi d2FsbEBlYXJ0aGxpbmsubmV0DQpjZG9ubmVyMkBqdW5vLmNvbQ0KdW5ndXJ1 QGFvbC5jb20NCmZyZWVtdW1pYW5vd0Bob3RtYWlsLmNvbQ0KbXVtaWFAd2Vi Y29tLmNvbQ0KYXVzYXI0QGhvdG1haWwuY29tDQpyb3NlLWJvYkBtYWlsLndp emFyZC5uZXQNCm15bHhpbmVAaG90bWFpbC5jb20NCmRvb21zZGF5MDdAaG90 bWFpbC5jb20NCnBhaW50YjQwNDBAYW9sLmNvbQ0KYXpvY2FraXJAbWVkeWFu b3ZhLmNvbQ0KaW5mb0Bob3RlbHNpbmlzdGFuYnVsLm5ldA0KaW5mb0B0cmF2 ZWxpbnMuaXQNCnNvbGVhZGFAdGlzY2FsaS5pdA0KY2FuYWRhQHpnLnRlbC5o cg0KYnJpdGlzaC1lbWJhc3N5QHpnLnRlbC5ocg0KaW5mb0BodHouaHINCnR6 emktcG9AcHUudGVsLmhyDQp0enppLXB1QHB1LnRlbC5ocg0KdGljQGFsZi50 ZWwuaHINCnR6LXJpamVrYUByaS50ZWwuaHINCmlzdHJhQGlzdHJhLmNvbQ0K emFncmViLmNvbnZlbnRpb25AY2NiLmhyDQp5b3VybmFtZUBzY2l0dWF0ZS5j b20NCmFza0AxNjM0LmNvbQ0KYWx1bkBuYWRhLmt0aC5zZQ0KdG94aW5AZHVr ZTQuY29tDQpjaHJpc2pAM2RyZWFsbXMuY29tDQptdXJyYXlnYW1ibGVAdGhl aGZlZ3JvdXAuY29tDQozYTEzZmEwMC40ODkzYjk0NUBocndhbGxpbmdmb3Jk LmNvLnVrDQppbmZvLXBlcmZvcm1lckBzZ2kuY29tDQpyZGJAaHJ3YWxsaW5n Zm9yZC5jby51aw0KYmFyYnNAc2FicmV0cmFkZS5jb20NCnBsdWRla0B1bHRy YWxpbmsuY29tDQpmY2JlQGloZXJtZXMuY29tDQptYWRzZW5zQHRlbHVzLm5l dA0Kc3d5c3R1bkBob3RtYWlsLmNvbQ0KYmFydGVyQHBhbmdlYS5jb20NCmNi c0BhdXRvYmFobi5tYi5jYQ0KcGF0QGludGVyYWN0Lm5zLmNhDQpuYmFlQG5i bmV0Lm5iLmNhDQpiY2ktY25kQG9uLmNhDQpiY2ljYW5hZGFAY3liZXJ1cy5j YQ0Ka2V2aW5AYmllLm9uLmNhDQpwZGQzM0Bhb2wuY29tDQpiYXJ0ZXJAYnhp Y2FuYWRhLmNvbQ0KY2VudHJhZGVAa29zLm5ldA0KY3RhQGxrcy5uZXQNCmth Y0BjZ29jYWJsZS5uZXQNCmdvcmRAbmFiZWwuY29tDQpiYXJ0ZXJAbmF0aW9u d2lkZWJhcnRlci5jb20NCm1pa2VAbmFiZWwuY29tDQpvbWVnYUBuZXRyb3Zl ci5jb20NCmdpbmFAdHJhZGV4YmFydGVyZXhjaGFuZ2UuY29tDQp2YWxsZXli YXJ0QHBlcnRoLmlncy5uZXQNCmNpc2VnQHdlYm5ldC5xYy5jYQ0KYmFydGVy QGNvbXRleHRyYWRlLmNvbQ0Kcm9sc2VuQGNvbnRhY3QubmV0DQpjdXN0c2Vy dkBnb2JhcnRlci5jb20NCmJhcnRlcmNhQHNoYXcuY2ENCmluZm9AMXN0YmFy dGVyLm5ldA0Kam9obkBiYXJ0ZXJvbmUuY29tDQpsYXJyeS5uZXVob2ZmQGl0 ZXgubmV0dGVyb25lLmNvbQ0KZXhlY3V0aXZlb25lQGp1bm8uY29tDQpjcmFp Z0BhYnhjaGFuZ2UubmV0DQp3ZWJhcnRlcml0QGFvbC5jb20NCm1pbGxlcmho OThAYW9sLmNvbQ0KdHJhZGVzb3VyY2VAaW5maWNhZC5jb20NCmFibkBhYm4t bmV0LmNvbQ0KYmFydGVyQHNpbXBseXdlYi5uZXQNCmJvb214MkBhb2wuY29t DQprZW5uZXRoLnNtaXRoQGl0ZXgubmV0DQpiYXJ0ZXJhbGxAZWFydGhsaW5r Lm5ldA0KdGRhc2NyZWVuQGFvbC5jb20NCnRyYWRlbmV0Y2FAYW9sLmNvbQ0K c2t5ZWNhcGVyQGFvbC5jb20NCmRvZ3dvb2QxQGNvbXB1c2VydmUuY29tDQpz ZWFkb2dAZ3dpLm5ldA0KMjBtYWNsZWFuMkBpeC5uZXRjb20uY29tDQptc3V6 dUB3YXZlLnBsYWxhLm9yLmpwDQptbGQtbWxAbWwubWxiLmNvLmpwDQpoaWth c2hpQG1sYi5jby5qcA0KcmFkaW90ZWxlc3RlbGxhQGxpYmVyby5pdA0KcmFk aW9zdGVsbGFAbGliZXJvLml0DQpyYWRpby5zdGVsbGFAbGliZXJvLml0DQpk cm51bmxleUBhb2wuY29tDQptYWlsbWFuQHJvcmFwLmNvbQ0KbWN6bDUxYUBw cm9kaWd5LmNvbQ0KeWpybTIxYUBwcm9kaWd5LmNvbQ0KYWJ1bmRhbnRAcG93 ZXJ1cC5jb20uYXUNCmFjcmFpZ2hhcmRlZUBwcm9kaWd5Lm5ldA0Kc3Vic2Ny aWJld2xAbGFuZHJ5LmNvbQ0KY21pbGxlcjU2NUBhb2wuY29tDQpza3VhNDlh QHByb2RpZ3kuY29tDQpnZ3piMDZhQHByb2RpZ3kuY29tDQpuamFhMzJhQHBy b2RpZ3kuY29tDQp5anJtMjFkQHByb2RpZ3kuY29tDQptYWpvcmRvbW9AbGlz dHNlcnYucHJvZGlneS5jb20NCmluZm9AYXNpYWJ5bmlnaHQuY29tDQp0YWt1 eWFAeWY2LnNvDQp0YWt1eWFAeWY2LnNvLW5ldC5uZS5qcA0KaG9yYXRhQHNw LnUtdG9rYWkuYWMuanANCm1hdGNoQGRpbWVuc2lvbmFsLmNvbQ0KZGtlbGx5 QHRhbm5pbmcuY29tDQpjbHVlLXRhbGtAY2x1ZS5kZW52ZXIuY28udXMNCm1h dHRoZXcudy5tY2lsbGVjZUBsbWNvLmNvbQ0KZGx3aWxsc29uQHRoZWdlZWsu bnUNCm93bmVyLWNsdWUtdGFsa0BzcG90LmVsZndlcmtzLmNvbQ0KYW5vbGFu ZEBkYXRhd2VzdC5uZXQNCmJiZXJrb3dAc2lkbGV5LmNvbQ0KY2FtcGJsQGNj LnVtYW5pdG9iYS5jYQ0KZW1vYW5naWVAYW9sLmNvbQ0KZ3dnYXRlQHV1bmV0 LnV1Lm5ldA0Kam1lcmNlcmJAYW9sLmNvbQ0KbGVnYWxAYW9sLmNvbQ0KbG51 c2dtYi5xejMxZGNAZ21lZHMuY29tDQptYWtsaWJAYW9sLmNvbQ0KbWF1cmVl bl9zaXJoYWxsQGxpdHRsZXIuY29tDQpyaWNoYXJkX3dpZWJlbGhhdXNAY2hh cm9uLmNhcmdpbGwuY29tDQpya2VsbWFuQHNjaGlmZmhhcmRpbi5jb20NCnNk ZXZsaW5AZGVjaGVydC5jb20NCnRlcnJhbnh0QGRhc2guY29tDQpzaXRlaW5m b0BjaXguY28udWsNCmZlbGRibHVtQGNuai5kaWdleC5uZXQNCmRhdmV0cmVr QGFvbC5jb20NCmF0bGFzckBhYmMuY29tDQpiaWx1YmlAYW9sLmNvbQ0KZGF2 aWRtQGxlY3JveS5jb20NCmVuaXNlbmJhdW1AYW9sLmNvbQ0KaWlhYUBscHQu ZmkNCmdvbGRlbmZveEBiaWdmb290LmNvbQ0KaHl2YXJ0ZXJAbHB0LmZpDQpj aHJpcy53b29kMUB2aXJnaW4ubmV0DQptbEBxb29sZS5jb20NCmdvbGY0ZG9s bGFyc0Btb3Njb3cuc2F2b3luZXQuY29tDQpyam9uZXNAaW1jbC5jb20NCnJl bW92ZUBoYXJyaXMtbWFya2V0aW5nLmNvbQ0KYWxsQG1vc2Nvdy5zYXZveW5l dC5jb20NCmdvbGZlcnNAbW9zY293LnNhdm95bmV0LmNvbQ0KZXJvYkBzYXZv eW5ldC5jb20NCmdvbGY0ZG9sbGFyc0Bnb2Y0ZG9sbGFycy5jb20NCjQ5OTI1 OTQyQGJpcmNoLm5ldA0KaXBjaWlhLi5uZXRyZXNwb25zZUB0YXlsb3Jjb20x Lm5ldA0KZ29sZDdAcGFuYW5ldC5uZXQNCmFuZ2llQHRheWxvcmNvbTEubmV0 DQpwcmcxQHVzYS5uZXQNCm5ld3NsZXR0ZXJAc2hvcHBpbmdwbGFuZXQuY29t DQpyajNAZG9jLmljLmFjLnVrDQplMHhtbGxoLTAwMDR6ai0wMEBvYWsxLmRv Yy5pYy5hYy51aw0Kc3Vic2NyaWJlQHNob3BwaW5ncGxhbmV0LmNvbQ0KdW5z dWJzY3JpYmVAc2hvcHBpbmdwbGFuZXQuY29tDQpqdWljZUB0bmxiLmNvbQ0K bGl2ZTFAdG5sYi5jb20NCjE5OTcxMDE3OTBmYWEzNzEzNkBwb3N0LmNvbQ0K a2l0dHljYXRAc3BlZWRtYXRyaXguY29tDQplbWFpbHByb2ZpdHNAbWFpbDMu Yy1mbGFzaC5uZXQNCjQ1QG5vd2hlcmUuY29tDQpmcmllbmRAcHVibGljLmNv bQ0KZTB4bXJmeC0wMDA0aXAtMDBAaGVsaXVtLmJ0aW50ZXJuZXQuY29tDQoy MjgwNDM3NUAwNTczNC5jb20NCm1haWxtYXN0ZXJAZmlzaC5uZXQNCjY3MzAw NTc3MjkwMzQuNDMzMDlAZmlzaC5uZXQNCnJlbW1lQGFuc3dlcm1lLmNvbQ0K dG1vbmV5QHRoZXdvcmxkLm5ldA0KY291cmllckBtZXNzYWdlNHUuY29tDQpi cmV0dEBkb21haW4uaGlkZGVuDQptYXJrLmFuZHJld3NAZG9tYWluLmhpZGRl bg0KbWFyay5hbmRyZXdzQHh4eHh4eHgNCjg3c25od29tMHYud2xAc3VyZmNo ZW0wLnJpa2VuLmdvLmpwDQpidXJ6aWs3NzdAcmFtYmxlci5ydQ0Kc2VhckB1 a3IubmV0DQpub3RlYkBtYWlsLm9kLnVhDQpzYWNoQHRla29tLm9kZXNzYS51 YQ0KdGVjb3RlQHRlY290ZS5vZC51YQ0KbG9iYW4wdkBtYWlsLnJ1DQphbXly QGlseWljaGV2c2sub2Rlc3NhLnVhDQprYXkyNzA3QHlhbmRleC5ydQ0Kd29y a0BvZGVzc2EubmV0DQpzbXNAb2Rlc3NhLm5ldA0KdmlnYWFyQHVrci5uZXQN CnBhbmNodWtfc2FzaGFAdWtyLm5ldA0KbXlsZXh4dXNAdWtyLm5ldA0KYmFy aTQ0QG1haWwucnUNCnBhcmFmaW5pdW1AdWtyLm5ldA0KZG5zX29kQHVrci5u ZXQNCmZyZWVwcmljZUB1a3IubmV0DQpob3RiaXJkQHNreS5vZC51YQ0Ka2V6 YUB1YS5mbQ0KaW5hZnRAbWFpbC5ydQ0KZ3JlY2FAbWFpbC5ydQ0KdndsQHVr ci5uZXQNCnZ2Z0Bza3lsaW5lLm9kLnVhDQpyZXh4MUBtYWlsLnJ1DQpvZGVz dm9kQHVrci5uZXQNCnNhbml6aG5AbWFpbC5ydQ0KMzgwNjc3MTQ3NzQzQDJz bXMua3lpdnN0YXIubmV0DQpzemFAbWFpbC5vZC51YQ0Kb21pdGF5QG5hcm9k LnJ1DQpyb21hbkBtYWlsLm9kLnVhDQpkdWJzQGN3dC5vZGVzc2EubmV0DQpl bGVjdHJvZGVAZ2FyYW5kbmV0Lm5ldA0KYXN0cm9kcmFiYkB5YWhvby5jb20N Cmpvc2VwaF9hLl9tZXJpbmdvbG9AZHNtbGxwLmNvbQ0KcHJtZWx0b25AbXdi Yi5jb20NCndpZXJ6YmFAbGpleHRyYS5jb20NCmxtb25hY294QGNvdW5zZWwu Y29tDQpqb2VhY3RvbkBoYWxjeW9uLmNvbQ0KaXNob3AxQGFvbC5jb20NCmhh bmRsZWJhcmhAYW9sLmNvbQ0KZGlpbGF3bGliQGFvbC5jb20NCmVtaWwubW9y YWxlc0Bjby5oZW5uZXBpbi5tbi51cw0KcmV5bm9sZHNAb25yYW1wLm5ldA0K anR3bGliQGFvbC5jb20NCmRhdmlkLnZlaXRjaEBjYWwuc3VucHViLmNvbQ0K aWFuX25hdGhhbnNvbkBvdHRhd2FzdW4uY29tDQpsb2FyYUAxMjYuY29tDQpq aGx4cUAxODgubmV0DQpzYW5qaWFuZ0AxMjYuY29tDQpzZW5zZWFAMTYzLm5l dA0KZG1jZEAxMjYuY29tDQpodWliZWFyQDIxY24uY29tDQpkZXV1QDI2My5u ZXQNCmR1bGl1QGthbGkuY29tLmNuDQpqbHp6ZkBlYXN0bWFpbC5jb20NCnh4 eEBzb2ltLm5ldA0KMDAxQDI2My5uZXQNCmEubWluZ0BjaGluYS5jb20NCm16 dHd4QDE2My5uZXQNCmJpbGxzb25nQDIxY24uY29tDQpsaWFucW1AMTYzLm5l dA0KYmFnZ2lvLnJAMzcxLm5ldA0KZ3l3QDEyNi5jb20NCmRtc0BzaW9tLm5l dHRoYW5rDQpseXlzMzcxQDM3MS5uZXQNCnpoYWlyd0AyNjMubmV0DQpqdXl1 ZmVuZ0AxNjMubmV0DQpnb3VydWlAMTYzLm5ldA0KZWxlY3RyaWNfbW9uc3Rl ckAxNjMubmV0DQozMjlAMjYzLm5ldA0KamVkaXNoZW5Ac29pbS5uZXQNCnAx NkAzNzEubmV0DQpoZ29qeUAxMy5uZXQNCnpsdDFAc29pbS5uZXQNCm1vb25s aW5AMjFjbi5jb20NCmNoYW5nbGFtQDI2My5uZXQNCmtiX21za0BjYXJhdmFu LnJ1DQpsanF1YW5AMTYzLm5ldA0KcWZjaGVuQHNvaW0ubmV0DQp4bWNvb3BA cHVibGljLnhtLmZqLmMNCnhpbmRlQDEyNi5jb20NCjk4MTIyMEAxODgubmV0 DQpsaGR5eEAxNjMubmV0DQpoYW9jYWlAa2FsaS5jb20NCnpvdWR1bmx1bkAy MWNuLmNvbQ0Kd2VpanVuOTlAMjFjbi5jb20NCmNucm9uZ0AxNjMubmV0DQpj cWN5QDIxY24uY29tDQpwaW5ncG9uZ0B0ZWxla2JpcmRjb20uY24NCmdhb3k2 QDM3MS5uZXQNCmhkX2tpbGxlckA5OTAubmV0DQpiaWdidWdAemIxNjkubmV0 DQpzaW1vbjczQDIxY24uY29tDQpodWFuZ2pnQGNvc2Nvbi5jb20NCnN3bWFp bEAxNjMubmV0DQpwd3U0OTA3Y2hAMjFjbi5jb20NCmR1bG1AMjFjLmNvbQ0K bGluaG5nZmRAMTI2LmNvbQ0Kam9yZG4tMjNAMjFjbi5jb20NCnpyenJAMTYz Lm5ldA0KZ3hfbm5fZnF5QDE2My5uZXQNCmZveDMyNUBzb2ltLm5ldA0KaHVw cGVuZ0B0b25naHVhLmNvbS5jbg0KdGdoQHNvaW0ubmV0DQpjb29sY2hhcnVA aG90bWFpbC5jb20NCmdyZWdAa3JvYWguY29tDQprcmF2aTI2QHlhaG9vLmNv bQ0Kamlrb3NAamlrb3MuY3oNCmNvbGRvbmVrbmlnaHRAcm9nZXJzLmNvbQ0K bWNlbnNhbXVlbEB5YWhvby5jb20NCnByYWRlZXBAaXQuaWl0Yi5hYy5pbg0K YnVsYkB1Y3cuY3oNCmFjaGFudGFwQHlhaG9vLmNvbQ0KYmhhcmFuaXNAZnV0 dXJlLmZ1dHNvZnQuY29tDQp6d2FuZUBsaW51eC5yZWFsbmV0LmNvLnN6DQpk YXZpZF9kYXZ5QGhvdG1haWwuY29tDQptYWxldGluc2t5QHNjcy5jaA0KcmJh YnNAeWFob28uY29tDQpzd2Fwc0Bwcm90b25pYy5jb20NCmJjcmxAcmVkaGF0 LmNvbQ0KYW1pdEBtdXBwZXRsYWJzLmNvbQ0Kc2Fybm9sZEB3aXJleC5jb20N CmprbmFwa2FAZWFydGhsaW5rLm5ldA0KYV9yX2thcnRoaWNAaG90bWFpbC5j b20NCmouYS5rLm1vdXdAaXRzLnR1ZGVsZnQubmwNCmFkYW0ua2hhbkBjYXZp dW0uY29tDQpxdWlja190b21AbHljb3MuY28udWsNCnNyaW5Ac3ltb25kcy5u ZXQNCndvYWlsaW51eEAxNjMuY29tDQpzcG1Admx1Zy5leWphci5pcw0KdG9u Z2NkQG5ldXNvZnQuY29tDQpzdmVuX2RlaG1sb3dAd2ViLmRlDQpya2FscGFA cmVkaWZmbWFpbC5jb20NCnp6d0B6encuY29tDQpzaGFyYXRoXzc1QHlhaG9v LmNvbQ0KYnJhdmluQG1paHkubW90LmNvbQ0KZnJhbmsuc2NoYWZlckBzZXR1 emEuY3oNCnZhcnVuQG1pbmRzdy5jb20NCmNsZ2lzb3R0aUB5YWhvby5jb20N Cmhvbmdoc3VAYmVsbGF0bGFudGljLm5ldA0KdGJyYWRsZXlAamF5Y29yLmNv bQ0KMTAwMDAwQGNzZWxpbnV4MS5jc2UuaWl0ay5hYy5pbg0KamFtaW5jQGFk YXB0LXRlbGUuY29tDQpmbncxMDAxQGNhbS5hYy51aw0KYW50aUB3ZWJob21l Lm51DQpjb2RleEBtYWdpYy1kcmVhbXMuZGUNCmZyM2Rfam9obnMwbkBob3Rt YWlsLmNvbQ0KdGFkLnVrQGR0bi5udGwuY29tDQpsZWFmbGFAaG90bWFpbC5j b20NCnJicm9ubmVua2FAZ2liYm9uc2xhdy5jb20NCmluZm9AYW5pbWFsaWVh bmltYWxpLml0DQpwZXRpemlvbmlAYW5pbWFsaWVhbmltYWxpLml0DQphLmIu ZGVzaWduZXJAY2lhb3dlYi5pdA0KYmFpcmRob2xtQGlucy5pbmZvbmV0Lm5l dA0KY291cnR0djNAYW9sLmNvbQ0KZC5icmFuZHRAb25yYW1wLm5ldA0KZGVi b3JhaDg2NUBkZWxwaGkuY29tDQpsdWJpbmpAZGVscGhpLmNvbQ0KbWF6em9u aUBzbXRwbGluay5icmFpbnMuY29tDQptY2VnZWxpc0Bhb2wuY29tDQpubHBj QGFvbC5jb20NCnRwc2FycmFzQGFvbC5jb20NCnNlY3VsYXJAbWFpbC5ydQ0K Z2hhbmR5QHNjZW5ldC5kZQ0KemF4ZUBwbGFuZXQubmwNCm5lYnVsYUBwbGFu ZXQubmwNCmhpbWlkdG93bkByb3NkZXZob3RlbHMuY29tDQphZGluZm9AYnls aW5lbWFnLmNvbQ0KYW5hbmRfcmFtYW5AcG9ib3hlcy5jb20NCndqb2RAd29y bGRuZXQuYXR0Lm5ldA0KdHJheW1lckBtYWlsLnN0YXRlLm1vLnVzDQpzZndv ZUBmbGFzaC5uZXQNCnNvdXJjZUBvbmUubmV0DQpzYW5kcmFoZWx0b25AY2Fy ZTIuY29tDQppbmZvQHVuaXZlcnNhbGNlbnRyZS5uZXQNCmVsaXphYmV0aEBl bGl6YWJldGhvd2Vucy5jb20NCm55dG5nYXlsZUBhb2wuY29tDQp6eTR0aEBt cGluZXQubmV0DQpwZXRlckBjYXNzYWRhZ2EuYml6DQptYXR0QGNhc3NhZGFn YS5jb20NCmR3ZWdlbGluQG1waW5ldC5uZXQNCnJpY2hhcmRnaXNtb0Bhb2wu Y29tDQpoZWNhdGU3MDBAeWFob28uY29tDQphcnRlbWlzN0BteWJsdWVsaWdo dC5jb20NCmVsbGlzb25AdG90Y29uLmNvbQ0KZHJob292ZXJAdG90Y29tLmNv bQ0Kc291cmFudEB0b3Rjb24uY29tDQpzZGV3ZWVzQGVhcnRobGluay5uZXQN Cm1lZGl1bUBpd29uLmNvbQ0Kc3RhcnR1bmVyQGFvbC5jb20NCnRyYWRpbmdj ZW50ZXJAbXBpbmV0Lm5ldA0KbWFlcmxpbkBtZXJsaW5zdmlzaW9uLmNvbQ0K am9yZGhlYWx0aEBhb2wuY29tDQptYXN0ZXJoZXJiYWxpc3RAbXNuLmNvbQ0K dGhlZXNlQGNmbC5yci5jb20NCndrZW1wZkBob3RtYWlsLmNvbQ0KaW5mb3JA bmV3bGVhZnN0dWRpby5uZXQNCnJjY0BtYWdpY25ldC5uZXQNCmxpZmVmb3Jj ZXNkb21lQGp1bm8uY29tDQpwdWNlbGxlQG1pbmRzcHJpbmcuY29tDQpoYXVu dHNvZmRheXRvbmFAYW9sLmNvbQ0Kc2FjcmVkc3BhY2UyMDAxQGVhcnRobGlu ay5uZXQNCndsb3dtb29uNTVAYW9sLmNvbQ0KbG92ZS1oZWFsc0B1c2NpdHku bmV0DQplYXJ0aC1nb2RkZXNzMUB3ZWJ0di5uZXQNCmdsYWRzdGFyQG1zbi5j b20NCmNyYmxtdEBhb2wuY29tDQp0YXRlcnJpZmljMUBhb2wuY29tDQpqc3J1 bmluOThAYXR0Lm5ldA0Kc2FsZXNAYWxvdHRhc2NlbnRzLmNvbQ0KYXJvbWFA c2FsdWJyaXVtLmNvbQ0KcmV2Z2xvMUBhb2wuY29tDQpscHJvc2UyMUBhb2wu Y29tDQpiZWtraUBtaW5kc3ByaW5nLmNvbQ0KanVsaWFuQGNhdWNlZ2xpYS5j b20NCnRvbUB0b21taWxsZXJsbXQubmV0DQp0aG5kcnRodW1ic0B3ZWJ0di5u ZXQNCnZlcm1vbnRiaXpAYW9sLmNvbQ0KbmFtaWFtaUBiZWxsc291dGgubmV0 DQpibHVlc2t5c0BtaW5kc3ByaW5nLmNvbQ0KcGF5b3V0MUBnYXRlLm5ldA0K bGl6QGFjdW1hc3NhZ2UuY29tDQpzZWFnbGU4ODUwQGFvbC5jb20NCmFibGVu ZXJneUBhb2wuY29tDQpkcm9lZGVyMTAzQGFvbC5jb20NCnJtam1haUBhb2wu Y29tDQpwYXVsa25vdHRANXBpbGxhcnMuY29tDQphaGVhbHRoeXBsQGFvbC5j b20NCmF0b3VjaG9mbGlnaHQ0dUBhb2wuY29tDQpyZWFkaW5nczR1QGFvbC5j b20NCnN0aW5maXRAbWVkaWFvbmUubmV0DQpsaWdodHdvcmtlcjE2QGVhcnRo bGluay5uZXQNCmxpbmRhbG15ZXJzQGNvbWNhc3QubmV0DQpoZWFsaW5nd3Jr QGFvbC5jb20NCm1pbWk0NDQ0NEBhb2wuY29tDQpyZXZyZWlraW5kQGNzLmNv bQ0KbnBhdGgxQGFvbC5jb20NCmJyb3duNDE4OEBhb2wuY29tDQphY3VtZWRk b2MxQGFsdGF2aXN0YS5jb20NCmJob3BraW5zYXBAYW9sLmNvbQ0KbWF5b0Bn ZW1pbmltYXJrZXRpbmcuY29tDQpoeXBlcjFyZWhhYkBhb2wuY29tDQptaGMx MDE1MEBhb2wuY29tDQpyZXZlcmVuZGNhcm1lbkBhb2wuY29tDQpkYm9ocmVy QG1waW5ldC5uZXQNCnlvZ2FjZW50cmFsODg4QGFvbC5jb20NCmx5bkBpbnNp ZGVmbGFnbGVyLmNvbQ0KbWlyaXRAeWFob28uY29tLmF1DQp3b3Jrc2hvcEBh bGNoZW15aGVhbGluZy5jb20NCnN1bmZseWVyQGF1Zy5jb20NCnZveWFnZXJh bmFzdGFzaWFAaG90bWFpbC5jb20NCmpwbGFuZTFAYW9sLmNvbQ0KbXNrZWVz aGE0MTFAYW9sLmNvbQ0KYm9keXNjYW5AZWFydGhsaW5rLm5ldA0KbWlzdGlr bzEzQGhvdG1haWwuY29tDQp1bml0eWNvcmxhbmRvQGFvbC5jb20NCmNvbmNl cHRzeW5lcmd5QHdvcmxkbmV0LmF0dC5uZXQNCmtycGhkdGhkY2FwQG1pbmRz cHJpbmcuY29tDQprYXJpbmliY2xjQGFvbC5jb20NCmRpYW5lQGRpYW5lcm9z cy5jb20NCmZyYW5rQHh0cmVtZWp1aWNlLnVzDQpvcmxhbmRvX21hc3NhZ2VA aG90bWFpbC5jb20NCmRvY3Zpc2NvbnRpQGFvbC5jb20NCnJlaWtpX3NhbmN0 dWFyeUBjZmwucnIuY29tDQpnbm9zaXNvcmxhbmRvQGhvdG1haWwuY29tDQpz YWxtYW5fYmluX2hhbWFkQGhvdG1haWwuY29tDQptc2xpbmRhQGVhcnRobGlu ay5uZXQNCjNkMjVmNjU0LjRkYzY2YmY2QGVhcnRobGluay5uZXQNCm1pbGxl cmNpcmVtb3ZlQGludmFsaWR0ZWx1cy5uZXQNCnBuNS43MTU2NjdAbmV3czEu dGVsdXNwbGFuZXQubmV0DQpwbjUuNzE1NjY3QG5ld3MxLnRlbHVzcGxhbmUN Cm1pbGxlcmNpcmVtb3ZlQGludmFsaWRjYW5hZGEuY29tDQpwaWNrb25lQHBp Y2t5LmNhDQpsZS4zMzM4MjA5NTZAcmFkDQpsZS4zMzM4MjA5NTZAcmFkb24u Z29sZGVuLm5ldA0KMS4zMzg3OTQ1MTJAcmFkbw0KMS4zMzg3OTQ1MTJAcmFk b24uZ29sZGVuLm5ldA0KcG41LjcxNTY2N0BuZXdzMS50ZWx1c3ANCmZsb3Jh aGlsbHNAeWFob28uY29tDQpiZXJ0QHZpc2kuY29tDQprb2tvcGVsbGlAdS5n ZW5pZS5jby51aw0KaGF0dW5lbkBjb3gubmV0DQpoYXR1dW5lbkBjb3gubmV0 DQpkYnBnZmlzaEB0ZWx1cy5uZXQNCjNkMjljYzE1LjMzODkwNDcxQG5ld3Mu Zg0KM2QyOWNjMTUuMzM4OTA0NzFAbmV3cy5mcmVlc2VydmUuY29tDQozZDI5 Y2MxNS4zMzg5MDQ3MUBuZXdzLg0KM2QyYTA2NTkuNDg4MDg2MTFAbmV3cy5m DQozZDJhMDY1OS40ODgwODYxMUBuZXdzLmZyZWVzZXJ2ZS5jb20NCjNkMjlj YzE1LjMzODkwNDcxQG5ldw0KcmlkZGxlQGlvLmNvbQ0KYnVnYmFyYmVxQGlj ZW0uaXQNCnNsN3NnaTcwOTk5NGdvY0A0YXguY29tDQpoZWxlbl9nZXJhbGRA aG90bWFpbC5jb20NCjAwMzkuMTMyZjRlMzNAcG9zdGluZy5nb29nbGUuY29t DQpkaWdpdDlAY29sdW1idXMucnIuY29tDQozODAxMzUwQHR3aXN0ZXIuY29s dW1idXMucnIuY29tDQpscDUuMzgwMTM1MEB0d2lzdGVyLmNvbHVtYnVzLnJy LmMNCmxtYXJrNTkxQGFvbC5jb20NCjAwMDAwMDI5QG1iLWZzLmFvbC5jb20N CmRrdWlrYWhpQGFvbC5jb20NCjM1MzNAbWItY2ouYW9sLmNvbQ0KbXNiQHZl eC5uZXQNCm1hcnRpbkBqYWNrZGF3LnUtbmV0LmNvbQ0KbS5nLnJpY2hAY2l0 eS5hYy51aw0KbWlrZTMzM19uQHlhaG9vLmNvbQ0KeWM0LjY5ODM2NkBuZXdz MC50ZWx1c3BsYW5ldC5uZXQNCnljNC42OTgzNjZAbmV3czAudGVsdXNwbGFu ZQ0KcG41LjcxNTY2N0BuZXdzMS50ZQ0KemVsbGVyczIyMDAwQHlhaG9vLmNv LnVrDQppbmZvQGNhbmFkYXZpc2EuY29tDQpjYXJscGF1ZmZAaG90bWFpbC5j b20NCmNfMi4xMDc5NDMxQG5ld3MyMC5iZWxsZ2xvYmFsLmNvbQ0KZ2lhaXNh QHRpc2NhbGluZXQuaXQNCnVyYmFtYW5AbGliZXJvLml0DQp3d3cudGhlY291 bnRlci5jb21AMTI1eDEyNS0xDQpzdWJtaXNzaW9uc0BpbnRlcm5ldC5jb20N CnRhdGljdUBob3RtYWlsLmNvbQ0KbG91bmdpbjgwQG15LWRlamEuY29tDQpj b2xuYWdvQGNpbnRlcm5ldC5uZXQNCnJhZ3JpbW1AYmlnZm9vdC5jb20NCnRo ZS5tdXJwaHlAc25hZnUuZGUNCmpvaG5hZUB3bW9sLmNvbQ0Kaml1emhlbmdA bmV0c2NhcGUubmV0DQpzbGFnX3BpbGVAbXktZGVqYS5jb20NCnRpbW15dEBy bWkubmV0DQphcmVrcmFqQGNvbW1vbi5wbA0KeDMuNDMyNTg0QG5ld3MudHBu ZXQucGwNCm1tbW1AZ214LmF0DQpicmVudHJicmlhbkBwcm9kaWd5Lm5ldA0K d2FsbGVuYm9ybkBwaHlzLmNoZW0uZXRoei5jaA0Kam9zZWYubWFsdGFuQGV5 ZW9ubGluZS5kZQ0KcXVhZGNpdHl0akBteS1kZWphLmNvbQ0KZ2pyaXR0ZXJA bXktZGVqYS5jb20NCmJrdW56QGV4LWxpYnJpcy5kZQ0Kb3phcm93QGx1Y2Vu dC5jb20NCmprZHVmYWlyQG15LWRlamEuY29tDQptZmVsdGVyQGNhcGl0YWxn YXpldHRlLmNvbQ0KY2Fwc3RhZmZAY2FwaXRhbGdhemV0dGUuY29tDQp0YXBl d29ybUBpbndpbmQuaXQNCmVlQGxpc3QudG8NCnM3MTQ3OGZiLjAyNEBoYXli b28uY29tDQppbnZlc3RtZW50QHJpdmEuY29tDQp0ZXN0QHRlc3QuY29tDQpu ZXdzQGJlZ3Jvb3Z5LmNvbQ0KbnV0Y2FzZUBiZWdyb292eS5jb20NCmJlYml0 c0BiZWJpdHMuY29tDQpidWdzQGJlYml0cy5jb20NCm1hcmtldGluZ0BiZWJp dHMuY29tDQp3ZWJndXlAYmViaXRzLmNvbQ0KaW5zYW5pdHlAYmViaXRzLmNv bQ0KbGlzdGFyQGx1Zy5ybw0KY2F0YUBndG8ucm8NCmZsb3dlcm9zQGdvbGlh LnJvDQpncm91bmR6ZXJvQHp1YXZyYS5uZXQNCnBldHJ1QHBhbGVyLm5ldA0K cnVkeUB2aXBlci5pYXNpLnJkc25ldC5ybw0KY3J1ZGVhbnVAeWFob28uY29t DQplZ294QHZhdmVsLm5ldA0KZGFuaUBjeWJlci5ybw0KZ2Fib25lQGl0YWNv LmZ4LnJvDQphbGV4YW5kcnUuYmFsYW5AaW5lcy5ybw0KYm9nbUB0b2tvLnJv DQpkYW5AZ2RzLnJvDQpybHVnQGx1Zy5ybw0KdXNlcl94QG9mZmljZS5vZg0K cG1hcmF2ZWlAY2lzY28uY29tDQpybHVnQDFhLnJvDQp3b2xmeUBwY25ldC5y bw0KYnVpbGRlckBiZS5jb20NCm5qaEBiYW5kc21hbi5jby51aw0Ka2V2cGF0 dEBleGNpdGUuY29tDQp0aW1rb2hAZG9nLmNvbQ0KZXhhckBuZXZlcndoZXJl LndzDQpzaW1vbi5vd2VuQGNvbnRhY3RtZS5jby51aw0KaG90cGxhc21hQGp1 bm8uY29tDQpza3l6eXhAaG90bWFpbC5jb20NCmFyY2JsYXplQGhvdG1haWwu Y29tDQpkckBrZ2IuaHUNCnJvYmx1bmRAbWl0c2kuY29tDQo4OTg5OEBwYWdl ci5taXJhYmlsaXMuY29tDQpmcmV5dGFnQGdteC5kZQ0KeGxyOEB0cmVmLm5s DQpzd2FyZGxhd0BwY25ldC5jb20NCmluZm9AZGF0YXdpbmcuY28udWsNCmZy YW5zQHhlbnRyb25peC5jb20NCnBoaWxpcHBlLmhvdWRvaW5AZnJlZS5mcg0K bWljaGFlbC5wZmVpZmZlckB1dGFuZXQuYXQNCnN0ZXBoY2VsQHNuZXQubmV0 DQpnYXV2aW5zQGNzLmRhbC5jYQ0KYmViaXRzZW1haWxAdXNhLm5ldA0KaGFu a0BiZS5jb20NCmVwb2l0aWVyQG9wZW5saW5rc3cuY28udWsNCnRzYWJvdUBh dGwuY29tDQptc2NoZWZlckBpcHJvbGluay5jaA0KcGV0ZXJAdmVyaGFzLmNv bQ0Kb3RqZV9qckBob3RtYWlsLmNvbQ0Kc2Vrc3lyeWFuQHlhaG9vLmNvbQ0K b3Vzc2llQHBsYW5ldC5ubA0KbWFsaWtmYXl5YXphaG1lZEBob3RtYWlsLmNv bQ0Kc3VndWliaW5AMjFjbi5jb20NCmRpb3JpbzExQGhvdG1haWwuY29tDQpy YW15X3NhbXlAeWFob28uY29tDQpwYWN0b3JqaEB5YWhvby5jb20uYXINCmVk Z2Fyb21hcjk5QHlhaG9vLmNvbQ0KYWNtb3JyaUB5YWhvby5jb20NCmluZm9A aXAzaW5jLmNvbQ0KZ2Fyc0BsYW5tLXBjLmNvbQ0KanRzb2Z0QGhvdG1haWwu Y29tDQpwdGJAb2JvZS5pdC51YzNtLmVzDQp3aWpzQGJhcnQubmwNCmlzdHZh bkBjcGsuYXVjLmRrDQpqYW1lc3BvQG15LWRlamEuY29tDQpqLmZhYXNzZW5A aG9tZS5ubA0KYXBsZ3VsZkBlbWlyYXRlcy5uZXQuYWUNCmdlbmVfaGVza2V0 dEBpb2xpbmMubmV0DQp0cmFyX3VyZnhyZ2dAdmJ5dmFwLmFyZw0KZHplcmFq c3NAbmV0c2NhcGUubmV0DQpkemVyYWpzc0Bob3RtYWlsLmNvbQ0KZ3JhaXRl ckBzdGFybWFpbC5jb20NCm10bl92aWV3QHNpcml1cy5jb20NCjNhMzAyYjE1 LmMzOTRhZGRjQHNpcml1cy5jb20NCmYubWljaGFlbEBnbXguZGUNCmEucmVn dGVyc2Nob3RAY2hlbGxvLm5sDQp0cmllYkBsaW51eHN0YXJ0LmNvbQ0Kampf bWJfNjlAc3ltcGF0aWNvLmNhDQpzZWp1cDFAYWx0ZXJuZXguY29tLmJyDQpr c2tlaGFuQGJpZ3BvbmQubmV0LmF1DQpjaGlhcGFzLWxAZHM1MDAwLmRnc2Nh LnVuYW0ubXgNCmNoaWFwYXMtbEBwcm9mbWV4aXMuZGdzY2EudW5hbS5teA0K b3duZXItY2hpYXBhcy1sQHByb2ZtZXhpcy5kZ3NjYS51bmFtLm14DQpib2J3 cmlnbGV5QGFvbC5jb20NCmFob2VzY2hvb25lckB3ZWJ0di5uZXQNCnRhaG9l c2Nob29uZXJAd2VidHYubmV0DQplZGl0b3JpYWxAbGF0aXR1ZGUzOC5jb20N CnJtNmstaHRtbkBhc2FoaS1uZXQub3IuanANCndlaXNzbWFubkBudG1sbGMu Y29tDQptdXJtb3JAZ214Lm5ldA0KMjBjYXBlMmNhcGVAaG90bWFpbC5jb20N CmNhcGUyY2FwZUBob3RtYWlsLmNvbQ0KZGFuaWVsLmdhbGlhY3lAaHBzLnRt LmZyDQpkZWVhQHJvdWVuLmNjaS5mcg0KY3NzdHRvQGl0cy5pdA0KcGFvbG8u cml2YUBlbHRyYWMuaXQNCmJlcmdlc2UuY0BpdmVjby5jb20NCmF0Y0Biby5u ZXR0dW5vLml0DQphbGVzc2FuZHJvLmZyb3ZhQG9tbml0ZWwuaXQNCm1vYmls aXRhQGNvbXVuZS5ib2xvZ25hLml0DQppbnRlcnBvcnRvYm9AYm8uaW50ZXJw b3J0by5pdA0KaW5mb0BuZWEubmwNCmFsZ2VtZWVuQGluZHV0aWwubmwNCnBv cnRfYWhAcG9zdDQudGVsZS5kaw0KaW5mb0B0Zmsuc2UNCmtmYkBrZmIuc2UN CnRyYWRlbWNvQG90ZW5ldC5ncg0KdHNpbmdvc0Bob2wuZ3INCmNhcG9jY2lA b3RlbmV0LmdyDQp0cnRoQGh5cGVyLmdyDQpoZ3Vuc2VsZEB1bnNlbGQuY29t DQpncGV0c2Noa0B1bnNlbGQuY29tDQpvZmZpY2VAaWxsLmNvLmF0DQpjc3N0 cm1AbWNsaW5rLml0DQpjc3N0bmFAdGluLml0DQplbWFpbEBuZWEubmwNCm50 dS1icnV4ZWxsZXNAbnR1LmRrDQp0c2dAd2VzdG1pbnN0ZXIuYWMudWsNCnBy NHVAY2FybGVjb20uY29tDQpsaXpAY2FybGVjb20uY29tDQpta2FjemthQGhh YW1tb25kZGV2Y29ycC5jb20NCmJyZW5kYXJhZmZlcnR5QHByb2RpZ3kubmV0 DQpta2FjemthQGhhbW1vbmRkZXZjb3JwLmNvbQ0KY2liZUB3ZWIubmV0DQp0 YnJraWNAaWlzZC5jYQ0KaW5mb0B3YmNzZC5jaA0KZ3JuZXdzY2FAc3ltcGF0 aWNvLmNhDQpuZXdzQGdsaWRldW5kZXJncm91bmQuY29tDQpjb21tZW50c0Bn bGlkZXVuZGVyZ3JvdW5kLmNvbQ0KbWlrZUBnbGlkZXVuZGVyZ3JvdW5kLmNv bQ0KamVmZkBqLW1heHgubmV0DQpyb2VlQGdsaWRldW5kZXJncm91bmQuY29t DQpyZWFjdG9yQHJlYWN0b3IucnUNCnNwaXJpdEByZWFjdG9yLnJ1DQp0b25l QHJlYWN0b3IucnUNCnBldGVyQHdpc2RvbXBvcnRhbC5jb20NCnJrZWFuZUBj bXAuY29tDQpid2hAaWRzb2Z0d2FyZS5jb20NCmdvZGRlc3NAYm9tYnNoZWxs cy5jb20NCmJpbGxAZzI1Ni5jb20NCm1maW5sYXlAanVwaXRlcm1lZGlhLmNv bQ0Kc2VzQGp1cGl0ZXJtZWRpYS5jb20NCmd0b2VtbWVzQGp1cGl0ZXJtZWRp YS5jb20NCnJlZ2lzdHJhdGlvbkBqdXBpdGVybWVkaWEuY29tDQpkMTI4LmNv bUBpbWFpbC5kMTI4LmNvbQ0Ka2lya0BmaW5nZXIubnZpZGlhLmNvbQ0KY2hh c0BmaW5nZXIubnZpZGlhLmNvbQ0KZHdpZ2h0QGZpbmdlci5udmlkaWEuY29t DQp6YXBob2RAaWRzb2Z0d2FyZS5jb20NCnRvZGRoQGlkc29mdHdhcmUuY29t DQp6b2lkQGlkc29mdHdhcmUuY29tDQpyaWNrLm92ZXJtYW5AZmluZ2VyLmR5 bmFtaXguY29tDQpsaWNlbnNpbmdAaW50ZXJuZXQuY29tDQpyZXByaW50c0Bp bnRlcm5ldC5jb20NCmNwYWNlQGludGVybmV0LmNvbQ0KcHJpdmFjeUBpbnRl cm5ldC5jb20NCmNwYWNlQGp1cGl0ZXJtZWRpYS5jb20NCnJib2d1ZUBpbnRl cm5ldC5jb20NCmxkNmNAdmlyZHNiLm5ldHpzZXJ2aWNlLmRlDQpob3Juc0B0 LW9ubGluZS5kZQ0Ka3VobkBjbC5jYW0uYWMudWsNCmhvZmZnQHVuaS10cmll ci5kZQ0KcGV0ZUBucy5hbHRhZGVuYS5uZXQNCnBldGVAZ29vbmV5LmFsdGFk ZW5hLm5ldA0Kcm9vdEBnb29uZXkuYWx0YWRlbmEubmV0DQpvbGxpQHNlY25l dGl4LmRlDQpkaWxsb25AYXBvbGxvLmJhY2twbGFuZS5jb20NCnlhbi56aHVA aW5maW5pdHkNCjNjYzA5NGE0LmIyMzgyY2ExQGluZmluaXR5DQoxMDAwMDBA Y2lyY3VpdC5tb3VyZWF1eC5jb20NCjNjYzA5MWMwLjgzNDFiYzllQGluZmlu aXR5DQp5YW4uemh1QGluZmluaXR5LWluc3VyYW5jZS5jb20NCnJlZGhhdC1s aXN0QGxpc3RtYW4ucmVkaGF0LmNvbQ0KcmVkaGF0LWxpc3QtcmVxdWVzdEBy ZWRoYXQuY29tDQozY2MwOTFjMC44MzQxYmM5ZUBpbmZpbml0eS1pbnN1cmFu Y2UuY29tDQpzdGF0dXhAYmlnZm9vdC5jb20NCmdyZWdvcnkuY2FtcEBvc2Mu Y29tDQpncmVnQG5hcy1pbmV0LmNvbQ0KZnNhdmlvbG9Ab3BlbmxpbmsuY29t DQpub25zdG9wbnlAYW9sLmNvbQ0KcGx1Z0BtaWNyb3NoYXJwLmNvbQ0Kb3du ZXItcGx1Z0BtaWNyb3NoYXJwLmNvbQ0KcmFuZHkuZHVubGFwQGludGVsLmNv bQ0KM2M1MTg3ZjYuMjVkOTdkOWFAbmltci5tcmMuYWMudWsNCnlhdUBuaW1y Lm1yYy5hYy51aw0KbXdpbGxlbXNAaXhvbmV0LmNvbQ0Ka2l0QHVrcnBhY2su bmV0DQptaWtlQHByb3NwZWt0LmtoYXJraXYuY29tDQpmb25hcmlrQHVrcnBh Y2submV0DQp2bGMtYXJjaGl2ZUB6ZW4udmlhLmVjcC5mcg0KdmxjLWFyY2hp dmVAdmlhLmVjcC5mcg0KdmxjQHZpYS5lY3AuZnINCnJvb3RAd3Mtb2ZmaWNl Lm12dy5uZXQNCm12d0BtdncubmV0DQplZXNlcmdAbGRjLm5ldA0KY29vbGhh aXJAb2sucnUNCjltc2tAcWxpbmsucXVlZW5zdS5jYQ0KcGhpbGZvcm1AcXNp bHZlci5xdWVlbnN1LmNhDQpyb2JlcnRhLmNvbG9tYm9AdW5pZnIuY2gNCnBm YXJhZ29AYWNjZXNzLmNoDQpoZWxlbmUuZ3JldmVuQHUtZ3Jlbm9ibGUzLmZy DQpzYW5kckBvZGVzc2EubmV0DQptb29uQGludGVycGxleS51a3JuZXQubmV0 DQp0b3Jla3lhLmJsYWd1c3NAdm9sYW5idXN6Lmh1DQp6ZXVzQG1haWwucnUN CndhcnJpb3JAY3JlYXRlci5kcC51YQ0Kcmljb19qb2huQHlhaG9vLmNvbQ0K d2VpZXJAc3Byb2cuYXVjLmRrDQphbGVzLTc3N0B1c2EubmV0DQpiYW5zaGVl X2xzZEBob3RtYWlsLmNvbQ0Kc29jaWFsLmp1c3RpY2VAYnJpZ2h0b24uYWMu dWsNCm5hdC1jb25mQGJyaXMuYWMudWsNCmMta3VrYXRoYXNAYWRmYS5vei5h dQ0Ka3ltbGlja2FAcG9zdC5xdWVlbnN1LmNhDQpvdHRvQGF0bG8ua2lldi51 YQ0Kd2hpdGVAdWtybmV0Lm5ldA0KYW5kcmV3ZGV5bmVrb0Bob3RtYWlsLmNv bQ0KeGV4ZUB4b3hvLnJ1DQphYmliaWtAZW1haWwuY29tDQphbGV4QHplb3Mu bmV0DQptb29uQGludGVycGxheS51a3JuZXQubmV0DQpmYWxjb25fZmRAcm9j ay5jb20NCm1hdHZleWxwOEBtYWlsLnJ1DQpkYW5pZWxAYWtjZWNjLmtpZXYu dWENCmtwZHBhcnRAdXNhLm5ldA0KaGF2aWxvQGxhbmdlcm9uLmtpZXYudWEN CnZlcmdlckB2bGFzaXVrLmtpZXYudWENCndpbnhwQG9zem9uZS5uZXQNCnNv ZnRAb3N6b25lLm5ldA0KbWFpbGxpc3RAb3N6b25lLm5ldA0KamswMUBuZ3Mu cnUNCmxlZ2lvbl9oZWxsQHBpc2VtLm5ldA0Kc2hhZG93QGd0ay5pZGtuZXQu Y29tDQphbmRyZXdAaXZjYXZpYS5jb20NCnBpYUBtdy5uYXJ6YW4uY29tDQpj cmFzaC5zbW9sZW5za0BtYWlsLnJ1DQp2YW5pa0BtYWlsLmt6DQpkb2Zmc3Vi c2NyaWJlQGhvdGJveC5ydQ0Kb2tuYUBzbGF2LmRuLnVhDQphel8yMDAwQG1h aWxydS5jb20NCmF3c0BtYWlsLmt1LnJ1DQpkaW1pdHJpY3VzQHJhbWJsZXIu cnUNCmdpZ2FieXRlX0Biay5ydQ0KYWxleG9zaXA2NEBtYWlsLnJ1DQptb25p dG9yMUB1c2VybGluZS5ydQ0KbWFuaWFjQHJpbmcuYnkNCmFrcmFzaWxuaWtv dkBpbmZvcnVtLXNpYi5ydQ0KdG9tQGZhYWNvbnN1bHRpbmcuY29tDQp0cGtA Y3MueW9yay5hYy51aw0KYmlsbF9nYXRlc0Bwb2NodGFtdC5ydQ0KdmxhZGlt aXJAa21hLnJ1DQphYmFydG9saUBhcmluYy5jb20NCnNhZmV0eS1jcml0aWNh bEBjcy55b3JrLmFjLnVrDQphanJAbWFpbC5ydQ0KcF9hbmRyZXlAbWFpbC5y dQ0KZmxldGNoZXJAcG9jaHRhbXQucnUNCnNhc2hhMDcxMTg0QG1haWwucnUN CnRlYUBiay5ydQ0Kb20yMDAyQGZyZWVtYWlsLnJ1DQphcm1hQGFybWEuY29t LnVhDQpwbXNfb2tAa2FydGFseS5zdXJ3LnJ1DQp2YXJfYWxleEBmcm9tcnUu Y29tDQp2ZXNuYTFAZXptYWlsLnJ1DQpnZW9waGljc0BtYWlsLnJ1DQpvZ2xh ZGlqQHpoeWRhY2hpdi5sdml2LnVhDQpwYW5nbWFuQGhvdGJveC5ydQ0Ka2ll dnNhc2hAYmlnbWlyLm5ldA0KbWFpbF9wcm9mb3JtQG1haWwucnUNCnZtYXpA aG90Ym94LnJ1DQppYW5kcmV3QGluYm94LnJ1DQphbGd1bUBubS5ydQ0Kdmlt YW5AcGlzZW0ubmV0DQpiYWhiaTRAeWFuZGV4LnJ1DQpzb2tvbHJ1cHNAdm9s b2dkYS5ydQ0Kb3ZhbDRAZXptYWlsLnJ1DQphbGV4MjQxMUB0dXQuYnkNCmdv Z2EtcGVybUBwZXJtb25saW5lLnJ1DQpjYXRAZ2xhem92Lm5ldA0KZGllbW9u QGJhemFyb3YubmV0DQphdGNAYWx0dHJhay5ydWJ0c292c2sucnUNCnNlcmdA Y29ubmVjdGZyZWUuY28udWsNCnNfeXVya292c2t5QG5tLnJ1DQp2YWxlcmlr QHN2aXRvbmxpbmUuY29tDQpnb29kYm95QHR1dC5ieQ0KdHJvbGxAcmJjbWFp bC5ydQ0KcGxleHVzQGZyb21ydS5jb20NCnVyc3VzMjVAcmFtYmxlci5ydQ0K a29uc2VyQHpoaXpuLnJ1DQpkX2NodUBtYWlsLnJ1DQpibGFja21hbkBtYWls Lmt6DQpsaW51eGludUBncmFwZXZpbmUyLmNvbQ0KYWNpZHIwMHRAaG90bWFp bC5jb20NCm9wZW5keC11c2Vyc0BvcGVuZHgud2F0c29uLmlibS5jb20NCm93 bmVyLW9wZW5keC11c2Vyc0BvcGVuZHgud2F0c29uLmlibS5jb20NCmFudG9z aGFAbWYuc2FtYmEucnUNCmF4aXRAcGFyYWRpc2UubmV0Lm56DQpuaWNrQGRv bWFpbi5oaWRkZW4NCmF4aXRAZG9tYWluLmhpZGRlbg0KbGludXgtdXNlcnNA ZG9tYWluLmhpZGRlbg0KbnpsdWdAZG9tYWluLmhpZGRlbg0KbWFpbHNlcnZA aXQuY2FudGVyYnVyeS5hYy5ueg0Kbmlja0Byb3V0LmNvLm56DQpzcGFya3lA ZW4uY29tDQpqYWNhdHRAZmxhc2gubmV0DQpydmlsbGVsbGFAd2lkb21ha2Vy LmNvbQ0KODg0MjY1OTA2LjEzMDAyMzQyNkBkZWphbmV3cy5jb20NCm9sZS5z Y2hlbGRlQGEtYWFyaHVzLmRrDQpsZXBvdXNzb25AeWFob28uZnINCmhlbGlA dHp2LmZhbC5kZQ0KY2NodUBmbHl0ZWNvbW0uY29tDQpyaWNrQGxpbnV4bWFm aWEuY29tDQptYXJrLnMuaGFycmlzQG1vdG9yb2xhLmNvbQ0KaXNrQGFscGhh LmVwYXMudXRvcm9udG8uY2ENCm1tY2theUBlcGFzLnV0b3JvbnRvLmNhDQpk YXZlc2dAbmV0YXhzLmNvbQ0KbWFyaWFuQHdvcmxkLnN0ZC5jb20NCmxpb250 YW1yQHBvc3RvZmZpY2UucHRkLm5ldA0KcGV0ZXJzckBzcGllZ2VsLmJlY2x0 ZC5jb20NCnN3ZW5zZWxAYnJhbmRlZ2VlLmxtLmNvbQ0KdWR1aWRvQGFvbC5j b20NCmJhYWFzdGFyZEBhb2wuY29tDQp0cm95QGFzYW4uY29tDQpmb3hkYWxl QHdvbGZzdGFyLmNvbQ0KZGRyZW1hY25hbUBhb2wuY29tDQphbGR5dGhAYW9s LmNvbQ0KdmFyanVAYW9sLmNvbQ0KcmVuZnJvd0Bza3lsYW5kcy5uZXQNCnBh cmxlaUBraS5zZQ0KcGFyLmxlaWpvbmh1ZnZ1ZEBsYWJ0ZWsua2kuc2UNCmFp bmVAc2hvY2tpbmcuY29tDQplbXN0ZXJAYWxhc2thLm5ldA0KbWVsaW9yYUBt YWNxdWFyaWUubWF0cmEuY29tLmF1DQpqbG1hdHRlcmVyQGxhYnlyaW50aC5u ZXQNCmNyeXN0YWxAcGRyLWlzLmNvbQ0Kcm9ieW4ucHJvYmVydEBsYXdwb2lu dC5jb20uYXUNCmxyZHJhc0Bhb2wuY29tDQpuZXZyYXlAbmV0c3BhY2UubmV0 LmF1DQphcmlhbm5Abm1pYS5jb20NCnNld2Vuc2VsQGJlbGxhdGxhbnRpYy5u ZXQNCnNldG9uMTM1NUBhb2wuY29tDQphMTRoQHplYnJhLm5ldA0KYmVja3lt Y0BtaWNyb3NvZnQuY29tDQpsaHVwbWFuQGtlbnlvbi5jb20NCg== --a28d7614-9edf-4268-b355-6f4c952135be-- From rusty@samba.org Wed Oct 16 18:57:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 18:57:40 -0700 (PDT) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H1vctG004862 for ; Wed, 16 Oct 2002 18:57:38 -0700 Received: by lists.samba.org (Postfix, from userid 590) id 0BAAA2C096; Wed, 16 Oct 2002 21:57:36 -0400 (EDT) Date: Thu, 17 Oct 2002 11:41:27 +1000 From: Rusty Russell To: Greg KH Cc: davem@redhat.com, becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks Message-Id: <20021017114127.759e0e81.rusty@rustcorp.com.au> In-Reply-To: <20021016000706.GI16966@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.com> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; powerpc-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev On Tue, 15 Oct 2002 17:07:06 -0700 Greg KH wrote: > On Tue, Oct 15, 2002 at 01:28:28PM -0700, Greg KH wrote: > > On Tue, Oct 15, 2002 at 01:10:37PM -0700, David S. Miller wrote: > > > > > > I will not even look at the networking LSM bits until > > > CONFIG_SECURITY=n is available. > > > > Good enough reason for me, I'll start working on this. Help from the > > other LSM developers is appreciated :) > > Ok, this wasn't that tough... > > Here's a first cut at what will need to be changed. It's a patch > against Linus's latest BK tree. I only converted one hook (the ptrace > one), and this will not link, but will build and gives people an idea of > where I'm heading. > > David, does something like this look acceptable? > > With it, and CONFIG_SECURITY=n the size of the security/*.o files are > now: > text data bss dec hex filename > 138 0 0 138 8a security/built-in.o > > which I hope are a bit more to your liking :) > I still need an empty sys_security stub in order to link properly, > that's the only function needed. The extra #includes are needed as > some files were getting security.h picked up from shed.h in the past. > > I'll work on fixing up the rest of the hooks, and removing the external > reference to security_ops, and actually test this thing, later this > evening. > > thanks, > > greg k-h > > diff -Naur -X ../dontdiff bleeding_edge-2.5/arch/i386/kernel/ptrace.c lsm-2.5/arch/i386/kernel/ptrace.c > --- bleeding_edge-2.5/arch/i386/kernel/ptrace.c Tue Oct 15 16:47:14 2002 > +++ lsm-2.5/arch/i386/kernel/ptrace.c Tue Oct 15 16:41:44 2002 > @@ -160,8 +160,7 @@ > /* are we already being traced? */ > if (current->ptrace & PT_PTRACED) > goto out; > - ret = security_ops->ptrace(current->parent, current); > - if (ret) > + if ((ret = security_ptrace(current->parent, current))) Um, rather than one macro per security_ops function, how about: #ifdef CONFIG_SECURITY #define security_call(func, default_ret, ...) \ (security_ops->func(__VA_ARGS__)) #else #define security_call(func, default_ret, ...) \ (default_ret) #endif This also allows someone in the future to do: #define security_call(func, default_ret, ...) \ ({ if (try_inc_mod_count(security_ops->owner)) (security_ops->func(__VA_ARGS__)); else (default_ret); }) Of course, you could skip the default_ret arg, and use #ifndef CONFIG_SECURITY #define security_call(func, ...) \ (security_default_##func) #endif Then all the defaults can be in a header somewhere. Cheers, Rusty. -- there are those who do and those who hang on and you don't see too many doers quoting their contemporaries. -- Larry McVoy From cannon@toad.postech.ac.kr Wed Oct 16 19:29:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 19:29:39 -0700 (PDT) Received: from toad.postech.ac.kr (toad.postech.ac.kr [141.223.14.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H2TatG011249 for ; Wed, 16 Oct 2002 19:29:37 -0700 Received: (from cannon@localhost) by toad.postech.ac.kr (8.10.2+Sun/8.11.1) id g9H2TTO21279; Thu, 17 Oct 2002 11:29:29 +0900 (KST) Date: Thu, 17 Oct 2002 11:29:28 +0900 From: Hyochang Nam To: niv@us.ibm.com Cc: netdev@oss.sgi.com Subject: [Question] SMP for Linux Message-ID: <20021017112928.B20854@toad.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cannon@postech.ac.kr Precedence: bulk X-list: netdev Many people helped me to solve the interrupt distribution problem. We tested the throughput of Layer 3 forwarding on a SMP machine which equips two Zero proessor(2Ghz). This is our results: ------------------------- SMP | No SMP ------------------------- 230 Mbps | 330 Mbps ------------------------- We use RedHat Linux 8.0 (which uses Linux Kernel 2.4.18-14) and two intel Pro1000 Server Adopters. In the table, SMP means we use the kernel builted for SMP Machine, and "No SMP" means the kernel builted for single CPU mode. I expected that the SMP might show better throughput than "NO SMP" environments. But, contrary to my expectation, SMP showed poor results. I don't know what is my fault in the experiments. - Hyochang Nam From mcr@sandelman.ottawa.on.ca Wed Oct 16 19:48:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 19:48:27 -0700 (PDT) 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 g9H2mOtG014274 for ; Wed, 16 Oct 2002 19:48:25 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g9H2mCG06330 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 16 Oct 2002 22:48:18 -0400 (EDT) Received: from marajade.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 g9H2mAsL011897 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 16 Oct 2002 22:48:11 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9H2m6bf011892; Wed, 16 Oct 2002 22:48:07 -0400 Message-Id: <200210170248.g9H2m6bf011892@marajade.sandelman.ottawa.on.ca> To: design@lists.freeswan.org CC: netdev@oss.sgi.com Subject: FreeSWAN's pfkey_v2.c Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 16 Oct 2002 22:48:06 -0400 From: Michael Richardson X-archive-position: 737 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----- In our pfkey_v2.c, we had: struct proto_ops SOCKOPS_WRAPPED(pfkey_ops); ... pfkey_create() { sock->ops = &SOCKOPS_WRAPPED(pfkey_ops); } ... struct proto_ops SOCKOPS_WRAPPED(pfkey_ops) = { } #ifdef NETDEV_23 #include SOCKOPS_WRAP(pfkey, PF_KEY); #endif /* NETDEV_23 */ When building with -Werror, we get a fatal error when SMP is defined, because we get a pfkey_ops which is never used. I believe that the error is that we should not be initializing the sock->ops to the WRAPPED version, but rather to "pfkey_ops", so that we actually are using the wrapped functions which lock stuff. I.e. we never actually were using the interface which the SOCKOPS_WRAP() macro so meticulously created for us. We probably haven't hit a problem before, because we tend to run on uniprocessors a lot, and we also tend to have only one single threaded process (pluto) that talks PF_KEY. I am looking for confirmation from network stack people that my conclusions from reading of the macros in linux/net.h is correct. ] 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 iQCVAwUBPa4k44qHRg3pndX9AQHArwQAmePHXduPugmIQemek8PDx7spY82uN25u MlZu+uuuGK1k0YvOiOLJUyaCmhdXRGtYOKd+GoDHVX5NJsnI7AbJzTmhy2H8DjZI /gR8sblD3w6Q/Fi/M4jQvLdsNSWZVSoMR1tnsRLorfQva8C737LTJ8Ipa9KrnWNH qx/0EyQnQ3o= =6xM7 -----END PGP SIGNATURE----- From ak@suse.de Wed Oct 16 19:51:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 19:51:06 -0700 (PDT) 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 g9H2p4tG014843 for ; Wed, 16 Oct 2002 19:51:05 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 21CF51402F; Thu, 17 Oct 2002 04:50:59 +0200 (MEST) Date: Thu, 17 Oct 2002 04:50:54 +0200 From: Andi Kleen To: Michael Richardson Cc: design@lists.freeswan.org, netdev@oss.sgi.com Subject: Re: FreeSWAN's pfkey_v2.c Message-ID: <20021017045054.A405@wotan.suse.de> References: <200210170248.g9H2m6bf011892@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210170248.g9H2m6bf011892@marajade.sandelman.ottawa.on.ca> User-Agent: Mutt/1.3.22.1i X-archive-position: 738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev > I am looking for confirmation from network stack people that my conclusions > from reading of the macros in linux/net.h is correct. What you should actually do is to add explicit proper SMP locking. Then you don't need any SOCKOPS_WRAP hacks. -Andi From acme@conectiva.com.br Wed Oct 16 19:54:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 19:54:14 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H2sAtG015953 for ; Wed, 16 Oct 2002 19:54:12 -0700 Received: from [200.181.168.222] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 181zrn-00031N-00; Wed, 16 Oct 2002 23:54:27 -0200 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 896D81966C; Thu, 17 Oct 2002 02:53:47 +0000 (UTC) Date: Wed, 16 Oct 2002 23:53:47 -0300 From: Arnaldo Carvalho de Melo To: Andi Kleen Cc: Michael Richardson , design@lists.freeswan.org, netdev@oss.sgi.com Subject: Re: FreeSWAN's pfkey_v2.c Message-ID: <20021017025347.GF7541@conectiva.com.br> References: <200210170248.g9H2m6bf011892@marajade.sandelman.ottawa.on.ca> <20021017045054.A405@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021017045054.A405@wotan.suse.de> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme X-archive-position: 739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Thu, Oct 17, 2002 at 04:50:54AM +0200, Andi Kleen escreveu: > > I am looking for confirmation from network stack people that my conclusions > > from reading of the macros in linux/net.h is correct. > > What you should actually do is to add explicit proper SMP locking. > Then you don't need any SOCKOPS_WRAP hacks. yup, so that eventually we can kill this hackish bandaid. - Arnaldo From phillips@arcor.de Wed Oct 16 20:34:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 20:34:29 -0700 (PDT) Received: from starship (dsl-213-023-039-240.arcor-ip.net [213.23.39.240]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H3YLtG021252 for ; Wed, 16 Oct 2002 20:34:22 -0700 Received: from daniel by starship with local (Exim 3.36 #1 (Debian)) id 1821PX-0004Ob-00; Thu, 17 Oct 2002 05:33:23 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Daniel Phillips To: Rusty Russell , Greg KH Subject: Re: [RFC] change format of LSM hooks Date: Thu, 17 Oct 2002 05:33:23 +0200 X-Mailer: KMail [version 1.3.2] Cc: davem@redhat.com, becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org References: <20021015194545.GC15864@kroah.com> <20021016000706.GI16966@kroah.com> <20021017114127.759e0e81.rusty@rustcorp.com.au> In-Reply-To: <20021017114127.759e0e81.rusty@rustcorp.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-archive-position: 740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: phillips@arcor.de Precedence: bulk X-list: netdev On Thursday 17 October 2002 03:41, Rusty Russell wrote: > This also allows someone in the future to do: > > #define security_call(func, default_ret, ...) \ > ({ if (try_inc_mod_count(security_ops->owner)) > (security_ops->func(__VA_ARGS__)); > else > (default_ret); > }) Hopefully, dec_mod_count as well. -- Daniel From mcr@sandelman.ottawa.on.ca Wed Oct 16 20:58:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 16 Oct 2002 20:58:30 -0700 (PDT) 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 g9H3wQtG023194 for ; Wed, 16 Oct 2002 20:58:27 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g9H3wGG07145 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 16 Oct 2002 23:58:22 -0400 (EDT) Received: from marajade.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 g9H3wDsL012441 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 16 Oct 2002 23:58:15 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9H3w90j012436; Wed, 16 Oct 2002 23:58:12 -0400 Message-Id: <200210170358.g9H3w90j012436@marajade.sandelman.ottawa.on.ca> To: Andi Kleen cc: design@lists.freeswan.org, netdev@oss.sgi.com Subject: Re: FreeSWAN's pfkey_v2.c In-reply-to: Your message of "Thu, 17 Oct 2002 04:50:54 +0200." <20021017045054.A405@wotan.suse.de> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 16 Oct 2002 23:58:07 -0400 From: Michael Richardson X-archive-position: 741 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 >>>>> "Andi" == Andi Kleen writes: >> I am looking for confirmation from network stack people that my >> conclusions from reading of the macros in linux/net.h is correct. Andi> What you should actually do is to add explicit proper SMP locking. Andi> Then you don't need any SOCKOPS_WRAP hacks. Yes, that's a good idea, but it doesn't help me understand the code. ] 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"); [ From ja@ssi.bg Thu Oct 17 02:25:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 02:25:15 -0700 (PDT) Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9H9P3tG021754 for ; Thu, 17 Oct 2002 02:25:09 -0700 Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1]) by l.himel.bg (8.9.3/8.9.3) with ESMTP id MAA03293; Thu, 17 Oct 2002 12:24:31 +0300 Date: Thu, 17 Oct 2002 12:24:31 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@l To: "Thompson, Ian" cc: "'netdev@oss.sgi.com'" Subject: Re: ARP problem? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Wed, 16 Oct 2002, Thompson, Ian wrote: > I am trying to devlop some code to support an active failover case, so I > want two seperate devices on the same physical network. I have seen the May be you need support for alternative non-default routes: http://www.ssi.bg/~ja/#routes These patches will make the routing to use the two link routes for your subnet (not only the first one), I assume you are worrying about problems with the two links to the hub. > TIA, > -ian Regards -- Julian Anastasov From kiran@in.ibm.com Thu Oct 17 03:25:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 03:25:30 -0700 (PDT) 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 g9HAPRtG028592 for ; Thu, 17 Oct 2002 03:25:27 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HAPRtr036196; Thu, 17 Oct 2002 06:25:27 -0400 Received: from asterix.in.ibm.com (asterix.in.ibm.com [9.182.12.249]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9HAPmN7128558; Thu, 17 Oct 2002 04:25:49 -0600 Received: (from kirant@localhost) by asterix.in.ibm.com (8.11.2/8.11.2) id g9HATuo17091; Thu, 17 Oct 2002 15:59:56 +0530 Date: Thu, 17 Oct 2002 15:59:55 +0530 From: Ravikiran G Thirumalai To: netdev Cc: linux-kernel@vger.kernel.org Subject: Qdisc drops not being reported to user space Message-ID: <20021017155955.E20237@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kiran@in.ibm.com Precedence: bulk X-list: netdev Sometime back, I had posted a patch to report Qdisc drops under /proc/net/dev. I'd noticed that Qdisc.drops was not being reported for the default queuing discipline (pfifo_fast). I was told that my approach mucked SNMP data. I was also told that prio will be made the default queuing discipline and pfifo_fast will be done away with. Is this the case even now? will prio be made the default queuing disc in the 2.5 time frame? If not, any solution in sight to report Qdisc drops to userland? (I think there is a kernel patch and a patch for tc from Jamal). I have noticed Qdisc drops under webserver loads, and heavy tx loads (I used my proc reporting patch .. it did not break ifconfig atleast..). IMO It'd not be right if packets are being dropped by the kernel (default queuing discipline) and the unsuspecting admin has no means to find that out. IMHO It'd also not be fair to expect users to use CONFIG_NET_SCH_PRIO and add the prio qdisc before using a n/w interface just to be able to make out Qdisc drops. One more thing...IMHO, there must be some documentation somewhere .... tc man page (which doesn't exist as of now?) or atleast the readme which should indicate to the user that drops seen from ifconfig (packets dropped by the adapter) are different from packets dropped from the qdisc as shown by tc. Thanks, Kiran From ahu@outpost.ds9a.nl Thu Oct 17 03:31:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 03:31:27 -0700 (PDT) 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 g9HAVEtG029408 for ; Thu, 17 Oct 2002 03:31:14 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B8B183FDC; Thu, 17 Oct 2002 12:02:43 +0200 (CEST) Date: Thu, 17 Oct 2002 12:02:43 +0200 From: bert hubert To: Hyochang Nam Cc: niv@us.ibm.com, netdev@oss.sgi.com Subject: Re: [Question] SMP for Linux Message-ID: <20021017100243.GA6569@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Hyochang Nam , niv@us.ibm.com, netdev@oss.sgi.com References: <20021017112928.B20854@toad.postech.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021017112928.B20854@toad.postech.ac.kr> User-Agent: Mutt/1.3.28i X-archive-position: 744 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, Oct 17, 2002 at 11:29:28AM +0900, Hyochang Nam wrote: > Many people helped me to solve the interrupt distribution problem. > We tested the throughput of Layer 3 forwarding on a SMP machine > which equips two Zero proessor(2Ghz). This is our results: > ------------------------- > SMP | No SMP > ------------------------- > 230 Mbps | 330 Mbps > ------------------------- There is something called 'irq affinity' which may be interesting for you. See here: http://www.dell.com/us/en/esg/topics/power_ps1q02-morse.htm /proc/irq/?/smp_affinity > I expected that the SMP might show better throughput than "NO SMP" > environments. But, contrary to my expectation, SMP showed poor results. > I don't know what is my fault in the experiments. SMP is not always a win. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From Robert.Olsson@data.slu.se Thu Oct 17 04:54:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 04:54:09 -0700 (PDT) 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 g9HBs2tG008128 for ; Thu, 17 Oct 2002 04:54:03 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id OAA19331; Thu, 17 Oct 2002 14:00:59 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15790.42618.961289.506241@robur.slu.se> Date: Thu, 17 Oct 2002 14:00:58 +0200 To: bert hubert Cc: Hyochang Nam , niv@us.ibm.com, netdev@oss.sgi.com Subject: Re: [Question] SMP for Linux In-Reply-To: <20021017100243.GA6569@outpost.ds9a.nl> References: <20021017112928.B20854@toad.postech.ac.kr> <20021017100243.GA6569@outpost.ds9a.nl> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 745 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 bert hubert writes: > On Thu, Oct 17, 2002 at 11:29:28AM +0900, Hyochang Nam wrote: > > Many people helped me to solve the interrupt distribution problem. > > We tested the throughput of Layer 3 forwarding on a SMP machine > > which equips two Zero proessor(2Ghz). This is our results: > > ------------------------- > > SMP | No SMP > > ------------------------- > > 230 Mbps | 330 Mbps > > ------------------------- > > There is something called 'irq affinity' which may be interesting for you. > See here: http://www.dell.com/us/en/esg/topics/power_ps1q02-morse.htm > > /proc/irq/?/smp_affinity Hello! Not always good for routing... Were you still get the problem were one interface is the output device from devices bound to different CPU's. TX-ring can hold skb's from many CPU's so a lot of cache bouncing happens when kfree and skb_headerinit is run. I've played with some to code to re-route the skb freeing to the CPU where it was processed this to minimize cache bouncing and I've seen some good effects of this. And to be fair with SMP you should compare multiple flows to see if you can get any aggregated performance from SMP. An experiment... Single flow eth0->eth1 w. e1000 NAPI. 2.4.20-pre5. PIII @ 2x933 MHz Bound = eth0, eth1 is bound to same CPU. Split = eth0, eth1 is bound to differnt CPU's. Free = unbound. SMP routing performance ======================= Bound Free Split "kfree-route" --------------------------------- 421 354 331 kpps 491 348 317 437 kpps w. skb recycling UP routing performance ====================== 494 kpps 593 kpps w. skb recycling With SMP test "kfree-route" the interfaces are not bound to any CPU still we now getting closer to "bound" (where both eth0, eth1 is bond to the same CPU). But yes UP is gives higher numbers in this single stream tests. Aggregated throughput tests are to be done. Cheers. --ro From hch@infradead.org Thu Oct 17 06:22:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 06:22:17 -0700 (PDT) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HDMAtG016071 for ; Thu, 17 Oct 2002 06:22:11 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 182Aaz-00066A-00; Thu, 17 Oct 2002 14:21:49 +0100 Date: Thu, 17 Oct 2002 14:21:49 +0100 From: Christoph Hellwig To: Greg KH Cc: "David S. Miller" , becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks Message-ID: <20021017142149.A23181@infradead.org> Mail-Followup-To: Christoph Hellwig , Greg KH , "David S. Miller" , becker@scyld.com, jmorris@intercode.com.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021016000706.GI16966@kroah.com>; from greg@kroah.com on Tue, Oct 15, 2002 at 05:07:06PM -0700 X-archive-position: 746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Tue, Oct 15, 2002 at 05:07:06PM -0700, Greg KH wrote: > On Tue, Oct 15, 2002 at 01:28:28PM -0700, Greg KH wrote: > > On Tue, Oct 15, 2002 at 01:10:37PM -0700, David S. Miller wrote: > > > > > > I will not even look at the networking LSM bits until > > > CONFIG_SECURITY=n is available. BTW, there's another big issues with LSM: so far all those hook have no user in a mergeable shape. For all other additions there is a strong need to present something mergable but LSM doesn't. IMHO we should require a pointer to a module in mergaable shape (i.e. certainly not selinux) for each new hook addition. From ajtuomin@tml.hut.fi Thu Oct 17 09:27:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 09:27:05 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HGQxtG002281 for ; Thu, 17 Oct 2002 09:27:00 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id TAA08716 for ; Thu, 17 Oct 2002 19:26:58 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma008696; Thu, 17 Oct 02 19:26:34 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HGQWMl025395; Thu, 17 Oct 2002 19:26:32 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HGQWF5017972; Thu, 17 Oct 2002 19:26:32 +0300 (EEST) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g9HGQPBY017971; Thu, 17 Oct 2002 19:26:25 +0300 (EEST) Date: Thu, 17 Oct 2002 19:26:25 +0300 From: Antti Tuominen To: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Cc: yoshfuji@wide.ad.jp, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com Subject: [PATCHSET] Mobile IPv6 for 2.5.43 Message-ID: <20021017162624.GC16370@morphine.tml.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev Hello Alexey, Dave, everyone, We are resending our code for kernel inclusion consideration. I hope with this submission we have addressed all the concerns raised on the list (i.e. draft revision) as well as offline (splitting the patch to smaller chunks). To Pekka and Hideaki, Intermediate revision of the specification "Draft 18++" appeared a few days ago, which addressed most of the issues with earlier drafts (16, 17, 18). This made it possible to update our code to something usable (later than 15). This patch set has support for most of it. To Alexey, (and everyone else) The patch has been split for easier reading as follows: ipv6_tunnel.patch 6over6 tunneling network_mods.patch Modifications to network code and hooks mipv6_cn_support.patch Correspondent node support (+common code) mipv6_mn_support.patch Mobile node support (+common code with HA) mipv6_ha_support.patch Home agent support The patches are incremental, so they must be applied in this order. Patches are not included in this mail, but you can find them at: http://www.mipl.mediapoli.com/patches/ipv6_tunnel.patch http://www.mipl.mediapoli.com/patches/network_mods.patch http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch Userspace tools are available at: http://www.mipl.mediapoli.com/download/mipv6-tools/ Regards, Antti -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From greg@kroah.com Thu Oct 17 09:56:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 09:56:36 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HGu0tG005170 for ; Thu, 17 Oct 2002 09:56:29 -0700 Received: (qmail 31570 invoked by uid 500); 17 Oct 2002 16:55:42 -0000 Date: Thu, 17 Oct 2002 09:55:41 -0700 From: Greg KH To: Christoph Hellwig , netdev@oss.sgi.com, linux-security-module@wirex.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] change format of LSM hooks Message-ID: <20021017165541.GC31464@kroah.com> References: <20021015194545.GC15864@kroah.com> <20021015.124502.130514745.davem@redhat.com> <20021015201209.GE15864@kroah.com> <20021015.131037.96602290.davem@redhat.com> <20021015202828.GG15864@kroah.com> <20021016000706.GI16966@kroah.com> <20021017142149.A23181@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021017142149.A23181@infradead.org> User-Agent: Mutt/1.4i X-archive-position: 748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Thu, Oct 17, 2002 at 02:21:49PM +0100, Christoph Hellwig wrote: > On Tue, Oct 15, 2002 at 05:07:06PM -0700, Greg KH wrote: > > On Tue, Oct 15, 2002 at 01:28:28PM -0700, Greg KH wrote: > > > On Tue, Oct 15, 2002 at 01:10:37PM -0700, David S. Miller wrote: > > > > > > > > I will not even look at the networking LSM bits until > > > > CONFIG_SECURITY=n is available. > > BTW, there's another big issues with LSM: so far all those hook > have no user in a mergeable shape. For all other additions > there is a strong need to present something mergable but LSM > doesn't. IMHO we should require a pointer to a module in mergaable > shape (i.e. certainly not selinux) for each new hook addition. Heh, require this, and oops, all of the hooks disappear :) Seriously, no, I don't agree with this. SELinux is currently being audited by a number of different companies (include some Linux distros), and after that happens, and the code is cleaned up, I think they will probably want their module merged (but I don't speak for them at all.) As for the other modules, I think the OWL-based one is good enough right now, and I have a very simple module that is in the November issue of Linux Journal that is probably clean enough to merge. thanks, greg k-h From yoshfuji@linux-ipv6.org Thu Oct 17 10:18:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 10:18:30 -0700 (PDT) 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 g9HHINtG007897 for ; Thu, 17 Oct 2002 10:18:23 -0700 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 g9HHI3lw005291; Fri, 18 Oct 2002 02:18:03 +0900 Date: Fri, 18 Oct 2002 02:18:02 +0900 (JST) Message-Id: <20021018.021802.87011078.yoshfuji@linux-ipv6.org> To: ajtuomin@morphine.tml.hut.fi Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021017162624.GC16370@morphine.tml.hut.fi> References: <20021017162624.GC16370@morphine.tml.hut.fi> 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-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: 749 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 <20021017162624.GC16370@morphine.tml.hut.fi> (at Thu, 17 Oct 2002 19:26:25 +0300), Antti Tuominen says: > The patch has been split for easier reading as follows: > > ipv6_tunnel.patch 6over6 tunneling > network_mods.patch Modifications to network code and hooks Several comments. [ipv6_tunnel] I think this is almost ok. 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/. 2. Please put outer address to hardware address in dev. Note: you need to modify SIOxxx ioctls too not to overrun! [network_mods etc.] 1. Too many hooks, and many duplicate codes in ipv6 stack and mipv6 stack. (prefix handler, header parser, ndisc handler etc...) more comment will come later... > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch Well, I can't find them. I hope they'll be available when I wake up tomorrow... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From kumarkr@us.ibm.com Thu Oct 17 10:25:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 10:25:03 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HHOstI008788 for ; Thu, 17 Oct 2002 10:25:01 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HHNu7U083924; Thu, 17 Oct 2002 13:23:56 -0400 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 g9HHNqTx016000; Thu, 17 Oct 2002 13:23:52 -0400 Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, pekkas@netcore.fi, torvalds@transmeta.com, "Venkata Jagana" , yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 17 Oct 2002 10:22:21 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 10/17/2002 11:23:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp X-archive-position: 750 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 > > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch > > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch > > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch > > Well, I can't find them. I hope they'll be available when I wake up > tomorrow... Just replace "_" with "-". - KK YOSHIFUJI Hideaki / 吉藤英明 To: ajtuomin@morphine.tml.hut.fi linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, Venkata Sent by: Jagana/Beaverton/IBM@IBMUS, yoshfuji@linux-ipv6.org netdev-bounce@oss Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 .sgi.com 10/17/2002 10:18 AM In article <20021017162624.GC16370@morphine.tml.hut.fi> (at Thu, 17 Oct 2002 19:26:25 +0300), Antti Tuominen says: > The patch has been split for easier reading as follows: > > ipv6_tunnel.patch 6over6 tunneling > network_mods.patch Modifications to network code and hooks Several comments. [ipv6_tunnel] I think this is almost ok. 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/. 2. Please put outer address to hardware address in dev. Note: you need to modify SIOxxx ioctls too not to overrun! [network_mods etc.] 1. Too many hooks, and many duplicate codes in ipv6 stack and mipv6 stack. (prefix handler, header parser, ndisc handler etc...) more comment will come later... > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch Well, I can't find them. I hope they'll be available when I wake up tomorrow... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From J_Fraser@bit-net.com Thu Oct 17 10:28:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 10:28:04 -0700 (PDT) Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HHS1tG009454 for ; Thu, 17 Oct 2002 10:28:02 -0700 Received: from CONCORDIA (mail.crossbeamsys.com [63.96.67.2]) by mail.bit-net.com (8.9.3/8.9.2) with SMTP id NAA29098 for ; Thu, 17 Oct 2002 13:28:01 -0400 (EDT) (envelope-from J_Fraser@bit-net.com) Reply-To: From: "Jon Fraser" To: Subject: RE: [Question] SMP for Linux Date: Thu, 17 Oct 2002 13:28:38 -0400 Message-ID: <008601c27602$a1ad8170$3701020a@CONCORDIA> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15790.42618.961289.506241@robur.slu.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-archive-position: 751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: J_Fraser@bit-net.com Precedence: bulk X-list: netdev What was your cpu utilization like in the bound vs split scenarios? Does your e1000 driver have transmit interrupts enabled or disabled? I'd be really interested to see the results with two flows in opposite directions. Jon > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com]On > Behalf Of Robert Olsson > Sent: Thursday, October 17, 2002 8:01 AM > To: bert hubert > Cc: Hyochang Nam; niv@us.ibm.com; netdev@oss.sgi.com > Subject: Re: [Question] SMP for Linux > > > > bert hubert writes: > > On Thu, Oct 17, 2002 at 11:29:28AM +0900, Hyochang Nam wrote: > > > Many people helped me to solve the interrupt > distribution problem. > > > We tested the throughput of Layer 3 forwarding on a SMP machine > > > which equips two Zero proessor(2Ghz). This is our results: > > > ------------------------- > > > SMP | No SMP > > > ------------------------- > > > 230 Mbps | 330 Mbps > > > ------------------------- > > > > There is something called 'irq affinity' which may be > interesting for you. > > See here: > http://www.dell.com/us/en/esg/topics/power_ps1q02-morse.htm > > > > /proc/irq/?/smp_affinity > > Hello! > > Not always good for routing... Were you still get the > problem were one > interface is the output device from devices bound to different CPU's. > > TX-ring can hold skb's from many CPU's so a lot of cache > bouncing happens > when kfree and skb_headerinit is run. > > I've played with some to code to re-route the skb freeing to the CPU > where it was processed this to minimize cache bouncing and I've seen > some good effects of this. > > And to be fair with SMP you should compare multiple flows to > see if you > can get any aggregated performance from SMP. > > An experiment... > > Single flow eth0->eth1 w. e1000 NAPI. 2.4.20-pre5. PIII @ 2x933 MHz > > Bound = eth0, eth1 is bound to same CPU. > Split = eth0, eth1 is bound to differnt CPU's. > Free = unbound. > > SMP routing performance > ======================= > > Bound Free Split "kfree-route" > --------------------------------- > 421 354 331 kpps > 491 348 317 437 kpps w. skb recycling > > > UP routing performance > ====================== > 494 kpps > 593 kpps w. skb recycling > > > With SMP test "kfree-route" the interfaces are not bound to > any CPU still > we now getting closer to "bound" (where both eth0, eth1 is > bond to the same > CPU). > > But yes UP is gives higher numbers in this single stream > tests. Aggregated > throughput tests are to be done. > > Cheers. > > --ro > > From kumarkr@us.ibm.com Thu Oct 17 10:47:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 10:47:52 -0700 (PDT) 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 g9HHlntG026501 for ; Thu, 17 Oct 2002 10:47:49 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HHlYtt037058; Thu, 17 Oct 2002 13:47:34 -0400 Received: from d03nm801.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 g9HHlVs5024452; Thu, 17 Oct 2002 11:47:33 -0600 Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 To: yoshfuji@linux-ipv6.org Cc: ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi, torvalds@transmeta.com, "Venkata Jagana" , yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 17 Oct 2002 10:46:00 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 10/17/2002 11:47:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp X-archive-position: 752 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 yoshifuji, > [network_mods etc.] > > 1. Too many hooks, > and many duplicate codes in ipv6 stack and mipv6 stack. > (prefix handler, header parser, ndisc handler etc...) What do you mean about having too many hooks ? Eg. prefix handler, you need to have a hook in the receive of router advertisement to do this. This is minimum hooks :-). Also, some of the ndisc handlers evaluate to NULL code for both regular IPv6 code (unless you have configured mobility) as well as some components of Mobile IPv6. Eg ndisc_mipv6_mn_solicit_ha() evaluates to NULL on HA and CN, but is a function call on every MN node. So I don't understand your concern here. Thanks, - KK YOSHIFUJI Hideaki / 吉藤英明 To: ajtuomin@morphine.tml.hut.fi linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, Venkata Sent by: Jagana/Beaverton/IBM@IBMUS, yoshfuji@linux-ipv6.org netdev-bounce@oss Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 .sgi.com 10/17/2002 10:18 AM In article <20021017162624.GC16370@morphine.tml.hut.fi> (at Thu, 17 Oct 2002 19:26:25 +0300), Antti Tuominen says: > The patch has been split for easier reading as follows: > > ipv6_tunnel.patch 6over6 tunneling > network_mods.patch Modifications to network code and hooks Several comments. [ipv6_tunnel] I think this is almost ok. 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/. 2. Please put outer address to hardware address in dev. Note: you need to modify SIOxxx ioctls too not to overrun! [network_mods etc.] 1. Too many hooks, and many duplicate codes in ipv6 stack and mipv6 stack. (prefix handler, header parser, ndisc handler etc...) more comment will come later... > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch Well, I can't find them. I hope they'll be available when I wake up tomorrow... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From mk@karaba.org Thu Oct 17 10:57:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 10:57:18 -0700 (PDT) Received: from zanzibar.karaba.org (karaba.org [218.219.152.88] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HHvAtG027565 for ; Thu, 17 Oct 2002 10:57:12 -0700 Received: from [3ffe:501:1057:710::1] (helo=hyakusiki.karaba.org.karaba.org) by zanzibar.karaba.org with esmtp (Exim 3.35 #1 (Debian)) id 182Esj-0007ns-00; Fri, 18 Oct 2002 02:56:25 +0900 Date: Fri, 18 Oct 2002 02:56:33 +0900 Message-ID: From: Mitsuru KANDA To: ajtuomin@morphine.tml.hut.fi Cc: yoshfuji@linux-ipv6.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: <20021018.021802.87011078.yoshfuji@linux-ipv6.org> References: <20021017162624.GC16370@morphine.tml.hut.fi> <20021018.021802.87011078.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-archive-position: 753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mk@linux-ipv6.org Precedence: bulk X-list: netdev > > The patch has been split for easier reading as follows: > > > > ipv6_tunnel.patch 6over6 tunneling > > network_mods.patch Modifications to network code and hooks > > Several comments. > > [ipv6_tunnel] > > I think this is almost ok. I think so. I know ipv6_tunnel is stable as I use. > > 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/. > 2. Please put outer address to hardware address in dev. > Note: you need to modify SIOxxx ioctls too not to overrun! plus: (maybe not whole kernel issue) It is important to integrate your ipv6tunnel command into ifconfig(8) and/or ip(8). Regards, -mk From pekkas@netcore.fi Thu Oct 17 13:15:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 13:15:53 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HKFotG007940 for ; Thu, 17 Oct 2002 13:15:51 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9HKFi428166 for ; Thu, 17 Oct 2002 23:15:44 +0300 Date: Thu, 17 Oct 2002 23:15:44 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: Re: Implementation worries about default address selection (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 755 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 Wed, 16 Oct 2002, Pekka Savola wrote: > There were some worries about default address selection performance. > > This is one person's (BSD implementer) has noticed, and it doesn't look > *too* bad for now. Oh, Microsoft reported they store the source address in destination cache for speed, which was pretty close to what Alexey suggested. -- 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 pekkas@netcore.fi Thu Oct 17 13:14:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 13:14:57 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HKEntG007690 for ; Thu, 17 Oct 2002 13:14:50 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9HKEWx28148; Thu, 17 Oct 2002 23:14:32 +0300 Date: Thu, 17 Oct 2002 23:14:32 +0300 (EEST) From: Pekka Savola To: Antti Tuominen cc: davem@redhat.com, , , , , , Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: <20021017162624.GC16370@morphine.tml.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 754 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, 17 Oct 2002, Antti Tuominen wrote: > Intermediate revision of the specification "Draft 18++" appeared a few > days ago, which addressed most of the issues with earlier drafts (16, > 17, 18). This made it possible to update our code to something usable > (later than 15). This patch set has support for most of it. Sounds great. Hopefully it slows down a bit from being a moving target. > To Alexey, (and everyone else) > > The patch has been split for easier reading as follows: > > ipv6_tunnel.patch 6over6 tunneling > network_mods.patch Modifications to network code and hooks > mipv6_cn_support.patch Correspondent node support (+common code) > mipv6_mn_support.patch Mobile node support (+common code with HA) > mipv6_ha_support.patch Home agent support I didn't look at these that much, but I'll make two generic observations: 1) current tunneling (including sanity checks which are, I believe, a bit non-existant at the moment) should be generalized to handle v6-in-v6 and v6-in-v4 tunneling anyway. Not sure if this is the right way, but that's IMO one priority item. 2) without IPSEC, there is no way to secure MN-HA traffic. Therefore I think the first priority is being able to support Correspondent Node behaviour. I belive Alexey, Davem et al are best to justify whether this feels like a right approach. Having IPSEC + MIPv6 in 2.6 series would be Really Cool, though :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From niv@us.ibm.com Thu Oct 17 14:49:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 14:49:14 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HLn9tG017283 for ; Thu, 17 Oct 2002 14:49:09 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HLn8sm040792; Thu, 17 Oct 2002 17:49:08 -0400 Received: from smtp.linux.ibm.com (ltc-eth1000.torolab.ibm.com [9.26.4.197]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9HLn7ft239696; Thu, 17 Oct 2002 15:49:07 -0600 Received: from imap.linux.ibm.com (imap.linux.ibm.com [9.27.103.44]) by smtp.linux.ibm.com (Postfix) with ESMTP id 20E1D3FE06; Thu, 17 Oct 2002 17:49:07 -0400 (EDT) Received: from w-nivedita.beaverton.ibm.com (unknown [9.47.18.15]) by imap.linux.ibm.com (Postfix) with ESMTP id 3A5947C017; Thu, 17 Oct 2002 17:49:06 -0400 (EDT) Date: Thu, 17 Oct 2002 14:49:04 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: nivedita@w-nivedita.beaverton.ibm.com To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [Patch 2.5.43] IpInDelivers, IpInDiscards Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 756 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 This patch cleans up the use of the SNMP stats counters IpInDelivers and IpInDiscards (and the v6 counterparts). A patch to address some of this had been submitted a while ago by Mark Price. Specifically this patch: - removes increments of IpInDelivers and IpInDiscards from upper level protocols and moves them to the IP layer. (upper layer protocols neednt know whether it was ip or ip6 that delivered the packet (eg what we might have in sctp)) - it also eliminates the subsequent atomic decrement of IpInDelivers when UDP drops a packet and the current duplicate incrementing of IpInDelivers for multicast packets. - leaves drops in raw sockets unaccounted for, at the moment. (that, along with remaining stats stuff will be addressed in subsequent patches if this is approved) thanks, Nivedita diff -urN linux-2.5.43/net/ipv4/ip_input.c linux-2.5.43s1/net/ipv4/ip_input.c --- linux-2.5.43/net/ipv4/ip_input.c Tue Oct 15 20:27:12 2002 +++ linux-2.5.43s1/net/ipv4/ip_input.c Thu Oct 17 14:23:51 2002 @@ -237,11 +237,13 @@ protocol = -ret; goto resubmit; } + IP_INC_STATS_BH(IpInDelivers); } else { if (!raw_sk) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); - } + } else + IP_INC_STATS_BH(IpInDelivers); kfree_skb(skb); } } @@ -304,8 +306,10 @@ --ANK (980813) */ - if (skb_cow(skb, skb_headroom(skb))) + if (skb_cow(skb, skb_headroom(skb))) { + IP_INC_STATS_BH(IpInDiscards); goto drop; + } iph = skb->nh.iph; if (ip_options_compile(NULL, skb)) @@ -353,8 +357,10 @@ IP_INC_STATS_BH(IpInReceives); - if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) { + IP_INC_STATS_BH(IpInDiscards); goto out; + } if (!pskb_may_pull(skb, sizeof(struct iphdr))) goto inhdr_error; diff -urN linux-2.5.43/net/ipv4/raw.c linux-2.5.43s1/net/ipv4/raw.c --- linux-2.5.43/net/ipv4/raw.c Tue Oct 15 20:27:08 2002 +++ linux-2.5.43s1/net/ipv4/raw.c Thu Oct 17 09:55:03 2002 @@ -226,12 +226,11 @@ /* Charge it to the socket. */ if (sock_queue_rcv_skb(sk, skb) < 0) { - IP_INC_STATS(IpInDiscards); + /* FIXME: increment a raw drops counter here */ kfree_skb(skb); return NET_RX_DROP; } - IP_INC_STATS(IpInDelivers); return NET_RX_SUCCESS; } diff -urN linux-2.5.43/net/ipv4/tcp_ipv4.c linux-2.5.43s1/net/ipv4/tcp_ipv4.c --- linux-2.5.43/net/ipv4/tcp_ipv4.c Tue Oct 15 20:27:50 2002 +++ linux-2.5.43s1/net/ipv4/tcp_ipv4.c Wed Oct 16 18:39:30 2002 @@ -1674,8 +1674,6 @@ goto discard; #endif /* CONFIG_FILTER */ - IP_INC_STATS_BH(IpInDelivers); - if (sk->state == TCP_ESTABLISHED) { /* Fast path */ TCP_CHECK_TIMER(sk); if (tcp_rcv_established(sk, skb, skb->h.th, skb->len)) diff -urN linux-2.5.43/net/ipv4/udp.c linux-2.5.43s1/net/ipv4/udp.c --- linux-2.5.43/net/ipv4/udp.c Tue Oct 15 20:27:19 2002 +++ linux-2.5.43s1/net/ipv4/udp.c Wed Oct 16 19:12:40 2002 @@ -819,8 +819,6 @@ if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if (__udp_checksum_complete(skb)) { UDP_INC_STATS_BH(UdpInErrors); - IP_INC_STATS_BH(IpInDiscards); - ip_statistics[smp_processor_id()*2].IpInDelivers--; kfree_skb(skb); return -1; } @@ -830,8 +828,6 @@ if (sock_queue_rcv_skb(sk,skb)<0) { UDP_INC_STATS_BH(UdpInErrors); - IP_INC_STATS_BH(IpInDiscards); - ip_statistics[smp_processor_id()*2].IpInDelivers--; kfree_skb(skb); return -1; } @@ -915,8 +911,6 @@ u32 daddr = skb->nh.iph->daddr; int len = skb->len; - IP_INC_STATS_BH(IpInDelivers); - /* * Validate the packet and the UDP length. */ diff -urN linux-2.5.43/net/ipv6/ip6_input.c linux-2.5.43s1/net/ipv6/ip6_input.c --- linux-2.5.43/net/ipv6/ip6_input.c Tue Oct 15 20:28:32 2002 +++ linux-2.5.43s1/net/ipv6/ip6_input.c Thu Oct 17 09:46:56 2002 @@ -60,8 +60,10 @@ IP6_INC_STATS_BH(Ip6InReceives); - if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) { + IP6_INC_STATS_BH(Ip6InDiscards); goto out; + } /* Store incoming device index. When the packet will be queued, we cannot refer to skb->dev anymore. @@ -175,11 +177,13 @@ nexthdr = -ret; goto resubmit; } + IP6_INC_STATS_BH(Ip6InDelivers); } else { if (!raw_sk) { IP6_INC_STATS_BH(Ip6InUnknownProtos); icmpv6_param_prob(skb, ICMPV6_UNK_NEXTHDR, nhoff); - } + } else + IP6_INC_STATS_BH(Ip6InDelivers); kfree_skb(skb); } diff -urN linux-2.5.43/net/ipv6/raw.c linux-2.5.43s1/net/ipv6/raw.c --- linux-2.5.43/net/ipv6/raw.c Tue Oct 15 20:27:54 2002 +++ linux-2.5.43s1/net/ipv6/raw.c Thu Oct 17 10:05:10 2002 @@ -275,7 +275,7 @@ #if defined(CONFIG_FILTER) if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } @@ -284,12 +284,11 @@ #endif /* Charge it to the socket. */ if (sock_queue_rcv_skb(sk,skb)<0) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } - IP6_INC_STATS_BH(Ip6InDelivers); return 0; } @@ -327,7 +326,7 @@ if (inet->hdrincl) { if (skb->ip_summed != CHECKSUM_UNNECESSARY && (unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } @@ -427,7 +426,7 @@ as some normal condition. */ err = (flags&MSG_DONTWAIT) ? -EAGAIN : -EHOSTUNREACH; - IP6_INC_STATS_USER(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ goto out_free; } diff -urN linux-2.5.43/net/ipv6/tcp_ipv6.c linux-2.5.43s1/net/ipv6/tcp_ipv6.c --- linux-2.5.43/net/ipv6/tcp_ipv6.c Tue Oct 15 20:28:23 2002 +++ linux-2.5.43s1/net/ipv6/tcp_ipv6.c Wed Oct 16 18:40:38 2002 @@ -1470,8 +1470,6 @@ * is currently called with bh processing disabled. */ - IP6_INC_STATS_BH(Ip6InDelivers); - /* Do Stevens' IPV6_PKTOPTIONS. Yes, guys, it is the only place in our code, where we diff -urN linux-2.5.43/net/ipv6/udp.c linux-2.5.43s1/net/ipv6/udp.c --- linux-2.5.43/net/ipv6/udp.c Tue Oct 15 20:27:48 2002 +++ linux-2.5.43s1/net/ipv6/udp.c Wed Oct 16 18:52:38 2002 @@ -512,7 +512,6 @@ if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { UDP6_INC_STATS_BH(UdpInErrors); - IP6_INC_STATS_BH(Ip6InDiscards); kfree_skb(skb); return 0; } @@ -521,11 +520,9 @@ #endif if (sock_queue_rcv_skb(sk,skb)<0) { UDP6_INC_STATS_BH(UdpInErrors); - IP6_INC_STATS_BH(Ip6InDiscards); kfree_skb(skb); return 0; } - IP6_INC_STATS_BH(Ip6InDelivers); UDP6_INC_STATS_BH(UdpInDatagrams); return 0; } From vnuorval@morphine.tml.hut.fi Thu Oct 17 14:57:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 14:57:42 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HLvctG018381; Thu, 17 Oct 2002 14:57:39 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id AAA11786; Fri, 18 Oct 2002 00:57:37 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma011772; Fri, 18 Oct 02 00:57:23 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HLvMMl027501; Fri, 18 Oct 2002 00:57:22 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HLvMF5018595; Fri, 18 Oct 2002 00:57:22 +0300 (EEST) Received: from localhost (vnuorval@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id g9HLv7rP018592; Fri, 18 Oct 2002 00:57:07 +0300 (EEST) Date: Fri, 18 Oct 2002 00:57:07 +0300 (EEST) From: Ville Nuorvala To: Krishna Kumar cc: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= , , , , , , , , , Venkata Jagana Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Thu, 17 Oct 2002, Krishna Kumar wrote: > > > > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch > > > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch > > > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch > > > > Well, I can't find them. I hope they'll be available when I wake up > > tomorrow... > > Just replace "_" with "-". > > - KK Thanks Krishna and yoshifuji! The files are now renamed properly. - Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tml.hut.fi, phone: +358 (0)9 451 5257 From davem@redhat.com Thu Oct 17 15:32:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 15:32:36 -0700 (PDT) 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 g9HMWWtG021676 for ; Thu, 17 Oct 2002 15:32:32 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA02339; Thu, 17 Oct 2002 15:24:53 -0700 Date: Thu, 17 Oct 2002 15:24:52 -0700 (PDT) Message-Id: <20021017.152452.43031634.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [Patch 2.5.43] IpInDelivers, IpInDiscards 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: 758 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: Thu, 17 Oct 2002 14:49:04 -0700 (PDT) This patch cleans up the use of the SNMP stats counters IpInDelivers and IpInDiscards (and the v6 counterparts). A patch to address some of this had been submitted a while ago by Mark Price. I agree with with. I just have some minor troubles with some of the changes to ip_input.c Specifically, the ip_rcv_finish() and ip_rcv() counter bumps should all move to right below the drop: label which exists in both functions. Make this fixup, and I'll apply the patch. Thanks. From vnuorval@morphine.tml.hut.fi Thu Oct 17 15:51:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 15:51:37 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HMpXtG023517 for ; Thu, 17 Oct 2002 15:51:33 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id BAA12150 for ; Fri, 18 Oct 2002 01:51:32 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma012139; Fri, 18 Oct 02 01:51:30 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HMpTMl027786; Fri, 18 Oct 2002 01:51:29 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HMpTF5018669; Fri, 18 Oct 2002 01:51:29 +0300 (EEST) Received: from localhost (vnuorval@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id g9HMpO5P018666; Fri, 18 Oct 2002 01:51:24 +0300 (EEST) Date: Fri, 18 Oct 2002 01:51:24 +0300 (EEST) From: Ville Nuorvala To: Antti Tuominen cc: davem@redhat.com, , , , , , , Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: <20021017162624.GC16370@morphine.tml.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Thu, 17 Oct 2002, Antti Tuominen wrote: > Userspace tools are available at: > http://www.mipl.mediapoli.com/download/mipv6-tools/ There was a file missing from the original package, so please download the updated version. -Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tml.hut.fi, phone: +358 (0)9 451 5257 From niv@us.ibm.com Thu Oct 17 16:48:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 16:48:16 -0700 (PDT) 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 g9HNmBtG028574 for ; Thu, 17 Oct 2002 16:48:11 -0700 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9HNm2UF162884; Thu, 17 Oct 2002 19:48:02 -0400 Received: from smtp.linux.ibm.com (ltc-eth1000.torolab.ibm.com [9.26.4.197]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9HNlxOj018776; Thu, 17 Oct 2002 19:48:00 -0400 Received: from imap.linux.ibm.com (imap.linux.ibm.com [9.27.103.44]) by smtp.linux.ibm.com (Postfix) with ESMTP id 909533FE06; Thu, 17 Oct 2002 19:48:01 -0400 (EDT) Received: from w-nivedita.beaverton.ibm.com (unknown [9.47.18.15]) by imap.linux.ibm.com (Postfix) with ESMTP id A5F817C017; Thu, 17 Oct 2002 19:48:00 -0400 (EDT) Date: Thu, 17 Oct 2002 16:47:58 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: nivedita@w-nivedita.beaverton.ibm.com To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [Patch 2.5.43] IpInDelivers, IpInDiscards Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 760 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 I made the changes, I think this is what you wanted.. If not, I'll gladly make any changes necessary.. However, note that IpInDiscards is meant to be mutually exclusive with IpInHdrErrors. I interpreted it to be a counter for stuff like being out of memory etc, based on what the MIB spec says: "The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly." However, I dont really object to it being a catchall for IP discards.. thanks, Nivedita diff -urN linux-2.5.43/net/ipv4/ip_input.c linux-2.5.43s1/net/ipv4/ip_input.c --- linux-2.5.43/net/ipv4/ip_input.c Tue Oct 15 20:27:12 2002 +++ linux-2.5.43s1/net/ipv4/ip_input.c Thu Oct 17 16:11:47 2002 @@ -237,11 +237,13 @@ protocol = -ret; goto resubmit; } + IP_INC_STATS_BH(IpInDelivers); } else { if (!raw_sk) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); - } + } else + IP_INC_STATS_BH(IpInDelivers); kfree_skb(skb); } } @@ -306,6 +308,7 @@ if (skb_cow(skb, skb_headroom(skb))) goto drop; + iph = skb->nh.iph; if (ip_options_compile(NULL, skb)) @@ -334,6 +337,7 @@ inhdr_error: IP_INC_STATS_BH(IpInHdrErrors); drop: + IP_INC_STATS_BH(IpInDiscards); kfree_skb(skb); return NET_RX_DROP; } @@ -407,6 +411,7 @@ drop: kfree_skb(skb); out: + IP_INC_STATS_BH(IpInDiscards); return NET_RX_DROP; } diff -urN linux-2.5.43/net/ipv4/raw.c linux-2.5.43s1/net/ipv4/raw.c --- linux-2.5.43/net/ipv4/raw.c Tue Oct 15 20:27:08 2002 +++ linux-2.5.43s1/net/ipv4/raw.c Thu Oct 17 09:55:03 2002 @@ -226,12 +226,11 @@ /* Charge it to the socket. */ if (sock_queue_rcv_skb(sk, skb) < 0) { - IP_INC_STATS(IpInDiscards); + /* FIXME: increment a raw drops counter here */ kfree_skb(skb); return NET_RX_DROP; } - IP_INC_STATS(IpInDelivers); return NET_RX_SUCCESS; } diff -urN linux-2.5.43/net/ipv4/tcp_ipv4.c linux-2.5.43s1/net/ipv4/tcp_ipv4.c --- linux-2.5.43/net/ipv4/tcp_ipv4.c Tue Oct 15 20:27:50 2002 +++ linux-2.5.43s1/net/ipv4/tcp_ipv4.c Wed Oct 16 18:39:30 2002 @@ -1674,8 +1674,6 @@ goto discard; #endif /* CONFIG_FILTER */ - IP_INC_STATS_BH(IpInDelivers); - if (sk->state == TCP_ESTABLISHED) { /* Fast path */ TCP_CHECK_TIMER(sk); if (tcp_rcv_established(sk, skb, skb->h.th, skb->len)) diff -urN linux-2.5.43/net/ipv4/udp.c linux-2.5.43s1/net/ipv4/udp.c --- linux-2.5.43/net/ipv4/udp.c Tue Oct 15 20:27:19 2002 +++ linux-2.5.43s1/net/ipv4/udp.c Wed Oct 16 19:12:40 2002 @@ -819,8 +819,6 @@ if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if (__udp_checksum_complete(skb)) { UDP_INC_STATS_BH(UdpInErrors); - IP_INC_STATS_BH(IpInDiscards); - ip_statistics[smp_processor_id()*2].IpInDelivers--; kfree_skb(skb); return -1; } @@ -830,8 +828,6 @@ if (sock_queue_rcv_skb(sk,skb)<0) { UDP_INC_STATS_BH(UdpInErrors); - IP_INC_STATS_BH(IpInDiscards); - ip_statistics[smp_processor_id()*2].IpInDelivers--; kfree_skb(skb); return -1; } @@ -915,8 +911,6 @@ u32 daddr = skb->nh.iph->daddr; int len = skb->len; - IP_INC_STATS_BH(IpInDelivers); - /* * Validate the packet and the UDP length. */ diff -urN linux-2.5.43/net/ipv6/ip6_input.c linux-2.5.43s1/net/ipv6/ip6_input.c --- linux-2.5.43/net/ipv6/ip6_input.c Tue Oct 15 20:28:32 2002 +++ linux-2.5.43s1/net/ipv6/ip6_input.c Thu Oct 17 09:46:56 2002 @@ -60,8 +60,10 @@ IP6_INC_STATS_BH(Ip6InReceives); - if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) { + IP6_INC_STATS_BH(Ip6InDiscards); goto out; + } /* Store incoming device index. When the packet will be queued, we cannot refer to skb->dev anymore. @@ -175,11 +177,13 @@ nexthdr = -ret; goto resubmit; } + IP6_INC_STATS_BH(Ip6InDelivers); } else { if (!raw_sk) { IP6_INC_STATS_BH(Ip6InUnknownProtos); icmpv6_param_prob(skb, ICMPV6_UNK_NEXTHDR, nhoff); - } + } else + IP6_INC_STATS_BH(Ip6InDelivers); kfree_skb(skb); } diff -urN linux-2.5.43/net/ipv6/raw.c linux-2.5.43s1/net/ipv6/raw.c --- linux-2.5.43/net/ipv6/raw.c Tue Oct 15 20:27:54 2002 +++ linux-2.5.43s1/net/ipv6/raw.c Thu Oct 17 10:05:10 2002 @@ -275,7 +275,7 @@ #if defined(CONFIG_FILTER) if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } @@ -284,12 +284,11 @@ #endif /* Charge it to the socket. */ if (sock_queue_rcv_skb(sk,skb)<0) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } - IP6_INC_STATS_BH(Ip6InDelivers); return 0; } @@ -327,7 +326,7 @@ if (inet->hdrincl) { if (skb->ip_summed != CHECKSUM_UNNECESSARY && (unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } @@ -427,7 +426,7 @@ as some normal condition. */ err = (flags&MSG_DONTWAIT) ? -EAGAIN : -EHOSTUNREACH; - IP6_INC_STATS_USER(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ goto out_free; } diff -urN linux-2.5.43/net/ipv6/tcp_ipv6.c linux-2.5.43s1/net/ipv6/tcp_ipv6.c --- linux-2.5.43/net/ipv6/tcp_ipv6.c Tue Oct 15 20:28:23 2002 +++ linux-2.5.43s1/net/ipv6/tcp_ipv6.c Wed Oct 16 18:40:38 2002 @@ -1470,8 +1470,6 @@ * is currently called with bh processing disabled. */ - IP6_INC_STATS_BH(Ip6InDelivers); - /* Do Stevens' IPV6_PKTOPTIONS. Yes, guys, it is the only place in our code, where we diff -urN linux-2.5.43/net/ipv6/udp.c linux-2.5.43s1/net/ipv6/udp.c --- linux-2.5.43/net/ipv6/udp.c Tue Oct 15 20:27:48 2002 +++ linux-2.5.43s1/net/ipv6/udp.c Wed Oct 16 18:52:38 2002 @@ -512,7 +512,6 @@ if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { UDP6_INC_STATS_BH(UdpInErrors); - IP6_INC_STATS_BH(Ip6InDiscards); kfree_skb(skb); return 0; } @@ -521,11 +520,9 @@ #endif if (sock_queue_rcv_skb(sk,skb)<0) { UDP6_INC_STATS_BH(UdpInErrors); - IP6_INC_STATS_BH(Ip6InDiscards); kfree_skb(skb); return 0; } - IP6_INC_STATS_BH(Ip6InDelivers); UDP6_INC_STATS_BH(UdpInDatagrams); return 0; } From davem@redhat.com Thu Oct 17 16:50:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 16:50:59 -0700 (PDT) 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 g9HNoutG029146 for ; Thu, 17 Oct 2002 16:50:56 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA03689; Thu, 17 Oct 2002 16:43:26 -0700 Date: Thu, 17 Oct 2002 16:43:26 -0700 (PDT) Message-Id: <20021017.164326.60506862.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [Patch 2.5.43] IpInDelivers, IpInDiscards 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: 761 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: Thu, 17 Oct 2002 16:47:58 -0700 (PDT) "The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly." However, I dont really object to it being a catchall for IP discards.. No, you are right. We should match mib specs here. I will take care of this myself, no need to repatch :) Thanks a lot for your work, I'll post what I end up applying to my tree. From vnuorval@morphine.tml.hut.fi Thu Oct 17 16:53:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 16:53:05 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9HNr2tG029662 for ; Thu, 17 Oct 2002 16:53:03 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id CAA12551 for ; Fri, 18 Oct 2002 02:53:01 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma012537; Fri, 18 Oct 02 02:52:51 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HNqnMl028073; Fri, 18 Oct 2002 02:52:49 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9HNqnF5018695; Fri, 18 Oct 2002 02:52:49 +0300 (EEST) Received: from localhost (vnuorval@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id g9HNqmmt018692; Fri, 18 Oct 2002 02:52:48 +0300 (EEST) Date: Fri, 18 Oct 2002 02:52:48 +0300 (EEST) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: ajtuomin@morphine.tml.hut.fi, , , , , , , Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: <20021018.021802.87011078.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Fri, 18 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article <20021017162624.GC16370@morphine.tml.hut.fi> (at Thu, 17 Oct 2002 19:26:25 +0300), Antti Tuominen says: > > [ipv6_tunnel] > > I think this is almost ok. > > 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/. Ok by me! The comment of course says IPIP6 tunnel at the moment, but the constant itself doesn't appear to be used anywhere. > 2. Please put outer address to hardware address in dev. The reason I haven't done this is that MAX_ADDR_LEN is just 8. Does anyone have any objections against changing the value to 16? > Note: you need to modify SIOxxx ioctls too not to overrun! Sorry, I'm not that familiar with ioctls, I just copied the basic functionality from sit.c. Could you explain it a bit more thoroughly, so even I with my thick skull understand what the problem is? -Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tml.hut.fi, phone: +358 (0)9 451 5257 From niv@us.ibm.com Thu Oct 17 17:14:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 17:15:02 -0700 (PDT) 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 g9I0EttG031960 for ; Thu, 17 Oct 2002 17:14:55 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9I0EkaZ007628; Thu, 17 Oct 2002 20:14:46 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9I0Egcr043256; Thu, 17 Oct 2002 20:14:43 -0400 Message-ID: <3DAF5172.8EDC0F1A@us.ibm.com> Date: Thu, 17 Oct 2002 17:10:26 -0700 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 Subject: Re: [Patch 2.5.43] IpInDelivers, IpInDiscards References: <20021017.164326.60506862.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 763 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 "David S. Miller" wrote: > I will take care of this myself, no need to repatch :) > > Thanks a lot for your work, I'll post what I end up applying > to my tree. Great :). Thanks much! Nivedita From yoshfuji@linux-ipv6.org Thu Oct 17 17:56:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 17:56:58 -0700 (PDT) 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 g9I0uptG004074 for ; Thu, 17 Oct 2002 17:56:51 -0700 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 g9I0unlw007863; Fri, 18 Oct 2002 09:56:49 +0900 Date: Fri, 18 Oct 2002 09:56:48 +0900 (JST) Message-Id: <20021018.095648.21063407.yoshfuji@linux-ipv6.org> To: vnuorval@morphine.tml.hut.fi Cc: ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021018.021802.87011078.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-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: 764 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, 18 Oct 2002 02:52:48 +0300 (EEST)), Ville Nuorvala says: > > 2. Please put outer address to hardware address in dev. > > The reason I haven't done this is that MAX_ADDR_LEN is just 8. Does anyone > have any objections against changing the value to 16? > > > Note: you need to modify SIOxxx ioctls too not to overrun! > > Sorry, I'm not that familiar with ioctls, I just copied the basic > functionality from sit.c. Could you explain it a bit more thoroughly, so > even I with my thick skull understand what the problem is? in net/core/dev.c, there're codes to copy between dev->dev_{addr,broadcast} and ifr_hwaddr.sa_data (points sockaddr{} sized 16). Well, we have code for it. :-) Please look at BTW, why don't we have SIOCGIFHWBROADCAST?? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Oct 17 20:52:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 20:52:11 -0700 (PDT) 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 g9I3q8tG016407 for ; Thu, 17 Oct 2002 20:52:08 -0700 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 g9I3qNlw008800; Fri, 18 Oct 2002 12:52:23 +0900 Date: Fri, 18 Oct 2002 12:52:23 +0900 (JST) Message-Id: <20021018.125223.130322644.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Sevaral MLD Fixes 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-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: 766 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, This patch fixes three points. 1. Check address in MLD Query if it is acceptable - unspecified address for General Query - multicast address for Multicast-Address-Specific Queries Otherwise, ignore it. 2. send MLD for link-local addresses (except for link-local scope all nodes address). 3. Don't send MLD for 0(reserved) scope addresses. Patch is against linux-2.4.20-pre11. Thanks is advance. ------------------------------------------------------------------- Patch-Name: Several MLD Fixes Patch-Id: FIX_2_4_20_pre11_MLD-20021018 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project Reference: RFC2710 ------------------------------------------------------------------- Index: include/net/addrconf.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/addrconf.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 addrconf.h --- include/net/addrconf.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/addrconf.h 2002/10/17 17:55:52 @@ -191,5 +191,21 @@ return (addr->s6_addr32[0] & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000); } +static inline int ipv6_addr_is_ll_all_nodes(const struct in6_addr *addr) +{ + return (addr->s6_addr32[0] == htonl(0xff020000) && + addr->s6_addr32[1] == 0 && + addr->s6_addr32[2] == 0 && + addr->s6_addr32[3] == htonl(0x00000001)); +} + +static inline int ipv6_addr_is_ll_all_routers(const struct in6_addr *addr) +{ + return (addr->s6_addr32[0] == htonl(0xff020000) && + addr->s6_addr32[1] == 0 && + addr->s6_addr32[2] == 0 && + addr->s6_addr32[3] == htonl(0x00000002)); +} + #endif #endif Index: include/net/ipv6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ipv6.h --- include/net/ipv6.h 2002/08/20 09:46:45 1.1.1.1 +++ include/net/ipv6.h 2002/10/17 17:55:52 @@ -74,6 +74,20 @@ #define IPV6_ADDR_RESERVED 0x2000U /* reserved address space */ /* + * Addr scopes + */ +#ifdef __KERNEL__ +#define IPV6_ADDR_MC_SCOPE(a) \ + ((a)->s6_addr[1] & 0x0f) /* nonstandard */ +#define __IPV6_ADDR_SCOPE_INVALID -1 +#endif +#define IPV6_ADDR_SCOPE_NODELOCAL 0x01 +#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 +#define IPV6_ADDR_SCOPE_SITELOCAL 0x05 +#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 +#define IPV6_ADDR_SCOPE_GLOBAL 0x0e + +/* * fragmentation header */ Index: net/ipv6/mcast.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/mcast.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.32.3 diff -u -r1.1.1.1 -r1.1.1.1.32.3 --- net/ipv6/mcast.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/mcast.c 2002/10/17 17:53:59 1.1.1.1.32.3 @@ -18,6 +18,9 @@ /* Changes: * * yoshfuji : fix format of router-alert option + * YOSHIFUJI Hideaki @USAGI: + * - Ignore Queries for invalid addresses. + * - MLD for link-local addresses. */ #define __NO_VERSION__ @@ -405,6 +408,7 @@ unsigned long resptime; struct inet6_dev *idev; struct icmp6hdr *hdr; + int addr_type; if (!pskb_may_pull(skb, sizeof(struct in6_addr))) return -EINVAL; @@ -420,6 +424,11 @@ resptime = (resptime<<10)/(1024000/HZ); addrp = (struct in6_addr *) (hdr + 1); + addr_type = ipv6_addr_type(addrp); + + if (addr_type != IPV6_ADDR_ANY && + !(addr_type&IPV6_ADDR_MULTICAST)) + return -EINVAL; idev = in6_dev_get(skb->dev); @@ -427,7 +436,7 @@ return 0; read_lock(&idev->lock); - if (ipv6_addr_any(addrp)) { + if (addr_type == IPV6_ADDR_ANY) { for (ma = idev->mc_list; ma; ma=ma->next) igmp6_group_queried(ma, resptime); } else { @@ -566,11 +575,9 @@ static void igmp6_join_group(struct ifmcaddr6 *ma) { unsigned long delay; - int addr_type; - - addr_type = ipv6_addr_type(&ma->mca_addr); - if ((addr_type & (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_LOOPBACK))) + if (IPV6_ADDR_MC_SCOPE(&ma->mca_addr) < IPV6_ADDR_SCOPE_LINKLOCAL || + ipv6_addr_is_ll_all_nodes(&ma->mca_addr)) return; igmp6_send(&ma->mca_addr, ma->idev->dev, ICMPV6_MGM_REPORT); @@ -592,10 +599,9 @@ static void igmp6_leave_group(struct ifmcaddr6 *ma) { int addr_type; - - addr_type = ipv6_addr_type(&ma->mca_addr); - if ((addr_type & IPV6_ADDR_LINKLOCAL)) + if (IPV6_ADDR_MC_SCOPE(&ma->mca_addr) < IPV6_ADDR_SCOPE_LINKLOCAL || + ipv6_addr_is_ll_all_nodes(&ma->mca_addr)) return; if (ma->mca_flags & MAF_LAST_REPORTER) From yoshfuji@linux-ipv6.org Thu Oct 17 20:52:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 20:52:03 -0700 (PDT) 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 g9I3q0tG016362 for ; Thu, 17 Oct 2002 20:52:01 -0700 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 g9I3qFlw008797; Fri, 18 Oct 2002 12:52:15 +0900 Date: Fri, 18 Oct 2002 12:52:15 +0900 (JST) Message-Id: <20021018.125215.922751890.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Source Address of MLD Message 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-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: 765 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! draft-ietf-magma-mld-source-02.txt clarifies that the source address of MLD Report / Done Message MUST be unspecified address when a link-local address is not available. This patch follows this clarification. This patch is against 2.4.20-pre10. Thanks in advance. ------------------------------------------------------------------- Patch-Name: Source Address of MLD Message Patch-Id: FIX_2_4_20_pre10_MLD_SADDR-20021017 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project Reference: draft-ietf-magma-mld-source-02.txt ------------------------------------------------------------------- Index: net/ipv6/mcast.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/mcast.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.30.2 diff -u -r1.1.1.1 -r1.1.1.1.30.2 --- net/ipv6/mcast.c 2002/08/20 09:47:02 1.1.1.1 +++ net/ipv6/mcast.c 2002/10/17 17:33:19 1.1.1.1.30.2 @@ -18,6 +18,9 @@ /* Changes: * * yoshfuji : fix format of router-alert option + * YOSHIFUJI Hideaki @USAGI: + * Fixed source address for MLD message based on + * . */ #define __NO_VERSION__ @@ -451,6 +454,7 @@ struct in6_addr *addrp; struct inet6_dev *idev; struct icmp6hdr *hdr; + int addr_type; /* Our own report looped back. Ignore it. */ if (skb->pkt_type == PACKET_LOOPBACK) @@ -462,7 +466,9 @@ hdr = (struct icmp6hdr*) skb->h.raw; /* Drop reports with not link local source */ - if (!(ipv6_addr_type(&skb->nh.ipv6h->saddr)&IPV6_ADDR_LINKLOCAL)) + addr_type = ipv6_addr_type(&skb->nh.ipv6h->saddr); + if (addr_type != IPV6_ADDR_ANY && + !(addr_type&IPV6_ADDR_LINKLOCAL)) return -EINVAL; addrp = (struct in6_addr *) (hdr + 1); @@ -529,11 +535,11 @@ } if (ipv6_get_lladdr(dev, &addr_buf)) { -#if MCAST_DEBUG >= 1 - printk(KERN_DEBUG "igmp6: %s no linklocal address\n", - dev->name); -#endif - goto out; + /* : + * use unspecified address as the source address + * when a valid link-local address is not available. + */ + memset(&addr_buf, 0, sizeof(addr_buf)); } ip6_nd_hdr(sk, skb, dev, &addr_buf, snd_addr, NEXTHDR_HOP, payload_len); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pekkas@netcore.fi Thu Oct 17 23:08:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 17 Oct 2002 23:08:45 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9I68btG026236 for ; Thu, 17 Oct 2002 23:08:38 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9I68P300591; Fri, 18 Oct 2002 09:08:25 +0300 Date: Fri, 18 Oct 2002 09:08:25 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: linux-kernel@vger.kernel.org, , Subject: Re: [PATCH] IPv6: Sevaral MLD Fixes In-Reply-To: <20021018.125223.130322644.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 767 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 Both patches appear to be fine from spec point of view at least, this is what should be done. draft-ietf-magma-mld-source-02.txt in the next patch is in the working group last call at the moment, so it should be quite stable now. I only expect some clarifications on situations where there are non-upgraded/upgraded MLD nodes on the link, but there shouldn't be anything major as far as I can see. On Fri, 18 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > Hi, > > This patch fixes three points. > 1. Check address in MLD Query if it is acceptable > - unspecified address for General Query > - multicast address for Multicast-Address-Specific Queries > Otherwise, ignore it. > 2. send MLD for link-local addresses (except for link-local scope > all nodes address). > 3. Don't send MLD for 0(reserved) scope addresses. > > Patch is against linux-2.4.20-pre11. > > Thanks is advance. > > ------------------------------------------------------------------- > Patch-Name: Several MLD Fixes > Patch-Id: FIX_2_4_20_pre11_MLD-20021018 > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > Credit: YOSHIFUJI Hideaki / USAGI Project > Reference: RFC2710 > ------------------------------------------------------------------- > Index: include/net/addrconf.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/addrconf.h,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 addrconf.h > --- include/net/addrconf.h 2002/08/20 09:46:45 1.1.1.1 > +++ include/net/addrconf.h 2002/10/17 17:55:52 > @@ -191,5 +191,21 @@ > return (addr->s6_addr32[0] & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000); > } > > +static inline int ipv6_addr_is_ll_all_nodes(const struct in6_addr *addr) > +{ > + return (addr->s6_addr32[0] == htonl(0xff020000) && > + addr->s6_addr32[1] == 0 && > + addr->s6_addr32[2] == 0 && > + addr->s6_addr32[3] == htonl(0x00000001)); > +} > + > +static inline int ipv6_addr_is_ll_all_routers(const struct in6_addr *addr) > +{ > + return (addr->s6_addr32[0] == htonl(0xff020000) && > + addr->s6_addr32[1] == 0 && > + addr->s6_addr32[2] == 0 && > + addr->s6_addr32[3] == htonl(0x00000002)); > +} > + > #endif > #endif > Index: include/net/ipv6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 ipv6.h > --- include/net/ipv6.h 2002/08/20 09:46:45 1.1.1.1 > +++ include/net/ipv6.h 2002/10/17 17:55:52 > @@ -74,6 +74,20 @@ > #define IPV6_ADDR_RESERVED 0x2000U /* reserved address space */ > > /* > + * Addr scopes > + */ > +#ifdef __KERNEL__ > +#define IPV6_ADDR_MC_SCOPE(a) \ > + ((a)->s6_addr[1] & 0x0f) /* nonstandard */ > +#define __IPV6_ADDR_SCOPE_INVALID -1 > +#endif > +#define IPV6_ADDR_SCOPE_NODELOCAL 0x01 > +#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 > +#define IPV6_ADDR_SCOPE_SITELOCAL 0x05 > +#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 > +#define IPV6_ADDR_SCOPE_GLOBAL 0x0e > + > +/* > * fragmentation header > */ > > Index: net/ipv6/mcast.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/mcast.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.32.3 > diff -u -r1.1.1.1 -r1.1.1.1.32.3 > --- net/ipv6/mcast.c 2002/08/20 09:47:02 1.1.1.1 > +++ net/ipv6/mcast.c 2002/10/17 17:53:59 1.1.1.1.32.3 > @@ -18,6 +18,9 @@ > /* Changes: > * > * yoshfuji : fix format of router-alert option > + * YOSHIFUJI Hideaki @USAGI: > + * - Ignore Queries for invalid addresses. > + * - MLD for link-local addresses. > */ > > #define __NO_VERSION__ > @@ -405,6 +408,7 @@ > unsigned long resptime; > struct inet6_dev *idev; > struct icmp6hdr *hdr; > + int addr_type; > > if (!pskb_may_pull(skb, sizeof(struct in6_addr))) > return -EINVAL; > @@ -420,6 +424,11 @@ > resptime = (resptime<<10)/(1024000/HZ); > > addrp = (struct in6_addr *) (hdr + 1); > + addr_type = ipv6_addr_type(addrp); > + > + if (addr_type != IPV6_ADDR_ANY && > + !(addr_type&IPV6_ADDR_MULTICAST)) > + return -EINVAL; > > idev = in6_dev_get(skb->dev); > > @@ -427,7 +436,7 @@ > return 0; > > read_lock(&idev->lock); > - if (ipv6_addr_any(addrp)) { > + if (addr_type == IPV6_ADDR_ANY) { > for (ma = idev->mc_list; ma; ma=ma->next) > igmp6_group_queried(ma, resptime); > } else { > @@ -566,11 +575,9 @@ > static void igmp6_join_group(struct ifmcaddr6 *ma) > { > unsigned long delay; > - int addr_type; > - > - addr_type = ipv6_addr_type(&ma->mca_addr); > > - if ((addr_type & (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_LOOPBACK))) > + if (IPV6_ADDR_MC_SCOPE(&ma->mca_addr) < IPV6_ADDR_SCOPE_LINKLOCAL || > + ipv6_addr_is_ll_all_nodes(&ma->mca_addr)) > return; > > igmp6_send(&ma->mca_addr, ma->idev->dev, ICMPV6_MGM_REPORT); > @@ -592,10 +599,9 @@ > static void igmp6_leave_group(struct ifmcaddr6 *ma) > { > int addr_type; > - > - addr_type = ipv6_addr_type(&ma->mca_addr); > > - if ((addr_type & IPV6_ADDR_LINKLOCAL)) > + if (IPV6_ADDR_MC_SCOPE(&ma->mca_addr) < IPV6_ADDR_SCOPE_LINKLOCAL || > + ipv6_addr_is_ll_all_nodes(&ma->mca_addr)) > return; > > if (ma->mca_flags & MAF_LAST_REPORTER) > > -- 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 ajtuomin@tml.hut.fi Fri Oct 18 00:39:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 00:39:47 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9I7dhtG001075 for ; Fri, 18 Oct 2002 00:39:43 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id KAA15440 for ; Fri, 18 Oct 2002 10:39:42 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma015423; Fri, 18 Oct 02 10:39:34 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9I7dXMl000375; Fri, 18 Oct 2002 10:39:33 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9I7dTF5019114; Fri, 18 Oct 2002 10:39:29 +0300 (EEST) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g9I7dIDX019113; Fri, 18 Oct 2002 10:39:18 +0300 (EEST) Date: Fri, 18 Oct 2002 10:39:17 +0300 From: Antti Tuominen To: Pekka Savola Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@wide.ad.jp, torvalds@transmeta.com, jagana@us.ibm.com Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 Message-ID: <20021018073917.GA19020@morphine.tml.hut.fi> References: <20021017162624.GC16370@morphine.tml.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Thu, Oct 17, 2002 at 11:14:32PM +0300, Pekka Savola wrote: > On Thu, 17 Oct 2002, Antti Tuominen wrote: > > Intermediate revision of the specification "Draft 18++" appeared a few > > days ago, which addressed most of the issues with earlier drafts (16, > > Sounds great. Hopefully it slows down a bit from being a moving target. I heard Draft 19 should be out next week, so that should consolidate the MIPv6 effort even further. > 1) current tunneling (including sanity checks which are, I believe, a bit > non-existant at the moment) should be generalized to handle v6-in-v6 and > v6-in-v4 tunneling anyway. Not sure if this is the right way, but that's > IMO one priority item. I'm sure we can improve the v6-in-v6 tunnel. We had some discussion with USAGI people about doing anything-in-v6 general tunnel, but since that is somewhat beyond our project scope, v6-in-v6 is all we can offer at this time. I don't know about the USAGI folks' status on this. > 2) without IPSEC, there is no way to secure MN-HA traffic. Therefore I > think the first priority is being able to support Correspondent Node > behaviour. Right. We've had our own IPSec AH support in all the previous releases, but as everyone probably knows the USAGI guys have implemented IPv6 IPSec. This is why we dropped the IPSec stuff in our code. There is no point doing the same work again. If (or when) USAGI IPSec gets accepted to the kernel, we will be sure to modify our code to support it. > Having IPSEC + MIPv6 in 2.6 series would be Really Cool, though :-) This is something we're hoping for too. Regards, Antti -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From benoit-lists@fb12.de Fri Oct 18 03:47:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 03:47:25 -0700 (PDT) Received: from turing.fb12.de (turing.fb12.de [80.76.224.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IAlItG018439 for ; Fri, 18 Oct 2002 03:47:18 -0700 Received: (qmail 21819 invoked by uid 500); 18 Oct 2002 10:47:17 -0000 Date: Fri, 18 Oct 2002 12:47:17 +0200 From: Sebastian Benoit To: netdev@oss.sgi.com Subject: network connection gets stuck with 2.5.43-bk1/mm2 Message-ID: <20021018124717.A21622@turing.fb12.de> Mail-Followup-To: Sebastian Benoit , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-MSMail-Priority: High x-gpg-fingerprint: 2999 9839 6C9E E4BF B540 C44B 4EC4 E1BE 5BA2 2F00 x-gpg-key: http://wwwkeys.de.pgp.net:11371 X-archive-position: 769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: benoit-lists@fb12.de Precedence: bulk X-list: netdev --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i posted the message below to linux-mm yesterday, Andrew Morton told me that it might be one of the changes in networking in -bk1. removing these changes solved the problem: include/linux/ip.h | 16=20 include/linux/tcp.h | 2=20 include/linux/udp.h | 31 - include/net/dst.h | 56 -- include/net/ip.h | 16=20 include/net/sock.h | 2=20 include/net/tcp.h | 2=20 include/net/udp.h | 2=20 net/core/dst.c | 25 - net/ipv4/af_inet.c | 17=20 net/ipv4/icmp.c | 4=20 net/ipv4/ip_output.c | 880 +++++++----------------------------------= ----- net/ipv4/ip_proc.c | 74 --- net/ipv4/ip_sockglue.c | 4=20 net/ipv4/raw.c | 7=20 net/ipv4/tcp.c | 49 -- net/ipv4/tcp_ipv4.c | 6=20 net/ipv4/tcp_minisocks.c | 10=20 net/ipv4/udp.c | 296 --------------- net/ipv6/tcp_ipv6.c | 5=20 net/netsyms.c | 1=20 (this is the diffstat of the reverse patch) Is this fixed already? /B. ----------------- quote ----------------- Hi,=20 funny problem w. 2.5.43-mm2: i'm running 2.5.43-mm2 on my workstation. Normal workload, X-windows, a few xterms, editor, mozilla, etc. (host A) I have a NFS/SAMBA-mount (both show the problem) to host B. Host B runs 2.4.19rc5aa1. I can get a xterm, in which i have a ssh-connection to a third host C 'stuck' by simply cat'ing a large file from the NFS/SAMBA server to /dev/null. The xterm/ssh seems stuck, that is no key i press is received on the other end, but output of the program running on host C is updated in the xterm. I checked with tcpdump: the keypress does not generate a packet, my host only sends ACK's on that ssh connection to host C. The ssh-connection is not unstuck by stopping the data transfer from host B. I checked that plain 2.5.42 and 2.5.43-mm1 do not have this problem: here my input goes through to C. At least for small amounts of input, i did not test anything beyond typing a few hundret chars. recap: "mount /mnt/hostB" "ssh hostC" -> type random stuff in that connection at the same time do "cat /mnt/hostB/bigfile > /dev/null" ssh gets stuck. hardware: PIII/600, 3c905B on 10baseT half-duplex I'm sorry i cant do any further checks until Friday afternoon (MET). /B. --------------- quote ends --------------- --=20 Sebastian Benoit My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ GnuPG 0x5BA22F00 2001-07-31 2999 9839 6C9E E4BF B540 C44B 4EC4 E1BE 5BA2 2= F00 Oxymoron #633: Mutual Differences --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2v5rUACgkQTsThvluiLwCu1QCgi38mkGpDNKO8kw/N1BWikRsg HR0AoIKi8Mfuf/7X27opcDoedwFOn1JN =rhqg -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From ajtuomin@tml.hut.fi Fri Oct 18 04:17:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 04:17:30 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IBHRtG021440 for ; Fri, 18 Oct 2002 04:17:27 -0700 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA01864 for ; Fri, 18 Oct 2002 14:17:26 +0300 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma001845; Fri, 18 Oct 02 14:16:59 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9IBGwMl001775; Fri, 18 Oct 2002 14:16:58 +0300 (EEST) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9IBGvF5019736; Fri, 18 Oct 2002 14:16:57 +0300 (EEST) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g9IBGP7q019735; Fri, 18 Oct 2002 14:16:25 +0300 (EEST) Date: Fri, 18 Oct 2002 14:16:25 +0300 From: Antti Tuominen To: Mitsuru KANDA Cc: yoshfuji@linux-ipv6.org, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 Message-ID: <20021018111625.GA19394@morphine.tml.hut.fi> References: <20021017162624.GC16370@morphine.tml.hut.fi> <20021018.021802.87011078.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Fri, Oct 18, 2002 at 02:56:33AM +0900, Mitsuru KANDA wrote: > > [ipv6_tunnel] > > > > I think this is almost ok. > I think so. > I know ipv6_tunnel is stable as I use. Thanks for the vote of confidence :) > plus: > (maybe not whole kernel issue) > It is important to integrate your ipv6tunnel command into > ifconfig(8) and/or ip(8). Obviously we will provide patches to add that functionality to ip (and maybe also ifconfig), if the code goes into the kernel. Regards, Antti -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From newsletters@the-financial-news.com Fri Oct 18 07:31:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 07:31:57 -0700 (PDT) Received: from wtnserver (213-96-214-72.uc.nombres.ttd.es [213.96.214.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IEVltG013235 for ; Fri, 18 Oct 2002 07:31:49 -0700 Received: from EI2 by wtnserver with SMTP (MDaemon.v3.1.2.R) for ; Fri, 18 Oct 2002 16:30:01 +0200 From: "The Financial News" Subject: Development countries. News in brief To: netdev@oss.sgi.com MIME-Version: 1.0 Date: Fri, 18 Oct 2002 16:26:01 +0200 X-Priority: 3 X-Library: Indy 8.0.22 X-MDRcpt-To: netdev@oss.sgi.com X-Return-Path: newsletters@the-financial-news.com X-MDaemon-Deliver-To: netdev@oss.sgi.com Reply-To: newsletters@the-financial-news.com Message-ID: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 4625 X-archive-position: 771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: newsletters@the-financial-news.com Precedence: bulk X-list: netdev The Financial News, October 2002 Production Mini-plants in mobile containers. Co-investment Program "...Science Network will supply to countries and developing regions the tec= hnology and the necessary support for the production in series of Mini-plan= ts in mobile containers (40-foot). The Mini-plant system is designed in suc= h a way that all the production machinery is fixed on the platform of the c= ontainer, with all wiring, piping, and installation parts; that is to say, = they are fully equipped... and the mini-plant is ready for production." More than 700 portable production systems: Bakeries, Steel Nails, Welding E= lectrodes, Tire Retreading, Reinforcement Bar Bending for Construction Fram= ework, Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum= Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasse= s, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Me= sh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitar= y Material, Hypodermic Syringes, Hemostatic Clamps, etc.=20 Science Network has started a process of Co-investment for the installation= of small Assembly plants to manufacture in series the Mini- plants of portable production on the site, region or country where they may= be required. One of the most relevant features is the fact that these plan= ts will be connected to the World Trade System (WTS) with access to more th= an 50 million raw materials, products and services and automatic transactio= ns for world trade. Due to financial reasons, involving cost and social impact, the right thing= to do is to set up assembly plants in the same countries and regions, usin= g local resources (labor, some equipment, etc.) Science Network participates with 50% in the investment of each Assembly pl= ant. For more information: Min= i-plants in mobile containers By Steven P. Leibacher, The Financial News, Editor Mini-plantas de produccion en contenedores moviles. Programa de Co-inversion "...Science Network suministrara a paises y regiones en vias de desarrollo = la tecnologia y el apoyo necesario para la fabricacion en serie de Mini-pla= ntas de produccion en contenedores moviles (40-foot). El sistema de mini-pl= antas esta dise=F1ado de forma que todas las maquinas de produccion van ins= taladas fijas sobre la propia plataforma del contenedor, con el cableado, t= uberias e instalaciones; es decir, completamente equipadas... y a partir de= ese momento est=E1n listas para producir."=20 Mas de 700 sistemas de produccion portatil: Panaderias, Producci=F3n de cla= vos de acero, Electrodos para soldadura, Recauchutado de neumaticos, Curvad= o de hierro para armaduras de construccion, Lamina perfilada para cubiertas= , techos y cerramientos de fachada, Bidones de chapa, Cubos de aluminio, Me= naje de polipropileno inyectado, Piezas de melamina prensada (vasos, platos= , tazas, cafeteras, etc.) Silenciadores para vehiculos, Malla electrosoldad= a para la construccion, Bolsas y envases de plastico, Unidades moviles de a= sistencia medica, Material sanitario (jeringas hipodermicas, Pinzas hemosta= ticas, etc.) Science Network ha puesto en marcha un proceso de Co-inversion para la inst= alacion de peque=F1as Plantas ensambladoras para fabricar en serie las Mini= -plantas de produccion portatil, en el lugar, region o pais que lo necesite= . Una de las caracter=EDsticas relevantes es el hecho de que dichas plantas= quedaran conectadas al Sistema del Comercio Mundial (WTS) con acceso a mas= de 50 millones de mercancias, materia primas, productos, servicios y las o= peraciones automaticas de comercio internacional. Resulta obvio que por razones economicas, de costes y de impacto social, lo= apropiado es instalar plantas ensambladoras en los mismos paises y regione= s asi como utilizar los recursos locales (mano de obra, ciertos equipamient= os, etc.) Science Network participa al 50% en la inversion de cada Planta ensamblador= a. Para recibir mas informacion: Mini-plantas de produccion en contenedores moviles Steven P. Leibacher, The Financial News, Editor ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, pl= ease return us indicating: remove or un-subscribe in 'subject' field, Thank= s. Editor =A9 2002 The Financial News. All rights reserved. [[HTML alternate version deleted]] From Robert.Olsson@data.slu.se Fri Oct 18 09:09:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 09:09:16 -0700 (PDT) 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 g9IG9AtG020907 for ; Fri, 18 Oct 2002 09:09:10 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id SAA14096; Fri, 18 Oct 2002 18:16:01 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15792.13249.474279.391081@robur.slu.se> Date: Fri, 18 Oct 2002 18:16:01 +0200 To: Cc: Subject: RE: [Question] SMP for Linux In-Reply-To: <008601c27602$a1ad8170$3701020a@CONCORDIA> References: <15790.42618.961289.506241@robur.slu.se> <008601c27602$a1ad8170$3701020a@CONCORDIA> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 772 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 Jon Fraser writes: > > What was your cpu utilization like in the bound vs split scenarios? Not measured. Gonna take a look w. varient of Manfred's loadtest when possible. But measuring the CPU this way also gives affects throughput. Other softirq's are allowed to run as well now. :-) Over 1 Mpps was injected into eth0 so a good assumption is that for UP all CPU is used but with SMP we might have some... > Does your e1000 driver have transmit interrupts enabled or disabled? transmit? > I'd be really interested to see the results with two flows in opposite > directions. Me too. Cheers. --ro From ph@digitalquake.com Fri Oct 18 09:57:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 09:57:51 -0700 (PDT) Received: from sun4.digitalquake.com (digitalquake.com [63.205.237.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9IGvntG026795 for ; Fri, 18 Oct 2002 09:57:49 -0700 Received: from phpc (netscreen-dmz.digitalquake.com [192.168.0.1]) by sun4.digitalquake.com (8.10.2+Sun/8.10.2) with SMTP id g9IGvLk04915; Fri, 18 Oct 2002 09:57:27 -0700 (PDT) From: "Paul Hernandez" To: , Subject: NIC on 2.4.19 SMP Date: Fri, 18 Oct 2002 09:57:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ph@digitalquake.com Precedence: bulk X-list: netdev Hello, It was suggested to me that I forward this issue to you both. OS: 2.4.19.SuSE SMP Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 (latest bios off Intel site) On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 dmesg output: e100: eth0: Intel(R) 8255x-based Ethernet Adapter Mem:0xfc221000 IRQ:7 Speed:0 Mbps Dx:N/A Failed to detect cable link Speed and duplex will be determined at time of connection Hardware receive checksums enabled cpu cycle saver enabled All three NIC's worked fine on 2.4.18.SuSE (SuSE 8.0) however I had to upgrade to correct non-functioning DMA on the on-board ide controller which now works. (The on-board Promise FastTrack100 RAID controller which also worked on 2.4.18.SuSE now fails with many "lost interrupts" messages...sigh) Trying to debug using mii-tool of mii-diag yields: SIOCGMIIPHY on eth0 failed: Operation not supported no MII interfaces found ifconfig eth0 shows all is fine however cannot ping the gateway with 2.4.19 as can with 2.4.18. I can ping its own ip address fine, Thanks in advance for any tips. Paul Hernandez 408-374-8686 x202 Campbell, CA From J_Fraser@bit-net.com Fri Oct 18 16:29:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 16:29:25 -0700 (PDT) Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9INTMtG027004 for ; Fri, 18 Oct 2002 16:29:22 -0700 Received: from CONCORDIA (mail.crossbeamsys.com [63.96.67.2]) by mail.bit-net.com (8.9.3/8.9.2) with SMTP id TAA79823; Fri, 18 Oct 2002 19:29:19 -0400 (EDT) (envelope-from J_Fraser@bit-net.com) Reply-To: From: "Jon Fraser" To: "'Robert Olsson'" Cc: Subject: RE: [Question] SMP for Linux Date: Fri, 18 Oct 2002 19:29:58 -0400 Message-ID: <000b01c276fe$46626720$3701020a@CONCORDIA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15792.13249.474279.391081@robur.slu.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-archive-position: 774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: J_Fraser@bit-net.com Precedence: bulk X-list: netdev I ran some tests this afternoon. The setup is: 2 x 1ghz PIII cpus w 256k cache 2 intel 82542 gig-e cards linux 2.4.20-pre11 kernel. I don't have the NAPI e1000 driver. I actually have to ship a 2.4.18 based kernel, but decided to run some tests on the 2.4.20 kernel. The e1000 driver has been modified in a couple of ways. The interrupts have been limited to 5k/second per card. This mimics the actual hardware being shipped which uses an intel 82543 chip but has an fpga used to do some control functions and generate the interrupts. We also don't use any transmit interrupts. The Tx ring is not cleaned at interrupt time. It's cleaned when we transmit frames and the number of free tx descriptors drops below a threshold. I also have some code which directs the freed skb back to the cpu it was allocated on, but it's not in this driver version. I used an ixia traffic generator to create the two udp flows. Using the same terminology: bound = interrupts for both cards bound to one cpu float = no smp affinity split = card 0 bound to cpu 0, card 1 bound to cpu 1 The results, in kpps: bound float split cpu % cpu% cpu% ----------------------- 1 flow 290 270 290 99%x1 65%x2 99%x1 2 flows 270 380 450 99%x1 82%x2 96%x2 Previously, I've used the CPU performance monitoring counters to find that cache invalidates tends to be a big problem when the interrupts are not bound to a pariticular cpu. Bind the card to a particular interrupt effectively binds the flow to a particular cpu. 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, etc., so they contribute a bit to the load. Jon > > > Jon Fraser writes: > > > > What was your cpu utilization like in the bound vs split scenarios? > > Not measured. Gonna take a look w. varient of Manfred's > loadtest when > possible. But measuring the CPU this way also gives affects > throughput. > Other softirq's are allowed to run as well now. :-) > > Over 1 Mpps was injected into eth0 so a good assumption is > that for UP > all CPU is used but with SMP we might have some... > > > Does your e1000 driver have transmit interrupts enabled or > disabled? > > transmit? > > > I'd be really interested to see the results with two flows > in opposite > > directions. > > Me too. > > Cheers. > --ro > > From niv@us.ibm.com Fri Oct 18 17:25:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 17:25:16 -0700 (PDT) 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 g9J0P9tG032056 for ; Fri, 18 Oct 2002 17:25:10 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9J0ORUF024418; Fri, 18 Oct 2002 20:24:27 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9J0OObs120662; Fri, 18 Oct 2002 20:24:24 -0400 Message-ID: <3DB0A536.A8FB364A@us.ibm.com> Date: Fri, 18 Oct 2002 17:20:06 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: J_Fraser@bit-net.com CC: "'Robert Olsson'" , netdev@oss.sgi.com Subject: Re: [Question] SMP for Linux References: <000b01c276fe$46626720$3701020a@CONCORDIA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Jon Fraser wrote: > bound = interrupts for both cards bound to one cpu > float = no smp affinity > split = card 0 bound to cpu 0, card 1 bound to cpu 1 > > The results, in kpps: > > bound float split > cpu % cpu% cpu% > ----------------------- > 1 flow 290 270 290 > 99%x1 65%x2 99%x1 > > 2 flows 270 380 450 > 99%x1 82%x2 96%x2 This is approximately what one should expect, correct? If you have only one task (flow), then the float case will be slower than the bound/split case (as long as the CPU isnt the bottleneck), because you'll have an increasing number of cacheline misses. When you have two or more flows, the general order in which things improve would be the bound, float and then split cases. The fact that the float case is halfway between the other two is indicative of how expensive the cacheline being on the other CPU is. In the float case, it would be nice if we could see the interrupt distribution between the CPU's. Would you happen to have the /proc/interrupt info? thanks, Nivedita From davem@redhat.com Fri Oct 18 18:17:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 18:17:21 -0700 (PDT) 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 g9J1HHtG003883 for ; Fri, 18 Oct 2002 18:17:17 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id SAA15390; Fri, 18 Oct 2002 18:09:34 -0700 Date: Fri, 18 Oct 2002 18:09:33 -0700 (PDT) Message-Id: <20021018.180933.80085592.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Source Address of MLD Message From: "David S. Miller" In-Reply-To: <20021018.125215.922751890.yoshfuji@linux-ipv6.org> References: <20021018.125215.922751890.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: 776 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 / 吉藤英明 Date: Fri, 18 Oct 2002 12:52:15 +0900 (JST) draft-ietf-magma-mld-source-02.txt clarifies that the source address of MLD Report / Done Message MUST be unspecified address when a link-local address is not available. This patch follows this clarification. This patch is against 2.4.20-pre10. Patch is applied, thanks. From davem@redhat.com Fri Oct 18 18:23:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 18:23:21 -0700 (PDT) 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 g9J1NGtG004668 for ; Fri, 18 Oct 2002 18:23:17 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id SAA15422; Fri, 18 Oct 2002 18:15:32 -0700 Date: Fri, 18 Oct 2002 18:15:32 -0700 (PDT) Message-Id: <20021018.181532.45064096.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Sevaral MLD Fixes From: "David S. Miller" In-Reply-To: <20021018.125223.130322644.yoshfuji@linux-ipv6.org> References: <20021018.125223.130322644.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: 777 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 / 吉藤英明 Date: Fri, 18 Oct 2002 12:52:23 +0900 (JST) I am going to apply this patch, but please be more careful in the future. You submitted two patches which modify the same hunk of comment to two different values, guarenteeing that if I just run 'patch' this one will not apply without rejects. @@ -18,6 +18,9 @@ /* Changes: * * yoshfuji : fix format of router-alert option + * YOSHIFUJI Hideaki @USAGI: + * - Ignore Queries for invalid addresses. + * - MLD for link-local addresses. */ #define __NO_VERSION__ Next time, please make patch relative to previous one and tell me "this patch depends upon MLD source address selection patch being applied first". This way we can avoid this problem. From davem@redhat.com Fri Oct 18 19:00:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 19:00:45 -0700 (PDT) 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 g9J20gtG008384 for ; Fri, 18 Oct 2002 19:00:42 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id SAA15780; Fri, 18 Oct 2002 18:52:58 -0700 Date: Fri, 18 Oct 2002 18:52:58 -0700 (PDT) Message-Id: <20021018.185258.27026815.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Sevaral MLD Fixes From: "David S. Miller" In-Reply-To: <20021018.125223.130322644.yoshfuji@linux-ipv6.org> References: <20021018.125223.130322644.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 778 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 I had to add the following to my tree after this patch, please watch for compiler warnings introducted by your changes. Thanks :-) --- net/ipv6/mcast.c.~1~ Fri Oct 18 18:55:04 2002 +++ net/ipv6/mcast.c Fri Oct 18 18:55:16 2002 @@ -605,8 +605,6 @@ static void igmp6_leave_group(struct ifmcaddr6 *ma) { - int addr_type; - if (IPV6_ADDR_MC_SCOPE(&ma->mca_addr) < IPV6_ADDR_SCOPE_LINKLOCAL || ipv6_addr_is_ll_all_nodes(&ma->mca_addr)) return; From kaos@ocs.com.au Fri Oct 18 19:33:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 19:33:20 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9J2XGtG011763 for ; Fri, 18 Oct 2002 19:33:17 -0700 Received: (qmail 11313 invoked from network); 19 Oct 2002 02:33:14 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Oct 2002 02:33:14 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 88D88300B29; Sat, 19 Oct 2002 12:33:12 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 613B5108F; Sat, 19 Oct 2002 12:33:12 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) In-reply-to: Your message of "Tue, 15 Oct 2002 13:10:37 MST." <20021015.131037.96602290.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Oct 2002 12:33:07 +1000 Message-ID: <4301.1034994787@ocs3.intra.ocs.com.au> X-archive-position: 779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: netdev On Tue, 15 Oct 2002 13:10:37 -0700 (PDT), "David S. Miller" wrote: > Yes, the size of the *.o files in the security directory can be shrunk a > bit: > text data bss dec hex filename > 6765 776 8 7549 1d7d built-in.o > 3280 392 4 3676 e5c capability.o > 1772 384 0 2156 86c dummy.o > 1713 0 4 1717 6b5 security.o > >It's a whopping 32K on sparc64, and that is only counting >the security/*.o objects. Double counting: built-in.o == (capability.o + dummy.o + security.o) From kaos@ocs.com.au Fri Oct 18 19:54:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 19:54:47 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9J2sitG014361 for ; Fri, 18 Oct 2002 19:54:45 -0700 Received: (qmail 11582 invoked from network); 19 Oct 2002 02:54:42 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Oct 2002 02:54:42 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 244A8300B29; Sat, 19 Oct 2002 12:54:41 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 03269108F; Sat, 19 Oct 2002 12:54:40 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) In-reply-to: Your message of "Sat, 19 Oct 2002 12:33:07 +1000." <4301.1034994787@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Oct 2002 12:54:35 +1000 Message-ID: <4914.1034996075@ocs3.intra.ocs.com.au> X-archive-position: 780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: netdev On Tue, 15 Oct 2002 13:10:37 -0700 (PDT), "David S. Miller" wrote: > Yes, the size of the *.o files in the security directory can be shrunk a > bit: > text data bss dec hex filename > 6765 776 8 7549 1d7d built-in.o > 3280 392 4 3676 e5c capability.o > 1772 384 0 2156 86c dummy.o > 1713 0 4 1717 6b5 security.o > >It's a whopping 32K on sparc64, and that is only counting >the security/*.o objects. Pressed send too soon :( Double counting: built-in.o == (capability.o + dummy.o + security.o) Also I suspect you double counted text+data+bss+dec, when dec = (text+data+bss). The real size of the *.o security files in the kernel is 7549, not 32K. Not that it makes any difference, there has to be a way to make that size 0 when LSM is compiled off. From greg@kroah.com Fri Oct 18 20:29:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 18 Oct 2002 20:29:45 -0700 (PDT) Received: from kroah.com (12-231-249-244.client.attbi.com [12.231.249.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9J3TftG017591 for ; Fri, 18 Oct 2002 20:29:41 -0700 Received: (qmail 13183 invoked by uid 500); 19 Oct 2002 03:29:07 -0000 Date: Fri, 18 Oct 2002 20:29:07 -0700 From: Greg KH To: Keith Owens Cc: netdev@oss.sgi.com, linux-security-module@wirex.com Subject: Re: [PATCH] LSM networking: skb hooks for 2.5.42 (2/7) Message-ID: <20021019032907.GC12716@kroah.com> References: <4301.1034994787@ocs3.intra.ocs.com.au> <4914.1034996075@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4914.1034996075@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.4i X-archive-position: 781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev On Sat, Oct 19, 2002 at 12:54:35PM +1000, Keith Owens wrote: > Not that it makes any difference, there has to be a way to make that > size 0 when LSM is compiled off. Already done, see the patches sent to lkml yesterday :) thanks, greg k-h From Robert.Olsson@data.slu.se Sat Oct 19 00:46:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 00:46:37 -0700 (PDT) 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 g9J7kYtG005290 for ; Sat, 19 Oct 2002 00:46:35 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id JAA29291; Sat, 19 Oct 2002 09:53:27 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15793.3958.926796.634263@robur.slu.se> Date: Sat, 19 Oct 2002 09:53:26 +0200 To: Cc: "'Robert Olsson'" , Subject: RE: [Question] SMP for Linux In-Reply-To: <000b01c276fe$46626720$3701020a@CONCORDIA> References: <15792.13249.474279.391081@robur.slu.se> <000b01c276fe$46626720$3701020a@CONCORDIA> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 782 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 Jon Fraser writes: > The e1000 driver has been modified in a couple of ways. > The interrupts have been limited to 5k/second per card. This > mimics the actual hardware being shipped which uses an > intel 82543 chip but has an fpga used to do some > control functions and generate the interrupts. > > We also don't use any transmit interrupts. The Tx ring > is not cleaned at interrupt time. It's cleaned when > we transmit frames and the number of free tx descriptors > drops below a threshold. I also have some code which > directs the freed skb back to the cpu it was allocated on, > but it's not in this driver version. NAPI stuff will do interrupt mitigation for you. You probably get a lot less RX interrupts at your loads. I did the old trick to clean TX-buffers at hard_xmit as well but don't see any particularly win from this. Input 1.14 Mpps. Both eth0, eth1 bound to CPU0 Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 4313221 8316434 8316434 5658887 28 0 0 0 BRU eth1 1500 0 23 0 0 0 4313217 0 0 0 BRU e1000 messes up RX-ERR and RX-DRP as seen but you see TX-OK on eth1. 491 kpps. CPU0 CPU1 24: 53005 1 IO-APIC-level eth1 25: 19 0 IO-APIC-level eth0 Alltogether 19 RX and 53k TX interrupts was used. 0041d09c 00000000 000038d9 00000000 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 RC hit/miss = 4313099/384 And this run used "bound" w. private skb receycling. > bound float split > cpu % cpu% cpu% > ----------------------- > 1 flow 290 270 290 > 99%x1 65%x2 99%x1 > > 2 flows 270 380 450 > 99%x1 82%x2 96%x2 Looks promising that you get aggregated performance from SMP. But "float" is the number to look for... It's almost impossible to use any device binding with forwarding at least as a general solution. > Previously, I've used the CPU performance monitoring counters > to find that cache invalidates tends to be a big problem when > the interrupts are not bound to a pariticular cpu. Bind the > card to a particular interrupt effectively binds the flow to > a particular cpu. Hope to verify this for "kfree-route" test. Did you use oprofile for performance counters? > 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? Cheers. --ro From pekkas@netcore.fi Sat Oct 19 04:39:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 04:39:10 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JBd3tG026072 for ; Sat, 19 Oct 2002 04:39:04 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9JBcuu12165 for ; Sat, 19 Oct 2002 14:38:57 +0300 Date: Sat, 19 Oct 2002 14:38:56 +0300 (EEST) From: Pekka Savola To: netdev@oss.sgi.com Subject: Re: Ambiguities in TCP/IP - firewall bypassing (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 783 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 See the thread on bugtraq. Linux 2.4.19 initiates TCP handshake with SYN and RST bits set. SYN with _RST_ seems like a total nonsense (SYN with FIN might even be useful for stuff like T/TCP) but I guess the spec didn't take any stance on that.. -- 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 ---------- Forwarded message ---------- Date: Sat, 19 Oct 2002 01:03:47 +0200 From: Florian Weimer To: Paul Starzetz Subject: Re: Ambiguities in TCP/IP - firewall bypassing Paul Starzetz writes: > * Linux 2.4.19 > > The examination of the source code of the TCP engine reveals that a > TCP connection can be opened by any combination of the TCP flags > having the SYN bit set and the ACK bit reset. For example we can open > a TCP connection by sending an obviously bogus SYN,RST packet: > > 14:25:43.888897 192.168.1.184.12345 > 192.168.1.111.9999: SR > 420:420(0) win 512 (DF) [tos 0x18] > 14:25:43.889143 192.168.1.111.9999 > 192.168.1.184.12345: S > 2168208394:2168208394(0) ack 421 win 5840 (DF) As a result of this bug, it's quite complicated (if not impossible in some configurations) to properly filter connection attempts to Linux hosts on Cisco IOS routers. If your access list is a whitelist with a "permit tcp any any established" statement somewhere, it's very likely that you can bypass the filter just by setting the RST in the initial SYN packet, as described above. The router will forward the packet, and the Linux host will happily initiate the three-way handshake. "established" in Cisco parlance does not mean "SYN unset", but "ACK or RST set". This means that the impact for non-Linux hosts (which do not react to SYN-RST packets according to Paul's survey) is less severe if your filters run IOS. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From greearb@candelatech.com Sat Oct 19 14:07:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 14:07:02 -0700 (PDT) Received: from grok.yi.org (IDENT:sRP9b9C+vv/cRu/iruLMgTZvls4WQH5y@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JL6wtG007067 for ; Sat, 19 Oct 2002 14:06:59 -0700 Received: from candelatech.com (IDENT:6zgMrdgIpYW1g96+RdyMaJ17HQNqMSml@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9JL6pq31736; Sat, 19 Oct 2002 14:06:52 -0700 Message-ID: <3DB1C96B.4070505@candelatech.com> Date: Sat, 19 Oct 2002 14:06:51 -0700 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: Jason Lunz CC: netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Jason Lunz wrote: > I figure a few people on this list will be interested in this: > > http://www.softwareandstuff.com/h_comp_inet4.html > > The site says almost nothing about the cards, but on a tip from a > coworker I bought one the last time this site had them for sale, and > have been extremely happy with it. lspci shows: I just got mine, and ordered a bunch more... These are the Phobos p430 NICs. I have extensively benchmarked 2 of those NICs that I got as eval copies, and they perform as good as or better than the 570tx, using the standard tulip driver. I just noticed lots of these are on eBay too, so I'm guessing a whole bunch of them got surplussed. This is good news for me, because they are too expensive if you try to purchase them from other channels! Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From shaeffer@neuralscape.com Sat Oct 19 14:23:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 14:23:41 -0700 (PDT) Received: from synapse.neuralscape.com ([198.144.200.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLNdtG008808 for ; Sat, 19 Oct 2002 14:23:39 -0700 Received: (from shaeffer@localhost) by synapse.neuralscape.com (8.11.6/8.11.6) id g9JLEHJ11673; Sat, 19 Oct 2002 14:14:17 -0700 Date: Sat, 19 Oct 2002 14:14:17 -0700 From: Karen Shaeffer To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available Message-ID: <20021019141417.A11659@synapse.neuralscape.com> References: <3DB1C96B.4070505@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DB1C96B.4070505@candelatech.com>; from greearb@candelatech.com on Sat, Oct 19, 2002 at 02:06:51PM -0700 X-archive-position: 785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shaeffer@neuralscape.com Precedence: bulk X-list: netdev On Sat, Oct 19, 2002 at 02:06:51PM -0700, Ben Greear wrote: > > http://www.softwareandstuff.com/h_comp_inet4.html > > > > The site says almost nothing about the cards, but on a tip from a > > coworker I bought one the last time this site had them for sale, and > > have been extremely happy with it. lspci shows: > > I just got mine, and ordered a bunch more... > > These are the Phobos p430 NICs. I have extensively benchmarked 2 > of those NICs that I got as eval copies, and they perform as good > as or better than the 570tx, using the standard tulip driver. I'm just curious. What do you do with a bunch of those cards? Do you put them in a PC and make a switch out of it? cheers, Karen -- Karen Shaeffer Neuralscape; Santa Cruz, Ca. 95060 shaeffer@neuralscape.com http://www.neuralscape.com From rgb@conscoop.ottawa.on.ca Sat Oct 19 14:27:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 14:27:19 -0700 (PDT) Received: from conscoop.ottawa.on.ca (cpu2747.adsl.bellglobal.com [207.236.55.216]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLRGtG009425 for ; Sat, 19 Oct 2002 14:27:16 -0700 Received: (from rgb@localhost) by conscoop.ottawa.on.ca (8.12.0.Beta5/8.11.6) id g9JLRxTX022351; Sat, 19 Oct 2002 17:27:59 -0400 Date: Sat, 19 Oct 2002 17:27:59 -0400 From: Richard Guy Briggs To: Karen Shaeffer Cc: Ben Greear , netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available Message-ID: <20021019172759.I9059@grendel.conscoop.ottawa.on.ca> References: <3DB1C96B.4070505@candelatech.com> <20021019141417.A11659@synapse.neuralscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021019141417.A11659@synapse.neuralscape.com>; from shaeffer@neuralscape.com on Sat, Oct 19, 2002 at 02:14:17PM -0700 X-archive-position: 786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgb@conscoop.ottawa.on.ca Precedence: bulk X-list: netdev On Sat, Oct 19, 2002 at 02:14:17PM -0700, Karen Shaeffer wrote: > On Sat, Oct 19, 2002 at 02:06:51PM -0700, Ben Greear wrote: > > > http://www.softwareandstuff.com/h_comp_inet4.html > > > > > > The site says almost nothing about the cards, but on a tip from a > > > coworker I bought one the last time this site had them for sale, and > > > have been extremely happy with it. lspci shows: > > > > I just got mine, and ordered a bunch more... > > > > These are the Phobos p430 NICs. I have extensively benchmarked 2 > > of those NICs that I got as eval copies, and they perform as good > > as or better than the 570tx, using the standard tulip driver. > > I'm just curious. What do you do with a bunch of those cards? Do you put > them in a PC and make a switch out of it? Or a firewall... Or a router... > cheers, > Karen > -- > Karen Shaeffer > Neuralscape; Santa Cruz, Ca. 95060 > shaeffer@neuralscape.com http://www.neuralscape.com > slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ From greearb@candelatech.com Sat Oct 19 14:32:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 14:32:18 -0700 (PDT) Received: from grok.yi.org (IDENT:VFzTicXotpaAOUMk8qhqjFH0LkphsHX2@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLWEtG010153 for ; Sat, 19 Oct 2002 14:32:15 -0700 Received: from candelatech.com (IDENT:LbYplbu6OakazXVv2BsgYSDiGcDEJtPu@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9JLWAq03314; Sat, 19 Oct 2002 14:32:10 -0700 Message-ID: <3DB1CF5A.9080701@candelatech.com> Date: Sat, 19 Oct 2002 14:32:10 -0700 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: Karen Shaeffer CC: netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available References: <3DB1C96B.4070505@candelatech.com> <20021019141417.A11659@synapse.neuralscape.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 787 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 Karen Shaeffer wrote: > On Sat, Oct 19, 2002 at 02:06:51PM -0700, Ben Greear wrote: > >>>http://www.softwareandstuff.com/h_comp_inet4.html >>> >>>The site says almost nothing about the cards, but on a tip from a >>>coworker I bought one the last time this site had them for sale, and >>>have been extremely happy with it. lspci shows: >> >>I just got mine, and ordered a bunch more... >> >>These are the Phobos p430 NICs. I have extensively benchmarked 2 >>of those NICs that I got as eval copies, and they perform as good >>as or better than the 570tx, using the standard tulip driver. > > > I'm just curious. What do you do with a bunch of those cards? Do you put > them in a PC and make a switch out of it? I make traffic generators out of them (www.candelatech.com) They are also good for firewalls and routers, as well as more exotic network devices. Using linux for a switch does not make so much sense these days when you can buy a 16 port switch for under $100, but with bridging code it can be done. Ben > > cheers, > Karen -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From shaeffer@neuralscape.com Sat Oct 19 14:38:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 14:38:16 -0700 (PDT) Received: from synapse.neuralscape.com ([198.144.200.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLcDtG010935 for ; Sat, 19 Oct 2002 14:38:14 -0700 Received: (from shaeffer@localhost) by synapse.neuralscape.com (8.11.6/8.11.6) id g9JLSb311705; Sat, 19 Oct 2002 14:28:37 -0700 Date: Sat, 19 Oct 2002 14:28:36 -0700 From: Karen Shaeffer To: Richard Guy Briggs Cc: greearb@candelatech.com, netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available Message-ID: <20021019142836.B11659@synapse.neuralscape.com> References: <3DB1C96B.4070505@candelatech.com> <20021019141417.A11659@synapse.neuralscape.com> <20021019172759.I9059@grendel.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021019172759.I9059@grendel.conscoop.ottawa.on.ca>; from rgb@conscoop.ottawa.on.ca on Sat, Oct 19, 2002 at 05:27:59PM -0400 X-archive-position: 788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shaeffer@neuralscape.com Precedence: bulk X-list: netdev On Sat, Oct 19, 2002 at 05:27:59PM -0400, Richard Guy Briggs wrote: > > > > I'm just curious. What do you do with a bunch of those cards? Do you put > > them in a PC and make a switch out of it? > > Or a firewall... Or a router... OK, I actually have 4 nics in a PC based router/firewall. But I wouldn't get excited about buying a bunch of those cards. I'm just having a little fun-- humor me. ;) Thanks for your comment. cheers, Karen -- Karen Shaeffer Neuralscape; Santa Cruz, Ca. 95060 shaeffer@neuralscape.com http://www.neuralscape.com From shaeffer@neuralscape.com Sat Oct 19 14:51:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 14:52:01 -0700 (PDT) Received: from synapse.neuralscape.com ([198.144.200.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLputG012282 for ; Sat, 19 Oct 2002 14:51:56 -0700 Received: (from shaeffer@localhost) by synapse.neuralscape.com (8.11.6/8.11.6) id g9JLgaE11730; Sat, 19 Oct 2002 14:42:36 -0700 Date: Sat, 19 Oct 2002 14:42:36 -0700 From: Karen Shaeffer To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available Message-ID: <20021019144236.C11659@synapse.neuralscape.com> References: <3DB1C96B.4070505@candelatech.com> <20021019141417.A11659@synapse.neuralscape.com> <3DB1CF5A.9080701@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DB1CF5A.9080701@candelatech.com>; from greearb@candelatech.com on Sat, Oct 19, 2002 at 02:32:10PM -0700 X-archive-position: 789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shaeffer@neuralscape.com Precedence: bulk X-list: netdev On Sat, Oct 19, 2002 at 02:32:10PM -0700, Ben Greear wrote: > Karen Shaeffer wrote: > > On Sat, Oct 19, 2002 at 02:06:51PM -0700, Ben Greear wrote: > > > I make traffic generators out of them (www.candelatech.com) > > They are also good for firewalls and routers, as well as more > exotic network devices. Using linux for a switch does not make so > much sense these days when you can buy a 16 port switch for under $100, > but with bridging code it can be done. Actually, I think linux based switches could be quite interesting in a pipelined, beowulf-like or openmosix cluster. (Of course, GigE would probably be employed rather than FE.) You could then integrate traffic shaping/monitoring functionality into the switch that could be designed to interoperate with the cluster nodes to assist in optimizing data flow and subsequent processing. With openmosix, this could also be used to migrate processes towards optimum node placement, based on network traffic analysis as well as nodal resource availability. It's a subject I've been thinking about quite a bit lately. This is most interesting in adaptive, pipelined clusters that will be processing real-time streaming data. That's certainly a niche market at the present time. cheers, Karen -- Karen Shaeffer Neuralscape; Santa Cruz, Ca. 95060 shaeffer@neuralscape.com http://www.neuralscape.com From greearb@candelatech.com Sat Oct 19 15:00:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 15:00:02 -0700 (PDT) Received: from grok.yi.org (IDENT:8NGvGAIBxCCPKcLvOYHa3TLu0RZuHOW/@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JLxxtG013672 for ; Sat, 19 Oct 2002 14:59:59 -0700 Received: from candelatech.com (IDENT:xqquxT9V0qyK+NX+XyhY5Ov3UuLo52v3@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9JLxuq12612; Sat, 19 Oct 2002 14:59:56 -0700 Message-ID: <3DB1D5DC.6040800@candelatech.com> Date: Sat, 19 Oct 2002 14:59:56 -0700 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: Karen Shaeffer CC: netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available References: <3DB1C96B.4070505@candelatech.com> <20021019141417.A11659@synapse.neuralscape.com> <3DB1CF5A.9080701@candelatech.com> <20021019144236.C11659@synapse.neuralscape.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 790 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 Karen Shaeffer wrote: > On Sat, Oct 19, 2002 at 02:32:10PM -0700, Ben Greear wrote: > >>Karen Shaeffer wrote: >> >>>On Sat, Oct 19, 2002 at 02:06:51PM -0700, Ben Greear wrote: >>> >> >>I make traffic generators out of them (www.candelatech.com) >> >>They are also good for firewalls and routers, as well as more >>exotic network devices. Using linux for a switch does not make so >>much sense these days when you can buy a 16 port switch for under $100, >>but with bridging code it can be done. > > > Actually, I think linux based switches could be quite interesting in > a pipelined, beowulf-like or openmosix cluster. (Of course, GigE would > probably be employed rather than FE.) You could then integrate traffic > shaping/monitoring functionality into the switch that could be designed > to interoperate with the cluster nodes to assist in optimizing data flow > and subsequent processing. With openmosix, this could also be used to > migrate processes towards optimum node placement, based on network > traffic analysis as well as nodal resource availability. > > It's a subject I've been thinking about quite a bit lately. This is most > interesting in adaptive, pipelined clusters that will be processing > real-time streaming data. That's certainly a niche market at the present > time. Right now, you'll have a tough time getting a single GigE NIC to run line speed, full duplex. However, I've thought about writing a controlling process that monitors and dynamically configures a switch though SNMP or some other API. That way, you could migrate machines across LANs/VLANs to better distribute your traffic. And, you could keep all your traffic running line speed (or however fast your switches run) > > cheers, > Karen -- 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 Sat Oct 19 15:03:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 15:03:38 -0700 (PDT) Received: from grok.yi.org (IDENT:38F27T9tmHzxMWvI8f7g/tFqkarvAOi5@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JM3YtG014340 for ; Sat, 19 Oct 2002 15:03:34 -0700 Received: from candelatech.com (IDENT:J5EnCVnDTIFs318omK80fKSVQNB/mbMc@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9JM3Xq13167 for ; Sat, 19 Oct 2002 15:03:33 -0700 Message-ID: <3DB1D6B5.6080305@candelatech.com> Date: Sat, 19 Oct 2002 15:03:33 -0700 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: tulip NAPI patch that works with 2.4.20-pre9 or so? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 791 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 The latest NAPI tulip patch I could find (tulip-020922.pat) will not load. The problem appears that the tulip_misc.c file no longer exists... If anyone has a newer patch, I'd love to try it out. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From rgooch@vindaloo.ras.ucalgary.ca Sat Oct 19 15:08:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 15:08:03 -0700 (PDT) Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9JM80tG015065 for ; Sat, 19 Oct 2002 15:08:00 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g9JM7tk27360; Sat, 19 Oct 2002 16:07:55 -0600 Date: Sat, 19 Oct 2002 16:07:55 -0600 Message-Id: <200210192207.g9JM7tk27360@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Karen Shaeffer Cc: Richard Guy Briggs , greearb@candelatech.com, netdev@oss.sgi.com Subject: Re: cheap 4-port tulip-based cards available In-Reply-To: <20021019142836.B11659@synapse.neuralscape.com> References: <3DB1C96B.4070505@candelatech.com> <20021019141417.A11659@synapse.neuralscape.com> <20021019172759.I9059@grendel.conscoop.ottawa.on.ca> <20021019142836.B11659@synapse.neuralscape.com> X-archive-position: 792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgooch@ras.ucalgary.ca Precedence: bulk X-list: netdev Karen Shaeffer writes: > On Sat, Oct 19, 2002 at 05:27:59PM -0400, Richard Guy Briggs wrote: > > > > > > I'm just curious. What do you do with a bunch of those cards? Do you put > > > them in a PC and make a switch out of it? > > > > Or a firewall... Or a router... > > OK, I actually have 4 nics in a PC based router/firewall. But I > wouldn't get excited about buying a bunch of those cards. I'm just > having a little fun-- humor me. ;) I used to have a desktop PC with 3 NICs running as a firewall. With a 4-port NIC and a Via/Cyrix C3 (low profile fan), I can fit a firewall into a 1U rackmount case. So, while it's a lot more troublesome getting a stable router with these 4-port cards :-(, it's worth it in the end if you've got space constraints. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From jgarzik@pobox.com Sat Oct 19 17:47:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 17:47:21 -0700 (PDT) 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 g9K0lEtG029348 for ; Sat, 19 Oct 2002 17:47:14 -0700 Received: from rdu74-162-005.nc.rr.com ([24.74.162.5] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 1834FL-0004X5-00; Sun, 20 Oct 2002 01:47:11 +0100 Message-ID: <3DB1FD1A.4020109@pobox.com> Date: Sat, 19 Oct 2002 20:47:22 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felipe W Damasio CC: Paul Hernandez , Linux-net , netdev@oss.sgi.com Subject: Re: NIC on 2.4.19 SMP References: <1035064119.2912.31.camel@tank> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 793 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 Felipe W Damasio wrote: > On Fri, 2002-10-18 at 16:57, Paul Hernandez wrote: > >>Hello, >> >>It was suggested to me that I forward this issue to you both. >> >>OS: 2.4.19.SuSE SMP >>Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 >>(latest bios off Intel site) >>On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) >>Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 >> >>dmesg output: >> >>e100: eth0: Intel(R) 8255x-based Ethernet Adapter > > >>SIOCGMIIPHY on eth0 failed: >>Operation not supported >>no MII interfaces found > > > Try using the eepro100.c driver from the kernel, and not the one from > Intel (the driver from the kernel supports SIOCGMIIPHY). > > Though it does not seem a problem with the driver, you should try using > the one from the kernel and see if it helps. I agree that comparison is useful, though it should be pointed out that ethtool is preferred for e100... Jeff From felipewd@terra.com.br Sat Oct 19 18:12:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 18:12:19 -0700 (PDT) Received: from sr1.terra.com.br (sr1.terra.com.br [200.176.3.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9K1C6tG031549 for ; Sat, 19 Oct 2002 18:12:07 -0700 Received: from pavuna.terra.com.br (pavuna.terra.com.br [200.176.3.41]) by sr1.terra.com.br (Postfix) with ESMTP id D5CFC6ED65; Sat, 19 Oct 2002 21:44:57 -0300 (BRT) Received: from tank.coqueiro.org (unknown [200.180.178.156]) (authenticated user felipewd) by pavuna.terra.com.br (Postfix) with ESMTP id E6B28683AE; Sat, 19 Oct 2002 21:44:56 -0300 (BRT) Subject: Re: NIC on 2.4.19 SMP From: Felipe W Damasio To: Paul Hernandez Cc: Linux-net , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Oct 2002 21:48:39 +0000 Message-Id: <1035064119.2912.31.camel@tank> Mime-Version: 1.0 X-archive-position: 794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipewd@terra.com.br Precedence: bulk X-list: netdev On Fri, 2002-10-18 at 16:57, Paul Hernandez wrote: > Hello, > > It was suggested to me that I forward this issue to you both. > > OS: 2.4.19.SuSE SMP > Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 > (latest bios off Intel site) > On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) > Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 > > dmesg output: > > e100: eth0: Intel(R) 8255x-based Ethernet Adapter > SIOCGMIIPHY on eth0 failed: > Operation not supported > no MII interfaces found Try using the eepro100.c driver from the kernel, and not the one from Intel (the driver from the kernel supports SIOCGMIIPHY). Though it does not seem a problem with the driver, you should try using the one from the kernel and see if it helps. If it doesn't, reply this mail with the mii-diag output (and driver version). Felipe From weixl@cs.caltech.edu Sat Oct 19 21:29:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 21:29:18 -0700 (PDT) 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 g9K4TEtG012166 for ; Sat, 19 Oct 2002 21:29:14 -0700 Received: from weixl (sonata.caltech.edu [131.215.220.1]) by swordfish.cs.caltech.edu (Postfix) with SMTP id 3E3EADF279 for ; Sat, 19 Oct 2002 21:29:14 -0700 (PDT) Message-ID: <002301c277f1$2f6afe80$f5f2010a@weixl> From: "Xiaoliang (David) Wei" To: Subject: The "retrans_out leaked." Date: Sat, 19 Oct 2002 21:28:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weixl@cs.caltech.edu Precedence: bulk X-list: netdev Hi Everyone, I tried to change tcp with a tentative congestion control algorithm. But sometimes, I got "retrans_out leaked." message, followed by series of "KERNEL: assertion ((int)tcp_packets_in_flight(tp) >= 0) failed at tcp_input.c" (generated at the end of tcp_sacktag_write_queue, where there are serveral assertions: #if FASTRETRANS_DEBUG > 0 BUG_TRAP((int)tp->sacked_out >= 0); BUG_TRAP((int)tp->lost_out >= 0); BUG_TRAP((int)tp->retrans_out >= 0); BUG_TRAP((int)tcp_packets_in_flight(tp) >= 0); #endif ) Then, after a long list of such assertion failure, the kernel crashed with some message saying intterupt handler error.... Can anyone tell me what's the possible problems? Also, how inaccurate is the packets_in_flight() calculation? Can it be negative? Thank you very much. Xiaoliang (David) Wei Graduate Student in CS@Caltech http://www.cs.caltech.edu/~weixl ==================================================== From ak@suse.de Sat Oct 19 21:35:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 19 Oct 2002 21:35:46 -0700 (PDT) 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 g9K4ZftG012867 for ; Sat, 19 Oct 2002 21:35:42 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id B5E0B1433B; Sun, 20 Oct 2002 06:35:35 +0200 (MEST) Date: Sun, 20 Oct 2002 06:35:35 +0200 From: Andi Kleen To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: Ambiguities in TCP/IP - firewall bypassing (fwd) Message-ID: <20021020063535.A6016@wotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-archive-position: 796 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 Sat, Oct 19, 2002 at 02:38:56PM +0300, Pekka Savola wrote: > See the thread on bugtraq. > > Linux 2.4.19 initiates TCP handshake with SYN and RST bits set. SYN with > _RST_ seems like a total nonsense (SYN with FIN might even be useful for > stuff like T/TCP) but I guess the spec didn't take any stance on that.. Here is a patch to fix it for 2.4.19. --- linux/net/ipv4/tcp_input.c-o 2002-10-15 17:24:53.000000000 +0200 +++ linux/net/ipv4/tcp_input.c 2002-10-20 06:34:05.000000000 +0200 @@ -3664,6 +3664,9 @@ goto discard; case TCP_LISTEN: + if(th->rst) + goto discard; + if(th->ack) return 1; -Andi From bctraore@netscape.net Sun Oct 20 03:50:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 03:50:59 -0700 (PDT) Received: from oss.sgi.com (node-c-3f09.a2000.nl [62.194.63.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KAootG009010 for ; Sun, 20 Oct 2002 03:50:52 -0700 Message-Id: <200210201050.g9KAootG009010@oss.sgi.com> From: "Benson Cisse Traore" Date: Sun, 20 Oct 2002 12:50:40 To: netdev@oss.sgi.com Subject: YOUR STRICTEST CONFIDENCE REQUIRED. MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bctraore@netscape.net Precedence: bulk X-list: netdev Hello, However strange or surprising this contact might seem to you, I ask that you give due consideration to its importance, as we both stand to benefit immensely. Though we have not met or know each other, this is a criteria I have used to select you, as I wish to cut off all ties with my people for security and safety reasons. At this point I wish to introduce myself properly to you. My name is Benson Cisse Traore, I am a personal aide to the Late General Robert Guei of blessed memory, former President of Cote de Ivoire (Ivory Coast). I do not know if you are conversant with the present situation in my country, which has gradually become a civil war. For the sake of what I envisage we achieve together, I wish to give you a general overview. We have had an undefined polity in my country. Founding president, Felix Houphouet-Boigny ruled us with individual blend of paternalism from independence in 1960 until his death in December 1993. He bowed to pressure for multi-party politics in 1990. In 1993, National Assembly president Henri Konan Bedie won a brief power struggle with Prime Minister Alassane Ouattara to succeed Houphouet-Boigny. The following month, the former single Ruling democratic Party set up by Houphouet-Boigny, then headed by Bedie won an overwhelming majority in the National assembly. On December 24, 1999, my mentor Gen. Robert Guei ousted Bedie in a coup de tat. Although this was highly criticized, but it was the right thing to do. In July 2000, Gen. Guei approved a new constitution in referendum with tough eligibility conditions for presidential candidates. In spite of criticism, he registered as a candidate. The Supreme Court intervened, and he was cleared. This was not totally acceptable to the other candidates from the ruling Democratic Party (PDCI-RDA), the country's largest. The only opponent was Socialist candidate Laurent Gbagbo. Admittedly, Gbagbo won the election of October 22, 2000, but his political immaturity, led to Gen. Guei being reluctant to relinquish power. There were allegations of election rigging etc. Ouattara who was previously barred by the referendum to contest election, was excluded from the December 10 parliamentary election because of doubts about his nationality and his supporters announced they would boycott the election. Gbagbos Popular Front (FPI) was victorious in the election, and there were demonstrations due to propaganda that Gen. Guei tried to rig the election. Under pressure from international donors, Gbagbo agreed to hold a reconciliation forum to draw a line under the political strife that followed the 1999 coup, but key players including Outtara failed to show up for the opening. After two years of build up, On September 19, 2002, Gen. Guei led a failed coup de tat against Gbagbo, in a bid to restore political stability. Unfortunately, he was killed. After Gen. Gueis death, there was turmoil in our camp; this has led to us losing half our strength. Although we still control the north and Central regions of the country. It is now a question of who will give in between us (now referred to as rebels) and Gbagbos government. There seem to be no chance for peace, as several attempts has been botched by Gbagbo. The US and France has since evacuated their citizens from our country. Destruction is imminent, as ECOWAS (Economy Community of West African States) has been called in to mediate. Their only way of doing this is to bring in ECOMOG (A monitoring group). We witnessed the horror they caused trying to restore peace to Liberia and Sierra Leone during the civil war. Thus I have lost faith and hope in the struggle. To the point, the essence of my contact with you is to seek your most needed assistance to siphon US$18,500,000 given to me for the purchase of arms and ammunination. Our Armory is seriously depleting, and I was sent on an emissary to make the purchase to strengthen our armory to prosecute the war. I have now decided to abandon the war and use this money for my personal benefit (as well as yours if you accept to be my partner). I see justification in diverting the money, rather than proceeding with the purchase of weapons for destruction of innocent lives and properties. This money was moved in cash to my present location in Europe through diplomatic means, and I have since deposited the trunk containing the funds with a private security company. If you accept to offer me your assistance, I will require that you assist me in claiming the box as a gift from me to you from the security company. Be informed that I am confiding in you by disclosing this to you, as it is only me (apparently you now) that have knowledge of this. When the box is claimed, we shall then have the money deposited into an account in your name, as I am being discrete of using my name for now. Then you shall have your own share withdrawn to an account of your choice, and leaving the rest as fixed deposit, for release to me at the appropriate time. The importance of prosecuting this in the next few days cannot be overlooked; hence your immediate response will be highly appreciated. On hearing from you, I shall disclose my location to you, and discuss the share of the money you will be entitled to for offering me your most needed assistance. In case you are not inclined to render me your assistance, endeavor to respond, so that I may move ahead. You may click this link http://news.bbc.co.uk/1/hi/world/africa/930254.stm to see me with my mentor Gen. Guei in 1999, so that you may associate this correspondence to my face. Sincerely, B. C. Traore. From bctraore@netscape.net Sun Oct 20 08:51:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 08:51:26 -0700 (PDT) Received: from oss.sgi.com (node-c-3f09.a2000.nl [62.194.63.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KFpGtG001648 for ; Sun, 20 Oct 2002 08:51:20 -0700 Message-Id: <200210201551.g9KFpGtG001648@oss.sgi.com> From: "Benson Cisse Traore" Date: Sun, 20 Oct 2002 17:51:05 To: netdev@oss.sgi.com Subject: YOUR STRICTEST CONFIDENCE REQUIRED. MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bctraore@netscape.net Precedence: bulk X-list: netdev Hello, However strange or surprising this contact might seem to you, I ask that you give due consideration to its importance, as we both stand to benefit immensely. Though we have not met or know each other, this is a criteria I have used to select you, as I wish to cut off all ties with my people for security and safety reasons. At this point I wish to introduce myself properly to you. My name is Benson Cisse Traore, I am a personal aide to the Late General Robert Guei of blessed memory, former President of Cote de Ivoire (Ivory Coast). I do not know if you are conversant with the present situation in my country, which has gradually become a civil war. For the sake of what I envisage we achieve together, I wish to give you a general overview. We have had an undefined polity in my country. Founding president, Felix Houphouet-Boigny ruled us with individual blend of paternalism from independence in 1960 until his death in December 1993. He bowed to pressure for multi-party politics in 1990. In 1993, National Assembly president Henri Konan Bedie won a brief power struggle with Prime Minister Alassane Ouattara to succeed Houphouet-Boigny. The following month, the former single Ruling democratic Party set up by Houphouet-Boigny, then headed by Bedie won an overwhelming majority in the National assembly. On December 24, 1999, my mentor Gen. Robert Guei ousted Bedie in a coup de tat. Although this was highly criticized, but it was the right thing to do. In July 2000, Gen. Guei approved a new constitution in referendum with tough eligibility conditions for presidential candidates. In spite of criticism, he registered as a candidate. The Supreme Court intervened, and he was cleared. This was not totally acceptable to the other candidates from the ruling Democratic Party (PDCI-RDA), the country's largest. The only opponent was Socialist candidate Laurent Gbagbo. Admittedly, Gbagbo won the election of October 22, 2000, but his political immaturity, led to Gen. Guei being reluctant to relinquish power. There were allegations of election rigging etc. Ouattara who was previously barred by the referendum to contest election, was excluded from the December 10 parliamentary election because of doubts about his nationality and his supporters announced they would boycott the election. Gbagbos Popular Front (FPI) was victorious in the election, and there were demonstrations due to propaganda that Gen. Guei tried to rig the election. Under pressure from international donors, Gbagbo agreed to hold a reconciliation forum to draw a line under the political strife that followed the 1999 coup, but key players including Outtara failed to show up for the opening. After two years of build up, On September 19, 2002, Gen. Guei led a failed coup de tat against Gbagbo, in a bid to restore political stability. Unfortunately, he was killed. After Gen. Gueis death, there was turmoil in our camp; this has led to us losing half our strength. Although we still control the north and Central regions of the country. It is now a question of who will give in between us (now referred to as rebels) and Gbagbos government. There seem to be no chance for peace, as several attempts has been botched by Gbagbo. The US and France has since evacuated their citizens from our country. Destruction is imminent, as ECOWAS (Economy Community of West African States) has been called in to mediate. Their only way of doing this is to bring in ECOMOG (A monitoring group). We witnessed the horror they caused trying to restore peace to Liberia and Sierra Leone during the civil war. Thus I have lost faith and hope in the struggle. To the point, the essence of my contact with you is to seek your most needed assistance to siphon US$18,500,000 given to me for the purchase of arms and ammunination. Our Armory is seriously depleting, and I was sent on an emissary to make the purchase to strengthen our armory to prosecute the war. I have now decided to abandon the war and use this money for my personal benefit (as well as yours if you accept to be my partner). I see justification in diverting the money, rather than proceeding with the purchase of weapons for destruction of innocent lives and properties. This money was moved in cash to my present location in Europe through diplomatic means, and I have since deposited the trunk containing the funds with a private security company. If you accept to offer me your assistance, I will require that you assist me in claiming the box as a gift from me to you from the security company. Be informed that I am confiding in you by disclosing this to you, as it is only me (apparently you now) that have knowledge of this. When the box is claimed, we shall then have the money deposited into an account in your name, as I am being discrete of using my name for now. Then you shall have your own share withdrawn to an account of your choice, and leaving the rest as fixed deposit, for release to me at the appropriate time. The importance of prosecuting this in the next few days cannot be overlooked; hence your immediate response will be highly appreciated. On hearing from you, I shall disclose my location to you, and discuss the share of the money you will be entitled to for offering me your most needed assistance. In case you are not inclined to render me your assistance, endeavor to respond, so that I may move ahead. You may click this link http://news.bbc.co.uk/1/hi/world/africa/930254.stm to see me with my mentor Gen. Guei in 1999, so that you may associate this correspondence to my face. Sincerely, B. C. Traore. From kaos@ocs.com.au Sun Oct 20 09:39:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 09:39:54 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KGdktG005162 for ; Sun, 20 Oct 2002 09:39:47 -0700 Received: (qmail 25621 invoked from network); 20 Oct 2002 16:39:44 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 20 Oct 2002 16:39:44 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 1EBE8300B3D; Mon, 21 Oct 2002 02:39:40 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id DC9EB108F; Mon, 21 Oct 2002 02:39:40 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: abuse@a2000.nl Cc: netdev@oss.sgi.com Subject: Re: YOUR STRICTEST CONFIDENCE REQUIRED. In-reply-to: Your message of "Sun, 20 Oct 2002 17:51:05." <200210201551.g9KFpGtG001648@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 02:39:35 +1000 Message-ID: <25469.1035131975@ocs3.intra.ocs.com.au> X-archive-position: 799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: netdev On Sun, 20 Oct 2002 17:51:05, "Benson Cisse Traore" wrote: >[Nigerian 419 spam deleted] Sigh, yet another spam from a2000.nl users, now they are attacking mailing lists. I strongly suggest that all mailing lists block a2000.nl. Repeated complaints to this ISP have been ignored, blocking them seems to be the only thing they take any notice of. From Robert.Olsson@data.slu.se Sun Oct 20 12:53:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 12:53:36 -0700 (PDT) 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 g9KJrWtG020083 for ; Sun, 20 Oct 2002 12:53:33 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id WAA30023; Sun, 20 Oct 2002 22:00:22 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15795.2902.180818.661384@robur.slu.se> Date: Sun, 20 Oct 2002 22:00:22 +0200 To: Ben Greear Cc: "'netdev@oss.sgi.com'" Subject: tulip NAPI patch that works with 2.4.20-pre9 or so? In-Reply-To: <3DB1D6B5.6080305@candelatech.com> References: <3DB1D6B5.6080305@candelatech.com> X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 800 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: > The latest NAPI tulip patch I could find (tulip-020922.pat) > will not load. The problem appears that the tulip_misc.c file > no longer exists... :-( I'll look into it. > If anyone has a newer patch, I'd love to try it out. Try Jamal's drop-in-replacement http://www.cyberus.ca/~hadi/patches/tulip-napi.tgz Cheers. --ro From greearb@candelatech.com Sun Oct 20 14:03:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 14:03:53 -0700 (PDT) Received: from grok.yi.org (IDENT:RZInynDq76svCsEBCtxGL2ICVc1Shkgm@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KL3ltG025122 for ; Sun, 20 Oct 2002 14:03:48 -0700 Received: from candelatech.com (IDENT:OdmORa/KucqrGUp4JTYrrO4RH4B3miG3@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9KL3kq16816 for ; Sun, 20 Oct 2002 14:03:46 -0700 Message-ID: <3DB31A32.9020107@candelatech.com> Date: Sun, 20 Oct 2002 14:03:46 -0700 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: reserving skbuffs for the drivers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 801 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'm getting dropped rx packets because the network driver cannot allocate an skbuf in time, evidently.... I have 256MB of RAM, is there some way to increase the amount of RAM that the kernel keeps around for GFP_ATOMIC allocations? Documentation I find talks about buffermem and freepages, which looks hopeful, but they appear to no longer be in the proc file system as tunables??? 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 Sun Oct 20 15:45:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 15:45:07 -0700 (PDT) Received: from grok.yi.org (IDENT:KsWXDU7770I/An543k37VtgthLnedYSX@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KMj1tG031246 for ; Sun, 20 Oct 2002 15:45:01 -0700 Received: from candelatech.com (IDENT:fIGCm/vPlcmQkKTQUSfCDb9Oe0RBODu9@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9KMilq03872; Sun, 20 Oct 2002 15:44:47 -0700 Message-ID: <3DB331DF.9090401@candelatech.com> Date: Sun, 20 Oct 2002 15:44:47 -0700 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: tulip NAPI patch that works with 2.4.20-pre9 or so? References: <3DB1D6B5.6080305@candelatech.com> <15795.2902.180818.661384@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 802 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: > > The latest NAPI tulip patch I could find (tulip-020922.pat) > > will not load. The problem appears that the tulip_misc.c file > > no longer exists... > > :-( I'll look into it. > > > > If anyone has a newer patch, I'd love to try it out. > > Try Jamal's drop-in-replacement > http://www.cyberus.ca/~hadi/patches/tulip-napi.tgz This one froze up after a few seconds on a p430 Phobos 4-port NIC. (60Mbps on one port, 10Mbps on the others) However, becker's driver hangs as well, and the 4x5 driver doesn't even get started... The driver in 2.4.20-pre9 works pretty good...but I seem to get rx lockups from time to time... Still trying to figure out how to work around that problem... I'll donate a NIC to a driver hacker if they think that will help them fix the problem. Thanks, 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 sandy@storm.ca Sun Oct 20 16:47:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 16:47:06 -0700 (PDT) Received: from mail.storm.ca (mail.storm.ca [209.87.239.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9KNkxtG003290 for ; Sun, 20 Oct 2002 16:47:00 -0700 Received: from storm.ca ([218.104.237.138]) by mail.storm.ca (8.11.6+Sun/8.11.6) with ESMTP id g9KNkiM02257; Sun, 20 Oct 2002 19:46:45 -0400 (EDT) Message-ID: <3DB41338.3070502@storm.ca> Date: Mon, 21 Oct 2002 07:46:16 -0700 From: Sandy Harris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mitsuru KANDA CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [Design] [PATCH] USAGI IPsec References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sandy@storm.ca Precedence: bulk X-list: netdev Mitsuru KANDA wrote: >Hello Linux kernel network maintainers, > >I'm a member of USAGI project. > >In IPv6 specifications, IPsec is mandatory. > >We implemented IPsec for Linux IP stack. > >At present, our implementation includes: > PF_KEY V2 interface, > Security Association Database and > Security Policy Database for whole IP versions, > IPsec for IPv6,(transport, tunnel mode), > IPsec for IPv4 (transport mode), > >Would you mind checking it ? > Is this code being checked in to the mainline kernel? Or becoming part of the CryptoAPI patch set? Bravo, in either case. How does that affect FreeS/WAN development? > > From davem@rth.ninka.net Sun Oct 20 19:30:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 19:30:06 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L2U3tG014344 for ; Sun, 20 Oct 2002 19:30:03 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9L2f8RU016458; Sun, 20 Oct 2002 19:41:08 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9L2f7KM016456; Sun, 20 Oct 2002 19:41:07 -0700 Subject: Re: [Design] [PATCH] USAGI IPsec From: "David S. Miller" To: Sandy Harris Cc: Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org In-Reply-To: <3DB41338.3070502@storm.ca> References: <3DB41338.3070502@storm.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Oct 2002 19:41:06 -0700 Message-Id: <1035168066.4817.1.camel@rth.ninka.net> Mime-Version: 1.0 X-archive-position: 804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@rth.ninka.net Precedence: bulk X-list: netdev > Is this code being checked in to the mainline kernel? Or becoming part > of the > CryptoAPI patch set? Bravo, in either case. We will be incorporating lots of ideas and small code pieces from USAGI's work, but most of the core engine will be a new implementation. A completely new CryptoAPI subsystem has been implemented so that full lists of page vectors can be passed into the ciphers, which is necessary for a clean IPSEC implementation. It is intended that this work will be complete (it isn't done as I type this) and pushed to Linus upon his return from vacation. From ak@suse.de Sun Oct 20 20:20:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 20:20:43 -0700 (PDT) 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 g9L3KbtG017814 for ; Sun, 20 Oct 2002 20:20:38 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 9F71E142BD; Mon, 21 Oct 2002 05:20:32 +0200 (MEST) Date: Mon, 21 Oct 2002 05:20:31 +0200 From: Andi Kleen To: Ben Greear Cc: "'netdev@oss.sgi.com'" Subject: Re: reserving skbuffs for the drivers Message-ID: <20021021052031.B16412@wotan.suse.de> References: <3DB31A32.9020107@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB31A32.9020107@candelatech.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 805 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 Sun, Oct 20, 2002 at 02:03:46PM -0700, Ben Greear wrote: > I'm getting dropped rx packets because the network > driver cannot allocate an skbuf in time, evidently.... > > I have 256MB of RAM, is there some way to increase the amount of RAM > that the kernel keeps around for GFP_ATOMIC allocations? > > Documentation I find talks about buffermem and freepages, which looks > hopeful, but they appear to no longer be in the proc file system as > tunables??? You should be asking on linux-mm, not on netdev. I've been complaining to the MM guys for years that they dropped freepages in 2.4, which makes it impossible to tune the VM for heavy network load, but so far nobody was interested in fixing it. -Andi From yoshfuji@linux-ipv6.org Sun Oct 20 20:43:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 20:43:36 -0700 (PDT) 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 g9L3hUtG019571 for ; Sun, 20 Oct 2002 20:43:31 -0700 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 g9L3h2HT017992; Mon, 21 Oct 2002 12:43:02 +0900 Date: Mon, 21 Oct 2002 12:42:57 +0900 (JST) Message-Id: <20021021.124257.131358184.yoshfuji@linux-ipv6.org> To: davem@rth.ninka.net Cc: sandy@storm.ca, mk@linux-ipv6.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [Design] [PATCH] USAGI IPsec From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1035168066.4817.1.camel@rth.ninka.net> References: <3DB41338.3070502@storm.ca> <1035168066.4817.1.camel@rth.ninka.net> 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-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: 806 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 <1035168066.4817.1.camel@rth.ninka.net> (at 20 Oct 2002 19:41:06 -0700), "David S. Miller" says: > > Is this code being checked in to the mainline kernel? Or becoming part > > of the > > CryptoAPI patch set? Bravo, in either case. > > We will be incorporating lots of ideas and small code pieces > from USAGI's work, but most of the core engine will be a new > implementation. : > It is intended that this work will be complete (it isn't done as I > type this) and pushed to Linus upon his return from vacation. Well, we'd like to learn more about your ideas... Source code is our friend. If you don't mind, would you send "as-is" codes to us? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From andre@linux-ide.org Sun Oct 20 21:24:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 21:25:01 -0700 (PDT) Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L4OvtG022255 for ; Sun, 20 Oct 2002 21:24:57 -0700 Received: from localhost (andre@localhost) by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id VAA01283; Sun, 20 Oct 2002 21:22:23 -0700 Date: Sun, 20 Oct 2002 21:22:23 -0700 (PDT) From: Andre Hedrick To: Sandy Harris cc: Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [Design] [PATCH] USAGI IPsec In-Reply-To: <3DB41338.3070502@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@linux-ide.org Precedence: bulk X-list: netdev It is all bolted togather and does not need to be piece from random parts. Thus in simple reality, it is superior. Maybe FreeS/WAN will get busy and compete or die. Cheers, Andre Hedrick LAD Storage Consulting Group On Mon, 21 Oct 2002, Sandy Harris wrote: > Mitsuru KANDA wrote: > > >Hello Linux kernel network maintainers, > > > >I'm a member of USAGI project. > > > >In IPv6 specifications, IPsec is mandatory. > > > >We implemented IPsec for Linux IP stack. > > > >At present, our implementation includes: > > PF_KEY V2 interface, > > Security Association Database and > > Security Policy Database for whole IP versions, > > IPsec for IPv6,(transport, tunnel mode), > > IPsec for IPv4 (transport mode), > > > >Would you mind checking it ? > > > Is this code being checked in to the mainline kernel? Or becoming part > of the > CryptoAPI patch set? Bravo, in either case. > > How does that affect FreeS/WAN development? > > > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From greearb@candelatech.com Sun Oct 20 22:00:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 22:00:19 -0700 (PDT) Received: from grok.yi.org (IDENT:8AEZCocUL/sLmFiO2Xt559FnJx6Tq836@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L50EtG025131 for ; Sun, 20 Oct 2002 22:00:15 -0700 Received: from candelatech.com (IDENT:n6JrIoIOdRba+cD8+jVqzmr7l0DvHyBN@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9L506q27269; Sun, 20 Oct 2002 22:00:06 -0700 Message-ID: <3DB389D5.9050403@candelatech.com> Date: Sun, 20 Oct 2002 22:00:05 -0700 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: Andi Kleen CC: "'netdev@oss.sgi.com'" Subject: Re: reserving skbuffs for the drivers References: <3DB31A32.9020107@candelatech.com> <20021021052031.B16412@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 808 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 Andi Kleen wrote: > On Sun, Oct 20, 2002 at 02:03:46PM -0700, Ben Greear wrote: > >>I'm getting dropped rx packets because the network >>driver cannot allocate an skbuf in time, evidently.... >> >>I have 256MB of RAM, is there some way to increase the amount of RAM >>that the kernel keeps around for GFP_ATOMIC allocations? >> >>Documentation I find talks about buffermem and freepages, which looks >>hopeful, but they appear to no longer be in the proc file system as >>tunables??? > > > You should be asking on linux-mm, not on netdev. > > I've been complaining to the MM guys for years that they dropped freepages > in 2.4, which makes it impossible to tune the VM for heavy network load, but > so far nobody was interested in fixing it. > > -Andi Lord knows I don't mind complaining...didn't know a linux-mm list existed... I wonder though...since we use the skbuff malloc/free wrappers in the networking code, maybe we could just keep a local cache of some tunable size. That may make the skb-malloc call as simple as popping something off of a head of list for the majority of the cases, and should free us from having to use the VM. The kernel default could be quite small so that low memory machines can still function w/out wasting memory... The other thing is that my dropped packet problem was mostly fixed by changing the rx buffer ring to be 512 instead of the 32 it was originally. As Becker notes, this is not a real solution though...just a hack to make the problem harder to trigger... After I made that change, I noticed that most of my dropped packets happened when the transmitter sent a packet, but the receiving NIC has no record of receiving the packet (errors or otherwise). I think there may be some bug with running multiple ports at once (I never see the problem with 2 of the 4 ports running, it's rare with 3, but with 4, it drops packets all over the place.) Thanks, 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 Sun Oct 20 22:46:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 22:46:07 -0700 (PDT) Received: from grok.yi.org (IDENT:QKZAQdBMQfQQzIQFq4b47nYxUc2/I8HT@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L5k4tG029071 for ; Sun, 20 Oct 2002 22:46:04 -0700 Received: from candelatech.com (IDENT:mBLwvwfAgY+SyZbW0CWaD6GYUvGIf0+H@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9L5joq04373; Sun, 20 Oct 2002 22:45:50 -0700 Message-ID: <3DB3948E.6080907@candelatech.com> Date: Sun, 20 Oct 2002 22:45:50 -0700 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: tulip NAPI patch that works with 2.4.20-pre9 or so? References: <3DB1D6B5.6080305@candelatech.com> <15795.2902.180818.661384@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 809 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: > > The latest NAPI tulip patch I could find (tulip-020922.pat) > > will not load. The problem appears that the tulip_misc.c file > > no longer exists... > > :-( I'll look into it. It works if you fix up the Makefile to not compile tulip_misc.c and if you change tulip.h to not define EXTRA_STATS. I'm running it now...initial 5 minutes are a definate improvement over the in-kernel code....now, if it will only remain stable :) 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 Sun Oct 20 23:46:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 20 Oct 2002 23:46:54 -0700 (PDT) Received: from grok.yi.org (IDENT:DsAGOHBeztz1LtBAt/xJMhLblpfsjZTB@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L6kptG000900 for ; Sun, 20 Oct 2002 23:46:51 -0700 Received: from candelatech.com (IDENT:/8pfEhagC74N05ufsIwehKnqUNS0HCLL@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9L6koq15472; Sun, 20 Oct 2002 23:46:50 -0700 Message-ID: <3DB3A2DA.40108@candelatech.com> Date: Sun, 20 Oct 2002 23:46:50 -0700 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'" , Robert Olsson Subject: [PATCH] Break 'budget' dependency on netdev_max_backlog. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 810 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 want to have a very high netdev_max_backlog, but that makes NAPI with the tulip driver (and 4 running ports) drop packets, I assume because by the time it polls the first 3, the 4th has been neglected too long... So, this patch makes the budget NAPI variable independently tunable. The default of 300 seems to work well, and is the current default. In the future, I'm guessing we want a per-interface budget, because a high performance GigE NIC will want a higher budget that the venerable 100bt. --- linux-2.4.19.p3/include/linux/sysctl.h Tue Oct 15 14:26:40 2002 +++ linux-2.4.19.p4/include/linux/sysctl.h Sun Oct 20 23:24:13 2002 @@ -206,7 +206,8 @@ NET_CORE_NO_CONG=14, NET_CORE_LO_CONG=15, NET_CORE_MOD_CONG=16, - NET_CORE_DEV_WEIGHT=17 + NET_CORE_DEV_WEIGHT=17, + NET_CORE_MAX_POLL=18 }; /* /proc/sys/net/ethernet */ --- linux-2.4.19.p3/net/core/dev.c Tue Oct 15 14:23:39 2002 +++ linux-2.4.19.p4/net/core/dev.c Sun Oct 20 23:36:02 2002 @@ -1092,6 +1092,7 @@ =======================================================================*/ int netdev_max_backlog = 300; +int netdev_max_poll = 300; /* 'Budget' for the NAPI poll method */ int weight_p = 64; /* old backlog weight */ /* These numbers are selected based on intuition and some * experimentatiom, if you have more scientific way of doing this @@ -1604,7 +1605,7 @@ int this_cpu = smp_processor_id(); struct softnet_data *queue = &softnet_data[this_cpu]; unsigned long start_time = jiffies; - int budget = netdev_max_backlog; + int budget = netdev_max_poll; br_read_lock(BR_NETPROTO_LOCK); local_irq_disable(); --- linux-2.4.19.p3/net/core/sysctl_net_core.c Wed Oct 9 00:24:02 2002 +++ linux-2.4.19.p4/net/core/sysctl_net_core.c Sun Oct 20 23:35:23 2002 @@ -12,6 +12,7 @@ #ifdef CONFIG_SYSCTL extern int netdev_max_backlog; +extern int netdev_max_poll; extern int weight_p; extern int no_cong_thresh; extern int no_cong; @@ -54,6 +55,9 @@ {NET_CORE_MAX_BACKLOG, "netdev_max_backlog", &netdev_max_backlog, sizeof(int), 0644, NULL, &proc_dointvec}, + {NET_CORE_MAX_POLL, "netdev_max_poll", + &netdev_max_poll, sizeof(int), 0644, NULL, + &proc_dointvec}, {NET_CORE_NO_CONG_THRESH, "no_cong_thresh", &no_cong, sizeof(int), 0644, NULL, &proc_dointvec}, -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From hvr@hvrlab.org Mon Oct 21 00:34:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 00:35:00 -0700 (PDT) Received: from phobos.hvrlab.org (IDENT:VXUXuQ1fHrseglfTgKB6TX2Tw7QlBsXW@h195202190178.med.cm.kabsi.at [195.202.190.178]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9L7YotG004211 for ; Mon, 21 Oct 2002 00:34:51 -0700 Received: from janus.txd.hvrlab.org (IDENT:hvr@janus.txd.hvrlab.org [10.51.1.5]) by phobos.hvrlab.org (8.11.6/8.11.6) with ESMTP id g9L7YEf32732; Mon, 21 Oct 2002 09:34:14 +0200 Subject: Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec From: Herbert Valerio Riedel To: "David S. Miller" Cc: Sandy Harris , Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org In-Reply-To: <1035168066.4817.1.camel@rth.ninka.net> References: <3DB41338.3070502@storm.ca> <1035168066.4817.1.camel@rth.ninka.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Oct 2002 09:34:14 +0200 Message-Id: <1035185654.21824.11.camel@janus.txd.hvrlab.org> Mime-Version: 1.0 X-archive-position: 811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hvr@hvrlab.org Precedence: bulk X-list: netdev On Mon, 2002-10-21 at 04:41, David S. Miller wrote: > A completely new CryptoAPI subsystem has been implemented so that > full lists of page vectors can be passed into the ciphers, which is > necessary for a clean IPSEC implementation. oh... nice to learn about your plans (so late) at all ;-) well, it would be cool if you'd cooperate (or at least share information) with us (the official cryptoapi project ;-), as we're open for the design requirements of the next generation cryptoapi... ...otherwise this may render the kerneli.org/cryptoapi effort completely useless :-/ ...of course, if it's your long term goal to take the cryptoapi development away from kerneli.org, I'd like to know too ;-) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 From dwmw2@redhat.com Mon Oct 21 04:18:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 04:18:17 -0700 (PDT) Received: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LBIBtG006134 for ; Mon, 21 Oct 2002 04:18:12 -0700 Received: from dwmw2 (helo=passion.cambridge.redhat.com) by passion.cambridge.redhat.com with local-esmtp (Exim 3.35 #5) id 183aZQ-0007H3-00; Mon, 21 Oct 2002 12:18:04 +0100 X-Mailer: exmh version 2.5 13/07/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: rtnetlink interface state monitoring problems. Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 21 Oct 2002 12:18:04 +0100 Message-ID: <27964.1035199084@passion.cambridge.redhat.com> X-archive-position: 812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev I'm playing with userspace applications which want to monitor the status of IrDA and Bluetooth devices. Rather than polling for the interface state (this is a handheld device and polling wastes CPU and battery), I want to use netlink. I have two problems: 1. I appear to need CAP_NET_ADMIN to bind to the netlink groups which give me this information. I can poll for it just fine, but need elevated privs to be notified. Why is this, and is there a workaround? 2. Even root doesn't get notification of state changes for Bluetooth interfaces, because they're not treated as 'normal' network devices like IrDA devices are. I can see the logic behind that -- by why is it done differently from IrDA? Is there a way to get notification of BT interface state changes? -- dwmw2 From sandy@storm.ca Mon Oct 21 04:27:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 04:27:56 -0700 (PDT) Received: from mail.storm.ca (mail.storm.ca [209.87.239.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LBRrtG007142 for ; Mon, 21 Oct 2002 04:27:54 -0700 Received: from storm.ca ([218.104.237.138]) by mail.storm.ca (8.11.6+Sun/8.11.6) with ESMTP id g9LBRWM18966; Mon, 21 Oct 2002 07:27:32 -0400 (EDT) Message-ID: <3DB4B77B.90607@storm.ca> Date: Mon, 21 Oct 2002 19:27:07 -0700 From: Sandy Harris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Valerio Riedel CC: "David S. Miller" , Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec References: <3DB41338.3070502@storm.ca> <1035168066.4817.1.camel@rth.ninka.net> <1035185654.21824.11.camel@janus.txd.hvrlab.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sandy@storm.ca Precedence: bulk X-list: netdev Herbert Valerio Riedel wrote: >On Mon, 2002-10-21 at 04:41, David S. Miller wrote: > > > >>A completely new CryptoAPI subsystem has been implemented so that >>full lists of page vectors can be passed into the ciphers, which is >>necessary for a clean IPSEC implementation. >> >> > >oh... nice to learn about your plans (so late) at all ;-) > >well, it would be cool if you'd cooperate (or at least share >information) with us (the official cryptoapi project ;-), as we're open >for the design requirements of the next generation cryptoapi... > >...otherwise this may render the kerneli.org/cryptoapi effort completely >useless :-/ ...of course, if it's your long term goal to take the >cryptoapi development away from kerneli.org, I'd like to know too ;-) > >regards, > > I think the long term goal should be to get good crypto, at least IPsec and disk encryption, into the mainline, standard Linux kernel. Also ipv6 support. Projects like FreeS/WAN, USAGI and cryptoapi seem necessary for getting the work done in the first place, but eventually you want to do away with patch sets and just have all the good stuff built in to the kernel. One payoff is integration. As I understand it, a current fully-patched kernel has either MD-5 or SHA-1 in the /dev/random driver, both in FreeS/WAN, and possibly both of those plus a few other hashes in the CryptoAPI stuff. This is silly. The obvious fix is for everyone to use the CryptoAPI hashes and ciphers. However, crypto is a special case. The US government (among others) has a long history of restricting it and, much as we would like to see good crypto in the standard kernel, there's a good case for being very careful to keep code out of their clutches. My suggestion would be that the standard kernel incorporate only one good hash and one good cipher, specifically AES and SHA-256 since (last I looked) those were en route to becoming requirements for IPsec. Let the FreeS/WAN and CryptoAPI folk -- outside the US -- maintain the other ciphers and hashes. That way we have a fallback position if the US goes back to being viciously restrictive. From nsri@tataelxsi.co.in Mon Oct 21 04:54:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 04:54:21 -0700 (PDT) Received: from mailscanout256k.tataelxsi.co.in ([203.197.168.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LBsCtG010017 for ; Mon, 21 Oct 2002 04:54:14 -0700 Message-ID: <3DB3EA14.7000005@tataelxsi.co.in> Date: Mon, 21 Oct 2002 17:20:44 +0530 From: "Sriram Narasimhan" MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: IPsec query Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 158 X-archive-position: 814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nsri@tataelxsi.co.in Precedence: bulk X-list: netdev Hello, "Is it mandatory to implement Security Architecture for IPv6 for HOSTS?" Thank you. Regards, Sriram Narasimhan [[HTML alternate version deleted]] From hadi@cyberus.ca Mon Oct 21 05:56:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 05:56:53 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LCumtG016774 for ; Mon, 21 Oct 2002 05:56:49 -0700 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 IAA23699; Mon, 21 Oct 2002 08:56:42 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9LCnAL19154; Mon, 21 Oct 2002 08:49:18 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 21 Oct 2002 08:49:09 -0400 (EDT) From: jamal To: Ben Greear cc: Robert Olsson , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? In-Reply-To: <3DB3948E.6080907@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 815 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 Theres a 2419 patch that should work for you at: http://www.cyberus.ca/~hadi/tulip-2419-napi-nifd.gz Also pick a small patch on top of this at: http://www.cyberus.ca/~hadi/patch-napi-tulip-20020915 Now if you wanna get adventorous why not pick: http://www.cyberus.ca/~hadi/tulip-feed.tgz You still need that second patch; In addition to solve your skb problem pick Roberts latest recycling patch at: ftp://robur.slu.se/pub/Linux/net-development/skb_recycling/recycle12.pat The driver i pointed to above has skb-recycling built in. cheers, jamal On Sun, 20 Oct 2002, Ben Greear wrote: > Robert Olsson wrote: > > Ben Greear writes: > > > The latest NAPI tulip patch I could find (tulip-020922.pat) > > > will not load. The problem appears that the tulip_misc.c file > > > no longer exists... > > > > :-( I'll look into it. > > It works if you fix up the Makefile to not compile tulip_misc.c > and if you change tulip.h to not define EXTRA_STATS. > > I'm running it now...initial 5 minutes are a definate improvement > over the in-kernel code....now, if it will only remain stable :) > > 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 Mon Oct 21 05:59:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 05:59:20 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LCxEtG017257 for ; Mon, 21 Oct 2002 05:59:14 -0700 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 IAA24702; Mon, 21 Oct 2002 08:59:12 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9LCplC19165; Mon, 21 Oct 2002 08:51:47 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 21 Oct 2002 08:51:46 -0400 (EDT) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" , Robert Olsson Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. In-Reply-To: <3DB3A2DA.40108@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 816 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 Patch looks fine except for the 300 number. What are you smoking? Please retain the original value. cheers, jamal On Sun, 20 Oct 2002, Ben Greear wrote: > I want to have a very high netdev_max_backlog, but that makes > NAPI with the tulip driver (and 4 running ports) drop packets, > I assume because by the time it polls the first 3, the 4th has > been neglected too long... > > So, this patch makes the budget NAPI variable independently tunable. > The default of 300 seems to work well, and is the current default. > > In the future, I'm guessing we want a per-interface budget, because > a high performance GigE NIC will want a higher budget that the > venerable 100bt. > > > --- linux-2.4.19.p3/include/linux/sysctl.h Tue Oct 15 14:26:40 2002 > +++ linux-2.4.19.p4/include/linux/sysctl.h Sun Oct 20 23:24:13 2002 > @@ -206,7 +206,8 @@ > NET_CORE_NO_CONG=14, > NET_CORE_LO_CONG=15, > NET_CORE_MOD_CONG=16, > - NET_CORE_DEV_WEIGHT=17 > + NET_CORE_DEV_WEIGHT=17, > + NET_CORE_MAX_POLL=18 > }; > > /* /proc/sys/net/ethernet */ > --- linux-2.4.19.p3/net/core/dev.c Tue Oct 15 14:23:39 2002 > +++ linux-2.4.19.p4/net/core/dev.c Sun Oct 20 23:36:02 2002 > @@ -1092,6 +1092,7 @@ > =======================================================================*/ > > int netdev_max_backlog = 300; > +int netdev_max_poll = 300; /* 'Budget' for the NAPI poll method */ > int weight_p = 64; /* old backlog weight */ > /* These numbers are selected based on intuition and some > * experimentatiom, if you have more scientific way of doing this > @@ -1604,7 +1605,7 @@ > int this_cpu = smp_processor_id(); > struct softnet_data *queue = &softnet_data[this_cpu]; > unsigned long start_time = jiffies; > - int budget = netdev_max_backlog; > + int budget = netdev_max_poll; > > br_read_lock(BR_NETPROTO_LOCK); > local_irq_disable(); > --- linux-2.4.19.p3/net/core/sysctl_net_core.c Wed Oct 9 00:24:02 2002 > +++ linux-2.4.19.p4/net/core/sysctl_net_core.c Sun Oct 20 23:35:23 2002 > @@ -12,6 +12,7 @@ > #ifdef CONFIG_SYSCTL > > extern int netdev_max_backlog; > +extern int netdev_max_poll; > extern int weight_p; > extern int no_cong_thresh; > extern int no_cong; > @@ -54,6 +55,9 @@ > {NET_CORE_MAX_BACKLOG, "netdev_max_backlog", > &netdev_max_backlog, sizeof(int), 0644, NULL, > &proc_dointvec}, > + {NET_CORE_MAX_POLL, "netdev_max_poll", > + &netdev_max_poll, sizeof(int), 0644, NULL, > + &proc_dointvec}, > {NET_CORE_NO_CONG_THRESH, "no_cong_thresh", > &no_cong, sizeof(int), 0644, NULL, > &proc_dointvec}, > > > -- > 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 Mon Oct 21 06:10:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 06:10:23 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LDAItG018667 for ; Mon, 21 Oct 2002 06:10:19 -0700 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 JAA29727; Mon, 21 Oct 2002 09:10:17 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9LD2mK19207; Mon, 21 Oct 2002 09:02:53 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 21 Oct 2002 09:02:48 -0400 (EDT) From: jamal To: David Woodhouse cc: , Subject: Re: rtnetlink interface state monitoring problems. In-Reply-To: <27964.1035199084@passion.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 817 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, 21 Oct 2002, David Woodhouse wrote: > I'm playing with userspace applications which want to monitor the status of > IrDA and Bluetooth devices. Rather than polling for the interface state > (this is a handheld device and polling wastes CPU and battery), I want to > use netlink. > > I have two problems: > > 1. I appear to need CAP_NET_ADMIN to bind to the netlink groups which give > me this information. I can poll for it just fine, but need > elevated privs to be notified. Why is this, and is there a workaround? > Alexey should be able to give you a better comment. If you can get the status via ioctl there should be no reason why you shouldnt get it via netlink. The change maybe a little involved (look at:net/netlink/af_netlink.c::netlink_bind()) since there are some valid reasons to block non-admin from receiving certain messages. I think the LSM people may have been trying to do this, cant remember details. > 2. Even root doesn't get notification of state changes for Bluetooth > interfaces, because they're not treated as 'normal' network devices > like IrDA devices are. I can see the logic behind that -- by why > is it done differently from IrDA? Is there a way to get notification > of BT interface state changes? I cant see anything on netlink and irda; i am also not very familiar with either IrDA or Bluetooth. Regardless, you dont need to be a net device to use netlink. Its a messaging system and you can use it both within the kernel as well as kernel<->userspace. If you get stuck writting the interface ping me privately. cheers, jamal From hadi@cyberus.ca Mon Oct 21 06:18:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 06:18:06 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LDHxtG019779 for ; Mon, 21 Oct 2002 06:18:00 -0700 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 JAA03077; Mon, 21 Oct 2002 09:17:59 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9LDATT19248; Mon, 21 Oct 2002 09:10:29 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 21 Oct 2002 09:10:29 -0400 (EDT) From: jamal To: Ben Greear cc: Robert Olsson , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 818 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, 21 Oct 2002, jamal wrote: > > Theres a 2419 patch that should work for you at: > http://www.cyberus.ca/~hadi/tulip-2419-napi-nifd.gz > Now if you wanna get adventorous why not pick: > http://www.cyberus.ca/~hadi/tulip-feed.tgz Make sure you turn off FEEDB in tulip.h (thats new stuff which hasnt hit the press yet). cheers, jamal From jmorris@intercode.com.au Mon Oct 21 06:46:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 06:46:47 -0700 (PDT) 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 g9LDkdtG022911 for ; Mon, 21 Oct 2002 06:46:41 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id XAA29164; Mon, 21 Oct 2002 23:46:24 +1000 Date: Mon, 21 Oct 2002 23:46:24 +1000 (EST) From: James Morris To: David Woodhouse cc: linux-kernel@vger.kernel.org, Subject: Re: rtnetlink interface state monitoring problems. In-Reply-To: <27964.1035199084@passion.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 819 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 Mon, 21 Oct 2002, David Woodhouse wrote: > 1. I appear to need CAP_NET_ADMIN to bind to the netlink groups which give > me this information. I can poll for it just fine, but need > elevated privs to be notified. Why is this, and is there a workaround? Andi Kleen implemented a simple and effective workaround this for 2.4 which has gone into the tree (see netlink_set_nonroot() in rtnetlink.c). Another more complicated solution was partially developed for 2.5, but is unlikely to make it in by Halloween. - James -- James Morris From jmorris@intercode.com.au Mon Oct 21 06:48:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 06:48:18 -0700 (PDT) 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 g9LDmEtG023240 for ; Mon, 21 Oct 2002 06:48:16 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id XAA29191; Mon, 21 Oct 2002 23:48:03 +1000 Date: Mon, 21 Oct 2002 23:48:03 +1000 (EST) From: James Morris To: David Woodhouse cc: linux-kernel@vger.kernel.org, Subject: Re: rtnetlink interface state monitoring problems. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 820 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 Mon, 21 Oct 2002, James Morris wrote: > Andi Kleen implemented a simple and effective workaround this for 2.4 > which has gone into the tree (see netlink_set_nonroot() in rtnetlink.c). > Forgot to add that it might be possible to get Andi's solution into 2.6. - James -- James Morris From ph@digitalquake.com Mon Oct 21 07:13:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 07:13:19 -0700 (PDT) Received: from sun4.digitalquake.com (digitalquake.com [63.205.237.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LEDFtG025281 for ; Mon, 21 Oct 2002 07:13:16 -0700 Received: from phisdn (ph.dialup.meer.net [209.157.134.48]) by sun4.digitalquake.com (8.10.2+Sun/8.10.2) with ESMTP id g9LECxk07955; Mon, 21 Oct 2002 07:12:59 -0700 (PDT) From: "Paul Hernandez" To: "Jeff Garzik" , "Felipe W Damasio" Cc: "Paul Hernandez" , "Linux-net" , Subject: RE: NIC on 2.4.19 SMP Date: Mon, 21 Oct 2002 07:20:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3DB1FD1A.4020109@pobox.com> X-archive-position: 821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ph@digitalquake.com Precedence: bulk X-list: netdev Jeff and Felipe, I naturally tried the default e100 first when I installed SuSE 8.1 and only tried the eepro100.c when the e100 failed identically. The e100 is harder to debug w/o MII so felt the e100pro with MII might shed some light. Any suggestions. I'll happily assist in resolving this. Paul Hernandez 408-374-8686 x202 Campbell, CA -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Saturday, October 19, 2002 17:47 PM To: Felipe W Damasio Cc: Paul Hernandez; Linux-net; netdev@oss.sgi.com Subject: Re: NIC on 2.4.19 SMP Felipe W Damasio wrote: > On Fri, 2002-10-18 at 16:57, Paul Hernandez wrote: > >>Hello, >> >>It was suggested to me that I forward this issue to you both. >> >>OS: 2.4.19.SuSE SMP >>Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 >>(latest bios off Intel site) >>On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) >>Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 >> >>dmesg output: >> >>e100: eth0: Intel(R) 8255x-based Ethernet Adapter > > >>SIOCGMIIPHY on eth0 failed: >>Operation not supported >>no MII interfaces found > > > Try using the eepro100.c driver from the kernel, and not the one from > Intel (the driver from the kernel supports SIOCGMIIPHY). > > Though it does not seem a problem with the driver, you should try using > the one from the kernel and see if it helps. I agree that comparison is useful, though it should be pointed out that ethtool is preferred for e100... Jeff From ph@digitalquake.com Mon Oct 21 07:14:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 07:14:54 -0700 (PDT) Received: from sun4.digitalquake.com (digitalquake.com [63.205.237.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LEEqtG025590 for ; Mon, 21 Oct 2002 07:14:52 -0700 Received: from phisdn (ph.dialup.meer.net [209.157.134.48]) by sun4.digitalquake.com (8.10.2+Sun/8.10.2) with ESMTP id g9LEEck07958; Mon, 21 Oct 2002 07:14:38 -0700 (PDT) From: "Paul Hernandez" To: "Felipe W Damasio" Cc: "Linux-net" , Subject: RE: NIC on 2.4.19 SMP Date: Mon, 21 Oct 2002 07:21:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <1035064119.2912.31.camel@tank> X-archive-position: 822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ph@digitalquake.com Precedence: bulk X-list: netdev Ok, I'll send the MII-diag output when I get into work in about an hour. Paul -----Original Message----- From: Felipe W Damasio [mailto:felipewd@terra.com.br] Sent: Saturday, October 19, 2002 14:49 PM To: Paul Hernandez Cc: Linux-net; netdev@oss.sgi.com Subject: Re: NIC on 2.4.19 SMP On Fri, 2002-10-18 at 16:57, Paul Hernandez wrote: > Hello, > > It was suggested to me that I forward this issue to you both. > > OS: 2.4.19.SuSE SMP > Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 > (latest bios off Intel site) > On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) > Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 > > dmesg output: > > e100: eth0: Intel(R) 8255x-based Ethernet Adapter > SIOCGMIIPHY on eth0 failed: > Operation not supported > no MII interfaces found Try using the eepro100.c driver from the kernel, and not the one from Intel (the driver from the kernel supports SIOCGMIIPHY). Though it does not seem a problem with the driver, you should try using the one from the kernel and see if it helps. If it doesn't, reply this mail with the mii-diag output (and driver version). Felipe From ph@digitalquake.com Mon Oct 21 08:17:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 08:17:08 -0700 (PDT) Received: from sun4.digitalquake.com (digitalquake.com [63.205.237.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LFH2tG002025 for ; Mon, 21 Oct 2002 08:17:02 -0700 Received: from phpc (netscreen-dmz.digitalquake.com [192.168.0.1]) by sun4.digitalquake.com (8.10.2+Sun/8.10.2) with SMTP id g9LFGOk08027; Mon, 21 Oct 2002 08:16:24 -0700 (PDT) From: "Paul Hernandez" To: "Jeff Garzik" , "Felipe W Damasio" Cc: "Linux-net" , Subject: RE: NIC on 2.4.19 SMP (mii-diag output) Date: Mon, 21 Oct 2002 08:16:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3DB1FD1A.4020109@pobox.com> X-archive-position: 823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ph@digitalquake.com Precedence: bulk X-list: netdev Jeff and Felipe, Here is the mii-diag output. Note that this same machine running SuSE 8.0 (2.4.18.SuSE-SMP) worked correctly with this on-board eepro100 LAN. Unfortunantely I had to move forward to 2.4.19.SuSE-SMP in order to correct (and did) a problem with 2.4.18 not recognizing the new ide controller on this new motherboard and it only ran pio mode .IDE DMA works fine now with 2.4.19.SuSE-SMP but LAN fails (with three different vendor boards) . The second on-board controller is a Promise FastTrack100 RAID which I also managed to get working on 2.4.18.SuSE-SMP but now fails as well on 2.4.19 with a bunch of "lost interrupts" messages when it tries to access drives on it. Servers me right for buying such a young motherboard. Thanks for letting me vent a bit. ;-) Paul linux19:~ # mii-diag -v eth0 mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. End of basic transceiver information. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Saturday, October 19, 2002 5:47 PM To: Felipe W Damasio Cc: Paul Hernandez; Linux-net; netdev@oss.sgi.com Subject: Re: NIC on 2.4.19 SMP Felipe W Damasio wrote: > On Fri, 2002-10-18 at 16:57, Paul Hernandez wrote: > >>Hello, >> >>It was suggested to me that I forward this issue to you both. >> >>OS: 2.4.19.SuSE SMP >>Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 >>(latest bios off Intel site) >>On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) >>Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 >> >>dmesg output: >> >>e100: eth0: Intel(R) 8255x-based Ethernet Adapter > > >>SIOCGMIIPHY on eth0 failed: >>Operation not supported >>no MII interfaces found > > > Try using the eepro100.c driver from the kernel, and not the one from > Intel (the driver from the kernel supports SIOCGMIIPHY). > > Though it does not seem a problem with the driver, you should try using > the one from the kernel and see if it helps. I agree that comparison is useful, though it should be pointed out that ethtool is preferred for e100... Jeff From ph@digitalquake.com Mon Oct 21 11:45:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 11:45:30 -0700 (PDT) Received: from sun4.digitalquake.com (digitalquake.com [63.205.237.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LIjQuR001002 for ; Mon, 21 Oct 2002 11:45:26 -0700 Received: from phpc (netscreen-dmz.digitalquake.com [192.168.0.1]) by sun4.digitalquake.com (8.10.2+Sun/8.10.2) with SMTP id g9LGXjM08269; Mon, 21 Oct 2002 09:33:45 -0700 (PDT) From: "Paul Hernandez" To: "Jeff Garzik" , "Felipe W Damasio" Cc: "Linux-net" , Subject: RE: NIC on 2.4.19 SMP (mii-diag output) Date: Mon, 21 Oct 2002 09:33:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-archive-position: 824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ph@digitalquake.com Precedence: bulk X-list: netdev lsmod shows its using e100. version .13a eepro100.c is v1.09j-t. -----Original Message----- From: Paul Hernandez [mailto:ph@digitalquake.com] Sent: Monday, October 21, 2002 8:16 AM To: Jeff Garzik; Felipe W Damasio Cc: Linux-net; netdev@oss.sgi.com Subject: RE: NIC on 2.4.19 SMP (mii-diag output) Jeff and Felipe, Here is the mii-diag output. Note that this same machine running SuSE 8.0 (2.4.18.SuSE-SMP) worked correctly with this on-board eepro100 LAN. Unfortunantely I had to move forward to 2.4.19.SuSE-SMP in order to correct (and did) a problem with 2.4.18 not recognizing the new ide controller on this new motherboard and it only ran pio mode .IDE DMA works fine now with 2.4.19.SuSE-SMP but LAN fails (with three different vendor boards) . The second on-board controller is a Promise FastTrack100 RAID which I also managed to get working on 2.4.18.SuSE-SMP but now fails as well on 2.4.19 with a bunch of "lost interrupts" messages when it tries to access drives on it. Servers me right for buying such a young motherboard. Thanks for letting me vent a bit. ;-) Paul linux19:~ # mii-diag -v eth0 mii-diag.c:v2.02 5/21/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. End of basic transceiver information. MII PHY #1 transceiver registers: 3000 7809 02a8 0154 05e1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x7809 ... 7809. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 00:aa:00:--:--:--, model 21 rev. 4. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Saturday, October 19, 2002 5:47 PM To: Felipe W Damasio Cc: Paul Hernandez; Linux-net; netdev@oss.sgi.com Subject: Re: NIC on 2.4.19 SMP Felipe W Damasio wrote: > On Fri, 2002-10-18 at 16:57, Paul Hernandez wrote: > >>Hello, >> >>It was suggested to me that I forward this issue to you both. >> >>OS: 2.4.19.SuSE SMP >>Motherboard: Intel Dual P4 Xeon Server board SE7500CW2 >>(latest bios off Intel site) >>On-borad LAN controller: Intel 82557/8/9 [Ether Pro 100] (rev 0d) >>Addional NIC's tried: 3-COM 3C-905C-TX-M, Netgear FA311 >> >>dmesg output: >> >>e100: eth0: Intel(R) 8255x-based Ethernet Adapter > > >>SIOCGMIIPHY on eth0 failed: >>Operation not supported >>no MII interfaces found > > > Try using the eepro100.c driver from the kernel, and not the one from > Intel (the driver from the kernel supports SIOCGMIIPHY). > > Though it does not seem a problem with the driver, you should try using > the one from the kernel and see if it helps. I agree that comparison is useful, though it should be pointed out that ethtool is preferred for e100... Jeff From greearb@candelatech.com Mon Oct 21 11:47:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 11:47:25 -0700 (PDT) Received: from grok.yi.org (IDENT:ArcHbC3rmRU1CMuMDPevKZHa6Q+YFD3T@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LIlMuT001310 for ; Mon, 21 Oct 2002 11:47:23 -0700 Received: from candelatech.com (IDENT:zrSmfjX0ytaCuPxUlfR+V7ccbiVUIKrI@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9LGPqq17916; Mon, 21 Oct 2002 09:25:53 -0700 Message-ID: <3DB42A90.1030709@candelatech.com> Date: Mon, 21 Oct 2002 09:25:52 -0700 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 , "'netdev@oss.sgi.com'" Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 826 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: > Patch looks fine except for the 300 number. What are you smoking? > Please retain the original value. The original value was 300, what do you want it to be? (Check out what backlog defaults to, that is what is currently used for the budget, in 2.4.20-pre9 at least.) 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 Mon Oct 21 11:47:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 11:47:25 -0700 (PDT) Received: from grok.yi.org (IDENT:ArcHbC3rmRU1CMuMDPevKZHa6Q+YFD3T@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LIlMuR001310 for ; Mon, 21 Oct 2002 11:47:22 -0700 Received: from candelatech.com (IDENT:n8GNjIhIQftA/xVdGeucCcMG/lfotKYk@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9LIbQq04938; Mon, 21 Oct 2002 11:37:27 -0700 Message-ID: <3DB44966.1070402@candelatech.com> Date: Mon, 21 Oct 2002 11:37:26 -0700 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: Robert Olsson , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 825 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: > Theres a 2419 patch that should work for you at: > http://www.cyberus.ca/~hadi/tulip-2419-napi-nifd.gz Link does not work for me. But I got Robert's patch to work with a small bit of hacking... (I changed HZ to 1000 and it locked up 10 seconds after I started (pkts were sent, but nothing received on any port). However, I restarted, and it ran all night with very few dropped packets...) > Also pick a small patch on top of this at: > http://www.cyberus.ca/~hadi/patch-napi-tulip-20020915 Does not work either... > > Now if you wanna get adventorous why not pick: > http://www.cyberus.ca/~hadi/tulip-feed.tgz > You still need that second patch; Do you have any descriptions of what this feed patch does differently from other drivers? > In addition to solve your skb problem pick Roberts latest > recycling patch at: > ftp://robur.slu.se/pub/Linux/net-development/skb_recycling/recycle12.pat > The driver i pointed to above has skb-recycling built in. I'll give that a try. Thanks! Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From dwmw2@redhat.com Mon Oct 21 11:58:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 11:58:38 -0700 (PDT) Received: from passion.cambridge.redhat.com (dell-paw-3.cambridge.redhat.com [195.224.55.237]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LIwZuR003800 for ; Mon, 21 Oct 2002 11:58:36 -0700 Received: from dwmw2 (helo=passion.cambridge.redhat.com) by passion.cambridge.redhat.com with local-esmtp (Exim 3.35 #5) id 183hkM-0006SJ-00; Mon, 21 Oct 2002 19:57:50 +0100 X-Mailer: exmh version 2.5 13/07/2001 with nmh-1.0.4 From: David Woodhouse X-Accept-Language: en_GB In-Reply-To: References: To: jamal Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: rtnetlink interface state monitoring problems. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Oct 2002 19:57:50 +0100 Message-ID: <24818.1035226670@passion.cambridge.redhat.com> X-archive-position: 827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev hadi@cyberus.ca said: > I cant see anything on netlink and irda; i am also not very familiar > with either IrDA or Bluetooth. Regardless, you dont need to be a net > device to use netlink. IrDA devices are network devices. The core network code sends a RTM_NETLINK message when they go up or down. All is well, and once the permission fix gets into the kernel I'm using, my irda monitor applet no longer needs to poll the state of the interface. But Bluetooth devices are not network devices, it seems. There exists no current mechanism for notifying anyone of state changes. Should we invent a new method of notification using netlink, or should Bluetooth interfaces in fact be normal network devices just like IrDA devices are? -- dwmw2 From bhattmanish1980@hotmail.com Mon Oct 21 12:02:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 12:02:02 -0700 (PDT) Received: from hotmail.com (f23.law14.hotmail.com [64.4.21.23]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LJ20uR004855 for ; Mon, 21 Oct 2002 12:02:00 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 21 Oct 2002 09:32:50 -0700 Received: from 61.11.54.91 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 21 Oct 2002 16:32:49 GMT X-Originating-IP: [61.11.54.91] From: "manish bhatt" To: yjing@cs.stanford.edu Cc: harshad_kulkarni@hotmail.com, sameer_sangawar@hotmail.com, odemir@binghamton.edu Subject: project help needed Date: Mon, 21 Oct 2002 22:02:49 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Oct 2002 16:32:50.0267 (UTC) FILETIME=[7F12A2B0:01C2791F] X-archive-position: 828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhattmanish1980@hotmail.com Precedence: bulk X-list: netdev hi everbody.. i m a final year engg. student. i m working on a bandwidth management system on linux plaform as part of my final year project.it will allocate and monitor bandwidth on user, protocol and subnet basis. i plan to use netfilter architecture.plz guide whether to use iptables and work with tcpdump .ifyes where can i find good documentation for src code of these softwares. also can ethereal or squid help me in any way. if u have any previous experience on such project then u can be a great help to me.i will be very thankfull for ur urgent help as ineed to complete this project within a month coz of our semester schedule. with regards manish bhatt _________________________________________________________________ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp From bhattmanish1980@hotmail.com Mon Oct 21 12:04:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 12:04:57 -0700 (PDT) Received: from hotmail.com (f129.law14.hotmail.com [64.4.21.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LJ4tuR005361 for ; Mon, 21 Oct 2002 12:04:55 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 21 Oct 2002 09:36:27 -0700 Received: from 61.11.54.91 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 21 Oct 2002 16:36:27 GMT X-Originating-IP: [61.11.54.91] From: "manish bhatt" To: raf@comdyn.com.au Subject: project help needed Date: Mon, 21 Oct 2002 22:06:27 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Oct 2002 16:36:27.0753 (UTC) FILETIME=[00B45D90:01C27920] X-archive-position: 829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhattmanish1980@hotmail.com Precedence: bulk X-list: netdev hi everbody.. i m a final year engg. student. i m working on a bandwidth management system on linux plaform as part of my final year project.it will allocate and monitor bandwidth on user, protocol and subnet basis. i plan to use netfilter architecture.plz guide whether to use iptables and work with tcpdump .ifyes where can i find good documentation for src code of these softwares. also can ethereal or squid help me in any way. if u have any previous experience on such project then u can be a great help to me.i will be very thankfull for ur urgent help as ineed to complete this project within a month coz of our semester schedule. with regards manish bhatt _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp From benoit-lists@fb12.de Mon Oct 21 12:20:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 12:20:52 -0700 (PDT) Received: from turing.fb12.de (turing.fb12.de [80.76.224.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LJKmuR007497 for ; Mon, 21 Oct 2002 12:20:48 -0700 Received: (qmail 8716 invoked by uid 500); 21 Oct 2002 15:44:10 -0000 Date: Mon, 21 Oct 2002 17:44:10 +0200 From: Sebastian Benoit To: netdev@oss.sgi.com Subject: network connection gets stuck with 2.5.44 Message-ID: <20021021174410.B8190@turing.fb12.de> Mail-Followup-To: Sebastian Benoit , netdev@oss.sgi.com References: <20021018124717.A21622@turing.fb12.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021018124717.A21622@turing.fb12.de>; from benoit-lists@fb12.de on Fri, Oct 18, 2002 at 12:47:17PM +0200 X-MSMail-Priority: High x-gpg-fingerprint: 2999 9839 6C9E E4BF B540 C44B 4EC4 E1BE 5BA2 2F00 x-gpg-key: http://wwwkeys.de.pgp.net:11371 X-archive-position: 830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: benoit-lists@fb12.de Precedence: bulk X-list: netdev --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Still happens... /B. Sebastian Benoit(benoit-lists@fb12.de)@2002.10.18 12:47:17 +0000: > Subject: Re: network connection gets stuck with 2.5.43-bk1/mm2 >=20 > Hi, >=20 > i posted the message below to linux-mm yesterday, Andrew Morton told me t= hat > it might be one of the changes in networking in -bk1. >=20 > removing these changes solved the problem: >=20 > include/linux/ip.h | 16=20 > include/linux/tcp.h | 2=20 > include/linux/udp.h | 31 - > include/net/dst.h | 56 -- > include/net/ip.h | 16=20 > include/net/sock.h | 2=20 > include/net/tcp.h | 2=20 > include/net/udp.h | 2=20 > net/core/dst.c | 25 - > net/ipv4/af_inet.c | 17=20 > net/ipv4/icmp.c | 4=20 > net/ipv4/ip_output.c | 880 +++++++--------------------------------= ------- > net/ipv4/ip_proc.c | 74 --- > net/ipv4/ip_sockglue.c | 4=20 > net/ipv4/raw.c | 7=20 > net/ipv4/tcp.c | 49 -- > net/ipv4/tcp_ipv4.c | 6=20 > net/ipv4/tcp_minisocks.c | 10=20 > net/ipv4/udp.c | 296 --------------- > net/ipv6/tcp_ipv6.c | 5=20 > net/netsyms.c | 1=20 >=20 > (this is the diffstat of the reverse patch) >=20 > Is this fixed already? > /B. >=20 >=20 >=20 > ----------------- quote ----------------- > Hi,=20 >=20 > funny problem w. 2.5.43-mm2: >=20 > i'm running 2.5.43-mm2 on my workstation. Normal workload, X-windows, a f= ew > xterms, editor, mozilla, etc. (host A) >=20 > I have a NFS/SAMBA-mount (both show the problem) to host B. Host B runs > 2.4.19rc5aa1. >=20 > I can get a xterm, in which i have a ssh-connection to a third host C > 'stuck' by simply cat'ing a large file from the NFS/SAMBA server to > /dev/null. >=20 > The xterm/ssh seems stuck, that is no key i press is received on the other > end, but output of the program running on host C is updated in the xterm.= I > checked with tcpdump: the keypress does not generate a packet, my host on= ly > sends ACK's on that ssh connection to host C. >=20 > The ssh-connection is not unstuck by stopping the data transfer from host= B. >=20 > I checked that plain 2.5.42 and 2.5.43-mm1 do not have this problem: here= my > input goes through to C. At least for small amounts of input, i did not t= est > anything beyond typing a few hundret chars. >=20 > recap: >=20 > "mount /mnt/hostB" > "ssh hostC" -> type random stuff in that connection > at the same time do "cat /mnt/hostB/bigfile > /dev/null" > ssh gets stuck. >=20 > hardware: PIII/600, 3c905B on 10baseT half-duplex >=20 > I'm sorry i cant do any further checks until Friday afternoon (MET). >=20 > /B. > --------------- quote ends --------------- >=20 >=20 >=20 > --=20 > Sebastian Benoit > My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.or= g/ > GnuPG 0x5BA22F00 2001-07-31 2999 9839 6C9E E4BF B540 C44B 4EC4 E1BE 5BA2= 2F00 >=20 > Oxymoron #633: Mutual Differences --=20 Sebastian Benoit My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ GnuPG 0x5BA22F00 2001-07-31 2999 9839 6C9E E4BF B540 C44B 4EC4 E1BE 5BA2 2= F00 The political and commercial morals of the United States are not merely food for laughter, they are an entire banquet. -- Mark Twain --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj20IMoACgkQTsThvluiLwAA/gCgptDWmYvz6P9IVOc85yfC/xN2 fvkAn1yogypzNBSgr4Fjge92BTYe5FYv =ciQV -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From davem@rth.ninka.net Mon Oct 21 12:22:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 12:22:52 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LJMouR007974 for ; Mon, 21 Oct 2002 12:22:51 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9LH1ERU024869; Mon, 21 Oct 2002 10:01:14 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9LH1Er6024867; Mon, 21 Oct 2002 10:01:14 -0700 Subject: Re: rtnetlink interface state monitoring problems. From: "David S. Miller" To: James Morris Cc: David Woodhouse , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Oct 2002 10:01:14 -0700 Message-Id: <1035219674.4817.5.camel@rth.ninka.net> Mime-Version: 1.0 X-archive-position: 831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@rth.ninka.net Precedence: bulk X-list: netdev On Mon, 2002-10-21 at 06:48, James Morris wrote: > Forgot to add that it might be possible to get Andi's solution into 2.6. Send me the patch for 2.5.x It not being there is by accident, usually when I make a 2.4.x patch I do 2.5.x in parallel. From tnt707@orgio.net Mon Oct 21 13:40:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 13:40:25 -0700 (PDT) Received: from orgio.net ([211.105.127.98]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LKe8uR017124 for ; Mon, 21 Oct 2002 13:40:23 -0700 Message-Id: <200210212040.g9LKe8uR017124@oss.sgi.com> Reply-To: tnt707@orgio.net From: To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?<=BC=BA=C0=CE=B1=A4=B0=ED>=A1=E1?= 100% =?ISO-8859-1?Q?=B0=F8=C2=A5=20=BC=BA=C0=CE=B5=BF=BF=B5=BB=F3?= =?ISO-8859-1?Q?=B9=CC=BC=D2=B3=E0=20=B0=A8=BB=F3...=20=A1=E1?= Date: Tue, 22 Oct 2002 05:40:25 +0900 Mime-Version: 1.0 Content-Type: text/html; charset="euc-kr" X-archive-position: 832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tnt707@orgio.net Precedence: bulk X-list: netdev
[] .
deny .


!! ..

..

.. ..

..!!

..!!









deny
From werkenbijdeotto1@37.com Mon Oct 21 13:42:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 13:42:47 -0700 (PDT) Received: from mail.nigol.net.ng (mail.nigol.net.ng [212.96.29.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LKgguR017644 for ; Mon, 21 Oct 2002 13:42:44 -0700 Received: from boston ([216.252.176.113]) by mail.nigol.net.ng (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44314U100L100S0) with SMTP id BII401 for ; Mon, 21 Oct 2002 21:42:45 +0100 To: "'netdev@oss.sgi.com'" From: werkenbijdeotto1@37.com Subject: AWARD NOTIFICATION Date: Mon, 21 Oct 2002 21:44:17 +0100 Message-Id: <37550.905753124998400.169628@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werkenbijdeotto1@37.com Precedence: bulk X-list: netdev WERKEN BIJ DE LOTTO, 41132, NL-1007 DB AMSTERDAM, THE NETHERLANDS. FROM: THE DESK OF THE DIRECTOR PROMOTIONS, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: WBL/67-B773524441 ATTN: AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today, 21ST OCTOBER. 2002, of winners of the WERKEN BIJ DE LOTTO/ INTERNATIONAL PROGRAMS held on 19TH MAY 2002. You / your company, attached to ticket number 013-2316-2002-477, with serial number A025-09 drew the lucky numbers 37-13-34-85-56-42, and consequently won in category C. You have therefore been approved for a lump sum pay out of US$1,500,000.00 in cash credited to file REF NO. REF: WBL/67-B773524441. This is from total prize money of US$22,500,000.00 shared among the fifteen international winners in the category C. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe,USA and North America as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a Finance and Security House and insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3 billion International lotto. To begin your claim, please contact your claims officer immediately: JANSEN DAVIS FOREIGN SERVICE MANAGER, EUROLITE BV, PHONE:31-619676795 TEL/FAX: 31 205241590 FAX: 31 205248221 EMAIL:eurolitebv2@theocffice.net For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claims officer not later than OCTOBER 27th, 2002. After this date, all funds will be returned as unclaimed. All correspondences to Mr. Jansen Davis,either by fax or email, should have this email sent along with it and also, your email address to which this email is sent, should be clearly and boldly written in your response. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your officer. Furthermore, should there be any change of your address, do inform your claims officer as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, THE DIRECTOR PROMOTIONS, WERKEN BIJ DE LOTTO. www.werken-bij-delotto.net N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply this mail. From matobu@rediffmail.com Mon Oct 21 13:48:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 13:48:29 -0700 (PDT) Received: from oss.sgi.com (node-c-3f09.a2000.nl [62.194.63.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LKmJuR018476 for ; Mon, 21 Oct 2002 13:48:20 -0700 Message-Id: <200210212048.g9LKmJuR018476@oss.sgi.com> From: "MARIO MATOBU" Date: Mon, 21 Oct 2002 22:47:40 To: netdev@oss.sgi.com Subject: STRICTLY CONFIDENTIAL MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matobu@rediffmail.com Precedence: bulk X-list: netdev Dear Friend, Naturally this mail will come to you as a surprise,but if I may crave your indulgence,I am MR. Mario Matobu,the first son of David Matobu,one of the most popular black farmer in Zimbabwe who was recectly murdered in the land dispute in my country.I APOLOGISE FOR INVADING YOUR PRIVACY, BUT PLEASE,I appeal to you to exercise a little patience and read through my letter, and I guarantee you will not have wasted your time. Before the death of my father, he had taken me to Johannesburg to deposit the sum of US8.5 Million (Eight Million, Five Hundred United States dollars)in one of the private security company, as he foresaw the looming danger in Zimbabwe this money was deposited in a box as gem stones to avoid much demurrage from security company. This amount was meant for the purchase of new machines and chemicals for the Farms and establishment of new farms in Swaziland. This land problem came when Zimbabwean President Mr.Robert Mugabe introduced a new Land Act Reform wholly affected the rich white farmers and some few black farmers.And this resulted to the killing and mob action by Zimbabwean war veterans and some lunatics in the society. In fact a lot of people were killed because of this Land reform Act for which my father was one of the victims. It is against this background that, I and my family fled Zimbabwe for fear of our lives and are currently staying in the Netherlands where we are seeking political asylum and moreso have decided to transfer my fathers money to a more reliable foreign account.since the law of Netherlands prohibits a refugee (asylum seeker) to open any bank account or to be involved in any financial transaction throughout the territorial zone of Netherlands, As the eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where this money could be transferred without the knowledge of my government who are bent on taking everything we have got. The South African government seems to be playing along with them. I am faced with the dilemma of moving this amount of money out of South Africa for fear of going through the same experience in future, both countries have similar political history. As a businessman,I am seeking for a partner who I have to entrust my future and of my family in his hands, I must let you know that this transaction is risk free. If you accept to assist me and my family,all I want you to do for me,is to arrangements with the security company to clear the consignment(funds) from their afiliate office here in the Netherlands as i have already given directives for the consignment to be brought to the Netherlands from South Africa.But before then all modalities will have to be put in place e.g change of ownership to the consignment and This money I intend to use for investment. I have two options for you. Firstly you can choose to have certain percentage of the money for nominating your account for this transaction. Or you can go into partnership with me for the proper profitable investment of the money in your country. Whichever the option you want, feel free to notify me. I have also mapped out 5% of this money for all kinds of expenses incurred in the process of this transaction. If you do not prefer a partnership I am willing to give you 15% of the money while the remaining 80% will be for my investment in your country. Contact me with throught my E-mail while I implore you to maintain the absolute secrecy required in this transaction. Thnak and God bless you, Yours Faithfully, Mario Matobu. From ian@latis.com Mon Oct 21 14:00:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 14:00:24 -0700 (PDT) Received: from dens700.corp.sbvc.com (dens700.hotbank.com [206.61.185.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LL0IuR020259 for ; Mon, 21 Oct 2002 14:00:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 MIME-Version: 1.0 Subject: Stupid netstat question Date: Mon, 21 Oct 2002 15:00:14 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stupid netstat question Thread-Index: AcJ5RNqBOVSIojSTSzG1PaF62XLSMA== From: "Ian Nelson" To: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 930 X-archive-position: 835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ian@latis.com Precedence: bulk X-list: netdev What exactly does the TCPSchedulerFailed metric mean? I'm building a network appliance that is doing a lot of nmap and nessus type stuff and I'm getting an extreme number of TCPSchedulerFailed and TCPAbortOnData. I've been tracking what I think is a bug in an Ethernet driver but I'm starting to think it's a software problem in application land. Much thanks for any direction, Ian . . . Ian S. Nelson Sr. Software Engineer Latis Networks, Inc. 303-642-4513 Direct 303-642-4501 Fax www.stillsecure.com Reducing your risk has never been this easy. . . . The information transmitted is intended only for the person to which it is addressed and may contain confidential material. Review or other use of this information by persons other than the intended recipient is prohibited. If you've received this in error, please contact the sender and delete from any computer. [[HTML alternate version deleted]] From niv@us.ibm.com Mon Oct 21 14:21:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 14:21:03 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LLL0uR022642 for ; Mon, 21 Oct 2002 14:21:01 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9LLKs0j192990; Mon, 21 Oct 2002 17:20:54 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9LLKqcI188290; Mon, 21 Oct 2002 17:20:52 -0400 Message-ID: <3DB46EB1.69B820FE@us.ibm.com> Date: Mon, 21 Oct 2002 14:16:33 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian Nelson CC: netdev@oss.sgi.com Subject: Re: Stupid netstat question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 836 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 Ian Nelson wrote: > > What exactly does the TCPSchedulerFailed metric mean? > I'm building a network appliance that is doing a lot of nmap and nessus > type stuff and I'm getting an extreme number of TCPSchedulerFailed and > TCPAbortOnData. I've been tracking what I think is a bug in an Ethernet > driver but I'm starting to think it's a software problem in application > land. Its the number of packets that are prequeued (partially completed tcp processing, waiting for a recvmsg to complete & send ack etc) when the delayed ack timer goes off. i.e I think, the thinking is this shouldnt happen, since the delayed ack timer really shouldnt go off - the receiver should have picked up the skb's and sent the acks. I'm probably off by a mile here..Dont know. It may be related to the AbortOnData counts. Are you closing apps with linger off or something? thanks, Nivedita From srompf@isg.de Mon Oct 21 14:37:13 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 14:37:15 -0700 (PDT) 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 g9LLbCuR024050 for ; Mon, 21 Oct 2002 14:37:13 -0700 Received: from isg.de (B178e.pppool.de [213.7.23.142]) by mail.isg.de (Postfix) with ESMTP id D232AD9C0EE; Mon, 21 Oct 2002 23:37:05 +0200 (CEST) Message-ID: <3DB473F0.4E8A58B7@isg.de> Date: Mon, 21 Oct 2002 23:38:56 +0200 From: Stefan Rompf X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-4GB i686) X-Accept-Language: en MIME-Version: 1.0 To: davem@redhat.com, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: Re: Patch: Idea for RFC2863 conform OperStatus References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 837 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 David, Hi Alexey, jamal wrote: > That lw_event is still bothering me ;-> But i dont wanna push it any > further ;-> I think we got some good stuff. Dave and Alexey should make > the call now. did you already have a chance to look at the latest patch? Cheers, Stefan From eletromarketing@spils.com Mon Oct 21 15:57:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 15:57:58 -0700 (PDT) Received: from 1142auto.com (pcp01107225pcs.clntn201.mi.comcast.net [68.62.69.162]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9LMvuuR030831 for ; Mon, 21 Oct 2002 15:57:56 -0700 Received: from plain [200.161.190.101] by 1142auto.com (SMTPD32-6.00) id AFC23E0058; Mon, 21 Oct 2002 18:54:10 -0700 From: eletromarketing@spils.com To: neteconomy@bol.com.br Subject: Negocios. Date: Mon, 21 Oct 2002 19:54:57 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" 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 Message-Id: <200210211855752.SM01208@plain> X-archive-position: 838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eletromarketing@spils.com Precedence: bulk X-list: netdev NEGOCIOS. A/C: Gerncia / Diretoria / Responsvel. VOC SABIA QUE O PROJETO DE LEI "PL-6210/2002" LHE GARANTE O DIREITO DO ENVIO DE E-MAILS COMERCIAIS ? Saiba mais visitando nosso Site: www.eletromarketing2002.com.br Conhea O meio mais gil, econmico e moderno de divulgar sua empresa e o seus servios para milhes de pessoas, atinja instantaneamente seus clientes: www.eletromarketing2002.com.br ou ainda pelo nosso e-mail excluisvo: pedidos@eletromarketing.com.br Tel. (0**11) 3851-2704 (Horrio Coml.) Muito obrigado por sua ateno e bons negcios ! Caso no queira mais receber emails como este clique aqui: remover@eletromarketing.com.br com o assunto "remove". From test2@test2.com Mon Oct 21 17:12:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 17:12:30 -0700 (PDT) Received: from test2.com ([218.48.35.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M0CPuR004345 for ; Mon, 21 Oct 2002 17:12:27 -0700 Message-Id: <200210220012.g9M0CPuR004345@oss.sgi.com> From: To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=B8=DE=C0=CF=B9=DF=BC=DB=B1=E2+=C3=DF=C3=E2=B1=E2=B0=A1?= =?ISO-8859-1?Q?=B2=C7=C2=A5=B4=D9!!?= Date: Tue, 22 Oct 2002 09:13:49 +0900 Mime-Version: 1.0 Content-Type: text/html; charset="euc-kr" X-archive-position: 839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: test2@test2.com Precedence: bulk X-list: netdev !!
We inform you, inaccordance with the advise of Ministry of information and Communication, that this email is an advertisement and the address of which hasbeen gathered form bulletine boards on internet as well as that we do not have any further information about you other than your email adress.If you do not wish to receive this email refuse button.
.
From bctraore@netscape.net Mon Oct 21 18:02:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 18:02:25 -0700 (PDT) Received: from oss.sgi.com (node-c-3f09.a2000.nl [62.194.63.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M12JuR008120 for ; Mon, 21 Oct 2002 18:02:20 -0700 Message-Id: <200210220102.g9M12JuR008120@oss.sgi.com> From: "Benson Cisse Traore" Date: Tue, 22 Oct 2002 03:02:15 To: netdev@oss.sgi.com Subject: Partnership. MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bctraore@netscape.net Precedence: bulk X-list: netdev Dear Prospective Partner, However strange or surprising this contact might seem to you, I ask that you give due consideration to its importance, as we both stand to benefit immensely. Though we have not met or know each other, this is a criteria I have used to select you, as I wish to cut off all ties with my people for security and safety reasons. At this point I wish to introduce myself properly to you. My name is Benson Cisse Traore, I am a personal aide to the Late General Robert Guei of blessed memory, former President of Cote d'Ivoire (Ivory Coast). You may not be conversant with the present situation in my country, which has gradually degenerated into a civil war. For the sake of what I envisage we achieve together, I wish to give you a general overview. My country in reality has ever since independence from France had an undefined and fragile polity. Founding president, Felix Houphouet-Boigny ruled us with individual blend of paternalism from independence in 1960 until his death in December 1993. He bowed to pressure for multi-party politics in 1990. In 1993, National Assembly president Henri Konan Bedie won a brief power struggle with Prime Minister Alassane Ouattara to succeed Houphouet-Boigny. The following month, the former single Ruling Democratic Party set up by Houphouet-Boigny, then headed by Bedie won an overwhelming majority in the National assembly. On December 24, 1999, my mentor Gen. Robert Guei ousted Bedie in a coup de tat. Although this was highly criticized, but it was the right thing to do. In July 2000, Gen. Guei approved a new constitution in referendum with tough eligibility conditions for presidential candidates. In spite of criticism, he registered as a candidate. The Supreme Court intervened, and he was cleared. This was not totally acceptable to the other candidates from the ruling Democratic Party (PDCI-RDA), the country's largest. The only opponent was Socialist candidate Laurent Gbagbo. Admittedly, Gbagbo won the election of October 22, 2000, but his political immaturity, led to Gen. Guei being reluctant to relinquish power. There were allegations of election rigging etc. Ouattara who was previously barred by the referendum to contest election, was excluded from the December 10 parliamentary election because of doubts about his nationality and his supporters announced they would boycott the election. Gbagbos Popular Front (FPI) was victorious in the election, and there were demonstrations due to propaganda that Gen. Guei tried to rig the election. Under pressure from international donors, Gbagbo agreed to hold a reconciliation forum to draw a line under the political strife that followed the 1999 coup, but key players including Outtara failed to show up for the opening. After two years of build up, On September 19, 2002, Gen. Guei led a failed coup de tat against Gbagbo, in a bid to restore political stability. Unfortunately, he was killed. After Gen. Gueis death, there was turmoil in our camp; this has led to us losing half our strength. Although we still control the north and Central regions of the country. It is now a question of who will give in between us (now referred to as rebels) and Gbagbos government. There seem to be no chance for peace, as several attempts has been botched by Gbagbo. Our Armory is seriously depleting, and we do not have the financial resources to strengthen it to prosecute the war. I have now decided to abandon the war. The US and France has since evacuated their citizens from our country. Destruction is imminent, as ECOWAS (Economy Community of West African States) has been called in to mediate. Their only way of doing this is to bring in ECOMOG (A monitoring group). We witnessed the horror they caused trying to restore peace to Liberia and Sierra Leone during the civil war. Thus I have lost faith and hope in the struggle. To the point, the essence of my contact with you is to seek your most needed assistance to siphon US$18,500,000 left in the bunker of Gen.Guei's Palace. Only Gen. Guei and me knew about this fund. Now that Gen. Guei is dead, I intend to use this money for my personal benefit (as well as yours if you accept to be my partner). I see justification in diverting the money, rather using it to support the purchase of weapons for destruction of innocent lives and properties. I secretly fled my Country, and this money was moved in cash to my present location in Europe through diplomatic means, and I have since deposited the trunk containing the funds with a private security company. If you accept to offer me your assistance, I will require that you assist me in claiming the box as a gift from me to you from the security company. Be informed that I am confiding in you by disclosing this to you, as it is only me (apparently you now) that have knowledge of this. When the box is claimed, we shall then have the money deposited into an Offshore account in your name, as I am being discrete of using my name for now. Then you shall have your own share withdrawn to an account of your choice, and leaving the rest as fixed deposit, for release to me at the appropriate time. The importance of prosecuting this within the next few days cannot be overlooked; hence your immediate response will be highly appreciated. On hearing from you, I shall disclose my location to you, and discuss the share of the money you will be entitled to for offering me your most needed assistance. In case you are not inclined to render me your assistance, endeavor to respond, so that I may move ahead. You may click this link http://news.bbc.co.uk/1/hi/world/africa/930254.stm to see me with my mentor Gen. Guei in 1999, so that you may associate this correspondence to my face. Sincerely, B. C. Traore. From jleu@nero.doit.wisc.edu Mon Oct 21 19:36:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 19:36:54 -0700 (PDT) Received: from nero.doit.wisc.edu (IDENT:root@nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M2aquR012708 for ; Mon, 21 Oct 2002 19:36:52 -0700 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.11.6/8.11.6) id g9M3cBU23160 for netdev@oss.sgi.com; Mon, 21 Oct 2002 22:38:11 -0500 Date: Mon, 21 Oct 2002 22:38:10 -0500 From: "James R. Leu" To: netdev@oss.sgi.com Subject: [RFC] Virtual Routing and Forwarding Message-ID: <20021021223810.A23086@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: none X-archive-position: 841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jleu@mindspring.com Precedence: bulk X-list: netdev Hello, I have given my first shot at implementing virtual routing and forwarding in the 2.4 IPv4 stack. I'm looking for feedback to see if there is a better way to go about this and to see if there is any interest from others. This patch associates a VRF index to netdevices and sockets. Packets arriving on an interface or being sent via the socket are marked with the VRF index. This VRF index is used to choose which rule list will be used for route lookups (in fib_lookup). This index is also used when handling TCP, UDP and raw sockets. The result is that each VRF has a complete rule list and associated tables. In addition the TCP and UDP ports are unique to each VRF (ie port numbers can be re-used and concurrently used in each VRF). I'm including only the kernel patch, but there are associated patches for ip (iproute2) and ping (iputils). There is also a userland utility for creating VRFs. Anyone who would like the full package (with some simple documentation) can get the package at http://sf.net/projects/linux-vrf/ in the file section. Humbly submitted. -- James R. Leu diff -uNr linux-kernel/include/asm-i386/socket.h vrf-kernel/include/asm-i386/socket.h --- linux-kernel/include/asm-i386/socket.h Sat Aug 24 00:21:07 2002 +++ vrf-kernel/include/asm-i386/socket.h Sat Aug 24 00:14:05 2002 @@ -44,6 +44,7 @@ #define SCM_TIMESTAMP SO_TIMESTAMP #define SO_ACCEPTCONN 30 +#define SO_VRF 31 /* Nasty libc5 fixup - bletch */ #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) diff -uNr linux-kernel/include/linux/inetdevice.h vrf-kernel/include/linux/inetdevice.h --- linux-kernel/include/linux/inetdevice.h Sat Aug 24 00:21:55 2002 +++ vrf-kernel/include/linux/inetdevice.h Sat Aug 24 00:14:19 2002 @@ -77,7 +77,7 @@ extern int register_inetaddr_notifier(struct notifier_block *nb); extern int unregister_inetaddr_notifier(struct notifier_block *nb); -extern struct net_device *ip_dev_find(u32 addr); +extern struct net_device *ip_dev_find(unsigned char vrf, u32 addr); extern int inet_addr_onlink(struct in_device *in_dev, u32 a, u32 b); extern int devinet_ioctl(unsigned int cmd, void *); extern void devinet_init(void); diff -uNr linux-kernel/include/linux/netdevice.h vrf-kernel/include/linux/netdevice.h --- linux-kernel/include/linux/netdevice.h Sat Aug 24 00:21:57 2002 +++ vrf-kernel/include/linux/netdevice.h Sun Sep 15 12:16:58 2002 @@ -431,6 +431,7 @@ /* this will get initialized at each interface type init routine */ struct divert_blk *divert; #endif /* CONFIG_NET_DIVERT */ + unsigned char vrf; }; diff -uNr linux-kernel/include/linux/rtnetlink.h vrf-kernel/include/linux/rtnetlink.h --- linux-kernel/include/linux/rtnetlink.h Sat Aug 24 00:22:03 2002 +++ vrf-kernel/include/linux/rtnetlink.h Sat Aug 24 00:14:20 2002 @@ -88,6 +88,7 @@ unsigned char rtm_tos; unsigned char rtm_table; /* Routing table id */ + unsigned char rtm_vrf; /* VRF id */ unsigned char rtm_protocol; /* Routing protocol; see below */ unsigned char rtm_scope; /* See below */ unsigned char rtm_type; /* See below */ @@ -179,6 +180,7 @@ RT_TABLE_LOCAL=255 }; #define RT_TABLE_MAX RT_TABLE_LOCAL +#define VRF_MAX 8 @@ -440,12 +442,13 @@ #define IFLA_COST IFLA_COST IFLA_PRIORITY, #define IFLA_PRIORITY IFLA_PRIORITY - IFLA_MASTER + IFLA_MASTER, #define IFLA_MASTER IFLA_MASTER + IFLA_VRF }; -#define IFLA_MAX IFLA_MASTER +#define IFLA_MAX IFLA_VRF #define IFLA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifinfomsg)))) #define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg)) diff -uNr linux-kernel/include/linux/skbuff.h vrf-kernel/include/linux/skbuff.h --- linux-kernel/include/linux/skbuff.h Sat Aug 24 00:22:04 2002 +++ vrf-kernel/include/linux/skbuff.h Sun Sep 15 12:16:58 2002 @@ -215,6 +215,7 @@ #ifdef CONFIG_NET_SCHED __u32 tc_index; /* traffic control index */ #endif + unsigned char vrf; }; #define SK_WMEM_MAX 65535 diff -uNr linux-kernel/include/linux/sockios.h vrf-kernel/include/linux/sockios.h --- linux-kernel/include/linux/sockios.h Sat Aug 24 00:22:04 2002 +++ vrf-kernel/include/linux/sockios.h Sat Aug 24 00:14:21 2002 @@ -105,6 +105,12 @@ #define SIOCGIFVLAN 0x8982 /* 802.1Q VLAN support */ #define SIOCSIFVLAN 0x8983 /* Set 802.1Q VLAN options */ +#define SIOCGIFVRF 0x8984 /* get VRF */ +#define SIOCSIFVRF 0x8985 /* set VRF */ + +#define SIOCADDVRF 0x8986 /* add VRF */ +#define SIOCDELVRF 0x8987 /* del VRF */ + /* bonding calls */ #define SIOCBONDENSLAVE 0x8990 /* enslave a device to the bond */ diff -uNr linux-kernel/include/net/ip_fib.h vrf-kernel/include/net/ip_fib.h --- linux-kernel/include/net/ip_fib.h Sat Aug 24 00:22:09 2002 +++ vrf-kernel/include/net/ip_fib.h Mon Sep 16 19:48:57 2002 @@ -132,69 +132,33 @@ void (*tb_select_default)(struct fib_table *table, const struct rt_key *key, struct fib_result *res); + unsigned char tb_vrf; unsigned char tb_data[0]; }; -#ifndef CONFIG_IP_MULTIPLE_TABLES - -extern struct fib_table *local_table; -extern struct fib_table *main_table; - -static inline struct fib_table *fib_get_table(int id) -{ - if (id != RT_TABLE_LOCAL) - return main_table; - return local_table; -} - -static inline struct fib_table *fib_new_table(int id) -{ - return fib_get_table(id); -} - -static inline int fib_lookup(const struct rt_key *key, struct fib_result *res) -{ - if (local_table->tb_lookup(local_table, key, res) && - main_table->tb_lookup(main_table, key, res)) - return -ENETUNREACH; - return 0; -} - -static inline void fib_select_default(const struct rt_key *key, struct fib_result *res) -{ - if (FIB_RES_GW(*res) && FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK) - main_table->tb_select_default(main_table, key, res); -} - -#else /* CONFIG_IP_MULTIPLE_TABLES */ -#define local_table (fib_tables[RT_TABLE_LOCAL]) -#define main_table (fib_tables[RT_TABLE_MAIN]) - -extern struct fib_table * fib_tables[RT_TABLE_MAX+1]; +extern struct fib_table * fib_tables[VRF_MAX][RT_TABLE_MAX+1]; extern int fib_lookup(const struct rt_key *key, struct fib_result *res); -extern struct fib_table *__fib_new_table(int id); +extern struct fib_table *__fib_new_table(unsigned char vrf, int id); extern void fib_rule_put(struct fib_rule *r); -static inline struct fib_table *fib_get_table(int id) +static inline struct fib_table *fib_get_table(unsigned char vrf, int id) { if (id == 0) id = RT_TABLE_MAIN; - return fib_tables[id]; + return fib_tables[vrf][id]; } -static inline struct fib_table *fib_new_table(int id) +static inline struct fib_table *fib_new_table(unsigned char vrf, int id) { if (id == 0) id = RT_TABLE_MAIN; - return fib_tables[id] ? : __fib_new_table(id); + return fib_tables[vrf][id] ? : __fib_new_table(vrf,id); } extern void fib_select_default(const struct rt_key *key, struct fib_result *res); -#endif /* CONFIG_IP_MULTIPLE_TABLES */ - /* Exported by fib_frontend.c */ extern void ip_fib_init(void); extern void fib_flush(void); @@ -212,11 +176,11 @@ extern int fib_semantic_match(int type, struct fib_info *, const struct rt_key *, struct fib_result*); extern struct fib_info *fib_create_info(const struct rtmsg *r, struct kern_rta *rta, - const struct nlmsghdr *, int *err); + const struct nlmsghdr *, unsigned char vrf, int *err); extern int fib_nh_match(struct rtmsg *r, struct nlmsghdr *, struct kern_rta *rta, struct fib_info *fi); extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event, u8 tb_id, u8 type, u8 scope, void *dst, int dst_len, u8 tos, - struct fib_info *fi); + struct fib_info *fi, unsigned char vrf); extern int fib_sync_down(u32 local, struct net_device *dev, int force); extern int fib_sync_up(struct net_device *dev); extern int fib_convert_rtentry(int cmd, struct nlmsghdr *nl, struct rtmsg *rtm, @@ -225,7 +189,7 @@ extern u32 __fib_res_prefsrc(struct fib_result *res); /* Exported by fib_hash.c */ -extern struct fib_table *fib_hash_init(int id); +extern struct fib_table *fib_hash_init(unsigned char vrf, int id); #ifdef CONFIG_IP_MULTIPLE_TABLES /* Exported by fib_rules.c */ diff -uNr linux-kernel/include/net/raw.h vrf-kernel/include/net/raw.h --- linux-kernel/include/net/raw.h Sat Aug 24 00:22:12 2002 +++ vrf-kernel/include/net/raw.h Sat Aug 24 00:14:24 2002 @@ -35,7 +35,7 @@ extern struct sock *__raw_v4_lookup(struct sock *sk, unsigned short num, unsigned long raddr, unsigned long laddr, - int dif); + int dif, unsigned char vrf); extern struct sock *raw_v4_input(struct sk_buff *skb, struct iphdr *iph, int hash); diff -uNr linux-kernel/include/net/route.h vrf-kernel/include/net/route.h --- linux-kernel/include/net/route.h Sat Aug 24 00:22:12 2002 +++ vrf-kernel/include/net/route.h Sun Sep 15 12:17:16 2002 @@ -56,6 +56,7 @@ #endif __u8 tos; __u8 scope; + __u8 vrf; }; struct inet_peer; @@ -126,11 +127,11 @@ extern void rt_cache_flush(int how); extern int ip_route_output_key(struct rtable **, const struct rt_key *key); extern int ip_route_input(struct sk_buff*, u32 dst, u32 src, u8 tos, struct net_device *devin); -extern unsigned short ip_rt_frag_needed(struct iphdr *iph, unsigned short new_mtu); +extern unsigned short ip_rt_frag_needed(struct iphdr *iph, unsigned short new_mtu, unsigned char vrf); extern void ip_rt_update_pmtu(struct dst_entry *dst, unsigned mtu); extern void ip_rt_send_redirect(struct sk_buff *skb); -extern unsigned inet_addr_type(u32 addr); +extern unsigned inet_addr_type(unsigned char vrf, u32 addr); extern void ip_rt_multicast_event(struct in_device *); extern int ip_rt_ioctl(unsigned int cmd, void *arg); extern void ip_rt_get_source(u8 *src, struct rtable *rt); @@ -161,17 +162,19 @@ return ip_tos2prio[IPTOS_TOS(tos)>>1]; } -static inline int ip_route_connect(struct rtable **rp, u32 dst, u32 src, u32 tos, int oif) +static inline int ip_route_connect(struct rtable **rp, u32 dst, u32 src, u32 tos, int oif, int vrf) { int err; - err = ip_route_output(rp, dst, src, tos, oif); + struct rt_key key = { dst:dst, src:src, oif:oif, tos:tos, vrf:vrf }; + + err = ip_route_output_key(rp, &key); if (err || (dst && src)) return err; - dst = (*rp)->rt_dst; - src = (*rp)->rt_src; + key.dst = (*rp)->rt_dst; + key.src = (*rp)->rt_src; ip_rt_put(*rp); *rp = NULL; - return ip_route_output(rp, dst, src, tos, oif); + return ip_route_output_key(rp, &key); } extern void rt_bind_peer(struct rtable *rt, int create); diff -uNr linux-kernel/include/net/sock.h vrf-kernel/include/net/sock.h --- linux-kernel/include/net/sock.h Sat Aug 24 00:22:12 2002 +++ vrf-kernel/include/net/sock.h Sun Sep 15 12:17:06 2002 @@ -493,6 +493,7 @@ __u16 dport; /* Destination port */ unsigned short num; /* Local port */ int bound_dev_if; /* Bound device index if != 0 */ + unsigned char vrf; /* VRF != 0 */ /* Main hash linkage for various protocol lookup tables. */ struct sock *next; diff -uNr linux-kernel/include/net/tcp.h vrf-kernel/include/net/tcp.h --- linux-kernel/include/net/tcp.h Sat Aug 24 00:22:13 2002 +++ vrf-kernel/include/net/tcp.h Sat Aug 24 00:14:24 2002 @@ -79,6 +79,7 @@ struct tcp_bind_bucket *next; struct sock *owners; struct tcp_bind_bucket **pprev; + unsigned char vrf; }; struct tcp_bind_hashbucket { @@ -136,10 +137,10 @@ extern kmem_cache_t *tcp_bucket_cachep; extern struct tcp_bind_bucket *tcp_bucket_create(struct tcp_bind_hashbucket *head, - unsigned short snum); + unsigned short snum,unsigned char vrf); extern void tcp_bucket_unlock(struct sock *sk); extern int tcp_port_rover; -extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif); +extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif, unsigned char vrf); /* These are AF independent. */ static __inline__ int tcp_bhashfn(__u16 lport) @@ -161,6 +162,7 @@ __u16 dport; unsigned short num; int bound_dev_if; + unsigned char vrf; struct sock *next; struct sock **pprev; struct sock *bind_next; @@ -229,17 +231,19 @@ #define TCP_V4_ADDR_COOKIE(__name, __saddr, __daddr) \ __u64 __name = (((__u64)(__daddr))<<32)|((__u64)(__saddr)); #endif /* __BIG_ENDIAN */ -#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif)\ +#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif, __vrf)\ (((*((__u64 *)&((__sk)->daddr)))== (__cookie)) && \ ((*((__u32 *)&((__sk)->dport)))== (__ports)) && \ - (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif)))) + (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif))) && \ + ((__sk)->vrf == (__vrf))) #else /* 32-bit arch */ #define TCP_V4_ADDR_COOKIE(__name, __saddr, __daddr) -#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif)\ +#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif, __vrf)\ (((__sk)->daddr == (__saddr)) && \ ((__sk)->rcv_saddr == (__daddr)) && \ ((*((__u32 *)&((__sk)->dport)))== (__ports)) && \ - (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif)))) + (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif))) && \ + ((__sk)->vrf == (__vrf))) #endif /* 64-bit arch */ #define TCP_IPV6_MATCH(__sk, __saddr, __daddr, __ports, __dif) \ diff -uNr linux-kernel/net/core/dev.c vrf-kernel/net/core/dev.c --- linux-kernel/net/core/dev.c Sat Aug 24 00:22:26 2002 +++ vrf-kernel/net/core/dev.c Sat Aug 24 00:14:27 2002 @@ -2011,6 +2011,14 @@ notifier_call_chain(&netdev_chain, NETDEV_CHANGEMTU, dev); return err; + case SIOCGIFVRF: /* Get the VRF for a device */ + ifr->ifr_flags = dev->vrf; + return 0; + + case SIOCSIFVRF: /* Set the VRF for a device */ + dev->vrf = ifr->ifr_flags; + return 0; + case SIOCGIFHWADDR: memcpy(ifr->ifr_hwaddr.sa_data,dev->dev_addr, MAX_ADDR_LEN); ifr->ifr_hwaddr.sa_family=dev->type; @@ -2185,6 +2193,7 @@ case SIOCGIFFLAGS: case SIOCGIFMETRIC: case SIOCGIFMTU: + case SIOCGIFVRF: case SIOCGIFHWADDR: case SIOCGIFSLAVE: case SIOCGIFMAP: @@ -2238,6 +2247,7 @@ case SIOCSIFFLAGS: case SIOCSIFMETRIC: case SIOCSIFMTU: + case SIOCSIFVRF: case SIOCSIFMAP: case SIOCSIFHWADDR: case SIOCSIFSLAVE: diff -uNr linux-kernel/net/core/rtnetlink.c vrf-kernel/net/core/rtnetlink.c --- linux-kernel/net/core/rtnetlink.c Sat Aug 24 00:22:26 2002 +++ vrf-kernel/net/core/rtnetlink.c Sat Aug 24 00:14:27 2002 @@ -155,6 +155,7 @@ struct ifinfomsg *r; struct nlmsghdr *nlh; unsigned char *b = skb->tail; + int vrf; nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*r)); if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; @@ -171,6 +172,8 @@ r->ifi_flags |= IFF_RUNNING; RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name); + vrf = dev->vrf; + RTA_PUT(skb, IFLA_VRF, sizeof(vrf), &vrf); if (dev->addr_len) { RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr); RTA_PUT(skb, IFLA_BROADCAST, dev->addr_len, dev->broadcast); @@ -187,6 +190,9 @@ dev->qdisc_sleeping->ops->id); if (dev->master) RTA_PUT(skb, IFLA_MASTER, sizeof(int), &dev->master->ifindex); + + RTA_PUT(skb, IFLA_VRF, sizeof(int), &dev->vrf); + if (dev->get_stats) { struct net_device_stats *stats = dev->get_stats(dev); if (stats) diff -uNr linux-kernel/net/core/skbuff.c vrf-kernel/net/core/skbuff.c --- linux-kernel/net/core/skbuff.c Sat Aug 24 00:22:26 2002 +++ vrf-kernel/net/core/skbuff.c Sat Aug 24 00:14:27 2002 @@ -249,6 +249,7 @@ #ifdef CONFIG_NET_SCHED skb->tc_index = 0; #endif + skb->vrf = 0; } static void skb_drop_fraglist(struct sk_buff *skb) @@ -398,6 +399,7 @@ #ifdef CONFIG_NET_SCHED C(tc_index); #endif + C(vrf); atomic_inc(&(skb_shinfo(skb)->dataref)); skb->cloned = 1; @@ -441,6 +443,7 @@ #ifdef CONFIG_NET_SCHED new->tc_index = old->tc_index; #endif + new->vrf = old->vrf; } /** diff -uNr linux-kernel/net/core/sock.c vrf-kernel/net/core/sock.c --- linux-kernel/net/core/sock.c Sat Aug 24 00:22:26 2002 +++ vrf-kernel/net/core/sock.c Sun Sep 15 16:05:54 2002 @@ -281,6 +281,13 @@ ret = -EPERM; break; + case SO_VRF: + if((val >= 0 && val <= 8) || capable(CAP_NET_ADMIN)) + sk->vrf = val; + else + ret = -EPERM; + break; + case SO_LINGER: if(optlenpasscred; break; + + case SO_VRF: + v.val = sk->vrf; + break; case SO_PEERCRED: if (len > sizeof(sk->peercred)) diff -uNr linux-kernel/net/ipv4/af_inet.c vrf-kernel/net/ipv4/af_inet.c --- linux-kernel/net/ipv4/af_inet.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/af_inet.c Sat Aug 24 00:14:27 2002 @@ -130,6 +130,8 @@ extern int tcp_get_info(char *, char **, off_t, int); extern int udp_get_info(char *, char **, off_t, int); extern void ip_mc_drop_socket(struct sock *sk); +extern int fib_add_vrf(unsigned char vrf); +extern int fib_del_vrf(unsigned char vrf); #ifdef CONFIG_DLCI extern int dlci_ioctl(unsigned int, void*); @@ -485,7 +487,7 @@ if (addr_len < sizeof(struct sockaddr_in)) return -EINVAL; - chk_addr_ret = inet_addr_type(addr->sin_addr.s_addr); + chk_addr_ret = inet_addr_type(sk->vrf, addr->sin_addr.s_addr); /* Not specified by any standard per-se, however it breaks too * many applications when removed. It is unfortunate since @@ -923,6 +925,18 @@ } #endif return -ENOPKG; + + case SIOCADDVRF: + lock_kernel(); + err = fib_add_vrf((unsigned char)arg); + unlock_kernel(); + return err; + + case SIOCDELVRF: + lock_kernel(); + err = fib_del_vrf((unsigned char)arg); + unlock_kernel(); + return err; default: if ((cmd >= SIOCDEVPRIVATE) && diff -uNr linux-kernel/net/ipv4/arp.c vrf-kernel/net/ipv4/arp.c --- linux-kernel/net/ipv4/arp.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/arp.c Sat Aug 24 00:14:27 2002 @@ -233,7 +233,7 @@ if (in_dev == NULL) return -EINVAL; - neigh->type = inet_addr_type(addr); + neigh->type = inet_addr_type(dev->vrf, addr); if (in_dev->arp_parms) neigh->parms = in_dev->arp_parms; @@ -322,7 +322,7 @@ u32 target = *(u32*)neigh->primary_key; int probes = atomic_read(&neigh->probes); - if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL) + if (skb && inet_addr_type(dev->vrf, skb->nh.iph->saddr) == RTN_LOCAL) saddr = skb->nh.iph->saddr; else saddr = inet_select_addr(dev, target, RT_SCOPE_LINK); @@ -347,11 +347,18 @@ static int arp_filter(__u32 sip, __u32 tip, struct net_device *dev) { + struct rt_key key; struct rtable *rt; int flag = 0; /*unsigned long now; */ - if (ip_route_output(&rt, sip, tip, 0, 0) < 0) + memset(&key,0,sizeof(key)); + key.dst = sip; + key.src = tip; + key.tos = 0; + key.oif = 0; + key.vrf = dev->vrf; + if (ip_route_output_key(&rt, &key) < 0) return 1; if (rt->u.dst.dev != dev) { NET_INC_STATS_BH(ArpFilter); @@ -404,7 +411,7 @@ paddr = ((struct rtable*)skb->dst)->rt_gateway; - if (arp_set_predefined(inet_addr_type(paddr), haddr, paddr, dev)) + if (arp_set_predefined(inet_addr_type(dev->vrf, paddr), haddr, paddr, dev)) return 0; n = __neigh_lookup(&arp_tbl, &paddr, dev, 1); @@ -627,6 +634,8 @@ arp = skb->nh.arph; arp_ptr= (unsigned char *)(arp+1); + skb->vrf = dev->vrf; + switch (dev_type) { default: if (arp->ar_pro != __constant_htons(ETH_P_IP)) @@ -755,7 +764,7 @@ /* Special case: IPv4 duplicate address detection packet (RFC2131) */ if (sip == 0) { if (arp->ar_op == __constant_htons(ARPOP_REQUEST) && - inet_addr_type(tip) == RTN_LOCAL) + inet_addr_type(dev->vrf, tip) == RTN_LOCAL) arp_send(ARPOP_REPLY,ETH_P_ARP,tip,dev,tip,sha,dev->dev_addr,dev->dev_addr); goto out; } @@ -811,7 +820,7 @@ */ if (n == NULL && arp->ar_op == __constant_htons(ARPOP_REPLY) && - inet_addr_type(sip) == RTN_UNICAST) + inet_addr_type(dev->vrf, sip) == RTN_UNICAST) n = __neigh_lookup(&arp_tbl, &sip, dev, -1); #endif @@ -918,8 +927,16 @@ if (r->arp_flags & ATF_PERM) r->arp_flags |= ATF_COM; if (dev == NULL) { + struct rt_key key; struct rtable * rt; - if ((err = ip_route_output(&rt, ip, 0, RTO_ONLINK, 0)) != 0) + + memset(&key,0,sizeof(key)); + key.dst = ip; + key.src = 0; + key.tos = RTO_ONLINK; + key.oif = 0; + key.vrf = 0; + if ((err = ip_route_output_key(&rt, &key)) != 0) return err; dev = rt->u.dst.dev; ip_rt_put(rt); @@ -1001,8 +1018,16 @@ } if (dev == NULL) { + struct rt_key key; struct rtable * rt; - if ((err = ip_route_output(&rt, ip, 0, RTO_ONLINK, 0)) != 0) + + memset(&key,0,sizeof(key)); + key.dst = ip; + key.src = 0; + key.tos = RTO_ONLINK; + key.oif = 0; + key.vrf = 0; + if ((err = ip_route_output_key(&rt, &key)) != 0) return err; dev = rt->u.dst.dev; ip_rt_put(rt); diff -uNr linux-kernel/net/ipv4/fib_frontend.c vrf-kernel/net/ipv4/fib_frontend.c --- linux-kernel/net/ipv4/fib_frontend.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/fib_frontend.c Mon Sep 16 20:12:42 2002 @@ -51,23 +51,20 @@ #define RT_TABLE_MIN RT_TABLE_MAIN -struct fib_table *local_table; -struct fib_table *main_table; - #else #define RT_TABLE_MIN 1 -struct fib_table *fib_tables[RT_TABLE_MAX+1]; +struct fib_table *fib_tables[VRF_MAX][RT_TABLE_MAX+1]; -struct fib_table *__fib_new_table(int id) +struct fib_table *__fib_new_table(unsigned char vrf, int id) { struct fib_table *tb; - tb = fib_hash_init(id); + tb = fib_hash_init(vrf,id); if (!tb) return NULL; - fib_tables[id] = tb; + fib_tables[vrf][id] = tb; return tb; } @@ -78,20 +75,17 @@ void fib_flush(void) { int flushed = 0; -#ifdef CONFIG_IP_MULTIPLE_TABLES struct fib_table *tb; + int vrf; int id; - for (id = RT_TABLE_MAX; id>0; id--) { - if ((tb = fib_get_table(id))==NULL) - continue; - flushed += tb->tb_flush(tb); - } -#else /* CONFIG_IP_MULTIPLE_TABLES */ - flushed += main_table->tb_flush(main_table); - flushed += local_table->tb_flush(local_table); -#endif /* CONFIG_IP_MULTIPLE_TABLES */ - + for (vrf = 0 ; vrf < VRF_MAX ; vrf++) { + for (id = RT_TABLE_MAX; id>0; id--) { + if ((tb = fib_get_table(vrf,id))==NULL) + continue; + flushed += tb->tb_flush(tb); + } + } if (flushed) rt_cache_flush(-1); } @@ -112,6 +106,7 @@ int first = offset/128; char *ptr = buffer; int count = (length+127)/128; + struct fib_table *table; int len; *start = buffer + offset%128; @@ -123,8 +118,8 @@ first = 0; } - if (main_table && count > 0) { - int n = main_table->tb_get_info(main_table, ptr, first, count); + if ((table = fib_get_table(0,RT_TABLE_MAIN)) && count > 0) { + int n = table->tb_get_info(table, ptr, first, count); count -= n; ptr += n*128; } @@ -142,19 +137,21 @@ * Find the first device with a given source address. */ -struct net_device * ip_dev_find(u32 addr) +struct net_device * ip_dev_find(unsigned char vrf, u32 addr) { struct rt_key key; struct fib_result res; struct net_device *dev = NULL; + struct fib_table *table; memset(&key, 0, sizeof(key)); key.dst = addr; + key.vrf = vrf; #ifdef CONFIG_IP_MULTIPLE_TABLES res.r = NULL; #endif - if (!local_table || local_table->tb_lookup(local_table, &key, &res)) { + if (!(table = fib_get_table(vrf,RT_TABLE_LOCAL)) || table->tb_lookup(table, &key, &res)) { return NULL; } if (res.type != RTN_LOCAL) @@ -168,10 +165,11 @@ return dev; } -unsigned inet_addr_type(u32 addr) +unsigned inet_addr_type(unsigned char vrf, u32 addr) { struct rt_key key; struct fib_result res; + struct fib_table *table; unsigned ret = RTN_BROADCAST; if (ZERONET(addr) || BADCLASS(addr)) @@ -181,13 +179,14 @@ memset(&key, 0, sizeof(key)); key.dst = addr; + key.vrf = vrf; #ifdef CONFIG_IP_MULTIPLE_TABLES res.r = NULL; #endif - if (local_table) { + if ((table = fib_get_table(vrf,RT_TABLE_LOCAL))) { ret = RTN_UNICAST; - if (local_table->tb_lookup(local_table, &key, &res) == 0) { + if (table->tb_lookup(table, &key, &res) == 0) { ret = res.type; fib_res_put(&res); } @@ -216,6 +215,7 @@ key.src = dst; key.tos = tos; key.oif = 0; + key.vrf = dev->vrf; key.iif = oif; key.scope = RT_SCOPE_UNIVERSE; @@ -304,12 +304,12 @@ err = fib_convert_rtentry(cmd, &req.nlh, &req.rtm, &rta, &r); if (err == 0) { if (cmd == SIOCDELRT) { - struct fib_table *tb = fib_get_table(req.rtm.rtm_table); + struct fib_table *tb = fib_get_table(req.rtm.rtm_vrf, req.rtm.rtm_table); err = -ESRCH; if (tb) err = tb->tb_delete(tb, &req.rtm, &rta, &req.nlh, NULL); } else { - struct fib_table *tb = fib_new_table(req.rtm.rtm_table); + struct fib_table *tb = fib_new_table(req.rtm.rtm_vrf, req.rtm.rtm_table); err = -ENOBUFS; if (tb) err = tb->tb_insert(tb, &req.rtm, &rta, &req.nlh, NULL); @@ -357,7 +357,7 @@ if (inet_check_attr(r, rta)) return -EINVAL; - tb = fib_get_table(r->rtm_table); + tb = fib_get_table(r->rtm_vrf, r->rtm_table); if (tb) return tb->tb_delete(tb, r, (struct kern_rta*)rta, nlh, &NETLINK_CB(skb)); return -ESRCH; @@ -372,7 +372,7 @@ if (inet_check_attr(r, rta)) return -EINVAL; - tb = fib_new_table(r->rtm_table); + tb = fib_new_table(r->rtm_vrf, r->rtm_table); if (tb) return tb->tb_insert(tb, r, (struct kern_rta*)rta, nlh, &NETLINK_CB(skb)); return -ENOBUFS; @@ -381,6 +381,7 @@ int inet_dump_fib(struct sk_buff *skb, struct netlink_callback *cb) { int t; + int v; int s_t; struct fib_table *tb; @@ -392,14 +393,18 @@ if (s_t == 0) s_t = cb->args[0] = RT_TABLE_MIN; - for (t=s_t; t<=RT_TABLE_MAX; t++) { - if (t < s_t) continue; - if (t > s_t) - memset(&cb->args[1], 0, sizeof(cb->args)-sizeof(cb->args[0])); - if ((tb = fib_get_table(t))==NULL) - continue; - if (tb->tb_dump(tb, skb, cb) < 0) - break; + for (v=0;v < VRF_MAX; v++) { + for (t=s_t; t<=RT_TABLE_MAX; t++) { + if (t < s_t) continue; + if (t > s_t) + memset(&cb->args[1], 0, sizeof(cb->args)-sizeof(cb->args[0])); + if ((tb = fib_get_table(v,t))==NULL) + continue; + if (tb->tb_dump(tb, skb, cb) < 0) { + v = VRF_MAX; + break; + } + } } cb->args[0] = t; @@ -414,7 +419,7 @@ only when netlink is already locked. */ -static void fib_magic(int cmd, int type, u32 dst, int dst_len, struct in_ifaddr *ifa) +static void fib_magic(int cmd, int type, u32 dst, int dst_len, struct in_ifaddr *ifa, unsigned char vrf) { struct fib_table * tb; struct { @@ -427,9 +432,9 @@ memset(&rta, 0, sizeof(rta)); if (type == RTN_UNICAST) - tb = fib_new_table(RT_TABLE_MAIN); + tb = fib_new_table(vrf, RT_TABLE_MAIN); else - tb = fib_new_table(RT_TABLE_LOCAL); + tb = fib_new_table(vrf, RT_TABLE_LOCAL); if (tb == NULL) return; @@ -442,6 +447,7 @@ req.rtm.rtm_dst_len = dst_len; req.rtm.rtm_table = tb->tb_id; + req.rtm.rtm_vrf = tb->tb_vrf; req.rtm.rtm_protocol = RTPROT_KERNEL; req.rtm.rtm_scope = (type != RTN_LOCAL ? RT_SCOPE_LINK : RT_SCOPE_HOST); req.rtm.rtm_type = type; @@ -473,24 +479,24 @@ } } - fib_magic(RTM_NEWROUTE, RTN_LOCAL, addr, 32, prim); + fib_magic(RTM_NEWROUTE, RTN_LOCAL, addr, 32, prim, dev->vrf); if (!(dev->flags&IFF_UP)) return; /* Add broadcast address, if it is explicitly assigned. */ if (ifa->ifa_broadcast && ifa->ifa_broadcast != 0xFFFFFFFF) - fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim); + fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim, dev->vrf); if (!ZERONET(prefix) && !(ifa->ifa_flags&IFA_F_SECONDARY) && (prefix != addr || ifa->ifa_prefixlen < 32)) { fib_magic(RTM_NEWROUTE, dev->flags&IFF_LOOPBACK ? RTN_LOCAL : - RTN_UNICAST, prefix, ifa->ifa_prefixlen, prim); + RTN_UNICAST, prefix, ifa->ifa_prefixlen, prim, dev->vrf); /* Add network specific broadcasts, when it takes a sense */ if (ifa->ifa_prefixlen < 31) { - fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32, prim); - fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix|~mask, 32, prim); + fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32, prim, dev->vrf); + fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix|~mask, 32, prim, dev->vrf); } } } @@ -511,7 +517,7 @@ if (!(ifa->ifa_flags&IFA_F_SECONDARY)) fib_magic(RTM_DELROUTE, dev->flags&IFF_LOOPBACK ? RTN_LOCAL : - RTN_UNICAST, any, ifa->ifa_prefixlen, prim); + RTN_UNICAST, any, ifa->ifa_prefixlen, prim, dev->vrf); else { prim = inet_ifa_byprefix(in_dev, any, ifa->ifa_mask); if (prim == NULL) { @@ -538,16 +544,16 @@ } if (!(ok&BRD_OK)) - fib_magic(RTM_DELROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim); + fib_magic(RTM_DELROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim, dev->vrf); if (!(ok&BRD1_OK)) - fib_magic(RTM_DELROUTE, RTN_BROADCAST, brd, 32, prim); + fib_magic(RTM_DELROUTE, RTN_BROADCAST, brd, 32, prim, dev->vrf); if (!(ok&BRD0_OK)) - fib_magic(RTM_DELROUTE, RTN_BROADCAST, any, 32, prim); + fib_magic(RTM_DELROUTE, RTN_BROADCAST, any, 32, prim, dev->vrf); if (!(ok&LOCAL_OK)) { - fib_magic(RTM_DELROUTE, RTN_LOCAL, ifa->ifa_local, 32, prim); + fib_magic(RTM_DELROUTE, RTN_LOCAL, ifa->ifa_local, 32, prim, dev->vrf); /* Check, that this local address finally disappeared. */ - if (inet_addr_type(ifa->ifa_local) != RTN_LOCAL) { + if (inet_addr_type(dev->vrf,ifa->ifa_local) != RTN_LOCAL) { /* And the last, but not the least thing. We must flush stray FIB entries. @@ -647,12 +653,7 @@ proc_net_create("route",0,fib_get_procinfo); #endif /* CONFIG_PROC_FS */ -#ifndef CONFIG_IP_MULTIPLE_TABLES - local_table = fib_hash_init(RT_TABLE_LOCAL); - main_table = fib_hash_init(RT_TABLE_MAIN); -#else fib_rules_init(); -#endif register_netdevice_notifier(&fib_netdev_notifier); register_inetaddr_notifier(&fib_inetaddr_notifier); diff -uNr linux-kernel/net/ipv4/fib_hash.c vrf-kernel/net/ipv4/fib_hash.c --- linux-kernel/net/ipv4/fib_hash.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/fib_hash.c Sun Sep 15 14:37:51 2002 @@ -427,7 +427,7 @@ static void rtmsg_fib(int, struct fib_node*, int, int, struct nlmsghdr *n, - struct netlink_skb_parms *); + struct netlink_skb_parms *, unsigned char vrf); static int fn_hash_insert(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, @@ -464,7 +464,7 @@ key = fz_key(dst, fz); } - if ((fi = fib_create_info(r, rta, n, &err)) == NULL) + if ((fi = fib_create_info(r, rta, n, tb->tb_vrf, &err)) == NULL) return err; #ifdef CONFIG_IP_ROUTE_LARGE_TABLES @@ -593,7 +593,7 @@ write_unlock_bh(&fib_hash_lock); if (!(f->fn_state&FN_S_ZOMBIE)) - rtmsg_fib(RTM_DELROUTE, f, z, tb->tb_id, n, req); + rtmsg_fib(RTM_DELROUTE, f, z, tb->tb_id, n, req, tb->tb_vrf); if (f->fn_state&FN_S_ACCESSED) rt_cache_flush(-1); fn_free_node(f); @@ -601,7 +601,7 @@ } else { rt_cache_flush(-1); } - rtmsg_fib(RTM_NEWROUTE, new_f, z, tb->tb_id, n, req); + rtmsg_fib(RTM_NEWROUTE, new_f, z, tb->tb_id, n, req, tb->tb_vrf); return 0; out: @@ -677,7 +677,7 @@ if (del_fp) { f = *del_fp; - rtmsg_fib(RTM_DELROUTE, f, z, tb->tb_id, n, req); + rtmsg_fib(RTM_DELROUTE, f, z, tb->tb_id, n, req, tb->tb_vrf); if (matched != 1) { write_lock_bh(&fib_hash_lock); @@ -807,7 +807,7 @@ RTM_NEWROUTE, tb->tb_id, (f->fn_state&FN_S_ZOMBIE) ? 0 : f->fn_type, f->fn_scope, &f->fn_key, fz->fz_order, f->fn_tos, - f->fn_info) < 0) { + f->fn_info, tb->tb_vrf) < 0) { cb->args[3] = i; return -1; } @@ -863,7 +863,8 @@ } static void rtmsg_fib(int event, struct fib_node* f, int z, int tb_id, - struct nlmsghdr *n, struct netlink_skb_parms *req) + struct nlmsghdr *n, struct netlink_skb_parms *req, + unsigned char vrf) { struct sk_buff *skb; u32 pid = req ? req->pid : 0; @@ -875,7 +876,7 @@ if (fib_dump_info(skb, pid, n->nlmsg_seq, event, tb_id, f->fn_type, f->fn_scope, &f->fn_key, z, f->fn_tos, - FIB_INFO(f)) < 0) { + FIB_INFO(f), vrf) < 0) { kfree_skb(skb); return; } @@ -887,11 +888,7 @@ netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT); } -#ifdef CONFIG_IP_MULTIPLE_TABLES -struct fib_table * fib_hash_init(int id) -#else -struct fib_table * __init fib_hash_init(int id) -#endif +struct fib_table * fib_hash_init(unsigned char vrf, int id) { struct fib_table *tb; @@ -906,6 +903,7 @@ return NULL; tb->tb_id = id; + tb->tb_vrf = vrf; tb->tb_lookup = fn_hash_lookup; tb->tb_insert = fn_hash_insert; tb->tb_delete = fn_hash_delete; diff -uNr linux-kernel/net/ipv4/fib_rules.c vrf-kernel/net/ipv4/fib_rules.c --- linux-kernel/net/ipv4/fib_rules.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/fib_rules.c Sun Sep 15 19:52:50 2002 @@ -74,32 +74,11 @@ #endif char r_ifname[IFNAMSIZ]; int r_dead; + unsigned char r_vrf; }; -static struct fib_rule default_rule = { - r_clntref: ATOMIC_INIT(2), - r_preference: 0x7FFF, - r_table: RT_TABLE_DEFAULT, - r_action: RTN_UNICAST, -}; - -static struct fib_rule main_rule = { - r_next: &default_rule, - r_clntref: ATOMIC_INIT(2), - r_preference: 0x7FFE, - r_table: RT_TABLE_MAIN, - r_action: RTN_UNICAST, -}; - -static struct fib_rule local_rule = { - r_next: &main_rule, - r_clntref: ATOMIC_INIT(2), - r_table: RT_TABLE_LOCAL, - r_action: RTN_UNICAST, -}; - -static struct fib_rule *fib_rules = &local_rule; -static rwlock_t fib_rules_lock = RW_LOCK_UNLOCKED; +static struct fib_rule *fib_rules[VRF_MAX]; +static rwlock_t fib_rules_lock[VRF_MAX]; int inet_rtm_delrule(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg) { @@ -107,8 +86,11 @@ struct rtmsg *rtm = NLMSG_DATA(nlh); struct fib_rule *r, **rp; int err = -ESRCH; + unsigned char vrf; - for (rp=&fib_rules; (r=*rp) != NULL; rp=&r->r_next) { + vrf = rtm->rtm_vrf; + + for (rp=&fib_rules[vrf]; (r=*rp) != NULL; rp=&r->r_next) { if ((!rta[RTA_SRC-1] || memcmp(RTA_DATA(rta[RTA_SRC-1]), &r->r_src, 4) == 0) && rtm->rtm_src_len == r->r_src_len && rtm->rtm_dst_len == r->r_dst_len && @@ -122,13 +104,13 @@ (!rta[RTA_IIF-1] || strcmp(RTA_DATA(rta[RTA_IIF-1]), r->r_ifname) == 0) && (!rtm->rtm_table || (r && rtm->rtm_table == r->r_table))) { err = -EPERM; - if (r == &local_rule) + if (r == fib_rules[0]) break; - write_lock_bh(&fib_rules_lock); + write_lock_bh(&fib_rules_lock[vrf]); *rp = r->r_next; r->r_dead = 1; - write_unlock_bh(&fib_rules_lock); + write_unlock_bh(&fib_rules_lock[vrf]); fib_rule_put(r); err = 0; break; @@ -139,13 +121,13 @@ /* Allocate new unique table id */ -static struct fib_table *fib_empty_table(void) +static struct fib_table *fib_empty_table(unsigned char vrf) { int id; for (id = 1; id <= RT_TABLE_MAX; id++) - if (fib_tables[id] == NULL) - return __fib_new_table(id); + if (fib_tables[vrf][id] == NULL) + return __fib_new_table(vrf,id); return NULL; } @@ -165,6 +147,7 @@ struct rtmsg *rtm = NLMSG_DATA(nlh); struct fib_rule *r, *new_r, **rp; unsigned char table_id; + unsigned char vrf; if (rtm->rtm_src_len > 32 || rtm->rtm_dst_len > 32 || (rtm->rtm_tos & ~IPTOS_TOS_MASK)) @@ -173,11 +156,12 @@ if (rta[RTA_IIF-1] && RTA_PAYLOAD(rta[RTA_IIF-1]) > IFNAMSIZ) return -EINVAL; + vrf = rtm->rtm_vrf; table_id = rtm->rtm_table; if (table_id == RT_TABLE_UNSPEC) { struct fib_table *table; if (rtm->rtm_type == RTN_UNICAST || rtm->rtm_type == RTN_NAT) { - if ((table = fib_empty_table()) == NULL) + if ((table = fib_empty_table(vrf)) == NULL) return -ENOBUFS; table_id = table->tb_id; } @@ -198,6 +182,7 @@ new_r->r_srcmask = inet_make_mask(rtm->rtm_src_len); new_r->r_dstmask = inet_make_mask(rtm->rtm_dst_len); new_r->r_tos = rtm->rtm_tos; + new_r->r_vrf = vrf; #ifdef CONFIG_IP_ROUTE_FWMARK if (rta[RTA_PROTOINFO-1]) memcpy(&new_r->r_fwmark, RTA_DATA(rta[RTA_PROTOINFO-1]), 4); @@ -221,11 +206,11 @@ memcpy(&new_r->r_tclassid, RTA_DATA(rta[RTA_FLOW-1]), 4); #endif - rp = &fib_rules; + rp = &fib_rules[vrf]; if (!new_r->r_preference) { - r = fib_rules; + r = fib_rules[vrf]; if (r && (r = r->r_next) != NULL) { - rp = &fib_rules->r_next; + rp = &fib_rules[vrf]->r_next; if (r->r_preference) new_r->r_preference = r->r_preference - 1; } @@ -239,9 +224,9 @@ new_r->r_next = r; atomic_inc(&new_r->r_clntref); - write_lock_bh(&fib_rules_lock); + write_lock_bh(&fib_rules_lock[vrf]); *rp = new_r; - write_unlock_bh(&fib_rules_lock); + write_unlock_bh(&fib_rules_lock[vrf]); return 0; } @@ -256,7 +241,7 @@ struct fib_rule *r = res->r; if (r->r_action == RTN_NAT) { - int addrtype = inet_addr_type(r->r_srcmap); + int addrtype = inet_addr_type(r->r_vrf, r->r_srcmap); if (addrtype == RTN_NAT) { /* Packet is from translated source; remember it */ @@ -285,11 +270,11 @@ { struct fib_rule *r; - for (r=fib_rules; r; r=r->r_next) { + for (r=fib_rules[dev->vrf]; r; r=r->r_next) { if (r->r_ifindex == dev->ifindex) { - write_lock_bh(&fib_rules_lock); + write_lock_bh(&fib_rules_lock[dev->vrf]); r->r_ifindex = -1; - write_unlock_bh(&fib_rules_lock); + write_unlock_bh(&fib_rules_lock[dev->vrf]); } } } @@ -298,11 +283,11 @@ { struct fib_rule *r; - for (r=fib_rules; r; r=r->r_next) { + for (r=fib_rules[dev->vrf]; r; r=r->r_next) { if (r->r_ifindex == -1 && strcmp(dev->name, r->r_ifname) == 0) { - write_lock_bh(&fib_rules_lock); + write_lock_bh(&fib_rules_lock[dev->vrf]); r->r_ifindex = dev->ifindex; - write_unlock_bh(&fib_rules_lock); + write_unlock_bh(&fib_rules_lock[dev->vrf]); } } } @@ -315,11 +300,12 @@ u32 daddr = key->dst; u32 saddr = key->src; + unsigned char vrf = key->vrf; FRprintk("Lookup: %u.%u.%u.%u <- %u.%u.%u.%u ", NIPQUAD(key->dst), NIPQUAD(key->src)); - read_lock(&fib_rules_lock); - for (r = fib_rules; r; r=r->r_next) { + read_lock(&fib_rules_lock[vrf]); + for (r = fib_rules[vrf]; r; r=r->r_next) { if (((saddr^r->r_src) & r->r_srcmask) || ((daddr^r->r_dst) & r->r_dstmask) || #ifdef CONFIG_IP_ROUTE_TOS @@ -328,6 +314,7 @@ #ifdef CONFIG_IP_ROUTE_FWMARK (r->r_fwmark && r->r_fwmark != key->fwmark) || #endif + (r->r_vrf != vrf) || (r->r_ifindex && r->r_ifindex != key->iif)) continue; @@ -338,34 +325,34 @@ policy = r; break; case RTN_UNREACHABLE: - read_unlock(&fib_rules_lock); + read_unlock(&fib_rules_lock[vrf]); return -ENETUNREACH; default: case RTN_BLACKHOLE: - read_unlock(&fib_rules_lock); + read_unlock(&fib_rules_lock[vrf]); return -EINVAL; case RTN_PROHIBIT: - read_unlock(&fib_rules_lock); + read_unlock(&fib_rules_lock[vrf]); return -EACCES; } - if ((tb = fib_get_table(r->r_table)) == NULL) + if ((tb = fib_get_table(vrf, r->r_table)) == NULL) continue; err = tb->tb_lookup(tb, key, res); if (err == 0) { res->r = policy; if (policy) atomic_inc(&policy->r_clntref); - read_unlock(&fib_rules_lock); + read_unlock(&fib_rules_lock[vrf]); return 0; } if (err < 0 && err != -EAGAIN) { - read_unlock(&fib_rules_lock); + read_unlock(&fib_rules_lock[vrf]); return err; } } FRprintk("FAILURE\n"); - read_unlock(&fib_rules_lock); + read_unlock(&fib_rules_lock[vrf]); return -ENETUNREACH; } @@ -374,7 +361,7 @@ if (res->r && res->r->r_action == RTN_UNICAST && FIB_RES_GW(*res) && FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK) { struct fib_table *tb; - if ((tb = fib_get_table(res->r->r_table)) != NULL) + if ((tb = fib_get_table(key->vrf, res->r->r_table)) != NULL) tb->tb_select_default(tb, key, res); } } @@ -414,6 +401,7 @@ RTA_PUT(skb, RTA_PROTOINFO, 4, &r->r_fwmark); #endif rtm->rtm_table = r->r_table; + rtm->rtm_vrf = r->r_vrf; rtm->rtm_protocol = 0; rtm->rtm_scope = 0; rtm->rtm_type = r->r_action; @@ -433,6 +421,7 @@ if (r->r_tclassid) RTA_PUT(skb, RTA_FLOW, 4, &r->r_tclassid); #endif + nlh->nlmsg_len = skb->tail - b; return skb->len; @@ -444,24 +433,108 @@ int inet_dump_rules(struct sk_buff *skb, struct netlink_callback *cb) { - int idx; + int idx = 0; + int vrf; int s_idx = cb->args[0]; struct fib_rule *r; - read_lock(&fib_rules_lock); - for (r=fib_rules, idx=0; r; r = r->r_next, idx++) { - if (idx < s_idx) - continue; - if (inet_fill_rule(skb, r, cb) < 0) - break; + for (vrf = 0;vrf < VRF_MAX;vrf++) { + read_lock(&fib_rules_lock[vrf]); + for (r=fib_rules[vrf]; r; r = r->r_next, idx++) { + if (idx < s_idx) + continue; + if (inet_fill_rule(skb, r, cb) < 0) { + vrf = VRF_MAX; + break; + } + } + read_unlock(&fib_rules_lock[vrf]); } - read_unlock(&fib_rules_lock); cb->args[0] = idx; return skb->len; } +void do_fib_del_vrf(struct fib_rule *rule) { + if (rule->r_next) { + do_fib_del_vrf(rule->r_next); + rule->r_next = NULL; + } + rule->r_dead = 1; + fib_rule_put(rule); +} + +int fib_del_vrf(unsigned char vrf) { + + if (!vrf) { + return 0; + } + write_lock_bh(&fib_rules_lock[vrf]); + + do_fib_del_vrf(fib_rules[vrf]); + fib_rules[vrf] = NULL; + + write_unlock_bh(&fib_rules_lock[vrf]); + + return 0; +} + +int fib_add_vrf(unsigned char vrf) { + struct fib_rule *df_rule; + struct fib_rule *main_rule; + struct fib_rule *loc_rule; + + if (fib_rules[vrf]) return -EEXIST; + if (vrf) write_lock_bh(&fib_rules_lock[vrf]); + + df_rule = kmalloc(sizeof(struct fib_rule),GFP_KERNEL); + main_rule = kmalloc(sizeof(struct fib_rule),GFP_KERNEL); + loc_rule = kmalloc(sizeof(struct fib_rule),GFP_KERNEL); + + memset(df_rule,0,sizeof(*df_rule)); + memset(main_rule,0,sizeof(*main_rule)); + memset(loc_rule,0,sizeof(*loc_rule)); + + df_rule->r_preference = 0x7FFF; + df_rule->r_table = RT_TABLE_DEFAULT; + df_rule->r_action = RTN_UNICAST; + df_rule->r_vrf = vrf; + + main_rule->r_next = df_rule; + main_rule->r_preference = 0x7FFE; + main_rule->r_table = RT_TABLE_MAIN; + main_rule->r_action = RTN_UNICAST; + main_rule->r_vrf = vrf; + + loc_rule->r_next = main_rule; + loc_rule->r_table = RT_TABLE_LOCAL; + loc_rule->r_action = RTN_UNICAST; + loc_rule->r_vrf = vrf; + + atomic_inc(&df_rule->r_clntref); + atomic_inc(&loc_rule->r_clntref); + atomic_inc(&main_rule->r_clntref); + + __fib_new_table(vrf,RT_TABLE_LOCAL); + __fib_new_table(vrf,RT_TABLE_MAIN); + __fib_new_table(vrf,RT_TABLE_DEFAULT); + + fib_rules[vrf] = loc_rule; + + if (vrf) write_unlock_bh(&fib_rules_lock[vrf]); + + return 0; +} + void __init fib_rules_init(void) { + int i; + for (i = 0;i < VRF_MAX;i++) { + fib_rules_lock[i] = RW_LOCK_UNLOCKED; + fib_rules[i] = NULL; + } + + fib_add_vrf(0); + register_netdevice_notifier(&fib_rules_notifier); } diff -uNr linux-kernel/net/ipv4/fib_semantics.c vrf-kernel/net/ipv4/fib_semantics.c --- linux-kernel/net/ipv4/fib_semantics.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/fib_semantics.c Sun Sep 15 14:38:22 2002 @@ -344,7 +344,7 @@ |-> {local prefix} (terminal node) */ -static int fib_check_nh(const struct rtmsg *r, struct fib_info *fi, struct fib_nh *nh) +static int fib_check_nh(const struct rtmsg *r, struct fib_info *fi, struct fib_nh *nh,unsigned char vrf) { int err; @@ -361,7 +361,7 @@ if (r->rtm_scope >= RT_SCOPE_LINK) return -EINVAL; - if (inet_addr_type(nh->nh_gw) != RTN_UNICAST) + if (inet_addr_type(r->rtm_vrf, nh->nh_gw) != RTN_UNICAST) return -EINVAL; if ((dev = __dev_get_by_index(nh->nh_oif)) == NULL) return -ENODEV; @@ -375,6 +375,7 @@ memset(&key, 0, sizeof(key)); key.dst = nh->nh_gw; key.oif = nh->nh_oif; + key.vrf = vrf; key.scope = r->rtm_scope + 1; /* It is not necessary, but requires a bit of thinking */ @@ -420,7 +421,7 @@ struct fib_info * fib_create_info(const struct rtmsg *r, struct kern_rta *rta, - const struct nlmsghdr *nlh, int *errp) + const struct nlmsghdr *nlh, unsigned char vrf, int *errp) { int err; struct fib_info *fi = NULL; @@ -534,7 +535,7 @@ goto failure; } else { change_nexthops(fi) { - if ((err = fib_check_nh(r, fi, nh)) != 0) + if ((err = fib_check_nh(r, fi, nh, vrf)) != 0) goto failure; } endfor_nexthops(fi) } @@ -542,7 +543,7 @@ if (fi->fib_prefsrc) { if (r->rtm_type != RTN_LOCAL || rta->rta_dst == NULL || memcmp(&fi->fib_prefsrc, rta->rta_dst, 4)) - if (inet_addr_type(fi->fib_prefsrc) != RTN_LOCAL) + if (inet_addr_type(r->rtm_vrf, fi->fib_prefsrc) != RTN_LOCAL) goto err_inval; } @@ -640,7 +641,7 @@ int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event, u8 tb_id, u8 type, u8 scope, void *dst, int dst_len, u8 tos, - struct fib_info *fi) + struct fib_info *fi, unsigned char vrf) { struct rtmsg *rtm; struct nlmsghdr *nlh; @@ -653,6 +654,7 @@ rtm->rtm_src_len = 0; rtm->rtm_tos = tos; rtm->rtm_table = tb_id; + rtm->rtm_vrf = vrf; rtm->rtm_type = type; rtm->rtm_flags = fi->fib_flags; rtm->rtm_scope = scope; @@ -803,7 +805,7 @@ ptr = &((struct sockaddr_in*)&r->rt_gateway)->sin_addr.s_addr; if (r->rt_gateway.sa_family == AF_INET && *ptr) { rta->rta_gw = ptr; - if (r->rt_flags&RTF_GATEWAY && inet_addr_type(*ptr) == RTN_UNICAST) + if (r->rt_flags&RTF_GATEWAY && inet_addr_type(0, *ptr) == RTN_UNICAST) rtm->rtm_scope = RT_SCOPE_UNIVERSE; } diff -uNr linux-kernel/net/ipv4/icmp.c vrf-kernel/net/ipv4/icmp.c --- linux-kernel/net/ipv4/icmp.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/icmp.c Sat Aug 24 00:14:28 2002 @@ -341,6 +341,7 @@ static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb) { struct sock *sk=icmp_socket->sk; + struct rt_key key; struct ipcm_cookie ipc; struct rtable *rt = (struct rtable*)skb->dst; u32 daddr; @@ -364,8 +365,15 @@ if (ipc.opt->srr) daddr = icmp_param->replyopts.faddr; } - if (ip_route_output(&rt, daddr, rt->rt_spec_dst, RT_TOS(skb->nh.iph->tos), 0)) + memset(&key,0,sizeof(key)); + key.dst = daddr; + key.src = rt->rt_spec_dst; + key.tos = RT_TOS(skb->nh.iph->tos); + key.oif = 0; + key.vrf = skb->vrf; + if (ip_route_output_key(&rt, &key)) goto out; + if (icmpv4_xrlim_allow(rt, icmp_param->data.icmph.type, icmp_param->data.icmph.code)) { ip_build_xmit(sk, icmp_glue_bits, icmp_param, @@ -391,6 +399,7 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, u32 info) { struct iphdr *iph; + struct rt_key key; int room; struct icmp_bxm icmp_param; struct rtable *rt = (struct rtable*)skb_in->dst; @@ -481,7 +490,13 @@ ((iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL) : iph->tos; - if (ip_route_output(&rt, iph->saddr, saddr, RT_TOS(tos), 0)) + memset(&key,0,sizeof(key)); + key.dst = iph->saddr; + key.src = saddr; + key.tos = RT_TOS(tos); + key.oif = 0; + key.vrf = skb_in->vrf; + if (ip_route_output_key(&rt, &key)) goto out; if (ip_options_echo(&icmp_param.replyopts, skb_in)) @@ -506,7 +521,13 @@ ipc.opt = &icmp_param.replyopts; if (icmp_param.replyopts.srr) { ip_rt_put(rt); - if (ip_route_output(&rt, icmp_param.replyopts.faddr, saddr, RT_TOS(tos), 0)) + memset(&key,0,sizeof(key)); + key.dst = icmp_param.replyopts.faddr; + key.src = saddr; + key.tos = RT_TOS(tos); + key.oif = 0; + key.vrf = skb_in->vrf; + if (ip_route_output_key(&rt, &key)) goto out; } @@ -586,7 +607,7 @@ printk(KERN_INFO "ICMP: %u.%u.%u.%u: fragmentation needed and DF set.\n", NIPQUAD(iph->daddr)); } else { - info = ip_rt_frag_needed(iph, ntohs(icmph->un.frag.mtu)); + info = ip_rt_frag_needed(iph, ntohs(icmph->un.frag.mtu), skb->vrf); if (!info) goto out; } @@ -622,7 +643,7 @@ if (!sysctl_icmp_ignore_bogus_error_responses) { - if (inet_addr_type(iph->daddr) == RTN_BROADCAST) + if (inet_addr_type(skb->vrf, iph->daddr) == RTN_BROADCAST) { if (net_ratelimit()) printk(KERN_WARNING "%u.%u.%u.%u sent an invalid ICMP error to a broadcast.\n", @@ -650,7 +671,8 @@ if ((raw_sk = raw_v4_htable[hash]) != NULL) { while ((raw_sk = __raw_v4_lookup(raw_sk, protocol, iph->daddr, - iph->saddr, skb->dev->ifindex)) != NULL) { + iph->saddr, skb->dev->ifindex, + skb->vrf)) != NULL) { raw_err(raw_sk, skb, info); raw_sk = raw_sk->next; iph = (struct iphdr *)skb->data; @@ -737,6 +759,7 @@ static void icmp_echo(struct sk_buff *skb) { + if (!sysctl_icmp_echo_ignore_all) { struct icmp_bxm icmp_param; diff -uNr linux-kernel/net/ipv4/igmp.c vrf-kernel/net/ipv4/igmp.c --- linux-kernel/net/ipv4/igmp.c Sat Aug 24 00:22:27 2002 +++ vrf-kernel/net/ipv4/igmp.c Sat Aug 24 00:14:28 2002 @@ -198,6 +198,7 @@ struct iphdr *iph; struct igmphdr *ih; struct rtable *rt; + struct rt_key key; u32 dst; /* According to IGMPv2 specs, LEAVE messages are @@ -207,7 +208,13 @@ if (type == IGMP_HOST_LEAVE_MESSAGE) dst = IGMP_ALL_ROUTER; - if (ip_route_output(&rt, dst, 0, 0, dev->ifindex)) + memset(&key,0,sizeof(key)); + key.dst = dst; + key.src = 0; + key.tos = 0; + key.oif = dev->ifindex; + key.vrf = dev->vrf; + if (ip_route_output_key(&rt, &key)) return -1; if (rt->rt_src == 0) { ip_rt_put(rt); @@ -609,20 +616,27 @@ write_unlock_bh(&in_dev->lock); } -static struct in_device * ip_mc_find_dev(struct ip_mreqn *imr) +static struct in_device * ip_mc_find_dev(unsigned char vrf, struct ip_mreqn *imr) { struct rtable *rt; + struct rt_key key; struct net_device *dev = NULL; struct in_device *idev = NULL; if (imr->imr_address.s_addr) { - dev = ip_dev_find(imr->imr_address.s_addr); + dev = ip_dev_find(vrf, imr->imr_address.s_addr); if (!dev) return NULL; __dev_put(dev); } - if (!dev && !ip_route_output(&rt, imr->imr_multiaddr.s_addr, 0, 0, 0)) { + memset(&key,0,sizeof(key)); + key.dst = imr->imr_multiaddr.s_addr; + key.src = 0; + key.tos = 0; + key.oif = 0; + key.vrf = vrf; + if (!dev && !ip_route_output_key(&rt, &key)) { dev = rt->u.dst.dev; ip_rt_put(rt); } @@ -652,7 +666,7 @@ rtnl_shlock(); if (!imr->imr_ifindex) - in_dev = ip_mc_find_dev(imr); + in_dev = ip_mc_find_dev(sk->vrf,imr); else { in_dev = inetdev_by_index(imr->imr_ifindex); if (in_dev) diff -uNr linux-kernel/net/ipv4/ip_gre.c vrf-kernel/net/ipv4/ip_gre.c --- linux-kernel/net/ipv4/ip_gre.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ip_gre.c Sat Aug 24 00:14:29 2002 @@ -411,6 +411,7 @@ int grehlen = (iph->ihl<<2) + 4; struct sk_buff *skb2; struct rtable *rt; + struct rt_key key; if (p[1] != __constant_htons(ETH_P_IP)) return; @@ -485,8 +486,14 @@ skb_pull(skb2, skb->data - (u8*)eiph); skb2->nh.raw = skb2->data; + memset(&key,0,sizeof(key)); + key.dst = eiph->saddr; + key.src = 0; + key.tos = RT_TOS(eiph->tos); + key.oif = 0; + key.vrf = skb->vrf /* Try to guess incoming interface */ - if (ip_route_output(&rt, eiph->saddr, 0, RT_TOS(eiph->tos), 0)) { + if (ip_route_output_key(&rt, &key)) { kfree_skb(skb2); return; } @@ -496,8 +503,12 @@ if (rt->rt_flags&RTCF_LOCAL) { ip_rt_put(rt); rt = NULL; - if (ip_route_output(&rt, eiph->daddr, eiph->saddr, eiph->tos, 0) || - rt->u.dst.dev->type != ARPHRD_IPGRE) { + key.dst = eiph->daddr; + key.src = eiph->saddr; + key.tos = eiph->tos; + key.oif = 0; + key.vrf = skb2->vrf; + if (ip_route_output_key(&rt, &key) || rt->u.dst.dev->type != ARPHRD_IPGRE) { ip_rt_put(rt); kfree_skb(skb2); return; @@ -677,6 +688,7 @@ struct net_device_stats *stats = &tunnel->stat; struct iphdr *old_iph = skb->nh.iph; struct iphdr *tiph; + struct rt_key key; u8 tos; u16 df; struct rtable *rt; /* Route to the other host */ @@ -747,7 +759,13 @@ tos &= ~1; } - if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) { + memset(&key,0,sizeof(key)); + key.dst = dst; + key.src = tiph->saddr; + key.tos = RT_TOS(tos); + key.oif = tunnel->parms.link; + key.vrf = skb->vrf; + if (ip_route_output_key(&rt, &key)) { tunnel->stat.tx_carrier_errors++; goto tx_error; } @@ -1102,10 +1120,16 @@ MOD_INC_USE_COUNT; if (MULTICAST(t->parms.iph.daddr)) { + struct rt_key key; struct rtable *rt; - if (ip_route_output(&rt, t->parms.iph.daddr, - t->parms.iph.saddr, RT_TOS(t->parms.iph.tos), - t->parms.link)) { + + memset(&key,0,sizeof(key)); + key.dst = t->parms.iph.daddr; + key.src = t->parms.iph.saddr; + key.tos = RT_TOS(t->parms.iph.tos); + key.oif = t->parms.link; + key.vrf = dev->vrf; + if (ip_route_output_key(&rt, &key)) { MOD_DEC_USE_COUNT; return -EADDRNOTAVAIL; } @@ -1176,7 +1200,15 @@ if (iph->daddr) { struct rtable *rt; - if (!ip_route_output(&rt, iph->daddr, iph->saddr, RT_TOS(iph->tos), tunnel->parms.link)) { + struct rt_key key; + + memset(&key,0,sizeof(key)); + key.dst = iph->daddr; + key.src = iph->saddr; + key.tos = RT_TOS(iph->tos); + key.oif = tunnel->parms.link; + key.vrf = dev->vrf; + if (!ip_route_output_key(&rt, &key)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -uNr linux-kernel/net/ipv4/ip_input.c vrf-kernel/net/ipv4/ip_input.c --- linux-kernel/net/ipv4/ip_input.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ip_input.c Sat Aug 24 00:14:29 2002 @@ -276,7 +276,7 @@ raw_rcv(raw_sk, skb); sock_put(raw_sk); } else if (!flag) { /* Free and report errors */ - icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); kfree_skb(skb); } } @@ -433,6 +433,7 @@ skb->ip_summed = CHECKSUM_NONE; } } + skb->vrf = dev->vrf; return NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL, ip_rcv_finish); diff -uNr linux-kernel/net/ipv4/ip_options.c vrf-kernel/net/ipv4/ip_options.c --- linux-kernel/net/ipv4/ip_options.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ip_options.c Sat Aug 24 00:14:29 2002 @@ -147,7 +147,7 @@ __u32 addr; memcpy(&addr, sptr+soffset-1, 4); - if (inet_addr_type(addr) != RTN_LOCAL) { + if (inet_addr_type(skb->vrf, addr) != RTN_LOCAL) { dopt->ts_needtime = 1; soffset += 8; } @@ -388,7 +388,7 @@ { u32 addr; memcpy(&addr, &optptr[optptr[2]-1], 4); - if (inet_addr_type(addr) == RTN_UNICAST) + if (inet_addr_type(skb->vrf, addr) == RTN_UNICAST) break; if (skb) timeptr = (__u32*)&optptr[optptr[2]+3]; diff -uNr linux-kernel/net/ipv4/ip_output.c vrf-kernel/net/ipv4/ip_output.c --- linux-kernel/net/ipv4/ip_output.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ip_output.c Sat Aug 24 00:14:29 2002 @@ -353,6 +353,7 @@ /* Make sure we can route this packet. */ rt = (struct rtable *)__sk_dst_check(sk, 0); if (rt == NULL) { + struct rt_key key; u32 daddr; /* Use correct destination address if we have options. */ @@ -364,9 +365,13 @@ * keep trying until route appears or the connection times itself * out. */ - if (ip_route_output(&rt, daddr, sk->saddr, - RT_CONN_FLAGS(sk), - sk->bound_dev_if)) + memset(&key,0,sizeof(key)); + key.dst = daddr; + key.src = sk->saddr; + key.tos = RT_CONN_FLAGS(sk); + key.oif = sk->bound_dev_if; + key.vrf = sk->vrf; + if (ip_route_output_key(&rt, &key)) goto no_route; __sk_dst_set(sk, &rt->u.dst); sk->route_caps = rt->u.dst.dev->features; @@ -532,6 +537,7 @@ skb->priority = sk->priority; skb->dst = dst_clone(&rt->u.dst); skb_reserve(skb, hh_len); + skb->vrf = sk->vrf; /* * Find where to start putting bytes. @@ -652,7 +658,7 @@ /* * Check for slow path. */ - if (length > rt->u.dst.pmtu || ipc->opt != NULL) + if (length > rt->u.dst.pmtu || ipc->opt != NULL) return ip_build_xmit_slow(sk,getfrag,frag,length,ipc,rt,flags); } else { if (length > rt->u.dst.dev->mtu) { @@ -683,6 +689,7 @@ skb_reserve(skb, hh_len); } + skb->vrf = rt->key.vrf; skb->priority = sk->priority; skb->dst = dst_clone(&rt->u.dst); @@ -948,6 +955,7 @@ struct ip_options opt; char data[40]; } replyopts; + struct rt_key key; struct ipcm_cookie ipc; u32 daddr; struct rtable *rt = (struct rtable*)skb->dst; @@ -965,7 +973,13 @@ daddr = replyopts.opt.faddr; } - if (ip_route_output(&rt, daddr, rt->rt_spec_dst, RT_TOS(skb->nh.iph->tos), 0)) + memset(&key,0,sizeof(key)); + key.dst = daddr; + key.src = rt->rt_spec_dst; + key.tos = RT_TOS(skb->nh.iph->tos); + key.oif = 0; + key.vrf = sk->vrf; + if (ip_route_output_key(&rt, &key)) return; /* And let IP do all the hard work. diff -uNr linux-kernel/net/ipv4/ip_sockglue.c vrf-kernel/net/ipv4/ip_sockglue.c --- linux-kernel/net/ipv4/ip_sockglue.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ip_sockglue.c Sat Aug 24 00:14:29 2002 @@ -560,7 +560,7 @@ err = 0; break; } - dev = ip_dev_find(mreq.imr_address.s_addr); + dev = ip_dev_find(sk->vrf, mreq.imr_address.s_addr); if (dev) { mreq.imr_ifindex = dev->ifindex; dev_put(dev); diff -uNr linux-kernel/net/ipv4/ipip.c vrf-kernel/net/ipv4/ipip.c --- linux-kernel/net/ipv4/ipip.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ipip.c Sat Aug 24 00:14:29 2002 @@ -356,6 +356,7 @@ int rel_info = 0; struct sk_buff *skb2; struct rtable *rt; + struct rt_key key; if (len < hlen + sizeof(struct iphdr)) return; @@ -416,8 +417,14 @@ skb_pull(skb2, skb->data - (u8*)eiph); skb2->nh.raw = skb2->data; + memset(&key,0,sizeof(key)); + key.dst = eiph->saddr; + key.src = 0; + key.tos = RT_TOS(eiph->tos); + key.oif = 0; + key.vrf = skb->vrf; /* Try to guess incoming interface */ - if (ip_route_output(&rt, eiph->saddr, 0, RT_TOS(eiph->tos), 0)) { + if (ip_route_output_key(&rt, &key)) { kfree_skb(skb2); return; } @@ -427,8 +434,12 @@ if (rt->rt_flags&RTCF_LOCAL) { ip_rt_put(rt); rt = NULL; - if (ip_route_output(&rt, eiph->daddr, eiph->saddr, eiph->tos, 0) || - rt->u.dst.dev->type != ARPHRD_IPGRE) { + key.dst = eiph->daddr; + key.src = eiph->saddr; + key.tos = eiph->tos; + key.oif = 0; + key.vrf = skb2->vrf; + if (ip_route_output_key(&rt, &key) || rt->u.dst.dev->type != ARPHRD_IPGRE) { ip_rt_put(rt); kfree_skb(skb2); return; @@ -531,6 +542,7 @@ struct iphdr *tiph = &tunnel->parms.iph; u8 tos = tunnel->parms.iph.tos; u16 df = tiph->frag_off; + struct rt_key key; struct rtable *rt; /* Route to the other host */ struct net_device *tdev; /* Device to other host */ struct iphdr *old_iph = skb->nh.iph; @@ -560,7 +572,13 @@ goto tx_error_icmp; } - if (ip_route_output(&rt, dst, tiph->saddr, RT_TOS(tos), tunnel->parms.link)) { + memset(&key,0,sizeof(key)); + key.dst = dst; + key.src = tiph->saddr; + key.tos = RT_TOS(tos); + key.oif = tunnel->parms.link; + key.vrf = skb->vrf; + if (ip_route_output_key(&rt, &key)) { tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; } @@ -822,8 +840,16 @@ ipip_tunnel_init_gen(dev); if (iph->daddr) { + struct rt_key key; struct rtable *rt; - if (!ip_route_output(&rt, iph->daddr, iph->saddr, RT_TOS(iph->tos), tunnel->parms.link)) { + + memset(&key,0,sizeof(key)); + key.dst = iph->daddr; + key.src = iph->saddr; + key.tos = RT_TOS(iph->tos); + key.oif = tunnel->parms.link; + key.vrf = dev->vrf; + if (!ip_route_output_key(&rt, &key)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -uNr linux-kernel/net/ipv4/ipmr.c vrf-kernel/net/ipv4/ipmr.c --- linux-kernel/net/ipv4/ipmr.c Sat Aug 24 00:22:28 2002 +++ vrf-kernel/net/ipv4/ipmr.c Sat Aug 24 00:14:29 2002 @@ -372,7 +372,7 @@ } } -static int vif_add(struct vifctl *vifc, int mrtsock) +static int vif_add(unsigned char vrf, struct vifctl *vifc, int mrtsock) { int vifi = vifc->vifc_vifi; struct vif_device *v = &vif_table[vifi]; @@ -403,7 +403,7 @@ return -ENOBUFS; break; case 0: - dev=ip_dev_find(vifc->vifc_lcl_addr.s_addr); + dev=ip_dev_find(vrf, vifc->vifc_lcl_addr.s_addr); if (!dev) return -EADDRNOTAVAIL; __dev_put(dev); @@ -890,7 +890,7 @@ return -ENFILE; rtnl_lock(); if (optname==MRT_ADD_VIF) { - ret = vif_add(&vif, sk==mroute_socket); + ret = vif_add(sk->vrf, &vif, sk==mroute_socket); } else { ret = vif_delete(vif.vifc_vifi); } @@ -1125,6 +1125,7 @@ struct rtable *rt; int encap = 0; struct sk_buff *skb2; + struct rt_key key; if (vif->dev == NULL) return; @@ -1141,11 +1142,23 @@ #endif if (vif->flags&VIFF_TUNNEL) { - if (ip_route_output(&rt, vif->remote, vif->local, RT_TOS(iph->tos), vif->link)) + memset(&key,0,sizeof(key)); + key.dst = vif->remote; + key.src = vif->local; + key.tos = RT_TOS(iph->tos); + key.oif = vif->link; + key.vrf = skb->vrf; + if (ip_route_output_key(&rt, &key)) return; encap = sizeof(struct iphdr); } else { - if (ip_route_output(&rt, iph->daddr, 0, RT_TOS(iph->tos), vif->link)) + memset(&key,0,sizeof(key)); + key.dst = iph->daddr; + key.src = 0; + key.tos = RT_TOS(iph->tos); + key.oif = vif->link; + key.vrf = skb->vrf; + if (ip_route_output_key(&rt, &key)) return; } diff -uNr linux-kernel/net/ipv4/raw.c vrf-kernel/net/ipv4/raw.c --- linux-kernel/net/ipv4/raw.c Sat Aug 24 00:22:31 2002 +++ vrf-kernel/net/ipv4/raw.c Sat Aug 24 00:14:30 2002 @@ -98,12 +98,13 @@ struct sock *__raw_v4_lookup(struct sock *sk, unsigned short num, unsigned long raddr, unsigned long laddr, - int dif) + int dif,unsigned char vrf) { struct sock *s = sk; for (s = sk; s; s = s->next) { if (s->num == num && + s->vrf == vrf && !(s->daddr && s->daddr != raddr) && !(s->rcv_saddr && s->rcv_saddr != laddr) && !(s->bound_dev_if && s->bound_dev_if != dif)) @@ -147,12 +148,13 @@ goto out; sk = __raw_v4_lookup(sk, iph->protocol, iph->saddr, iph->daddr, - skb->dev->ifindex); + skb->dev->ifindex, skb->vrf); while (sk) { struct sock *sknext = __raw_v4_lookup(sk->next, iph->protocol, iph->saddr, iph->daddr, - skb->dev->ifindex); + skb->dev->ifindex, + skb->vrf); if (iph->protocol != IPPROTO_ICMP || !icmp_filter(sk, skb)) { struct sk_buff *clone; @@ -307,6 +309,7 @@ struct ipcm_cookie ipc; struct rawfakehdr rfh; struct rtable *rt = NULL; + struct rt_key key; int free = 0; u32 daddr; u8 tos; @@ -408,7 +411,13 @@ rfh.saddr = sk->protinfo.af_inet.mc_addr; } - err = ip_route_output(&rt, daddr, rfh.saddr, tos, ipc.oif); + memset(&key,0,sizeof(key)); + key.dst = daddr; + key.src = rfh.saddr; + key.tos = tos; + key.oif = ipc.oif; + key.vrf = sk->vrf; + err = ip_route_output_key(&rt, &key); if (err) goto done; @@ -463,7 +472,7 @@ if (sk->state != TCP_CLOSE || addr_len < sizeof(struct sockaddr_in)) goto out; - chk_addr_ret = inet_addr_type(addr->sin_addr.s_addr); + chk_addr_ret = inet_addr_type(sk->vrf, addr->sin_addr.s_addr); ret = -EADDRNOTAVAIL; if (addr->sin_addr.s_addr && chk_addr_ret != RTN_LOCAL && chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST) diff -uNr linux-kernel/net/ipv4/route.c vrf-kernel/net/ipv4/route.c --- linux-kernel/net/ipv4/route.c Sat Aug 24 00:22:32 2002 +++ vrf-kernel/net/ipv4/route.c Sun Sep 15 16:21:47 2002 @@ -792,7 +792,7 @@ if (IN_DEV_SEC_REDIRECTS(in_dev) && ip_fib_check_default(new_gw, dev)) goto reject_redirect; } else { - if (inet_addr_type(new_gw) != RTN_UNICAST) + if (inet_addr_type(dev->vrf, new_gw) != RTN_UNICAST) goto reject_redirect; } @@ -811,6 +811,7 @@ if (rth->key.dst != daddr || rth->key.src != skeys[i] || rth->key.tos != tos || + rth->key.vrf != dev->vrf || rth->key.oif != ikeys[k] || rth->key.iif != 0) { rthp = &rth->u.rt_next; @@ -1015,7 +1016,7 @@ out: kfree_skb(skb); return 0; -} +} /* * The last two values are not from the RFC but @@ -1035,7 +1036,7 @@ return 68; } -unsigned short ip_rt_frag_needed(struct iphdr *iph, unsigned short new_mtu) +unsigned short ip_rt_frag_needed(struct iphdr *iph, unsigned short new_mtu, unsigned char vrf) { int i; unsigned short old_mtu = ntohs(iph->tot_len); @@ -1058,6 +1059,7 @@ rth->key.src == skeys[i] && rth->rt_dst == daddr && rth->rt_src == iph->saddr && + rth->key.vrf == vrf && rth->key.tos == tos && rth->key.iif == 0 && !(rth->u.dst.mxlock & (1 << RTAX_MTU))) { @@ -1271,6 +1273,7 @@ #ifdef CONFIG_IP_ROUTE_FWMARK rth->key.fwmark = skb->nfmark; #endif + rth->key.vrf = dev->vrf; rth->key.src = saddr; rth->rt_src = saddr; #ifdef CONFIG_IP_ROUTE_NAT @@ -1350,6 +1353,7 @@ key.fwmark = skb->nfmark; #endif key.iif = dev->ifindex; + key.vrf = skb->vrf; key.oif = 0; key.scope = RT_SCOPE_UNIVERSE; @@ -1488,6 +1492,7 @@ #endif rth->rt_iif = rth->key.iif = dev->ifindex; + rth->key.vrf = skb->vrf; rth->u.dst.dev = out_dev->dev; dev_hold(rth->u.dst.dev); rth->key.oif = 0; @@ -1565,6 +1570,7 @@ #endif rth->rt_iif = rth->key.iif = dev->ifindex; + rth->key.vrf = dev->vrf; rth->u.dst.dev = &loopback_dev; dev_hold(rth->u.dst.dev); rth->key.oif = 0; @@ -1647,6 +1653,7 @@ for (rth = rt_hash_table[hash].chain; rth; rth = rth->u.rt_next) { if (rth->key.dst == daddr && rth->key.src == saddr && + rth->key.vrf == skb->vrf && rth->key.iif == iif && rth->key.oif == 0 && #ifdef CONFIG_IP_ROUTE_FWMARK @@ -1718,6 +1725,7 @@ key.src = oldkey->src; key.tos = tos & IPTOS_RT_MASK; key.iif = loopback_dev.ifindex; + key.vrf = oldkey->vrf; key.oif = oldkey->oif; #ifdef CONFIG_IP_ROUTE_FWMARK key.fwmark = oldkey->fwmark; @@ -1737,7 +1745,7 @@ goto out; /* It is equivalent to inet_addr_type(saddr) == RTN_LOCAL */ - dev_out = ip_dev_find(oldkey->src); + dev_out = ip_dev_find(oldkey->vrf, oldkey->src); if (dev_out == NULL) goto out; @@ -1929,6 +1937,7 @@ rth->key.tos = tos; rth->key.src = oldkey->src; rth->key.iif = 0; + rth->key.vrf = oldkey->vrf; rth->key.oif = oldkey->oif; #ifdef CONFIG_IP_ROUTE_FWMARK rth->key.fwmark = oldkey->fwmark; @@ -2008,6 +2017,7 @@ rth->key.src == key->src && rth->key.iif == 0 && rth->key.oif == key->oif && + rth->key.vrf == key->vrf && #ifdef CONFIG_IP_ROUTE_FWMARK rth->key.fwmark == key->fwmark && #endif @@ -2165,10 +2175,17 @@ if (!err && rt->u.dst.error) err = -rt->u.dst.error; } else { + struct rt_key key; int oif = 0; if (rta[RTA_OIF - 1]) memcpy(&oif, RTA_DATA(rta[RTA_OIF - 1]), sizeof(int)); - err = ip_route_output(&rt, dst, src, rtm->rtm_tos, oif); + memset(&key,0,sizeof(key)); + key.dst = dst; + key.src = src; + key.tos = rtm->rtm_tos; + key.oif = oif; + key.vrf = rtm->rtm_vrf; + err = ip_route_output_key(&rt, &key); } if (err) { kfree_skb(skb); diff -uNr linux-kernel/net/ipv4/syncookies.c vrf-kernel/net/ipv4/syncookies.c --- linux-kernel/net/ipv4/syncookies.c Sat Aug 24 00:22:32 2002 +++ vrf-kernel/net/ipv4/syncookies.c Sat Aug 24 00:14:30 2002 @@ -117,6 +117,7 @@ int mss; struct rtable *rt; __u8 rcv_wscale; + struct rt_key key; if (!sysctl_tcp_syncookies || !skb->h.th->ack) goto out; @@ -169,12 +170,13 @@ * hasn't changed since we received the original syn, but I see * no easy way to do this. */ - if (ip_route_output(&rt, - opt && - opt->srr ? opt->faddr : req->af.v4_req.rmt_addr, - req->af.v4_req.loc_addr, - RT_CONN_FLAGS(sk), - 0)) { + memset(&key,0,sizeof(key)); + key.dst = opt && opt->srr ? opt->faddr : req->af.v4_req.rmt_addr; + key.src = req->af.v4_req.loc_addr; + key.oif = 0; + key.tos = RT_CONN_FLAGS(sk); + key.vrf = sk->vrf; + if (ip_route_output_key(&rt, &key)) { tcp_openreq_free(req); goto out; } diff -uNr linux-kernel/net/ipv4/tcp_ipv4.c vrf-kernel/net/ipv4/tcp_ipv4.c --- linux-kernel/net/ipv4/tcp_ipv4.c Sat Aug 24 00:22:32 2002 +++ vrf-kernel/net/ipv4/tcp_ipv4.c Sat Sep 14 23:48:05 2002 @@ -124,13 +124,14 @@ * The bindhash mutex for snum's hash chain must be held here. */ struct tcp_bind_bucket *tcp_bucket_create(struct tcp_bind_hashbucket *head, - unsigned short snum) + unsigned short snum, unsigned char vrf) { struct tcp_bind_bucket *tb; tb = kmem_cache_alloc(tcp_bucket_cachep, SLAB_ATOMIC); if(tb != NULL) { tb->port = snum; + tb->vrf = vrf; tb->fastreuse = 0; tb->owners = NULL; if((tb->next = head->chain) != NULL) @@ -186,9 +187,10 @@ if (!sk_reuse || !sk2->reuse || sk2->state == TCP_LISTEN) { - if (!sk2->rcv_saddr || + if ((sk->vrf == sk2->vrf) && + (!sk2->rcv_saddr || !sk->rcv_saddr || - (sk2->rcv_saddr == sk->rcv_saddr)) + (sk2->rcv_saddr == sk->rcv_saddr))) break; } } @@ -243,7 +245,7 @@ head = &tcp_bhash[tcp_bhashfn(snum)]; spin_lock(&head->lock); for (tb = head->chain; tb != NULL; tb = tb->next) - if (tb->port == snum) + if (tb->port == snum && tb->vrf == sk->vrf) break; } if (tb != NULL && tb->owners != NULL) { @@ -259,7 +261,7 @@ } ret = 1; if (tb == NULL && - (tb = tcp_bucket_create(head, snum)) == NULL) + (tb = tcp_bucket_create(head, snum, sk->vrf)) == NULL) goto fail_unlock; if (tb->owners == NULL) { if (sk->reuse && sk->state != TCP_LISTEN) @@ -413,7 +415,7 @@ * connection. So always assume those are both wildcarded * during the search since they can never be otherwise. */ -static struct sock *__tcp_v4_lookup_listener(struct sock *sk, u32 daddr, unsigned short hnum, int dif) +static struct sock *__tcp_v4_lookup_listener(struct sock *sk, u32 daddr, unsigned short hnum, int dif, unsigned char vrf) { struct sock *result = NULL; int score, hiscore; @@ -434,7 +436,11 @@ continue; score++; } - if (score == 3) + + if (sk->vrf != vrf) + continue; + score++; + if (score == 4) return sk; if (score > hiscore) { hiscore = score; @@ -446,7 +452,7 @@ } /* Optimize the common listener case. */ -__inline__ struct sock *tcp_v4_lookup_listener(u32 daddr, unsigned short hnum, int dif) +__inline__ struct sock *tcp_v4_lookup_listener(u32 daddr, unsigned short hnum, int dif, unsigned char vrf) { struct sock *sk; @@ -458,7 +464,7 @@ (!sk->rcv_saddr || sk->rcv_saddr == daddr) && !sk->bound_dev_if) goto sherry_cache; - sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); + sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif, vrf); } if (sk) { sherry_cache: @@ -475,7 +481,7 @@ */ static inline struct sock *__tcp_v4_lookup_established(u32 saddr, u16 sport, - u32 daddr, u16 hnum, int dif) + u32 daddr, u16 hnum, int dif, unsigned char vrf) { struct tcp_ehash_bucket *head; TCP_V4_ADDR_COOKIE(acookie, saddr, daddr) @@ -490,13 +496,13 @@ head = &tcp_ehash[hash]; read_lock(&head->lock); for(sk = head->chain; sk; sk = sk->next) { - if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) + if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif, vrf)) goto hit; /* You sunk my battleship! */ } /* Must check for a TIME_WAIT'er before going to listener hash. */ for(sk = (head + tcp_ehash_size)->chain; sk; sk = sk->next) - if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) + if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif, vrf)) goto hit; read_unlock(&head->lock); @@ -508,25 +514,25 @@ return sk; } -static inline struct sock *__tcp_v4_lookup(u32 saddr, u16 sport, - u32 daddr, u16 hnum, int dif) +static inline struct sock *__tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, + u16 hnum, int dif, unsigned char vrf) { struct sock *sk; - sk = __tcp_v4_lookup_established(saddr, sport, daddr, hnum, dif); + sk = __tcp_v4_lookup_established(saddr, sport, daddr, hnum, dif, vrf); if (sk) return sk; - return tcp_v4_lookup_listener(daddr, hnum, dif); + return tcp_v4_lookup_listener(daddr, hnum, dif, vrf); } -__inline__ struct sock *tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif) +__inline__ struct sock *tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif, unsigned char vrf) { struct sock *sk; local_bh_disable(); - sk = __tcp_v4_lookup(saddr, sport, daddr, ntohs(dport), dif); + sk = __tcp_v4_lookup(saddr, sport, daddr, ntohs(dport), dif, vrf); local_bh_enable(); return sk; @@ -547,6 +553,7 @@ u32 daddr = sk->rcv_saddr; u32 saddr = sk->daddr; int dif = sk->bound_dev_if; + unsigned char vrf = sk->vrf; TCP_V4_ADDR_COOKIE(acookie, saddr, daddr) __u32 ports = TCP_COMBINED_PORTS(sk->dport, lport); int hash = tcp_hashfn(daddr, lport, saddr, sk->dport); @@ -561,7 +568,7 @@ skp = &sk2->next) { tw = (struct tcp_tw_bucket*)sk2; - if(TCP_IPV4_MATCH(sk2, acookie, saddr, daddr, ports, dif)) { + if(TCP_IPV4_MATCH(sk2, acookie, saddr, daddr, ports, dif, vrf)) { struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); /* With PAWS, it is safe from the viewpoint @@ -596,7 +603,7 @@ /* And established part... */ for(skp = &head->chain; (sk2=*skp)!=NULL; skp = &sk2->next) { - if(TCP_IPV4_MATCH(sk2, acookie, saddr, daddr, ports, dif)) + if(TCP_IPV4_MATCH(sk2, acookie, saddr, daddr, ports, dif, vrf)) goto not_unique; } @@ -690,7 +697,7 @@ } } - tb = tcp_bucket_create(head, rover); + tb = tcp_bucket_create(head, rover, sk->vrf); if (!tb) { spin_unlock(&head->lock); break; @@ -771,7 +778,7 @@ } tmp = ip_route_connect(&rt, nexthop, sk->saddr, - RT_CONN_FLAGS(sk), sk->bound_dev_if); + RT_CONN_FLAGS(sk), sk->bound_dev_if, sk->vrf); if (tmp < 0) return tmp; @@ -985,7 +992,7 @@ return; } - sk = tcp_v4_lookup(iph->daddr, th->dest, iph->saddr, th->source, tcp_v4_iif(skb)); + sk = tcp_v4_lookup(iph->daddr, th->dest, iph->saddr, th->source, tcp_v4_iif(skb), skb->vrf); if (sk == NULL) { ICMP_INC_STATS_BH(IcmpInErrors); return; @@ -1259,14 +1266,18 @@ static struct dst_entry* tcp_v4_route_req(struct sock *sk, struct open_request *req) { struct rtable *rt; + struct rt_key key; struct ip_options *opt; opt = req->af.v4_req.opt; - if(ip_route_output(&rt, ((opt && opt->srr) ? - opt->faddr : - req->af.v4_req.rmt_addr), - req->af.v4_req.loc_addr, - RT_CONN_FLAGS(sk), sk->bound_dev_if)) { + memset(&key,0,sizeof(key)); + key.dst = ((opt && opt->srr) ? opt->faddr : req->af.v4_req.rmt_addr); + key.src = req->af.v4_req.loc_addr; + key.oif = sk->bound_dev_if; + key.tos = RT_CONN_FLAGS(sk); + key.vrf = sk->vrf; + + if(ip_route_output_key(&rt, &key)) { IP_INC_STATS_BH(IpOutNoRoutes); return NULL; } @@ -1295,6 +1306,7 @@ goto out; skb = tcp_make_synack(sk, dst, req); + skb->vrf = sk->vrf; if (skb) { struct tcphdr *th = skb->h.th; @@ -1599,7 +1611,7 @@ th->source, skb->nh.iph->daddr, ntohs(th->dest), - tcp_v4_iif(skb)); + tcp_v4_iif(skb), skb->vrf); if (nsk) { if (nsk->state != TCP_TIME_WAIT) { @@ -1749,7 +1761,8 @@ TCP_SKB_CB(skb)->sacked = 0; sk = __tcp_v4_lookup(skb->nh.iph->saddr, th->source, - skb->nh.iph->daddr, ntohs(th->dest), tcp_v4_iif(skb)); + skb->nh.iph->daddr, ntohs(th->dest), + tcp_v4_iif(skb), skb->vrf); if (!sk) goto no_tcp_socket; @@ -1804,7 +1817,8 @@ { struct sock *sk2; - sk2 = tcp_v4_lookup_listener(skb->nh.iph->daddr, ntohs(th->dest), tcp_v4_iif(skb)); + sk2 = tcp_v4_lookup_listener(skb->nh.iph->daddr, + ntohs(th->dest), tcp_v4_iif(skb), skb->vrf); if (sk2 != NULL) { tcp_tw_deschedule((struct tcp_tw_bucket *)sk); tcp_timewait_kill((struct tcp_tw_bucket *)sk); @@ -1847,7 +1861,7 @@ /* Query new route. */ err = ip_route_connect(&rt, daddr, 0, RT_TOS(sk->protinfo.af_inet.tos)|sk->localroute, - sk->bound_dev_if); + sk->bound_dev_if, sk->vrf); if (err) return err; @@ -1883,6 +1897,7 @@ int tcp_v4_rebuild_header(struct sock *sk) { struct rtable *rt = (struct rtable *)__sk_dst_check(sk, 0); + struct rt_key key; u32 daddr; int err; @@ -1895,8 +1910,13 @@ if(sk->protinfo.af_inet.opt && sk->protinfo.af_inet.opt->srr) daddr = sk->protinfo.af_inet.opt->faddr; - err = ip_route_output(&rt, daddr, sk->saddr, - RT_CONN_FLAGS(sk), sk->bound_dev_if); + memset(&key,0,sizeof(key)); + key.dst = daddr; + key.src = sk->saddr; + key.oif = sk->bound_dev_if; + key.tos = RT_CONN_FLAGS(sk); + key.vrf = sk->vrf; + err = ip_route_output_key(&rt, &key); if (!err) { __sk_dst_set(sk, &rt->u.dst); sk->route_caps = rt->u.dst.dev->features; diff -uNr linux-kernel/net/ipv4/tcp_output.c vrf-kernel/net/ipv4/tcp_output.c --- linux-kernel/net/ipv4/tcp_output.c Sat Aug 24 00:22:32 2002 +++ vrf-kernel/net/ipv4/tcp_output.c Sat Aug 24 00:14:30 2002 @@ -265,6 +265,7 @@ TCP_ECN_send(sk, tp, skb, tcp_header_size); } + skb->vrf = sk->vrf; tp->af_specific->send_check(sk, th, skb->len, skb); if (tcb->flags & TCPCB_FLAG_ACK) diff -uNr linux-kernel/net/ipv4/udp.c vrf-kernel/net/ipv4/udp.c --- linux-kernel/net/ipv4/udp.c Sat Aug 24 00:22:32 2002 +++ vrf-kernel/net/ipv4/udp.c Sat Sep 14 23:36:58 2002 @@ -160,6 +160,7 @@ if (sk2->num == snum && sk2 != sk && sk2->bound_dev_if == sk->bound_dev_if && + sk2->vrf == sk->vrf && (!sk2->rcv_saddr || !sk->rcv_saddr || sk2->rcv_saddr == sk->rcv_saddr) && @@ -208,7 +209,7 @@ /* UDP is nearly always wildcards out the wazoo, it makes no sense to try * harder than this. -DaveM */ -struct sock *udp_v4_lookup_longway(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif) +struct sock *udp_v4_lookup_longway(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif, unsigned char vrf) { struct sock *sk, *result = NULL; unsigned short hnum = ntohs(dport); @@ -237,7 +238,11 @@ continue; score++; } - if(score == 4) { + if(sk->vrf != vrf) + continue; + score++; + + if(score == 5) { result = sk; break; } else if(score > badness) { @@ -249,12 +254,12 @@ return result; } -__inline__ struct sock *udp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif) +__inline__ struct sock *udp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif, unsigned char vrf) { struct sock *sk; read_lock(&udp_hash_lock); - sk = udp_v4_lookup_longway(saddr, sport, daddr, dport, dif); + sk = udp_v4_lookup_longway(saddr, sport, daddr, dport, dif, vrf); if (sk) sock_hold(sk); read_unlock(&udp_hash_lock); @@ -271,9 +276,10 @@ for(; s; s = s->next) { if ((s->num != hnum) || (s->daddr && s->daddr!=rmt_addr) || - (s->dport != rmt_port && s->dport != 0) || + (s->dport != rmt_port && s->dport != 0) || (s->rcv_saddr && s->rcv_saddr != loc_addr) || - (s->bound_dev_if && s->bound_dev_if != dif)) + (s->bound_dev_if && s->bound_dev_if != dif) || + (s->vrf != sk->vrf)) continue; break; } @@ -301,7 +307,7 @@ int harderr; int err; - sk = udp_v4_lookup(iph->daddr, uh->dest, iph->saddr, uh->source, skb->dev->ifindex); + sk = udp_v4_lookup(iph->daddr, uh->dest, iph->saddr, uh->source, skb->dev->ifindex, skb->vrf); if (sk == NULL) { ICMP_INC_STATS_BH(IcmpInErrors); return; /* No socket for error */ @@ -517,7 +523,14 @@ rt = (struct rtable*)sk_dst_check(sk, 0); if (rt == NULL) { - err = ip_route_output(&rt, daddr, ufh.saddr, tos, ipc.oif); + struct rt_key key; + memset(&key,0,sizeof(key)); + key.dst = daddr; + key.src = ufh.saddr; + key.tos = tos; + key.oif = ipc.oif; + key.vrf = sk->vrf; + err = ip_route_output_key(&rt, &key); if (err) goto out; @@ -734,7 +747,7 @@ saddr = sk->protinfo.af_inet.mc_addr; } err = ip_route_connect(&rt, usin->sin_addr.s_addr, saddr, - RT_CONN_FLAGS(sk), oif); + RT_CONN_FLAGS(sk), oif, sk->vrf); if (err) return err; if ((rt->rt_flags&RTCF_BROADCAST) && !sk->broadcast) { @@ -915,7 +928,7 @@ if(rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST)) return udp_v4_mcast_deliver(skb, uh, saddr, daddr); - sk = udp_v4_lookup(saddr, uh->source, daddr, uh->dest, skb->dev->ifindex); + sk = udp_v4_lookup(saddr, uh->source, daddr, uh->dest, skb->dev->ifindex, skb->vrf); if (sk != NULL) { udp_queue_rcv_skb(sk, skb); From sim897@lycos.co.kr Mon Oct 21 20:30:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 20:30:30 -0700 (PDT) Received: from lycos.co.kr (202-177-15-179.kdd.net.hk [202.177.15.179] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M3UOuR016573 for ; Mon, 21 Oct 2002 20:30:25 -0700 Message-Id: <200210220330.g9M3UOuR016573@oss.sgi.com> Reply-To: sim897@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?=C6=F7=B8=A3=B3=EB?= ! =?ISO-8859-1?Q?=C7=CF=C1=F6=B8=B8=20DVD=B6=F3=B3=D7?= ! Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 1 Nov 2002 11:33:05 +0800 X-archive-position: 842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sim897@lycos.co.kr Precedence: bulk X-list: netdev .

 

.

GOSEXGO !!

GOSEXGO DVD . ?. ?

.

CD . . . DVD . .

. DVD ? ?

 

<<<  >>>

 

From returnmail@mailsend.sgi.com Mon Oct 21 20:38:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 20:38:22 -0700 (PDT) Received: from mailsend ([203.234.205.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M3cJuR017415 for ; Mon, 21 Oct 2002 20:38:19 -0700 Message-Id: <200210220338.g9M3cJuR017415@oss.sgi.com> Reply-To: returnmail@mailsend.sgi.com From: TGland To: Subject: =?ISO-8859-1?Q?[=B1=A4=B0=ED]=20TG=B7=A3=B5=E5=B0=A1=20=B8=B6=B1=B8?= =?ISO-8859-1?Q?=BD=EE=B0=DA=BD=C0=B4=CF=B4=D9.?= - =?ISO-8859-1?Q?=BF=C0=C7=C2=202=C1=D6=B3=E2=20=B1=E2=B3=E4?= =?ISO-8859-1?Q?=C0=CC=BA=A5=C6=AE?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 12:45:50 +0900 X-Priority: 3 X-Mailer: Mailtouch 1.0 X-archive-position: 843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: returnmail@mailsend.sgi.com Precedence: bulk X-list: netdev
Untitled-1
50
[] . e-mail ,
.
. , .
From zero_game_re@lycos.co.kr Mon Oct 21 20:40:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 20:40:28 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.159]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M3eQuR017910 for ; Mon, 21 Oct 2002 20:40:26 -0700 Message-Id: <200210220340.g9M3eQuR017910@oss.sgi.com> Reply-To: zero_game_re@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=C0=CE=B0=F8=C1=F6=B4=C9?= =?ISO-8859-1?Q?=BB=E7=C1=D6=C7=AE=C0=CC=20"=BC=BC=C0=CC=BB=E7=C1=D6"?= =?ISO-8859-1?Q?=BF=C0=C7=C2=20=C0=CC=BA=A5=C6=AE!!?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 12:40:28 +0900 X-archive-position: 844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zero_game_re@lycos.co.kr Precedence: bulk X-list: netdev ::::::::

                                                                    

From jari.ruusu@pp.inet.fi Mon Oct 21 22:02:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 22:02:06 -0700 (PDT) Received: from fep08.tmt.tele.fi (hank-fep8-0.inet.fi [194.251.242.203]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M521uR022895 for ; Mon, 21 Oct 2002 22:02:02 -0700 Received: from pp.inet.fi ([194.197.67.58]) by fep08.tmt.tele.fi (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20021022050201.BBAC1315.fep08.tmt.tele.fi@pp.inet.fi>; Tue, 22 Oct 2002 08:02:01 +0300 Message-ID: <3DB4DBC8.8647E32E@pp.inet.fi> Date: Tue, 22 Oct 2002 08:02:00 +0300 From: Jari Ruusu X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.20aa1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Herbert Valerio Riedel CC: "David S. Miller" , Sandy Harris , Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec References: <3DB41338.3070502@storm.ca> <1035168066.4817.1.camel@rth.ninka.net> <1035185654.21824.11.camel@janus.txd.hvrlab.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jari.ruusu@pp.inet.fi Precedence: bulk X-list: netdev Herbert Valerio Riedel wrote: > On Mon, 2002-10-21 at 04:41, David S. Miller wrote: > > A completely new CryptoAPI subsystem has been implemented so that > > full lists of page vectors can be passed into the ciphers, which is > > necessary for a clean IPSEC implementation. > > oh... nice to learn about your plans (so late) at all ;-) > > well, it would be cool if you'd cooperate (or at least share > information) with us (the official cryptoapi project ;-), as we're open > for the design requirements of the next generation cryptoapi... Official cryptoapi? Define official. > ...otherwise this may render the kerneli.org/cryptoapi effort completely > useless :-/ ...of course, if it's your long term goal to take the > cryptoapi development away from kerneli.org, I'd like to know too ;-) kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other people are able to see the limitations/sillyness of kerneli.org/cryptoapi: 1) You are trying to replace link/insmod time overhead with runtime overhead + unnecessary bloat. 2) No direct link access to low level cipher functions or higher level functions. 3) No clean way to replace cipher code with processor type optimized assembler implementations. Regards, Jari Ruusu From bctraore@netscape.net Mon Oct 21 22:18:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 22:18:26 -0700 (PDT) Received: from oss.sgi.com (node-c-3f09.a2000.nl [62.194.63.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M5IJuR024135 for ; Mon, 21 Oct 2002 22:18:22 -0700 Message-Id: <200210220518.g9M5IJuR024135@oss.sgi.com> From: "Benson Cisse Traore" Date: Tue, 22 Oct 2002 07:18:11 To: netdev@oss.sgi.com Subject: Partnership. MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bctraore@netscape.net Precedence: bulk X-list: netdev Dear Prospective Partner, However strange or surprising this contact might seem to you, I ask that you give due consideration to its importance, as we both stand to benefit immensely. Though we have not met or know each other, this is a criteria I have used to select you, as I wish to cut off all ties with my people for security and safety reasons. At this point I wish to introduce myself properly to you. My name is Benson Cisse Traore, I am a personal aide to the Late General Robert Guei of blessed memory, former President of Cote d'Ivoire (Ivory Coast). You may not be conversant with the present situation in my country, which has gradually degenerated into a civil war. For the sake of what I envisage we achieve together, I wish to give you a general overview. My country in reality has ever since independence from France had an undefined and fragile polity. Founding president, Felix Houphouet-Boigny ruled us with individual blend of paternalism from independence in 1960 until his death in December 1993. He bowed to pressure for multi-party politics in 1990. In 1993, National Assembly president Henri Konan Bedie won a brief power struggle with Prime Minister Alassane Ouattara to succeed Houphouet-Boigny. The following month, the former single Ruling Democratic Party set up by Houphouet-Boigny, then headed by Bedie won an overwhelming majority in the National assembly. On December 24, 1999, my mentor Gen. Robert Guei ousted Bedie in a coup de tat. Although this was highly criticized, but it was the right thing to do. In July 2000, Gen. Guei approved a new constitution in referendum with tough eligibility conditions for presidential candidates. In spite of criticism, he registered as a candidate. The Supreme Court intervened, and he was cleared. This was not totally acceptable to the other candidates from the ruling Democratic Party (PDCI-RDA), the country's largest. The only opponent was Socialist candidate Laurent Gbagbo. Admittedly, Gbagbo won the election of October 22, 2000, but his political immaturity, led to Gen. Guei being reluctant to relinquish power. There were allegations of election rigging etc. Ouattara who was previously barred by the referendum to contest election, was excluded from the December 10 parliamentary election because of doubts about his nationality and his supporters announced they would boycott the election. Gbagbos Popular Front (FPI) was victorious in the election, and there were demonstrations due to propaganda that Gen. Guei tried to rig the election. Under pressure from international donors, Gbagbo agreed to hold a reconciliation forum to draw a line under the political strife that followed the 1999 coup, but key players including Outtara failed to show up for the opening. After two years of build up, On September 19, 2002, Gen. Guei led a failed coup de tat against Gbagbo, in a bid to restore political stability. Unfortunately, he was killed. After Gen. Gueis death, there was turmoil in our camp; this has led to us losing half our strength. Although we still control the north and Central regions of the country. It is now a question of who will give in between us (now referred to as rebels) and Gbagbos government. There seem to be no chance for peace, as several attempts has been botched by Gbagbo. Our Armory is seriously depleting, and we do not have the financial resources to strengthen it to prosecute the war. I have now decided to abandon the war. The US and France has since evacuated their citizens from our country. Destruction is imminent, as ECOWAS (Economy Community of West African States) has been called in to mediate. Their only way of doing this is to bring in ECOMOG (A monitoring group). We witnessed the horror they caused trying to restore peace to Liberia and Sierra Leone during the civil war. Thus I have lost faith and hope in the struggle. To the point, the essence of my contact with you is to seek your most needed assistance to siphon US$18,500,000 left in the bunker of Gen.Guei's Palace. Only Gen. Guei and me knew about this fund. Now that Gen. Guei is dead, I intend to use this money for my personal benefit (as well as yours if you accept to be my partner). I see justification in diverting the money, rather using it to support the purchase of weapons for destruction of innocent lives and properties. I secretly fled my Country, and this money was moved in cash to my present location in Europe through diplomatic means, and I have since deposited the trunk containing the funds with a private security company. If you accept to offer me your assistance, I will require that you assist me in claiming the box as a gift from me to you from the security company. Be informed that I am confiding in you by disclosing this to you, as it is only me (apparently you now) that have knowledge of this. When the box is claimed, we shall then have the money deposited into an Offshore account in your name, as I am being discrete of using my name for now. Then you shall have your own share withdrawn to an account of your choice, and leaving the rest as fixed deposit, for release to me at the appropriate time. The importance of prosecuting this within the next few days cannot be overlooked; hence your immediate response will be highly appreciated. On hearing from you, I shall disclose my location to you, and discuss the share of the money you will be entitled to for offering me your most needed assistance. In case you are not inclined to render me your assistance, endeavor to respond, so that I may move ahead. You may click this link http://news.bbc.co.uk/1/hi/world/africa/930254.stm to see me with my mentor Gen. Guei in 1999, so that you may associate this correspondence to my face. Sincerely, B. C. Traore. From kmg6165@hitel.net Mon Oct 21 22:43:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 22:43:36 -0700 (PDT) Received: from hitel.net ([61.75.230.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M5hPuR025950 for ; Mon, 21 Oct 2002 22:43:30 -0700 Message-Id: <200210220543.g9M5hPuR025950@oss.sgi.com> Reply-To: kmg6165@hitel.net From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=BD=C7=B3=BB=BF=A1?= =?ISO-8859-1?Q?=B3=F5=BE=C6=B5=CE=B1=E2=B8=B8=20=C7=CF=B8=E9?= =?ISO-8859-1?Q?6=B0=A1=C1=F6=20=C8=BF=B4=C9=C0=CC...?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 14:38:42 +0900 X-archive-position: 847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kmg6165@hitel.net Precedence: bulk X-list: netdev
O 50 []
O e-mail ,


  (polgent)

http://www.polgent.net
 


*?

() (101989) .. .   

 

* *
* *

1) , .
2) , .
3) .
4) .
5)   .                                

**

,,,,, .   
                                         / : 612-04-67345
                                            : / TEL : 080-377-7175

                                

 
O .
O  
O If you don`t want this type of information or e-mail, please click the `refuse` button.

 

From greearb@candelatech.com Mon Oct 21 23:08:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Oct 2002 23:08:16 -0700 (PDT) Received: from grok.yi.org (IDENT:rnXGHhB81F8huSNL7zDqvpu/NjuSj7gk@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M68EuR027834 for ; Mon, 21 Oct 2002 23:08:14 -0700 Received: from candelatech.com (IDENT:YqV8/MNhxI4QLjjbWeL8SLHrhkqHHxdi@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9M67Xq24327; Mon, 21 Oct 2002 23:07:35 -0700 Message-ID: <3DB4EB25.5050706@candelatech.com> Date: Mon, 21 Oct 2002 23:07:33 -0700 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: Robert Olsson , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 848 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: > In addition to solve your skb problem pick Roberts latest > recycling patch at: > ftp://robur.slu.se/pub/Linux/net-development/skb_recycling/recycle12.pat > The driver i pointed to above has skb-recycling built in. Robert, I am porting the existing tulip + your napi patch to support skb-recycling. (I realize someone has probably done that, but I can't find it...Jamal's links are busted!) In the help file, you suggest this at close: for (i=0; icnt[i]) { current->state = TASK_INTERRUPTIBLE; schedule_timeout(1); } } I think the second if should probably be while, ie like this: for (i=0; icnt[i]) { current->state = TASK_INTERRUPTIBLE; schedule_timeout(1); } } Otherwise, you race, and may delete an object that is still in use somewhere up the stack. Let me know if I'm nuts! Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From shopping4u@lycos.co.kr Tue Oct 22 00:59:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 00:59:21 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9M7xIuR003419 for ; Tue, 22 Oct 2002 00:59:19 -0700 Message-Id: <200210220759.g9M7xIuR003419@oss.sgi.com> Reply-To: shopping4u@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20"=BF=A1=C4=DA?= =?ISO-8859-1?Q?=B4=D9=BF=EE=C6=C4=C4=AB=20198000=BF=F8=C0=BB?= =?ISO-8859-1?Q?=B4=DC=B5=B7=203=B8=B89=C3=B5=BF=F8=BF=A1!!!"?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 16:59:24 +0900 X-archive-position: 849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shopping4u@lycos.co.kr Precedence: bulk X-list: netdev
[] .
.
We do not have any personal infotmation except your E-mail address.
If you push the button 'REMOVE' the mail will not be sent anymore.


Copyright 2002 AfterU Korea Co., Ltd. All rights reserved.

: 113-81-74054 / : 0 9 5 4 4
: 670-4 B1F
() :
: 0 2 ) 6 5 9 - 2 4 4 4 / E-Mail : cs@afteru.co.kr

From daccima@lycos.co.kr Tue Oct 22 03:50:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 03:51:01 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MAowuR018238 for ; Tue, 22 Oct 2002 03:50:59 -0700 Message-Id: <200210221050.g9MAowuR018238@oss.sgi.com> Reply-To: daccima@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=B8=AE=C4=A1=B8=F4?= =?ISO-8859-1?Q?=BF=C0=C7=C2=B1=E2=B3=E4=20=C0=CC=BA=A5=C6=AE!!?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 19:51:04 +0900 X-archive-position: 850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daccima@lycos.co.kr Precedence: bulk X-list: netdev mail

. .
| | | | /
Copyright (c)2002 K-Richmall All rights reserved. Email: richmall@k-richmall.com
Tel : 053-814-0383 / Fax : 053-817-6646
510-1 4 | : 053-814-0383 | :
: 502-08-78562
From koreaphilip@koreaphilip.com Tue Oct 22 05:06:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 05:06:02 -0700 (PDT) Received: from localhost ([211.216.14.181]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MC5uuR024098 for ; Tue, 22 Oct 2002 05:05:59 -0700 Message-Id: <200210221205.g9MC5uuR024098@oss.sgi.com> Reply-To: koreaphilip@koreaphilip.com From: To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?[=B1=A4=B0=ED]=BD=C4=C7=B0,=BE=EE=C6=D0=B7=F9=BF=A1?= =?ISO-8859-1?Q?=B0=A2=C1=BE?= =?ISO-8859-1?Q?=C0=AF=C7=D8=B9=B0=C1=FA,=BC=BC=B1=D5,=B3=BF=BB=F5?= =?ISO-8859-1?Q?100%=C1=A6=B0=C5?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 21:04:50 +0900 X-archive-position: 851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: koreaphilip@koreaphilip.com Precedence: bulk X-list: netdev From daccima@lycos.co.kr Tue Oct 22 05:19:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 05:19:08 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.159]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MCJ6uR026022 for ; Tue, 22 Oct 2002 05:19:07 -0700 Message-Id: <200210221219.g9MCJ6uR026022@oss.sgi.com> Reply-To: daccima@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=B8=AE=C4=A1=B8=F4?= =?ISO-8859-1?Q?=BF=C0=C7=C2=B1=E2=B3=E4=20=C0=CC=BA=A5=C6=AE!!?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 21:19:10 +0900 X-archive-position: 852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daccima@lycos.co.kr Precedence: bulk X-list: netdev mail

. .
| | | | /
Copyright (c)2002 K-Richmall All rights reserved. Email: richmall@k-richmall.com
Tel : 053-814-0383 / Fax : 053-817-6646
510-1 4 | : 053-814-0383 | :
: 502-08-78562
From Robert.Olsson@data.slu.se Tue Oct 22 06:48:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 06:48:35 -0700 (PDT) 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 g9MDmVuR002641 for ; Tue, 22 Oct 2002 06:48:32 -0700 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id PAA05964; Tue, 22 Oct 2002 15:55:20 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <15797.22728.683363.412344@robur.slu.se> Date: Tue, 22 Oct 2002 15:55:20 +0200 To: Ben Greear Cc: jamal , Robert Olsson , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? In-Reply-To: <3DB4EB25.5050706@candelatech.com> References: <3DB4EB25.5050706@candelatech.com> X-Mailer: VM 6.92 under Emacs 19.34.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9MDmVuR002641 X-archive-position: 853 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: In the help file, you suggest this at close: for (i=0; icnt[i]) { . I think the second if should probably be while, ie like this: for (i=0; icnt[i]) { Thanks! Your postings about driver for p430 Phobos 4-port NIC was very confusing. I assume that tulip in 2.4.20-pre9 works even without the tulip-020922.pat. Right? Does the board have separate MII-transceivers or is the tulip chips used for MII? Cheers. --ro From freezoneplus@yahoo.co.kr Tue Oct 22 07:57:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 07:57:26 -0700 (PDT) Received: from yahoo.co.kr ([61.79.206.123]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MEvNuR008362 for ; Tue, 22 Oct 2002 07:57:24 -0700 Message-Id: <200210221457.g9MEvNuR008362@oss.sgi.com> Reply-To: freezoneplus@yahoo.co.kr From: x To: Subject: =?ISO-8859-1?Q?=BF=E4=C1=F2=20=C8=AD=B2=F6=C7=D1?= =?ISO-8859-1?Q?=BC=BA=C0=CE=B5=BF=BF=B5=BB=F3=B8=B8=20=B8=F0=C0=BA?= =?ISO-8859-1?Q?=C0=DA=B7=E1=BD=C7=B0=F8=B0=B3[=BC=BA=C0=CE=B1=A4=B0=ED]?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Oct 2002 23:58:18 +0900 X-archive-position: 854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: freezoneplus@yahoo.co.kr Precedence: bulk X-list: netdev

c,y,l ,

++

.

!

~

http://sexsexok.com

230-53 3
[] .

  - -

. , . [(refuse)] . (If you don't want this type of information or e-mail, please click the 'refuse' button) From roseike98@usa.com Tue Oct 22 09:07:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 09:07:40 -0700 (PDT) Received: from emztd155.com (host-217-146-2-126.warsun.com [217.146.2.126] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MG76uR012974 for ; Tue, 22 Oct 2002 09:07:26 -0700 Message-Id: <200210221607.g9MG76uR012974@oss.sgi.com> From: "Princess Rose Ike" Reply-To: roseike98@hotmail.com Date: Tue, 22 Oct 2002 17:16:02 -0700 Subject: PLEA FOR ASSISTANCE X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9MG76uR012974 X-archive-position: 855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roseike98@usa.com Precedence: bulk X-list: netdev IN VIEW OF YOUR PROFESSION INTRODUCTION: I am Princess Rose Ike, daughter of Osi Ike, the king of Ogoni Kingdom. I am 23 years old and a graduate of Mass Communication My father was in charge of Reviving royalties from the multi-national oil companies and government on behalf off the oil producing communities in Nigeria before he die. But before his death, he called me and told me he has Twelve Million Seven Hundred thousand Dollars (US$12.7M) cash in his possession, specially deposited in AFRICAN DEVELOPMENT BANK GROUP (ADBG). He advised me not to tell anybody except my mother who is the last wife of the (8) eight wives that he married. My mother did not bear any male child for him. Which implies that all my fathers properties, companies etc, we have no share in them because my mother has no male child according to African tradition. My father there fore secretly gave me all the relevant document of the said money, and told me that I should use this money with my mother and my younger sisters, because he knows that traditionally, if he dies we cannot get anything, as inheritance. He importantly advised me that I should seek foreign assistance and that I should not invest this money here in Nigeria because of his other wives and male children who happen to be my elders. I am soliciting for your immediate assistance to get a bungalow for us, wherein will live with my mother and two younger sisters and further advise me where and how I will invest the balance money overseas, possibly on products of your company and other profitable ventures. I believe that by the special grace of God, you will help us move this money out of African Development Bank Group to any country of your choice where we can invest this money judiciously with you. You are entitled to a reasonable part of this Money based on our agreement, and God will bless you as you help us. Please reply through my e-mail roseike98@hotmail.com and please you can as well contract me back preferably through my private Fax 234-1-7593342 for security reasons if you did not hear from me after 3days in regards of your email response. Looking forward to hear from you as soon as possible on receipt of this message. Best Regard, PRINCESS ROSE IKE From greearb@candelatech.com Tue Oct 22 09:57:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 09:57:29 -0700 (PDT) Received: from grok.yi.org (IDENT:a/8oCwwR/ZzKSqHMESTnhAPMX1BX4s0Z@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MGvRuR015789 for ; Tue, 22 Oct 2002 09:57:27 -0700 Received: from candelatech.com (IDENT:sOX3DL0xijnFdrj1aQ9vZteIO7kHBMXZ@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9MGuxq25938; Tue, 22 Oct 2002 09:56:59 -0700 Message-ID: <3DB5835B.8000502@candelatech.com> Date: Tue, 22 Oct 2002 09:56:59 -0700 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: jamal , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? References: <3DB4EB25.5050706@candelatech.com> <15797.22728.683363.412344@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 856 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: > > > In the help file, you suggest this at close: > for (i=0; i - if(adapter->cnt[i]) { > . > I think the second if should probably be while, ie like this: > for (i=0; i + while(adapter->cnt[i]) { > > Thanks! > > Your postings about driver for p430 Phobos 4-port NIC was very confusing. > I assume that tulip in 2.4.20-pre9 works even without the tulip-020922.pat. > Right? It works fine as far as negotiation and ping goes, it just drops packets (and very rarely, locks up on receive) at higher speeds. With NAPI and larger receive buffers, it drops very few packets, though it does occasionally lock up when I first start traffic. I will run tulip-diag on it next time it does this... > > Does the board have separate MII-transceivers or is the tulip chips used > for MII? I'm not sure... Thanks, 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 mdsk25200oramd@compuserve.net Tue Oct 22 12:41:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 12:41:18 -0700 (PDT) Received: from 200.171.111.111 (200-171-111-111.dsl.telesp.net.br [200.171.111.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MJeduR026182 for ; Tue, 22 Oct 2002 12:40:49 -0700 Message-Id: <200210221940.g9MJeduR026182@oss.sgi.com> Received: from unknown (52.127.142.42) by rly-xl04.mx.aol.com with smtp; Oct, 22 2002 3:15:45 PM +0400 Received: from smtp-server1.cfl.rr.com ([5.151.138.187]) by rly-xl04.mx.aol.com with esmtp; Oct, 22 2002 2:14:45 PM -0000 Received: from 51.110.169.187 ([51.110.169.187]) by rly-xl04.mx.aol.com with SMTP; Oct, 22 2002 1:17:54 PM -0300 From: "pvpi25200oramd@compuserve.net" To: Oral.Care@oss.sgi.com Cc: Subject: Gingivitis? - Gum Disease? - Bleeding Gums? xnxh Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 22 Oct 2002 15:43:03 -0400 X-Mailer: The Bat! (v1.52f) Business X-archive-position: 857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mdsk25200oramd@compuserve.net Precedence: bulk X-list: netdev ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gum Disease? - Gingivitis? - Bleeding Gums? Nature Provides the Best Answer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gum disease occurs naturally. You can end it naturally too! "Since using Oramd, my wife and I have both noticed improvements in our gums. My gums had been bleeding due to separation between the gum and tooth, or plaque build-up. Using two drops for brushing has made a difference. I am re-ordering the product because I am convinced that it is working for both of us, and I want to see how much improvement I can realize over a longer period of time. I've only been using it for a month and I can see a difference". Richard Massie, New York ----------------------------------- "I was experiencing sensitive teeth (sensitive to hot and cold) and went to the dentist. He coated the affected tooth with a product that was supposed to stop the sensitivity but it did not. Two days later my first order of OraMD arrived and I started to use it. By the second day the sensitivity was gone. Also, I like the way my teeth feel, clean and fresh, after using OraMD. Your product is great". Bill Gore Cincinnati, OH ----------------------------------- "I really do enjoy using your product ORAMD. It gives my mouth such a clean refreshing taste. I was so excited when I went to the dentist after using your product for 3 months , I had zero bleeding points!! That was the first time I had ever had no bleeding points. I especially like the fact that it is all natural with no chemicals or preservatives. If gives my mouth a fresh awaking feeling and I feel like I have not had bad breath since I have started using it. Its a terrific product and would highly recommend it to anyone. Thanks for making a healthy tooth polish combination mouth wash!" Sue Donahoe, Lexington, KY Click for more information and tons of testimonials http://www.oramd.com/_le.htm This message sent to netdev@oss.sgi.com We absolutely honor your request to be taken off our mailing list http://www.oramd.com/_goodbye.htm From hyangmee12@dreamwiz.com Tue Oct 22 13:24:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 13:24:28 -0700 (PDT) Received: from dreamwiz.com ([211.61.65.123]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MKOOuR030595 for ; Tue, 22 Oct 2002 13:24:25 -0700 Message-ID: <287910-2200210222204810140@dreamwiz.com> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 Reply-To: hyangmee12@dreamwiz.com From: "" To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?[=BC=BA=C0=CE=B1=A4=B0=ED]=C0=BD=B8=DE~=20=C0=BD=B8=DE~?= Date: Wed, 23 Oct 2002 05:48:10 +0900 MIME-Version: 1.0 Content-Type: text/html; charset=KS_C_5601-1987 Content-Transfer-Encoding: quoted-printable X-archive-position: 858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hyangmee12@dreamwiz.com Precedence: bulk X-list: netdev

=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF= =A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0= =CF=C0=D4=B4=CF=B4=D9=2E
=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD= =C3=B8=E9 = =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4

=2E           &n= bsp;             &n= bs p;            = &n bsp;           &nbs= p;             &n= bs p;            = =20        =20 Reject/Remove

    =C0=CC =C1=A4=BA=B8=B4=C2= =C3=BB=BC=D2=B3=E2 =C0=AF=C7=D8=B8=C5=C3=BC=B9=B0=B7=CE=BC=AD =C1=A4=BA=B8=C5=EB=BD=C5=B8=C1 = =C0=CC=BF=EB=C3=CB=C1=F8 =B9=D7 =C1=A4=BA=B8=BA=B8=C8=A3=B5=EE=BF=A1 =B0=FC= =C7=D1 =B9=FD=B7=FC =B9=D7 =C3=BB=BC=D2=B3=E2 =BA=B8=C8=A3=B9=FD=C0=C7 =B1=D4=C1=A4=BF=A1=20 =C0=C7=C7=CF=BF=A9 19=BC=BC =B9=CC=B8=B8=C0=C7 =C3=BB= =BC=D2=B3=E2=C0=CC =C0=CC=BF=EB=C7=D2=BC=F6 =BE=F8=BD=C0=B4=CF=B4=D9=2E

=B9=CC=BC=BA=B3=E2=C0=DA =B6=C7=B4=C2 =BF=F8=C4=A1 =BE=CA=B4=C2 =BA=D0=C0= =BA =C0=A7=BF=A1 =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B9=DD=B5=E5=BD=C3 =B9=DD=B5= =E5=BD=C3 =B2=C0 =B4=AD=B7=AF=C1=D6=BD=C3=B1=E2=20 =B9=D9=B6=F8=B4=CF=B4=D9=2E

=C5=AC=B8=AF =C7=CF=BD=C3=B8=E9=2E=2E=2E= =2E =BC=BA=C0=CE =BB=E7=C0=CC=C6=AE=B7=CE =C0=CC=B5=BF=C7=D5=B4=CF=B4= =D9=2E

=BF=F8=C7=CF=B4=C2 =B0=F7=C0=BB =C5=AC=B8= =AF=C7=D8 =C1=D6=BC=BC=BF=E4=2E=20 =B0=F1=B6=F3=BA=B8=B4=C2 =C0=E7=B9=CC= =B0=A1 =C0=D6=B4=D9=2E

=BC=BA=C0=CE =B8=B8=C8=AD=B8=A6 =BA=B8=BD=C3=B0=ED =BD=CD=C0=B8=BD=C5 =BA= =D0=C0=BA =C5=AC=B8=AF=C7=D8 =C1=D6=BC=BC=BF=E4=2E

=20

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

=B9=DF=BC=DB=C0=DA =BF=AC=B6=F4=C3=B3= =2E=2E yoon hyang_mee=20 =BF=B5=B5=EE=C6=F7=B1=B8 =BD=C5=B1=E66=B5=BF 3183-26 e-mail=C0=BAkkhmra@korea=2Ecom

Tel=20 019-295-0621

From info@arelax.net Tue Oct 22 15:39:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 15:39:24 -0700 (PDT) Received: from st47.arena.ne.jp (st47.arena.ne.jp [210.150.221.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9MMdLuR009522 for ; Tue, 22 Oct 2002 15:39:21 -0700 Received: (qmail 18557 invoked by uid 114); 23 Oct 2002 07:39:25 +0900 Received: from info@arelax.net by st47.arena.ne.jp by uid 111 with qmail-scanner-1.10 (sophie: 2.10/3.62. . Clear:0. Processed in 0.025719 secs); 23 Oct 2002 07:39:25 +0900 Received: from unknown (HELO s1) (211.8.48.135) by arelax.net with SMTP; 23 Oct 2002 07:39:25 +0900 To: netdev@oss.sgi.com Message-ID: <20021023.0737010468.babaq@info-arelax.net> Date: Wed, 23 Oct 2002 07:37:01 +0900 From: "Arelax.NET-AD" Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoJVshPCVgJVohPCU4JHIkPyQvGyhC?= =?ISO-2022-JP?B?GyRCJDUkcyROSn0kWDgrJEYkYiRpJCgka0p9SyEbKEI=?= MIME-Version: 1.0 X-Mail-Agent: Extra Japan @Mailer Content-Type: text/plain; charset=ISO-2022-JP X-archive-position: 859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: info@arelax.net Precedence: bulk X-list: netdev <事業者>アリラックス　アクセスアップサポート　info@arelax.net ※特定商取引法施行規則<広告の受取を希望しない場合の連絡方法> この案内は一度のみの送信ですが、当方からの広告配信停止を希望 される方は、このメールにそのまま返信いただくか、若しくは、件 名を「配信停止」と書き換え返信してください。 ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲ ■■　　　　　　　個人でも十分利用可能な価格設定　　　　　　　　　■■ ▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼ 　　低料金なので、個人サイトのアクセスアップにもご利用者急増中！ 　個人・非営利サイト 1800円　業界最安！ 　法人・営利サイト 3500円　業界最安！ 　最大約300件程度まで登録可能 （お客様のホームページの内容や希望カテゴリによって登録数は変わります） 登録される数が多い方や、自分で多数の検索サイトに登録したい方には、自動 登録ソフトも取り扱っております。 ◆詳細はこちらから http://arelax.net/pc/marketing/ ホームページのアクセスアップや、 まだパソコンに慣れない方へのパソコン習得のヒントがここに！ ◆総合トップページ◆ http://www.arelax.net/pc/ ◆検索サイトよかもんサーチへご登録ください。もちろん登録は無料◆ http://www.arelax.net/cgi-bin/src/yomi.cgi ※料金比較当方2002/9/15調べ ===================================================================== 　　　特定商取引法施行規則　受け取りを希望しない場合の連絡方法 ===================================================================== 　メールアドレスを複数お持ちの場合や、万が一誤って複数届いている場合 　やメーリングリストのアドレスに送信されてしまっている場合など、広告 　メールの配信停止を希望の場合は、このメールにそのまま返信いただくか、 　若しくは、件名を「配信停止」と書き換え返信してください。 　その返信元のアドレスに対する配信は停止いたします。 　　　　　　info@arelax.net ====================================================================== 当方では、特定商取引法に従い適正な商業広告メール配信を行っております。 ====================================================================== _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ アリラックスＰＣセンター　ホームページアクセスアップサポート 熊本市楡木５丁目２７−３ info@arelax.net _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From hadi@cyberus.ca Tue Oct 22 17:54:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 17:54:42 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N0seuR019880 for ; Tue, 22 Oct 2002 17:54:40 -0700 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 UAA15203; Tue, 22 Oct 2002 20:54:45 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N0lJv24559; Tue, 22 Oct 2002 20:47:19 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 20:47:19 -0400 (EDT) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. In-Reply-To: <3DB42A90.1030709@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 860 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, 21 Oct 2002, Ben Greear wrote: > jamal wrote: > > Patch looks fine except for the 300 number. What are you smoking? > > Please retain the original value. > > The original value was 300, what do you want it to be? > Ok, i take back what i said then. Your patch is not that useful. For some reason i thought you were introducing NET_CORE_DEV_WEIGHT which happens to already exist with default value of 64. The value you put out MUST be the same as netdev_max_backlog in order to be fair to non-NAPI devices. Any change to one must be reflected to the other. So a useful patch will try to shadow NET_CORE_MAX_BACKLOG to that value and allow only changes to happen to NET_CORE_MAX_BACKLOG; i.e no need for two separate parameters. cheers, jamal From hadi@cyberus.ca Tue Oct 22 18:02:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:02:13 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N12BuR020708 for ; Tue, 22 Oct 2002 18:02:11 -0700 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 VAA17672; Tue, 22 Oct 2002 21:02:13 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N0smG24577; Tue, 22 Oct 2002 20:54:48 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 20:54:48 -0400 (EDT) From: jamal To: Ben Greear cc: Robert Olsson , "'netdev@oss.sgi.com'" Subject: Re: tulip NAPI patch that works with 2.4.20-pre9 or so? In-Reply-To: <3DB44966.1070402@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 861 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, 21 Oct 2002, Ben Greear wrote: > jamal wrote: > > Theres a 2419 patch that should work for you at: > > http://www.cyberus.ca/~hadi/tulip-2419-napi-nifd.gz Links were wrong, prefix is: http://www.cyberus.ca/~hadi/patches > Do you have any descriptions of what this feed patch does differently > from other drivers? Id rather not tell you since we are still evaluating its usefullness and it may not be there next week. Anyways, i put a patched driver - so you only need to pick the extra patch: http://www.cyberus.ca/~hadi/patches/tulip-feed-patched.tgz this + the core patch from Roberts site. Make sure you edit tulip.h and edit the number of CPUS you have to avoid NR_CPU stupidity. cheers, jamal From aaaaaaaab73@korea.com Tue Oct 22 18:06:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:06:24 -0700 (PDT) Received: from aaaaaaaab73 ([211.189.119.253]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N16KuR021340 for ; Tue, 22 Oct 2002 18:06:21 -0700 Message-Id: <200210230106.g9N16KuR021340@oss.sgi.com> Reply-To: aaaaaaaab73@korea.com From: aaaaaaaab73 To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?=C1=F8=C2=A5=20=BF=DC=B1=B9=20=C6=F7=B8=A3=B3=EB?= =?ISO-8859-1?Q?=BB=E7=C0=CC=C6=AE=C0=D4=B4=CF=B4=D9.?= =?ISO-8859-1?Q?=B9=CC=BC=BA=B3=E2=C0=DA?= =?ISO-8859-1?Q?=C0=FD=B4=EB=B0=FC=B6=F7=BA=D2=B0=A1!!?= Date: Wed, 23 Oct 2002 09:08:55 +0900 Mime-Version: 1.0 Content-Type: text/html; charset="euc-kr" X-archive-position: 862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aaaaaaaab73@korea.com Precedence: bulk X-list: netdev . !!
.
.

. . .

, 20 .
. .

This web site contains sexually oriented adult material which is not suitable for those who are under the age of 20. If you are under the age of 20 or find material of an adult nature offensive, or if you are accessing this site from a country where adult material is specifically prohibited by law, please leave this site immediately. By entering this web page you are acknowledging that you are in fact 20 years of age or older, and therefore we will hold no responsibility for any adult material you find on this web site. All models on this site are 20 years of age or older. We do not promote violent, malignant, or child pornography. If you understand and accept these terms you may enter.

From greearb@candelatech.com Tue Oct 22 18:06:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:06:30 -0700 (PDT) Received: from grok.yi.org (IDENT:5YOsp9QdAZUppPFGeFBDkQ7vckHR0J89@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N16RuR021402 for ; Tue, 22 Oct 2002 18:06:28 -0700 Received: from candelatech.com (IDENT:QzLhnx20vA2olCKA1uSYGpyOMOYzsknl@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9N16Dq02065; Tue, 22 Oct 2002 18:06:13 -0700 Message-ID: <3DB5F605.1010507@candelatech.com> Date: Tue, 22 Oct 2002 18:06:13 -0700 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: [PATCH] Break 'budget' dependency on netdev_max_backlog. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 863 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 Mon, 21 Oct 2002, Ben Greear wrote: > > >>jamal wrote: >> >>>Patch looks fine except for the 300 number. What are you smoking? >>>Please retain the original value. >> >>The original value was 300, what do you want it to be? >> > > > Ok, i take back what i said then. Your patch is not that useful. > For some reason i thought you were introducing NET_CORE_DEV_WEIGHT > which happens to already exist with default value of 64. > The value you put out MUST be the same as netdev_max_backlog in order > to be fair to non-NAPI devices. > Any change to one must be reflected to the other. So a useful patch > will try to shadow NET_CORE_MAX_BACKLOG to that value and allow only > changes to happen to NET_CORE_MAX_BACKLOG; i.e no need for two separate > parameters. Actually, with the changes the way they are, if you have a backlog value of 300, and the first NAPI driver reads 300 packets, then all the rest of the NAPI drivers will just throw away packets because the max-backlog has already been hit (if I understand things correctly). If we make the backlog big enough to handle a large burst of incomming traffic w/out dropping them, then the first NAPI driver can hog a very large amount of CPU because its budget is now huge. The rest of the devices in the poll loop will not be serviced in time, and will drop packets (I saw this when testing out the 4-port tulip driver with the NAPI patch). Ben > > cheers, > jamal > -- 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 Tue Oct 22 18:06:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:06:46 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N16huR021654 for ; Tue, 22 Oct 2002 18:06:44 -0700 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 VAA19311; Tue, 22 Oct 2002 21:06:48 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N0xNd24611; Tue, 22 Oct 2002 20:59:23 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 20:59:22 -0400 (EDT) From: jamal To: David Woodhouse cc: , Subject: Re: rtnetlink interface state monitoring problems. In-Reply-To: <24818.1035226670@passion.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 864 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, 21 Oct 2002, David Woodhouse wrote: > > hadi@cyberus.ca said: > > I cant see anything on netlink and irda; i am also not very familiar > > with either IrDA or Bluetooth. Regardless, you dont need to be a net > > device to use netlink. > > IrDA devices are network devices. The core network code sends a RTM_NETLINK > message when they go up or down. All is well, and once the permission fix > gets into the kernel I'm using, my irda monitor applet no longer needs to > poll the state of the interface. > Ah, ok. I see what you mean - for a moment i thought IrDA was doing something clever with netlink. > But Bluetooth devices are not network devices, it seems. There exists no > current mechanism for notifying anyone of state changes. Should we invent a > new method of notification using netlink, or should Bluetooth interfaces in > fact be normal network devices just like IrDA devices are? > I think the only time you should go netdev is when it makes sense to run IP. Is there IP over bluttooth? Then you could take advantage of all the nice features provided by netdevices (other than being IP devices;->). If not, it probably time for someone to write a generic notification scheme via netlink. cheers, jamal From g4group4@mail.com Tue Oct 22 18:14:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:14:49 -0700 (PDT) Received: from oss.sgi.com ([213.181.64.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N1EhuR022884 for ; Tue, 22 Oct 2002 18:14:46 -0700 Message-Id: <200210230114.g9N1EhuR022884@oss.sgi.com> From: "Mr Daniel Osondu" Date: Wed, 23 Oct 2002 02:26:04 To: netdev@oss.sgi.com Subject: Urgent Business Proposal ( Reply Please) MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: g4group4@mail.com Precedence: bulk X-list: netdev ATTN:MANAGING DIRECTOR I am writing this proposal hoping that you would be of assistance in this business of mutual benefit. My name is Mr Daniel Osondu an auditor at one of the Federal Ministries in lagos-Nigeria. During our last audit exercise,some amount of money totalling $16.5Million was discovered and traced to be owned by one late Engineer Muller Robert, a foreigner who died in a plane crash. The source of this fund was further traced to be a contract payment made to him but has remained unclaimed till now.Since his death, nobody has shown up to claim this fund and this attracted my curiosity. I therefore made a research and found out that he did not leave any next of kin in his confidential document with the ministry that he executed the contract for. A panel setup by the Federal Government on recovery of funds expects that this fund should be unquestionably claimed by any of his available foreign next of kin or alternatively the fund should be donated for arms and ammunition at a military war college here in Nigeria. Fervent valuable efforts were made by the Panel to get in touch with any of the family or relatives but all have proved to no avail. It is because of the perceived possibility of not going to be able to locate any next of kin ( he had no wife and children) that the panel under the influence of our chairman, Rtd Major General Usman Bello, that arrangement is being made for the fund to be declared UNCLAIMABLED and then be donated to the Trust Fund for arms and ammunition which will further enhance the perpetration of war in Africa and the third world in general. To forestall this move, my colleagues and I have taken it upon ourselves to source for a foreign partner who could assist in claimimg this fund for further transfer abroad. I have been given the sole mandate to source for a partner as soon as possible to that effect.All documents and proof to enable you get this fund have been carefully worked out and I am assuring you a 100% risk free involvement. Your share would be 30% of the total amount if you agree to assist while 10% would be set aside to offset all expenses in course of the transfer and the rest would be for us for investment purposes in your country. If this proposal is OK by you, and you do wish to take the advantage of the trust we hope to bestow on you and your company, then kindly reach me immediately via e-mail furnishing me with your most confidential telephone and fax numbers and exclusive email so that I can forward to you the relevant details of the transaction. Reply to my confidential email account or send a fax to fax number +23417597019 I expect your urgent response. Regards, Mr Daniel Osondu From felipewd@terra.com.br Tue Oct 22 18:17:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:17:11 -0700 (PDT) Received: from videira.terra.com.br (videira.terra.com.br [200.176.3.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N1GxuR023374 for ; Tue, 22 Oct 2002 18:16:59 -0700 Received: from engenho.terra.com.br (engenho.terra.com.br [200.176.3.42]) by videira.terra.com.br (Postfix) with ESMTP id EE8E1E1B86; Tue, 22 Oct 2002 21:46:11 -0300 (BRT) Received: from tank.coqueiro.org (200-180-162-250-paemt7001.dsl.telebrasilia.net.br [200.180.162.250]) (authenticated user felipewd) by engenho.terra.com.br (Postfix) with ESMTP id 3E781B4135; Tue, 22 Oct 2002 21:46:11 -0300 (BRT) Subject: RE: NIC on 2.4.19 SMP (mii-diag output) From: Felipe W Damasio To: Paul Hernandez Cc: Jeff Garzik , Linux-net , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 22 Oct 2002 21:49:49 +0000 Message-Id: <1035323389.714.33.camel@tank> Mime-Version: 1.0 X-archive-position: 866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipewd@terra.com.br Precedence: bulk X-list: netdev On Mon, 2002-10-21 at 15:16, Paul Hernandez wrote: > I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD > 10baseT > Advertising no additional info pages. > IEEE 802.3 CSMA/CD protocol. > Link partner capability is 0000:. > Negotiation did not complete. The link partner is not advertising it's capabilities. Can you reproduce this bug with 2.4.19 stock? Felipe From hadi@cyberus.ca Tue Oct 22 18:18:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:18:23 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N1ILuR023814 for ; Tue, 22 Oct 2002 18:18:22 -0700 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 VAA23402; Tue, 22 Oct 2002 21:18:26 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N1B1l24663; Tue, 22 Oct 2002 21:11:01 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 21:11:01 -0400 (EDT) From: jamal To: "James R. Leu" cc: Subject: Re: [RFC] Virtual Routing and Forwarding In-Reply-To: <20021021223810.A23086@nero.doit.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev I think you are mucking with too many things. heres some thoughts: - use aliases - tag skbs based on which local aliases they arrived destined to and send them to the right VR - use multi routing table feature already available on linux Of course this is the easy part. Separation of VRs is going to be the challenge (talking about CPU and memory isolation - such that for example gated for VR1 doesnt talk to gated for VR2) cheers, jamal From hadi@cyberus.ca Tue Oct 22 18:26:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:26:02 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N1Q0uR024997 for ; Tue, 22 Oct 2002 18:26:01 -0700 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 VAA25930; Tue, 22 Oct 2002 21:26:05 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N1Iew24677; Tue, 22 Oct 2002 21:18:40 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 21:18:40 -0400 (EDT) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. In-Reply-To: <3DB5F605.1010507@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 868 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, 22 Oct 2002, Ben Greear wrote: > Actually, with the changes the way they are, if you have a backlog value > of 300, and the first NAPI driver reads 300 packets, then all the rest of the > NAPI drivers will just throw away packets because the max-backlog has > already been hit (if I understand things correctly). > The 300 is shared amongst all the drivers which have something on their rx DMA. This is done on a roundrobin fashion. Also all the drivers which are non-napi are given the same quota. > If we make the backlog big enough to handle a large burst of incomming > traffic w/out dropping them, then the first NAPI driver can hog a very > large amount of CPU because its budget is now huge. The rest of > the devices in the poll loop will not be serviced in time, and will > drop packets (I saw this when testing out the 4-port tulip driver with > the NAPI patch). > I think you misunderstood. Look at the dev->weight. cheers, jamal From thockin@www.hockin.org Tue Oct 22 18:44:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 18:44:29 -0700 (PDT) Received: from www.hockin.org (IDENT:root@adsl-64-166-241-227.dsl.snfc21.pacbell.net [64.166.241.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N1iRuR026247 for ; Tue, 22 Oct 2002 18:44:27 -0700 Received: (from thockin@localhost) by www.hockin.org (8.10.2/8.10.2) id g9N1iDx11822; Tue, 22 Oct 2002 18:44:13 -0700 From: Tim Hockin Message-Id: <200210230144.g9N1iDx11822@www.hockin.org> Subject: Re: rtnetlink interface state monitoring problems. To: hadi@cyberus.ca (jamal) Date: Tue, 22 Oct 2002 18:44:13 -0700 (PDT) Cc: dwmw2@infradead.org (David Woodhouse), linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: from "jamal" at Oct 22, 2002 08:59:22 PM 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: 869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thockin@hockin.org Precedence: bulk X-list: netdev > If not, it probably time for someone to write a generic notification > scheme via netlink. How generic? I need to pay some attention to cleaning up the next version of the link-changes via netlink patch that was discussed last week or the week before. What kind of generic are you thinking about? :) From greearb@candelatech.com Tue Oct 22 19:37:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 19:37:08 -0700 (PDT) Received: from grok.yi.org (IDENT:MK2pdS7cyGOiIZxpvAWOeccQk0JPmUwC@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N2b5uR029590 for ; Tue, 22 Oct 2002 19:37:05 -0700 Received: from candelatech.com (IDENT:3lXvIurERER6J/y3yNDUP9MnUDOpe+Qq@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9N2b3q15582; Tue, 22 Oct 2002 19:37:03 -0700 Message-ID: <3DB60B4E.1090004@candelatech.com> Date: Tue, 22 Oct 2002 19:37:02 -0700 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: [PATCH] Break 'budget' dependency on netdev_max_backlog. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 870 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: > I think you misunderstood. Look at the dev->weight. Yep, I was definately confused. I don't see how changing the value as I did could affect anything in a good way, but I definately saw changes in dropped packets...maybe it was too late at night :) So, after further looking at the code, it appears that the dev->weight is basically hard-coded in the tulip driver, and the weight_p value in dev.c (and settable though sysctl) is not used anywhere except netdev_init (ie, not soon enough to actually set via sysctl). Think we should add an IOCTL to change the weight of a device dynamically? (I want my e1000 and tg3 to have higher weight than the tulip nics, I imagine) Is there a ready-built proc interface to do things to individual devices? Thanks, 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 Tue Oct 22 19:48:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 19:48:07 -0700 (PDT) Received: from beohost.scyld.com (pcp723594pcs.arlngt01.va.comcast.net [68.49.195.178]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N2lxuR030515 for ; Tue, 22 Oct 2002 19:48:05 -0700 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id g9N2Kom24292; Tue, 22 Oct 2002 22:21:10 -0400 Date: Tue, 22 Oct 2002 22:20:50 -0400 (EDT) From: Donald Becker To: Felipe W Damasio cc: Paul Hernandez , Jeff Garzik , Linux-net , Subject: RE: NIC on 2.4.19 SMP (mii-diag output) In-Reply-To: <1035323389.714.33.camel@tank> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 871 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 22 Oct 2002, Felipe W Damasio wrote: > On Mon, 2002-10-21 at 15:16, Paul Hernandez wrote: > > I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD > > 10baseT > > Advertising no additional info pages. > > IEEE 802.3 CSMA/CD protocol. > > Link partner capability is 0000:. > > Negotiation did not complete. > > The link partner is not advertising it's capabilities. No! There is not link partner. 0000 is the default value for the register when there is no negotiation going on. If you have link beat _and_ the register is 0000, then no autonegotiation took place. If the link partner advertised "not capable of anything", the register will report 0001. -- 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 hadi@cyberus.ca Tue Oct 22 20:24:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 20:24:37 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N3OZuR003225 for ; Tue, 22 Oct 2002 20:24:35 -0700 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 XAA29622; Tue, 22 Oct 2002 23:24:40 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N3HD524899; Tue, 22 Oct 2002 23:17:14 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 23:17:13 -0400 (EDT) From: jamal To: Tim Hockin cc: David Woodhouse , , Subject: Re: rtnetlink interface state monitoring problems. In-Reply-To: <200210230144.g9N1iDx11822@www.hockin.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 872 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, 22 Oct 2002, Tim Hockin wrote: > > If not, it probably time for someone to write a generic notification > > scheme via netlink. > > How generic? I need to pay some attention to cleaning up the next version > of the link-changes via netlink patch that was discussed last week or the > week before. The patch posted by Stefan seems good to me and ready to merge. > > What kind of generic are you thinking about? :) > netlink is a messaging system; so what i am thinking is creating a event notifier for other devices other than network devices. Something other non-network devices could use (eg bluetooth). Given that netlink packetizes the data, this facilitates a distributed control type of environment. cheers, jamal From hadi@cyberus.ca Tue Oct 22 20:28:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 20:28:30 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N3SSuR004064 for ; Tue, 22 Oct 2002 20:28:29 -0700 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 XAA00524; Tue, 22 Oct 2002 23:28:34 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N3L8924913; Tue, 22 Oct 2002 23:21:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 23:21:08 -0400 (EDT) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. In-Reply-To: <3DB60B4E.1090004@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 873 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, 22 Oct 2002, Ben Greear wrote: > Think we should add an IOCTL to change the weight of a device > dynamically? (I want my e1000 and tg3 to have higher weight than > the tulip nics, I imagine) > > Is there a ready-built proc interface to do things to individual devices? > tulip hardcodes it; net/core/dev.c::weight_p is supposed to be the general one and is proc settable via NET_CORE_DEV_WEIGHT; only problem is that is not shadowed by the devices. I am not sure if ioctls or module parameters are the best way to override the default weight_p value. Somehow we need something to set this value. cheers, jamal From greearb@candelatech.com Tue Oct 22 20:43:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 20:43:07 -0700 (PDT) Received: from grok.yi.org (IDENT:k+uxYbE0R0liP5zFAZufI41Tq5nS4sy9@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N3h4uR005630 for ; Tue, 22 Oct 2002 20:43:05 -0700 Received: from candelatech.com (IDENT:vD3dxUsDYkCaXtsSyEZwJLtl0EYtnIn2@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9N3h0q30291; Tue, 22 Oct 2002 20:43:00 -0700 Message-ID: <3DB61AC4.4070907@candelatech.com> Date: Tue, 22 Oct 2002 20:43:00 -0700 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: [PATCH] Break 'budget' dependency on netdev_max_backlog. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 874 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 Tue, 22 Oct 2002, Ben Greear wrote: > > >>Think we should add an IOCTL to change the weight of a device >>dynamically? (I want my e1000 and tg3 to have higher weight than >>the tulip nics, I imagine) >> >>Is there a ready-built proc interface to do things to individual devices? >> > > > tulip hardcodes it; net/core/dev.c::weight_p is supposed to be the general > one and is proc settable via NET_CORE_DEV_WEIGHT; only problem is that > is not shadowed by the devices. > I am not sure if ioctls or module parameters are the best way to override > the default weight_p value. Somehow we need something to set this value. No reason not to provide both! The IOCTL can take care of any drivers that don't take module parameters for it, and can do it in a generic way. The tulip driver I am poking at hard-coded it to 16. 64 seems to work just as good. Any idea (other than trial and error) for how to determine a good value for this? Maybe should take the number of active devices into account and wiggle things dynamically from user-space? Ben > > cheers, > jamal > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From master@inmoney.net Tue Oct 22 20:47:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 20:47:32 -0700 (PDT) Received: from admin ([211.195.136.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N3lGuR006635 for ; Tue, 22 Oct 2002 20:47:27 -0700 Message-Id: <200210230347.g9N3lGuR006635@oss.sgi.com> From: To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=B4=EB=C3=E2,=20=C4=AB=B5=E5=C1=F5=BE=D7?= =?ISO-8859-1?Q?=C8=AE=BD=C7=C7=D1=20=BA=F1=B9=FD?= Date: Tue, 23 Oct 2001 12:44:16 +0900 Mime-Version: 1.0 Content-Type: text/html; charset="euc-kr" X-archive-position: 875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@inmoney.net Precedence: bulk X-list: netdev
50 [] .
.
From hadi@cyberus.ca Tue Oct 22 20:51:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 20:51:58 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N3puuR007275 for ; Tue, 22 Oct 2002 20:51:56 -0700 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 XAA05684; Tue, 22 Oct 2002 23:52:01 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N3iZG24954; Tue, 22 Oct 2002 23:44:35 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 23:44:35 -0400 (EDT) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. In-Reply-To: <3DB61AC4.4070907@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 876 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, 22 Oct 2002, Ben Greear wrote: > No reason not to provide both! The IOCTL can take care of any drivers > that don't take module parameters for it, and can do it in a generic > way. sure maybe via the ethertool or whatever tool that is being used would be a good start. The default should still be weight_p. > > The tulip driver I am poking at hard-coded it to 16. 64 seems to work > just as good. > > Any idea (other than trial and error) for how to determine a good value > for this? Maybe should take the number of active devices into account > and wiggle things dynamically from user-space? > What i recall is 64 was a good number and thats why we had it as default. I cant remember who changed the value to 16(Robert?), but it does seem to be a good value as well. If that was the only driver and it had a lot of packets, it would still get to use all the 300 packets in the budget; it will just have to do it in 300/16 times .. cheers, jamal From greearb@candelatech.com Tue Oct 22 21:00:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 21:00:58 -0700 (PDT) Received: from grok.yi.org (IDENT:q1d8aiYhViIRJ64tYDKkM9J44TjrXnvi@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N40tuR008574 for ; Tue, 22 Oct 2002 21:00:56 -0700 Received: from candelatech.com (IDENT:d3VoUShsm8q8O4XxQ0zzNPv4bo/fZSlk@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9N40xq04273; Tue, 22 Oct 2002 21:00:59 -0700 Message-ID: <3DB61EFB.4020401@candelatech.com> Date: Tue, 22 Oct 2002 21:00:59 -0700 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: [PATCH] Break 'budget' dependency on netdev_max_backlog. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 877 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: > What i recall is 64 was a good number and thats why we had it as default. > I cant remember who changed the value to 16(Robert?), but it does seem to > be a good value as well. If that was the only driver and it had a lot of > packets, it would still get to use all the 300 packets in the budget; it > will just have to do it in 300/16 times .. Is there any way to influence how often the poll loop gets run? I'll have a patch to set the weight via IOCTL soon.... Thanks, 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 Tue Oct 22 21:05:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 21:05:52 -0700 (PDT) Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N45ouR009599 for ; Tue, 22 Oct 2002 21:05:50 -0700 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 AAA09438; Wed, 23 Oct 2002 00:05:56 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9N3wT424984; Tue, 22 Oct 2002 23:58:29 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Tue, 22 Oct 2002 23:58:27 -0400 (EDT) From: jamal To: Ben Greear cc: "'netdev@oss.sgi.com'" Subject: Re: [PATCH] Break 'budget' dependency on netdev_max_backlog. In-Reply-To: <3DB61EFB.4020401@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 878 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, 22 Oct 2002, Ben Greear wrote: > Is there any way to influence how often the poll loop gets run? the softirq is scheduled like others. You could play with niceness of ksoftirqd, however note that you may starve user space etc. You could also increase that backlog queue, but you will be preempted if that softirq runs for too long. cheers, jamal From webmaster@semiperfume.com Tue Oct 22 23:08:34 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 22 Oct 2002 23:08:36 -0700 (PDT) Received: from oss.sgi.com ([211.179.124.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N68SuR019522 for netdev@oss.sgi.com; Tue, 22 Oct 2002 23:08:33 -0700 Date: Tue, 22 Oct 2002 23:08:28 -0700 Message-Id: <200210230608.g9N68SuR019522@oss.sgi.com> To: From: Subject: =?ISO-8859-1?Q?[=B1=A4=B0=ED]=B0=A1=C0=BB,=B3=AB=BF=B1?= =?ISO-8859-1?Q?=B1=D7=B8=AE=B0=ED=20=C7=E2=BC=F6?= Content-Type: text/html;charset=ks_c_5601-1987 X-archive-position: 879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: webmaster@semiperfume.com Precedence: bulk X-list: netdev Imitation Perfume World - Semi




From yoshfuji@linux-ipv6.org Wed Oct 23 00:24:45 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 00:24:47 -0700 (PDT) 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 g9N7OhuR025469 for ; Wed, 23 Oct 2002 00:24:44 -0700 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 g9N7OeHT003343; Wed, 23 Oct 2002 16:24:42 +0900 Date: Wed, 23 Oct 2002 16:24:39 +0900 (JST) Message-Id: <20021023.162439.114324450.yoshfuji@linux-ipv6.org> To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200210031552.TAA29921@sex.inr.ac.ru> References: <20021004.001929.03389091.yoshfuji@linux-ipv6.org> <200210031552.TAA29921@sex.inr.ac.ru> 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-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: 880 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 <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > Actually, it would be great if you said what is wrong in that my patch? > It looks so simple that I am not ready to agree that real one should be > so complicated. :-) Well, I've refered alexey's patch and simplified many if-clauses. Here's the new patch and test results. seems ok. -------------------- Linux IPv6 stack provides the ability for IPv6 applications to interoperate with IPv4 applications. Port space for TCP (or UDP) is shared by IPv6 and IPv4. This conforms to RFC2553. However, some kind of applications may want to restrict their use of an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is defined for such applications in RFC2553bis, which is successor of RFC2553. This patch allows to bind both IPv6 and IPv4 sockets with the single port number at the same time if IPV6_V6ONLY socket options is set to the IPv6 socket. Packet delivery strategy is similar to one before, but we prefer IPv4 a bit. Test results and patch against 2.4.20-pre11 follows. *** Test for bind(2) *** [SOCK_DGRAM w/o IPV6_V6ONLY] 0 :: 127.1 ::1 0 x x x x :: x x x x 127.1 x x x o ::1 x x o x ==> OK [SOCK_DGRAM w/ IPV6_V6ONLY] 0 :: 127.1 ::1 0 x o x o :: o x o x 127.1 x o x o ::1 o x o x ==> OK [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] 0 :: 127.1 ::1 0 o o o o :: o o o o 127.1 o o o o ::1 o o o o ==> OK [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY] 0 :: 127.1 ::1 0 o o o o :: o o o o 127.1 o o o o ::1 o o o o ==> OK [SOCK_STREAM w/o IPV6_V6ONLY] 0 :: 127.1 ::1 0 x x x x :: x x x x 127.1 x x x o ::1 x x o x ==> OK [SOCK_STREAM w/ IPV6_V6ONLY] 0 :: 127.1 ::1 0 x o x o :: o x o x 127.1 x o x o ::1 o x o x ==> OK [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] 0 :: 127.1 ::1 0 o o o o :: o o o o 127.1 o o o o ::1 o o o o ==> OK [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY] 0 :: 127.1 ::1 0 o o o o :: o o o o 127.1 o o o o ::1 o o o o ==> OK *** Test for Receiver *** [IPv6] 1a. :: <- ::1 received from ::1 1b. :: w/IPV6_V6ONLY <- ::1 received from ::1 2a. :: <- 127.0.0.1 received from ::1 2b. :: w/IPV6_V6ONLY <- 127.0.0.1 none received 3a. :: <- ff02::1 received from fe80::EUI64 3b. :: w/IPV6_V6ONLY <- ff02::1 received from fe80::EUI64 4a. :: <- 224.0.0.1 received from ::ffff:ipv4addr 4b. :: w/IPV6_V6ONLY <- 224.0.0.1 none received ==> OK [IPv4] 1. 0.0.0.0 <- ::1 none received 2. 0.0.0.0 <- 127.0.0.1 received from 127.0.0.1 3. 0.0.0.0 <- ff02::1 none received 4. 0.0.0.0 <- 224.0.0.1 received from ipv4addr ==> OK [IPv6 vs IPv4] 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1 ipv6 received from ::1 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1 ipv4 received from 127.0.0.1 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1 ipv6 received from fe80::EUI64 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1 ipv4 received from ipv4addra ==> OK ------------------------------------------------------------------- Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) - Rev.2 Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project Reference: RFC2553bis ------------------------------------------------------------------- Index: Documentation/networking/ip-sysctl.txt =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.42.1 diff -u -r1.1.1.1 -r1.1.1.1.42.1 --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 1.1.1.1 +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 1.1.1.1.42.1 @@ -462,6 +462,15 @@ IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ also apply to IPv6 [XXX?]. +bindv6only - BOOLEAN + Default value for IPV6_V6ONLY socket option, + which restricts use of the IPv6 socket to IPv6 communication + only. + TRUE: disable IPv4-mapped address feature + FALSE: enable IPv4-mapped address feature + + Default: FALSE (as specified in RFC2553bis) + conf/default/*: Change the interface-specific default settings. Index: include/linux/in6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.40.1 diff -u -r1.1.1.1 -r1.1.1.1.40.1 --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1 +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 @@ -156,6 +156,7 @@ #define IPV6_MTU_DISCOVER 23 #define IPV6_MTU 24 #define IPV6_RECVERR 25 +#define IPV6_V6ONLY 26 /* IPV6_MTU_DISCOVER values */ #define IPV6_PMTUDISC_DONT 0 Index: include/linux/sysctl.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2 -r1.1.1.2.16.1 --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 @@ -345,7 +345,8 @@ enum { NET_IPV6_CONF=16, NET_IPV6_NEIGH=17, - NET_IPV6_ROUTE=18 + NET_IPV6_ROUTE=18, + NET_IPV6_BINDV6ONLY=20, }; enum { Index: include/net/ipv6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.38.1 diff -u -r1.1.1.1 -r1.1.1.1.38.1 --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1 @@ -88,6 +88,9 @@ #include +/* sysctls */ +extern int sysctl_ipv6_bindv6only; + extern struct ipv6_mib ipv6_statistics[NR_CPUS*2]; #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field) #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field) Index: include/net/sock.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.40.1 diff -u -r1.1.1.1 -r1.1.1.1.40.1 --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 @@ -171,7 +171,8 @@ __u8 mc_loop:1, recverr:1, sndflow:1, - pmtudisc:2; + pmtudisc:2, + ipv6only:1; struct ipv6_mc_socklist *ipv6_mc_list; struct ipv6_fl_socklist *ipv6_fl_list; @@ -188,6 +189,12 @@ struct icmp6_filter filter; }; +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only) +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \ + (sk)->net_pinfo.af_inet6.ipv6only) +#else +#define __ipv6_only_sock(sk) 0 +#define ipv6_only_sock(sk) 0 #endif /* IPV6 */ #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE) Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.16.2 diff -u -r1.1.1.2 -r1.1.1.2.16.2 --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2 +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 @@ -45,9 +45,13 @@ * Vitaly E. Lavrov : Transparent proxy revived after year coma. * Andi Kleen : Fix new listen. * Andi Kleen : Fix accept error reporting. + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which + * allow both IPv4 and IPv6 sockets to bind + * a single port at the same time. */ #include + #include #include #include @@ -182,6 +186,7 @@ for( ; sk2 != NULL; sk2 = sk2->bind_next) { if (sk != sk2 && sk2->reuse <= 1 && + !ipv6_only_sock(sk2) && sk->bound_dev_if == sk2->bound_dev_if) { if (!sk_reuse || !sk2->reuse || @@ -418,23 +423,27 @@ struct sock *result = NULL; int score, hiscore; - hiscore=0; + hiscore=-1; for(; sk; sk = sk->next) { - if(sk->num == hnum) { + if(sk->num == hnum && !ipv6_only_sock(sk)) { __u32 rcv_saddr = sk->rcv_saddr; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + score = sk->family == PF_INET ? 1 : 0; +#else score = 1; +#endif if(rcv_saddr) { if (rcv_saddr != daddr) continue; - score++; + score+=2; } if (sk->bound_dev_if) { if (sk->bound_dev_if != dif) continue; - score++; + score+=2; } - if (score == 3) + if (score == 5) return sk; if (score > hiscore) { hiscore = score; @@ -456,6 +465,7 @@ if (sk->num == hnum && sk->next == NULL && (!sk->rcv_saddr || sk->rcv_saddr == daddr) && + (sk->family == PF_INET || !ipv6_only_sock(sk)) && !sk->bound_dev_if) goto sherry_cache; sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); Index: net/ipv4/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.40.1 diff -u -r1.1.1.1 -r1.1.1.1.40.1 --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 @@ -61,6 +61,9 @@ * return ENOTCONN for unconnected sockets (POSIX) * Janos Farkas : don't deliver multi/broadcasts to a different * bound-to-device socket + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which + * allow both IPv4 and IPv6 sockets to bind + * a single port at the same time. * * * This program is free software; you can redistribute it and/or @@ -85,6 +88,7 @@ #include #include #include +#include #include #include #include @@ -159,6 +163,7 @@ sk2 = sk2->next) { if (sk2->num == snum && sk2 != sk && + !ipv6_only_sock(sk2) && sk2->bound_dev_if == sk->bound_dev_if && (!sk2->rcv_saddr || !sk->rcv_saddr || @@ -215,29 +220,34 @@ int badness = -1; for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { - if(sk->num == hnum) { - int score = 0; + if(sk->num == hnum && !ipv6_only_sock(sk)) { + int score; +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) + score = sk->family == PF_INET ? 1 : 0; +#else + score = 1; +#endif if(sk->rcv_saddr) { if(sk->rcv_saddr != daddr) continue; - score++; + score+=2; } if(sk->daddr) { if(sk->daddr != saddr) continue; - score++; + score+=2; } if(sk->dport) { if(sk->dport != sport) continue; - score++; + score+=2; } if(sk->bound_dev_if) { if(sk->bound_dev_if != dif) continue; - score++; + score+=2; } - if(score == 4) { + if(score == 9) { result = sk; break; } else if(score > badness) { @@ -273,6 +283,7 @@ (s->daddr && s->daddr!=rmt_addr) || (s->dport != rmt_port && s->dport != 0) || (s->rcv_saddr && s->rcv_saddr != loc_addr) || + ipv6_only_sock(s) || (s->bound_dev_if && s->bound_dev_if != dif)) continue; break; Index: net/ipv6/af_inet6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.36.1 diff -u -r1.1.1.1 -r1.1.1.1.36.1 --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 @@ -88,6 +88,8 @@ extern void ipv6_sysctl_unregister(void); #endif +int sysctl_ipv6_bindv6only; + #ifdef INET_REFCNT_DEBUG atomic_t inet6_sock_nr; #endif @@ -173,6 +175,8 @@ sk->net_pinfo.af_inet6.mc_loop = 1; sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only; + /* Init the ipv4 part of the socket since we can have sockets * using v6 API for ipv4. */ Index: net/ipv6/ipv6_sockglue.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.36.1 diff -u -r1.1.1.1 -r1.1.1.1.36.1 --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 @@ -157,7 +157,8 @@ break; } - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { + if (ipv6_only_sock(sk) || + !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { retv = -EADDRNOTAVAIL; break; } @@ -203,6 +204,13 @@ } goto e_inval; + case IPV6_V6ONLY: + if (sk->num) + goto e_inval; + np->ipv6only = valbool; + retv = 0; + break; + case IPV6_PKTINFO: np->rxopt.bits.rxinfo = valbool; retv = 0; @@ -465,6 +473,10 @@ return -ENOTCONN; break; } + + case IPV6_V6ONLY: + val = np->ipv6only; + break; case IPV6_PKTINFO: val = np->rxopt.bits.rxinfo; Index: net/ipv6/sysctl_net_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.40.1 diff -u -r1.1.1.1 -r1.1.1.1.40.1 --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 @@ -17,6 +17,8 @@ ctl_table ipv6_table[] = { {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, + {NET_IPV6_BINDV6ONLY, "bindv6only", + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, {0} }; Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2 -r1.1.1.2.16.1 --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 @@ -14,6 +14,9 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which + * allow both IPv4 and IPv6 sockets to bind + * a single port at the same time. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -148,14 +151,23 @@ !sk2->reuse || sk2->state == TCP_LISTEN) { /* NOTE: IPv6 tw bucket have different format */ - if (!sk2->rcv_saddr || - addr_type == IPV6_ADDR_ANY || - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, - sk2->state != TCP_TIME_WAIT ? - &sk2->net_pinfo.af_inet6.rcv_saddr : - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && - sk->rcv_saddr==sk2->rcv_saddr)) + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || + (sk2->family == AF_INET6 && + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || + (addr_type == IPV6_ADDR_ANY && + (!ipv6_only_sock(sk) || + !(sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED : 1))) || + (sk2->family == AF_INET6 && + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, + sk2->state != TCP_TIME_WAIT ? + &sk2->net_pinfo.af_inet6.rcv_saddr : + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) || + (addr_type == IPV6_ADDR_MAPPED && + !ipv6_only_sock(sk2) && + (!sk2->rcv_saddr || + !sk->rcv_saddr || + sk->rcv_saddr == sk2->rcv_saddr))) break; } } @@ -601,6 +613,9 @@ struct sockaddr_in sin; SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); + + if (__ipv6_only_sock(sk)) + return -ENETUNREACH; sin.sin_family = AF_INET; sin.sin_port = usin->sin6_port; Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2 -r1.1.1.2.16.1 --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 @@ -11,6 +11,9 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which + * allow both IPv4 and IPv6 sockets to bind + * a single port at the same time. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -106,13 +109,21 @@ if (sk2->num == snum && sk2 != sk && sk2->bound_dev_if == sk->bound_dev_if && - (!sk2->rcv_saddr || - addr_type == IPV6_ADDR_ANY || - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, - &sk2->net_pinfo.af_inet6.rcv_saddr) || + ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || + (sk2->family == AF_INET6 && + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || + (addr_type == IPV6_ADDR_ANY && + (!ipv6_only_sock(sk) || + !(sk2->family == AF_INET6 ? (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) : 1))) || + (sk2->family == AF_INET6 && + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, + &sk2->net_pinfo.af_inet6.rcv_saddr)) || (addr_type == IPV6_ADDR_MAPPED && - sk2->family == AF_INET && - sk->rcv_saddr == sk2->rcv_saddr)) && + !ipv6_only_sock(sk2) && + (!sk2->rcv_saddr || + !sk->rcv_saddr || + sk->rcv_saddr == sk2->rcv_saddr))) && (!sk2->reuse || !sk->reuse)) goto fail; } @@ -221,6 +232,8 @@ int err; if (usin->sin6_family == AF_INET) { + if (__ipv6_only_sock(sk)) + return -EAFNOSUPPORT; err = udp_connect(sk, uaddr, addr_len); goto ipv4_connected; } @@ -256,6 +269,9 @@ if (addr_type == IPV6_ADDR_MAPPED) { struct sockaddr_in sin; + if (__ipv6_only_sock(sk)) + return -ENETUNREACH; + sin.sin_family = AF_INET; sin.sin_addr.s_addr = daddr->s6_addr32[3]; sin.sin_port = usin->sin6_port; @@ -783,8 +799,11 @@ fl.oif = 0; if (sin6) { - if (sin6->sin6_family == AF_INET) + if (sin6->sin6_family == AF_INET) { + if (__ipv6_only_sock(sk)) + return -ENETUNREACH; return udp_sendmsg(sk, msg, ulen); + } if (addr_len < SIN6_LEN_RFC2133) return -EINVAL; @@ -830,6 +849,9 @@ if (addr_type == IPV6_ADDR_MAPPED) { struct sockaddr_in sin; + + if (__ipv6_only_sock(sk)) + return -ENETUNREACH; sin.sin_family = AF_INET; sin.sin_addr.s_addr = daddr->s6_addr32[3]; From davem@redhat.com Wed Oct 23 00:31:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 00:32:00 -0700 (PDT) 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 g9N7VwuR026199 for ; Wed, 23 Oct 2002 00:31:58 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id AAA12843; Wed, 23 Oct 2002 00:23:04 -0700 Date: Wed, 23 Oct 2002 00:23:03 -0700 (PDT) Message-Id: <20021023.002303.67097780.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: "David S. Miller" In-Reply-To: <20021023.162439.114324450.yoshfuji@linux-ipv6.org> References: <20021004.001929.03389091.yoshfuji@linux-ipv6.org> <200210031552.TAA29921@sex.inr.ac.ru> <20021023.162439.114324450.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: 881 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 / 吉藤英明 Date: Wed, 23 Oct 2002 16:24:39 +0900 (JST) Well, I've refered alexey's patch and simplified many if-clauses. Here's the new patch and test results. seems ok. So, because you simplified some if clauses in Alexey's patch, USAGI is the only entity who deserves credit for the work in the comments? That's dishonest. Please fix this. From pekkas@netcore.fi Wed Oct 23 00:36:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 00:36:38 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N7aXuR026748 for ; Wed, 23 Oct 2002 00:36:34 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9N7aJN26924; Wed, 23 Oct 2002 10:36:19 +0300 Date: Wed, 23 Oct 2002 10:36:19 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: kuznet@ms2.inr.ac.ru, , , Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) In-Reply-To: <20021023.162439.114324450.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 882 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 Overview looks good. Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is also enabled, from IPv4 addresses using TCP without 'match-mapped-addresses yes', or is that a separate problem? (with IPV6_V6ONLY if supported that would work all right.) On Wed, 23 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > Actually, it would be great if you said what is wrong in that my patch? > > It looks so simple that I am not ready to agree that real one should be > > so complicated. :-) > > Well, I've refered alexey's patch and simplified many if-clauses. > Here's the new patch and test results. seems ok. > > -------------------- > Linux IPv6 stack provides the ability for IPv6 applications to > interoperate with IPv4 applications. Port space for TCP (or UDP) is > shared by IPv6 and IPv4. This conforms to RFC2553. > However, some kind of applications may want to restrict their use of > an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is > defined for such applications in RFC2553bis, which is successor of RFC2553. > This patch allows to bind both IPv6 and IPv4 sockets with the single > port number at the same time if IPV6_V6ONLY socket options is set to > the IPv6 socket. > > Packet delivery strategy is similar to one before, but we prefer > IPv4 a bit. > > Test results and patch against 2.4.20-pre11 follows. > > *** Test for bind(2) *** > > [SOCK_DGRAM w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x x x x > :: x x x x > 127.1 x x x o > ::1 x x o x > > ==> OK > > [SOCK_DGRAM w/ IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x o x o > :: o x o x > 127.1 x o x o > ::1 o x o x > > ==> OK > > [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_STREAM w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x x x x > :: x x x x > 127.1 x x x o > ::1 x x o x > > ==> OK > > [SOCK_STREAM w/ IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x o x o > :: o x o x > 127.1 x o x o > ::1 o x o x > > ==> OK > > [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > *** Test for Receiver *** > > [IPv6] > 1a. :: <- ::1 > received from ::1 > > 1b. :: w/IPV6_V6ONLY <- ::1 > received from ::1 > > 2a. :: <- 127.0.0.1 > received from ::1 > > 2b. :: w/IPV6_V6ONLY <- 127.0.0.1 > none received > > 3a. :: <- ff02::1 > received from fe80::EUI64 > > 3b. :: w/IPV6_V6ONLY <- ff02::1 > received from fe80::EUI64 > > 4a. :: <- 224.0.0.1 > received from ::ffff:ipv4addr > > 4b. :: w/IPV6_V6ONLY <- 224.0.0.1 > none received > > ==> OK > > [IPv4] > 1. 0.0.0.0 <- ::1 > none received > > 2. 0.0.0.0 <- 127.0.0.1 > received from 127.0.0.1 > > 3. 0.0.0.0 <- ff02::1 > none received > > 4. 0.0.0.0 <- 224.0.0.1 > received from ipv4addr > > ==> OK > > [IPv6 vs IPv4] > 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1 > ipv6 received from ::1 > > 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1 > ipv4 received from 127.0.0.1 > > 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1 > ipv6 received from fe80::EUI64 > > 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1 > ipv4 received from ipv4addra > > ==> OK > > ------------------------------------------------------------------- > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) - Rev.2 > Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023 > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > Credit: YOSHIFUJI Hideaki / USAGI Project > Reference: RFC2553bis > ------------------------------------------------------------------- > Index: Documentation/networking/ip-sysctl.txt > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.42.1 > diff -u -r1.1.1.1 -r1.1.1.1.42.1 > --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 1.1.1.1 > +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 1.1.1.1.42.1 > @@ -462,6 +462,15 @@ > IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ also > apply to IPv6 [XXX?]. > > +bindv6only - BOOLEAN > + Default value for IPV6_V6ONLY socket option, > + which restricts use of the IPv6 socket to IPv6 communication > + only. > + TRUE: disable IPv4-mapped address feature > + FALSE: enable IPv4-mapped address feature > + > + Default: FALSE (as specified in RFC2553bis) > + > conf/default/*: > Change the interface-specific default settings. > > Index: include/linux/in6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1 > +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -156,6 +156,7 @@ > #define IPV6_MTU_DISCOVER 23 > #define IPV6_MTU 24 > #define IPV6_RECVERR 25 > +#define IPV6_V6ONLY 26 > > /* IPV6_MTU_DISCOVER values */ > #define IPV6_PMTUDISC_DONT 0 > Index: include/linux/sysctl.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 > +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -345,7 +345,8 @@ > enum { > NET_IPV6_CONF=16, > NET_IPV6_NEIGH=17, > - NET_IPV6_ROUTE=18 > + NET_IPV6_ROUTE=18, > + NET_IPV6_BINDV6ONLY=20, > }; > > enum { > Index: include/net/ipv6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.38.1 > diff -u -r1.1.1.1 -r1.1.1.1.38.1 > --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1 > @@ -88,6 +88,9 @@ > > #include > > +/* sysctls */ > +extern int sysctl_ipv6_bindv6only; > + > extern struct ipv6_mib ipv6_statistics[NR_CPUS*2]; > #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field) > #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field) > Index: include/net/sock.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -171,7 +171,8 @@ > __u8 mc_loop:1, > recverr:1, > sndflow:1, > - pmtudisc:2; > + pmtudisc:2, > + ipv6only:1; > > struct ipv6_mc_socklist *ipv6_mc_list; > struct ipv6_fl_socklist *ipv6_fl_list; > @@ -188,6 +189,12 @@ > struct icmp6_filter filter; > }; > > +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only) > +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \ > + (sk)->net_pinfo.af_inet6.ipv6only) > +#else > +#define __ipv6_only_sock(sk) 0 > +#define ipv6_only_sock(sk) 0 > #endif /* IPV6 */ > > #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE) > Index: net/ipv4/tcp_ipv4.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.2 > diff -u -r1.1.1.2 -r1.1.1.2.16.2 > --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2 > +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 > @@ -45,9 +45,13 @@ > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > * Andi Kleen : Fix new listen. > * Andi Kleen : Fix accept error reporting. > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > */ > > #include > + > #include > #include > #include > @@ -182,6 +186,7 @@ > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > if (sk != sk2 && > sk2->reuse <= 1 && > + !ipv6_only_sock(sk2) && > sk->bound_dev_if == sk2->bound_dev_if) { > if (!sk_reuse || > !sk2->reuse || > @@ -418,23 +423,27 @@ > struct sock *result = NULL; > int score, hiscore; > > - hiscore=0; > + hiscore=-1; > for(; sk; sk = sk->next) { > - if(sk->num == hnum) { > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > __u32 rcv_saddr = sk->rcv_saddr; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = sk->family == PF_INET ? 1 : 0; > +#else > score = 1; > +#endif > if(rcv_saddr) { > if (rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if (sk->bound_dev_if) { > if (sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if (score == 3) > + if (score == 5) > return sk; > if (score > hiscore) { > hiscore = score; > @@ -456,6 +465,7 @@ > if (sk->num == hnum && > sk->next == NULL && > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > + (sk->family == PF_INET || !ipv6_only_sock(sk)) && > !sk->bound_dev_if) > goto sherry_cache; > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > Index: net/ipv4/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -61,6 +61,9 @@ > * return ENOTCONN for unconnected sockets (POSIX) > * Janos Farkas : don't deliver multi/broadcasts to a different > * bound-to-device socket > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * > * This program is free software; you can redistribute it and/or > @@ -85,6 +88,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -159,6 +163,7 @@ > sk2 = sk2->next) { > if (sk2->num == snum && > sk2 != sk && > + !ipv6_only_sock(sk2) && > sk2->bound_dev_if == sk->bound_dev_if && > (!sk2->rcv_saddr || > !sk->rcv_saddr || > @@ -215,29 +220,34 @@ > int badness = -1; > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { > - if(sk->num == hnum) { > - int score = 0; > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > + int score; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = sk->family == PF_INET ? 1 : 0; > +#else > + score = 1; > +#endif > if(sk->rcv_saddr) { > if(sk->rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if(sk->daddr) { > if(sk->daddr != saddr) > continue; > - score++; > + score+=2; > } > if(sk->dport) { > if(sk->dport != sport) > continue; > - score++; > + score+=2; > } > if(sk->bound_dev_if) { > if(sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if(score == 4) { > + if(score == 9) { > result = sk; > break; > } else if(score > badness) { > @@ -273,6 +283,7 @@ > (s->daddr && s->daddr!=rmt_addr) || > (s->dport != rmt_port && s->dport != 0) || > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > + ipv6_only_sock(s) || > (s->bound_dev_if && s->bound_dev_if != dif)) > continue; > break; > Index: net/ipv6/af_inet6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.36.1 > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > @@ -88,6 +88,8 @@ > extern void ipv6_sysctl_unregister(void); > #endif > > +int sysctl_ipv6_bindv6only; > + > #ifdef INET_REFCNT_DEBUG > atomic_t inet6_sock_nr; > #endif > @@ -173,6 +175,8 @@ > sk->net_pinfo.af_inet6.mc_loop = 1; > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only; > + > /* Init the ipv4 part of the socket since we can have sockets > * using v6 API for ipv4. > */ > Index: net/ipv6/ipv6_sockglue.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.36.1 > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > @@ -157,7 +157,8 @@ > break; > } > > - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > + if (ipv6_only_sock(sk) || > + !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > retv = -EADDRNOTAVAIL; > break; > } > @@ -203,6 +204,13 @@ > } > goto e_inval; > > + case IPV6_V6ONLY: > + if (sk->num) > + goto e_inval; > + np->ipv6only = valbool; > + retv = 0; > + break; > + > case IPV6_PKTINFO: > np->rxopt.bits.rxinfo = valbool; > retv = 0; > @@ -465,6 +473,10 @@ > return -ENOTCONN; > break; > } > + > + case IPV6_V6ONLY: > + val = np->ipv6only; > + break; > > case IPV6_PKTINFO: > val = np->rxopt.bits.rxinfo; > Index: net/ipv6/sysctl_net_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -17,6 +17,8 @@ > > ctl_table ipv6_table[] = { > {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, > + {NET_IPV6_BINDV6ONLY, "bindv6only", > + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, > {0} > }; > > Index: net/ipv6/tcp_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -14,6 +14,9 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -148,14 +151,23 @@ > !sk2->reuse || > sk2->state == TCP_LISTEN) { > /* NOTE: IPv6 tw bucket have different format */ > - if (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - sk2->state != TCP_TIME_WAIT ? > - &sk2->net_pinfo.af_inet6.rcv_saddr : > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > - sk->rcv_saddr==sk2->rcv_saddr)) > + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > + (sk2->family == AF_INET6 && > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > + (addr_type == IPV6_ADDR_ANY && > + (!ipv6_only_sock(sk) || > + !(sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED : 1))) || > + (sk2->family == AF_INET6 && > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > + sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) || > + (addr_type == IPV6_ADDR_MAPPED && > + !ipv6_only_sock(sk2) && > + (!sk2->rcv_saddr || > + !sk->rcv_saddr || > + sk->rcv_saddr == sk2->rcv_saddr))) > break; > } > } > @@ -601,6 +613,9 @@ > struct sockaddr_in sin; > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > + > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_port = usin->sin6_port; > Index: net/ipv6/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -11,6 +11,9 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -106,13 +109,21 @@ > if (sk2->num == snum && > sk2 != sk && > sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > + ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > + (sk2->family == AF_INET6 && > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > + (addr_type == IPV6_ADDR_ANY && > + (!ipv6_only_sock(sk) || > + !(sk2->family == AF_INET6 ? (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) : 1))) || > + (sk2->family == AF_INET6 && > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > + &sk2->net_pinfo.af_inet6.rcv_saddr)) || > (addr_type == IPV6_ADDR_MAPPED && > - sk2->family == AF_INET && > - sk->rcv_saddr == sk2->rcv_saddr)) && > + !ipv6_only_sock(sk2) && > + (!sk2->rcv_saddr || > + !sk->rcv_saddr || > + sk->rcv_saddr == sk2->rcv_saddr))) && > (!sk2->reuse || !sk->reuse)) > goto fail; > } > @@ -221,6 +232,8 @@ > int err; > > if (usin->sin6_family == AF_INET) { > + if (__ipv6_only_sock(sk)) > + return -EAFNOSUPPORT; > err = udp_connect(sk, uaddr, addr_len); > goto ipv4_connected; > } > @@ -256,6 +269,9 @@ > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > + > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > sin.sin_port = usin->sin6_port; > @@ -783,8 +799,11 @@ > fl.oif = 0; > > if (sin6) { > - if (sin6->sin6_family == AF_INET) > + if (sin6->sin6_family == AF_INET) { > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > return udp_sendmsg(sk, msg, ulen); > + } > > if (addr_len < SIN6_LEN_RFC2133) > return -EINVAL; > @@ -830,6 +849,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > + > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From yoshfuji@linux-ipv6.org Wed Oct 23 00:58:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 00:58:33 -0700 (PDT) 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 g9N7wUuR027574 for ; Wed, 23 Oct 2002 00:58:31 -0700 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 g9N7wXHT003531; Wed, 23 Oct 2002 16:58:40 +0900 Date: Wed, 23 Oct 2002 16:58:32 +0900 (JST) Message-Id: <20021023.165832.11432472.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021023.002303.67097780.davem@redhat.com> References: <200210031552.TAA29921@sex.inr.ac.ru> <20021023.162439.114324450.yoshfuji@linux-ipv6.org> <20021023.002303.67097780.davem@redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-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: 883 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 <20021023.002303.67097780.davem@redhat.com> (at Wed, 23 Oct 2002 00:23:03 -0700 (PDT)), "David S. Miller" says: > So, because you simplified some if clauses in Alexey's patch, USAGI is > the only entity who deserves credit for the work in the comments? > > That's dishonest. Please fix this. Hmm, we simplified our patch based on original linux kernel. In fact, I use ipv6_only_sock() from his patch. Sorry about that, apply this agaist that patch: Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.2.16.2 diff -u -r1.1.1.2.16.2 tcp_ipv4.c --- net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 +++ net/ipv4/tcp_ipv4.c 23 Oct 2002 07:46:23 -0000 @@ -45,8 +45,8 @@ * Vitaly E. Lavrov : Transparent proxy revived after year coma. * Andi Kleen : Fix new listen. * Andi Kleen : Fix accept error reporting. - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * and Alexey Kuznetsov allow both IPv4 and IPv6 sockets to bind * a single port at the same time. */ Index: net/ipv4/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v retrieving revision 1.1.1.1.40.1 diff -u -r1.1.1.1.40.1 udp.c --- net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 +++ net/ipv4/udp.c 23 Oct 2002 07:46:23 -0000 @@ -61,8 +61,8 @@ * return ENOTCONN for unconnected sockets (POSIX) * Janos Farkas : don't deliver multi/broadcasts to a different * bound-to-device socket - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * and Alexey Kuznetsov: allow both IPv4 and IPv6 sockets to bind * a single port at the same time. * * Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2.16.1 tcp_ipv6.c --- net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 +++ net/ipv6/tcp_ipv6.c 23 Oct 2002 07:46:23 -0000 @@ -14,8 +14,8 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * Alexey Kuznetsov allow both IPv4 and IPv6 sockets to bind * a single port at the same time. * * This program is free software; you can redistribute it and/or Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2.16.1 udp.c --- net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 +++ net/ipv6/udp.c 23 Oct 2002 07:46:23 -0000 @@ -11,8 +11,8 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * Alexey Kuznetsov allow both IPv4 and IPv6 sockets to bind * a single port at the same time. * * This program is free software; you can redistribute it and/or -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Wed Oct 23 01:05:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 01:05:54 -0700 (PDT) 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 g9N85puR028335 for ; Wed, 23 Oct 2002 01:05:51 -0700 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 g9N860HT003612; Wed, 23 Oct 2002 17:06:01 +0900 Date: Wed, 23 Oct 2002 17:06:00 +0900 (JST) Message-Id: <20021023.170600.16828978.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021023.165832.11432472.yoshfuji@linux-ipv6.org> References: <20021023.162439.114324450.yoshfuji@linux-ipv6.org> <20021023.002303.67097780.davem@redhat.com> <20021023.165832.11432472.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-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: 885 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 <20021023.165832.11432472.yoshfuji@linux-ipv6.org> (at Wed, 23 Oct 2002 16:58:32 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > Sorry about that, apply this agaist that patch: oops, typo. please use this instead: Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v retrieving revision 1.1.1.2.16.2 diff -u -r1.1.1.2.16.2 tcp_ipv4.c --- net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 +++ net/ipv4/tcp_ipv4.c 23 Oct 2002 08:03:09 -0000 @@ -45,8 +45,8 @@ * Vitaly E. Lavrov : Transparent proxy revived after year coma. * Andi Kleen : Fix new listen. * Andi Kleen : Fix accept error reporting. - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * Alexey Kuznetsov allow both IPv4 and IPv6 sockets to bind * a single port at the same time. */ Index: net/ipv4/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v retrieving revision 1.1.1.1.40.1 diff -u -r1.1.1.1.40.1 udp.c --- net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 +++ net/ipv4/udp.c 23 Oct 2002 08:03:09 -0000 @@ -61,8 +61,8 @@ * return ENOTCONN for unconnected sockets (POSIX) * Janos Farkas : don't deliver multi/broadcasts to a different * bound-to-device socket - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * Alexey Kuznetsov: allow both IPv4 and IPv6 sockets to bind * a single port at the same time. * * Index: net/ipv6/tcp_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2.16.1 tcp_ipv6.c --- net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 +++ net/ipv6/tcp_ipv6.c 23 Oct 2002 08:03:09 -0000 @@ -14,8 +14,8 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * Alexey Kuznetsov allow both IPv4 and IPv6 sockets to bind * a single port at the same time. * * This program is free software; you can redistribute it and/or Index: net/ipv6/udp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2.16.1 udp.c --- net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 +++ net/ipv6/udp.c 23 Oct 2002 08:03:09 -0000 @@ -11,8 +11,8 @@ * * Fixes: * Hideaki YOSHIFUJI : sin6_scope_id support - * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which - * allow both IPv4 and IPv6 sockets to bind + * YOSHIFUJI Hideaki @USAGI and: Support IPV6_V6ONLY socket option, which + * Alexey Kuznetsov allow both IPv4 and IPv6 sockets to bind * a single port at the same time. * * This program is free software; you can redistribute it and/or From michael@albog.dk Wed Oct 23 01:05:51 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 01:05:53 -0700 (PDT) Received: from alboeg.gatlink.dk ([81.19.231.245]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N85luR028330 for ; Wed, 23 Oct 2002 01:05:51 -0700 Received: (qmail 3126 invoked by uid 33); 23 Oct 2002 08:05:50 -0000 Received: from 62.199.138.3 ( [62.199.138.3]) as user michael@albog.dk@localhost by webmail.debianlinux.dk with HTTP; Wed, 23 Oct 2002 10:05:50 +0200 Message-ID: <1035360350.3db6585e0bdce@webmail.debianlinux.dk> Date: Wed, 23 Oct 2002 10:05:50 +0200 From: michael@albog.dk To: netdev@oss.sgi.com Subject: Fwd: Question about kernel and IPv6... MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 62.199.138.3 X-archive-position: 884 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michael@albog.dk Precedence: bulk X-list: netdev Alan Cox have recommended my to forward my questions to you, hope you will help me! Read the following: ----- Videresendt meddelelse fra michael@albog.dk ----- Dato: Wed, 23 Oct 2002 09:42:51 +0200 Fra: michael@albog.dk Reply-To: michael@albog.dk Emne: Question about kernel and IPv6... Til: Alan Cox To Alan Cox! Hi Alan, I am working on a master thesis called Internet Protocol version 6. In the project I have to setup a test-network for analyzing the RIPng protocol etc. I am using four normal Intel PCs each running Debian Linux, with a custom compiled kernel 2.4.19 downloaded from www.kernel.org. Two of the PCs are running as a software-based router (using Zebra 0.92a-6), and the other is separately working as a client and server, respectively connect to router1 and router2. My problem is when I try to send an ICMPv6 request via the WAN-link (router1 and router2) from the client, I not getting any response from server. The problem only appears when I try making a connection via the WAN-link, and not from router1<->server and router2<->client. My question is: - Could a problem be due to a wrong kernel-configuration? (I can attach the .config if you are interested). - What "kernel mechanism" is responsible for routing/transporting data between two interfaces? (I think thats the problem in router1 and router2. Zebra is only exchanging the "IPv6 kernel routing information" between router1 and router2, and it is working fine). - What kernel version have most IPv6 features build-in ?? (Maybe a feature is missing in 2.4.19. I have read an article about patching the kernel: http://project6.ferrara.linux.it/papers/best_ipv6_support_4_linux/best_ipv6_supp ort_4_linux.html, it is necessary?). I hope you understand what my main problem is English is not my primary language. I have got many information from mailinglists, messagesboards and homepages, but the main problem is, that those information is conflicting. Thats why I writing to the Linux Guru him self. Btw. You are doing a very good job with the Linux kernel! Best regards, Michael Olsen Atkins Danmark A/S, Tele Pilestrde 58 DK-1112 Kbenhavn K Telefon: +45 8233 9154 Fax: +45 8233 9017 ----- Slut af videresendt meddelelse ----- From pekkas@netcore.fi Wed Oct 23 01:09:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 01:09:20 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N89HuR029284 for ; Wed, 23 Oct 2002 01:09:17 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9N89H727229; Wed, 23 Oct 2002 11:09:17 +0300 Date: Wed, 23 Oct 2002 11:09:16 +0300 (EEST) From: Pekka Savola To: michael@albog.dk cc: netdev@oss.sgi.com Subject: Re: Fwd: Question about kernel and IPv6... In-Reply-To: <1035360350.3db6585e0bdce@webmail.debianlinux.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by netcore.fi id g9N89H727229 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9N89HuR029284 X-archive-position: 886 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 Please try using 2000::/3 route instead of "default" route and see if that helps. You could also try to ensure you've enabled IPv6 forwarding. On Wed, 23 Oct 2002 michael@albog.dk wrote: > Alan Cox have recommended my to forward my questions to you, hope you will help > me! > > Read the following: > > ----- Videresendt meddelelse fra michael@albog.dk ----- > Dato: Wed, 23 Oct 2002 09:42:51 +0200 > Fra: michael@albog.dk > Reply-To: michael@albog.dk > Emne: Question about kernel and IPv6... > Til: Alan Cox > > To Alan Cox! > > Hi Alan, > > I am working on a master thesis called Internet Protocol version 6. > > In the project I have to setup a test-network for analyzing the RIPng protocol > etc. I am using four normal Intel PCs each running Debian Linux, with a custom > compiled kernel 2.4.19 downloaded from www.kernel.org. Two of the PCs are > running as a software-based router (using Zebra 0.92a-6), and the other is > separately working as a client and server, respectively connect to router1 and > router2. > > My problem is when I try to send an ICMPv6 request via the WAN-link (router1 > and router2) from the client, I not getting any response from server. The > problem only appears when I try making a connection via the WAN-link, and not > from router1<->server and router2<->client. > > My question is: > > - Could a problem be due to a wrong kernel-configuration? (I can attach > the .config if you are interested). > > - What "kernel mechanism" is responsible for routing/transporting data between > two interfaces? (I think thats the problem in router1 and router2. Zebra is > only exchanging the "IPv6 kernel routing information" between router1 and > router2, and it is working fine). > > - What kernel version have most IPv6 features build-in ?? (Maybe a feature is > missing in 2.4.19. I have read an article about patching the kernel: > http://project6.ferrara.linux.it/papers/best_ipv6_support_4_linux/best_ipv6_supp > ort_4_linux.html, it is necessary?). > > I hope you understand what my main problem is English is not my primary > language. > > I have got many information from mailinglists, messagesboards and homepages, > but the main problem is, that those information is conflicting. Thats why I > writing to the Linux Guru him self. > > Btw. You are doing a very good job with the Linux kernel! > > Best regards, > > Michael Olsen > > Atkins Danmark A/S, Tele > Pilestrde 58 > DK-1112 Kbenhavn K > Telefon: +45 8233 9154 > Fax: +45 8233 9017 > > ----- Slut af videresendt meddelelse ----- > > -- 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 Wed Oct 23 01:11:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 01:11:49 -0700 (PDT) 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 g9N8BluR029800 for ; Wed, 23 Oct 2002 01:11:47 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id BAA12929; Wed, 23 Oct 2002 01:03:00 -0700 Date: Wed, 23 Oct 2002 01:02:59 -0700 (PDT) Message-Id: <20021023.010259.37664577.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: "David S. Miller" In-Reply-To: <20021023.170600.16828978.yoshfuji@linux-ipv6.org> References: <20021023.002303.67097780.davem@redhat.com> <20021023.165832.11432472.yoshfuji@linux-ipv6.org> <20021023.170600.16828978.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: 887 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 / 吉藤英明 Date: Wed, 23 Oct 2002 17:06:00 +0900 (JST) oops, typo. please use this instead: Thank you. From total2424@lycos.co.kr Wed Oct 23 01:47:08 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 01:47:10 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N8l7uR032195 for ; Wed, 23 Oct 2002 01:47:08 -0700 Message-Id: <200210230847.g9N8l7uR032195@oss.sgi.com> Reply-To: total2424@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=B0=A1=C0=E5=20=C0=FA=B7=C5=C7=D1?= =?ISO-8859-1?Q?=B9=E6=B9=FD=C0=B8=B7=CE=20=C0=CC=BB=E7=C7=CF=B4=C2?= =?ISO-8859-1?Q?=B9=E6=B9=FD!!?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 23 Oct 2002 17:47:17 +0900 X-archive-position: 888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: total2424@lycos.co.kr Precedence: bulk X-list: netdev 1-1
: () : : 212-13-80742
: 02-485-1124 : 249-4

. , .
, .
[] .
We sincerely apologize for sending advertising e-mail to you without your permission. We have indicated that this is advertising mail in accordance to the Law of Information and Network Usage, and we have installed a Spam Guard function. We obtained your e-mail address in an open place of public access on the Internet. Please be assured that we do not have any of your personal information other than your e-mail address. If you do not wish to receive it, please click the [reject bulk mail] function.
                                                  
From yijernghoon2@lycos.co.kr Wed Oct 23 02:00:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 02:00:38 -0700 (PDT) Received: from localhost ([211.198.39.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N90SuR000868 for ; Wed, 23 Oct 2002 02:00:31 -0700 Message-Id: <200210230900.g9N90SuR000868@oss.sgi.com> Reply-To: yijernghoon2@lycos.co.kr From: To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=B0=A8=C0=DA20kgBOX(=BB=F3)?= =?ISO-8859-1?Q?14,000=BF=F8-=B9=AB=B7=E1=B9=E8=BC=DB/=C8=C4=BA=D2=C1=A6?= =?ISO-8859-1?Q?=B1=B8=B8=AE=B8=B6=C4=CF?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 23 Oct 2002 17:29:32 +0900 X-archive-position: 889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yijernghoon2@lycos.co.kr Precedence: bulk X-list: netdev /



.


. .

-/
//// /
. .

z
  20kgBOX ------------------------14,000
:
: 20kgBOX
:
  13kgBOX-----------------------18,000
:
:13kgBOX
:
  ()15kgBOX -------------------32,000

:
:15kg BOX(61-70)
:

6kgBOX----------------------51,000
  :
: 6kgBOX 59/54
:
20kgBOX ------------------------25,000
:
: 20kgBOX
:
[] [] [] [] [] [] [] [] [] []


























  
  
  


()




  | | | |              1023 .
O 50 ()
O e-mail
O .
O DB . (TEL:031-513-6704) .
   [] .
From kaju@globalnetworks.co.kr Wed Oct 23 02:38:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 02:38:39 -0700 (PDT) Received: from globalnetworks.co.kr ([211.41.0.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N9cXuR003403 for ; Wed, 23 Oct 2002 02:38:34 -0700 Message-Id: <200210230938.g9N9cXuR003403@oss.sgi.com> Reply-To: kaju@globalnetworks.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=B1=B9=C1=A6=C0=FC=C8=AD=B9=CC=B1=B976=BF=F8,=C0=CF=BA=BB139=BF=F8,=C1=DF=B1=B9154=BF=F8?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 23 Oct 2002 18:35:26 +0900 X-Priority: 3 X-Mailer: Mailtouch 1.0 X-archive-position: 890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaju@globalnetworks.co.kr Precedence: bulk X-list: netdev


001

002

008

840

828

786

370

76

1484

1488

1428

870

154

984

972

924

400

139

2160

2136

2028

1100

312

1272

1272

1224

720

303

From gamsayo@dreamwiz.com Wed Oct 23 02:47:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 02:47:18 -0700 (PDT) Received: from localhost ([211.61.127.197]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9N9lBuR005563 for ; Wed, 23 Oct 2002 02:47:14 -0700 Message-Id: <200210230947.g9N9lBuR005563@oss.sgi.com> Reply-To: gamsayo@dreamwiz.com From: ktman To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=C7=D1=B1=B9=C5=EB=BD=C5?= =?ISO-8859-1?Q?=C0=FC=C8=AD=C1=A4=BE=D7=C1=A6=B7=CE?= =?ISO-8859-1?Q?=B9=AB=C1=A6=C7=D1=20=C5=EB=C8=AD~~!!?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 19 Oct 2002 18:51:41 +0900 X-archive-position: 891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gamsayo@dreamwiz.com Precedence: bulk X-list: netdev

 


 
1
1~2
2~3
3~5
5
1,000
1,500
2,000
3,000
5,000
 

) 6 5,000 1 5,000 + 1,000 =

: ,ADSL... /









1
1
~2
2
~3
3
~4
4
~5
5
~10
10
1,000
1,500
2,000
2,500
3,000
3,500
5,000
 

) 6 7,000 1 7,000 + 1,000 =










 

1. .
 
  , ( )
  /
  2002 3
 
2. ( )
3. : KT



[] .
[Deny] .

             

                  :   KT   ( 032-547-0100 )

 
From yoshfuji@linux-ipv6.org Wed Oct 23 03:01:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 03:01:34 -0700 (PDT) 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 g9NA1VuR006880 for ; Wed, 23 Oct 2002 03:01:32 -0700 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 g9NA1WHT004293; Wed, 23 Oct 2002 19:01:32 +0900 Date: Wed, 23 Oct 2002 19:01:31 +0900 (JST) Message-Id: <20021023.190131.67057125.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: kuznet@ms2.inr.ac.ru, davem@redhat.com, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021023.162439.114324450.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-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: 892 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 Wed, 23 Oct 2002 10:36:19 +0300 (EEST)), Pekka Savola says: > Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is > also enabled, from IPv4 addresses using TCP without > 'match-mapped-addresses yes', or is that a separate problem? Bind9 trys to bind :: and all ipv4 addresses on the node. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From roy@karlsbakk.net Wed Oct 23 03:10:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 03:10:40 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NAAbuR007909 for ; Wed, 23 Oct 2002 03:10:38 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9NABJG12153; Wed, 23 Oct 2002 12:11:19 +0200 Content-Type: text/plain; charset="us-ascii" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: netdev@oss.sgi.com Subject: tuning linux for high network performance? Date: Wed, 23 Oct 2002 12:18:18 +0200 User-Agent: KMail/1.4.1 Cc: Kernel mailing list MIME-Version: 1.0 Message-Id: <200210231218.18733.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NAAbuR007909 X-archive-position: 893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev hi I've got this video server serving video for VoD. problem is the P4 1.8 seems to be maxed out by a few system calls. The below output is for ~50 clients streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU maxes out. Does anyone have an idea? bash-2.05# readprofile | sort -rn +2 | head -30 154203 default_idle 2409.4219 212723 csum_partial_copy_generic 916.9095 100164 handle_IRQ_event 695.5833 24979 system_call 390.2969 37300 e1000_intr 388.5417 119699 ide_intr 340.0540 30598 skb_release_data 273.1964 40740 do_softirq 195.8654 131818 do_wp_page 164.7725 9935 fget 155.2344 24747 kfree 154.6687 10911 del_timer 113.6562 11683 ip_conntrack_find_get 91.2734 4120 sock_poll 85.8333 9357 ip_ct_find_proto 83.5446 5194 sock_wfree 81.1562 4929 add_wait_queue 77.0156 8361 flush_tlb_page 74.6518 4571 remove_wait_queue 71.4219 2191 __brelse 68.4688 29477 skb_clone 68.2338 8562 do_gettimeofday 59.4583 5673 process_timeout 59.0938 11097 tcp_v4_send_check 57.7969 6124 kfree_skbmem 54.6786 17115 tcp_poll 53.4844 21130 nf_hook_slow 52.8250 8299 ip_ct_refresh 51.8687 15429 __kfree_skb 50.7533 1059 lru_cache_del 46.0435 roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From pekkas@netcore.fi Wed Oct 23 03:15:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 03:15:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NAFeuR008594 for ; Wed, 23 Oct 2002 03:15:41 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NAFQ228329; Wed, 23 Oct 2002 13:15:26 +0300 Date: Wed, 23 Oct 2002 13:15:26 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: kuznet@ms2.inr.ac.ru, , , Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) In-Reply-To: <20021023.190131.67057125.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 894 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 Wed, 23 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Wed, 23 Oct 2002 10:36:19 +0300 (EEST)), Pekka Savola says: > > > Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is > > also enabled, from IPv4 addresses using TCP without > > 'match-mapped-addresses yes', or is that a separate problem? > > Bind9 trys to bind :: and all ipv4 addresses on the node. Yes, but binding those IPv4 addresses _for TCP_ failed after binding to ::, at least previously. That worked e.g. on BSD. Does that work now, too? I.e. I have two boxes, both running Bind 9.2.1. Linux gives: $ netstat -an | grep :53 tcp 0 0 :::53 :::* LISTEN udp 0 0 193.94.160.1:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 :::53 :::* and BSD gives: # netstat -an | grep .53 tcp6 0 0 ::1.953 *.* LISTEN tcp4 0 0 127.0.0.1.953 *.* LISTEN tcp4 0 0 127.0.0.1.53 *.* LISTEN tcp4 0 0 193.166.4.206.53 *.* LISTEN tcp4 0 0 193.166.187.10.53 *.* LISTEN tcp6 0 0 *.53 *.* LISTEN udp4 0 0 127.0.0.1.53 *.* udp4 0 0 193.166.4.206.53 *.* udp4 0 0 193.166.187.10.53 *.* udp6 0 0 *.53 *.* Will this work 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 davem@redhat.com Wed Oct 23 03:21:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 03:21:18 -0700 (PDT) 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 g9NALGuR009307 for ; Wed, 23 Oct 2002 03:21:16 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id DAA13229; Wed, 23 Oct 2002 03:12:25 -0700 Date: Wed, 23 Oct 2002 03:12:24 -0700 (PDT) Message-Id: <20021023.031224.102206819.davem@redhat.com> To: pekkas@netcore.fi Cc: yoshfuji@linux-ipv6.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: "David S. Miller" In-Reply-To: References: <20021023.190131.67057125.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 895 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: Pekka Savola Date: Wed, 23 Oct 2002 13:15:26 +0300 (EEST) Will this work too? It should work as a side effect of the USAGI patch. Because when bind9 does ipv6only bind on wildcarded ipv6, the ipv4 specific IP binds will then be allowed. From hanarointernet@lycos.co.kr Wed Oct 23 03:38:21 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 03:38:22 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.159]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NAcKuR010798 for ; Wed, 23 Oct 2002 03:38:21 -0700 Message-Id: <200210231038.g9NAcKuR010798@oss.sgi.com> Reply-To: hanarointernet@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=C1=F6=B1=DF=C1=F6=B1=DF=C7=D1?= =?ISO-8859-1?Q?=B9=AB=C1=BB!?= =?ISO-8859-1?Q?=C0=CC=C1=A8=20=BE=C8=B3=E7~~?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 23 Oct 2002 19:38:27 +0900 X-archive-position: 896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hanarointernet@lycos.co.kr Precedence: bulk X-list: netdev
: 820-10 4
: 02 - 3452 -7347 / : 031-703 - 5670 / H.P 018 - 310 - 5670
: 129-20-18866 / 3849 / :
[] .
.
[] . .
(Please click here to remove your address from our mailing list. Sorry for the trouble.)

                                                                                            

From roy@karlsbakk.net Wed Oct 23 03:58:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 03:58:40 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NAwZuR012479 for ; Wed, 23 Oct 2002 03:58:36 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9NAxIG12309; Wed, 23 Oct 2002 12:59:18 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: netdev@oss.sgi.com Subject: [RESEND] tuning linux for high network performance? Date: Wed, 23 Oct 2002 13:06:18 +0200 User-Agent: KMail/1.4.1 Cc: Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> In-Reply-To: <200210231218.18733.roy@karlsbakk.net> MIME-Version: 1.0 Message-Id: <200210231306.18422.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NAwZuR012479 X-archive-position: 897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev > I've got this video server serving video for VoD. problem is the P4 1.8 > seems to be maxed out by a few system calls. The below output is for ~50 > clients streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU > maxes out. > > Does anyone have an idea? ...adding the whole profile output - sorted by the first column this time... 905182 total 0.4741 121426 csum_partial_copy_generic 474.3203 93633 default_idle 1800.6346 74665 do_wp_page 111.1086 65857 ide_intr 184.9916 53636 handle_IRQ_event 432.5484 21973 do_softirq 107.7108 20498 e1000_intr 244.0238 19800 do_page_fault 16.8081 19395 skb_clone 45.7429 14564 system_call 260.0714 13592 kfree 89.4211 13557 skb_release_data 116.8707 13025 ide_do_request 17.6970 12988 do_rw_disk 8.4557 11841 tcp_sendmsg 2.6814 11720 nf_hook_slow 29.0099 11712 tcp_poll 34.0465 10688 schedule 7.8588 10386 __kfree_skb 34.1645 10052 ipt_do_table 10.1741 8286 fget 115.0833 7436 tcp_v4_send_check 44.2619 7191 e1000_clean_tx_irq 16.6458 7031 kmalloc 18.1211 6610 tcp_write_xmit 9.3892 6241 tcp_clean_rtx_queue 8.0425 6232 ip_conntrack_find_get 51.9333 6140 ide_dmaproc 8.4341 6125 tcp_packet 14.0482 5858 qdisc_restart 15.4158 5734 e1000_xmit_frame 5.6660 5709 tcp_v4_rcv 3.7363 5703 sys_rt_sigprocmask 11.4060 5445 tcp_transmit_skb 3.7500 5273 alloc_skb 11.8761 4961 ide_wait_stat 18.7917 4790 ip_ct_find_proto 44.3519 4782 add_timer 18.3923 4760 ip_ct_refresh 29.7500 4729 do_anonymous_page 17.6455 4616 e1000_clean_rx_irq 4.9106 4464 do_gettimeofday 37.2000 4359 flush_tlb_page 38.9196 4209 ip_finish_output2 16.4414 3731 get_hash_table 23.3188 3714 eth_type_trans 21.1023 3712 __make_request 2.3375 3680 __ip_conntrack_find 12.7778 3480 ip_route_input 9.1579 3363 kfree_skbmem 32.3365 3295 __switch_to 15.2546 3205 fput 13.1352 3143 rmqueue 5.3452 3137 ip_conntrack_in 5.0272 3008 sync_timers 250.6667 2861 sock_wfree 47.6833 2580 ip_queue_xmit 2.0347 2578 process_timeout 26.8542 2577 netif_rx 6.1357 2555 get_user_pages 6.2623 2504 sock_poll 62.6000 2346 ide_build_sglist 5.6394 2316 brw_kiovec 2.5619 2256 csum_partial 7.8333 2251 ip_queue_xmit2 4.2958 2198 start_request 4.0404 2186 dev_queue_xmit 2.7462 2167 timer_bh 2.2203 2162 __free_pages_ok 3.1608 2157 zap_page_range 2.4400 1942 mark_dirty_kiobuf 21.1087 1733 process_backlog 5.9349 1719 tcp_rcv_established 0.8493 1689 add_wait_queue 32.4808 1650 mod_timer 6.1567 1603 wait_kio 17.4239 1575 net_rx_action 4.8611 1554 get_pid 4.0052 1434 lru_cache_add 12.8036 1429 handle_mm_fault 7.7663 1397 ip_local_deliver_finish 4.5357 1357 nf_iterate 10.2803 1350 e1000_alloc_rx_buffers 5.2734 1298 do_select 2.5155 1268 unlock_page 12.1923 1209 submit_bh 10.7946 1184 add_entropy_words 5.9200 1175 __brelse 36.7188 1125 __pollwait 7.8125 1108 shrink_list 5.7708 1099 generic_make_request 3.6151 1080 __free_pages 33.7500 1052 tcp_ack 1.2524 1020 ip_rcv 1.0851 986 raid0_make_request 2.9345 898 ext3_direct_io_get_block 4.7766 883 pfifo_fast_dequeue 11.6184 863 sys_gettimeofday 5.5321 828 tcp_ack_update_window 3.9808 813 ipt_local_out_hook 7.8173 761 __lru_cache_del 6.5603 756 sys_write 2.9531 742 __rdtsc_delay 26.5000 730 uhci_interrupt 3.3182 718 net_tx_action 2.5643 710 batch_entropy_store 3.9444 701 add_timer_randomness 3.3066 666 tasklet_hi_action 4.1625 662 sys_nanosleep 1.7796 635 set_page_dirty 5.4741 627 __tcp_data_snd_check 3.1350 611 netif_receive_skb 1.9094 601 pfifo_fast_enqueue 5.3661 590 del_timer_sync 4.3382 587 lru_cache_del 26.6818 574 get_unmapped_area 2.1103 561 wait_for_tcp_memory 0.7835 557 ip_refrag 5.8021 546 ip_conntrack_local 6.2045 515 sys_select 0.4486 507 __tcp_select_window 2.2634 481 ext3_get_branch 2.2689 433 ip_output 1.2301 389 ip_confirm 9.7250 384 find_vma 4.5714 379 set_bh_page 9.4750 376 tcp_v4_do_rcv 1.0108 370 tcp_ack_no_tstamp 1.4453 368 batch_entropy_process 2.0000 365 ide_build_dmatable 1.1551 364 ip_rcv_finish 0.7696 363 kmem_cache_free 2.8359 362 __wake_up 1.8854 338 ext3_get_block_handle 0.5152 336 inet_sendmsg 5.2500 318 bh_action 2.3382 298 tcp_data_queue 0.1064 272 md_make_request 2.6154 272 ext3_block_to_path 0.9714 248 sock_sendmsg 1.8235 244 __alloc_pages 0.6932 238 kmem_cache_alloc 0.7532 226 __free_pte 3.1389 225 tcp_ack_probe 1.3720 224 __run_task_queue 2.0741 213 ide_get_queue 5.3250 209 __ip_ct_find_proto 4.3542 202 get_sample_stats 1.7414 195 tcp_write_space 1.6810 185 schedule_timeout 1.1859 184 do_signal 0.2992 182 ipt_hook 4.5500 171 generic_direct_IO 0.5552 168 can_share_swap_page 1.8261 157 ip_local_deliver 0.3965 155 get_conntrack_index 2.7679 145 tcp_push_one 0.5664 145 ide_set_handler 1.2500 144 pipe_poll 1.4400 143 max_select_fd 0.8938 139 pte_alloc 0.5792 138 del_timer 1.6429 136 sock_write 0.7234 131 poll_freewait 1.9265 131 getblk 1.7237 130 send_sig_info 0.8553 128 __release_sock 1.4545 125 ret_from_sys_call 7.3529 120 ext3_direct_IO 0.1807 118 tcp_pkt_to_tuple 3.6875 117 find_vma_prev 0.6648 114 do_no_page 0.2298 112 tqueue_bh 4.0000 112 follow_page 1.0769 110 bread 1.1000 108 e1000_rx_checksum 1.2273 107 generic_file_direct_IO 0.1938 102 add_interrupt_randomness 2.5500 97 remove_wait_queue 1.7321 96 mark_page_accessed 2.0000 91 kill_something_info 0.2645 85 invert_tuple 1.9318 81 exit_notify 0.1151 81 cpu_idle 0.9643 80 tcp_new_space 0.6061 79 nf_register_queue_handler 0.5197 75 uhci_remove_pending_qhs 0.3906 69 pdc202xx_dmaproc 0.1250 68 sys_read 0.2656 68 nf_reinject 0.1491 66 map_user_kiobuf 0.2619 65 find_vma_prepare 0.6500 64 generic_file_read 0.2353 61 check_pgt_cache 2.5417 60 free_pages 1.8750 58 error_code 0.9667 57 vm_enough_memory 0.5481 56 __delay 1.4000 55 __const_udelay 1.0577 53 tcp_ioctl 0.0908 53 journal_commit_transaction 0.0132 53 do_munmap 0.0901 52 _alloc_pages 2.1667 51 uhci_finish_completion 0.4554 51 credit_entropy_store 1.1591 50 rh_report_status 0.1953 50 free_page_and_swap_cache 0.8929 49 sys_rt_sigsuspend 0.1750 49 nr_free_pages 0.6125 49 do_mmap_pgoff 0.0394 48 e1000_update_stats 0.0307 48 do_get_write_access 0.0366 48 __journal_file_buffer 0.0916 48 __get_free_pages 2.0000 48 .text.lock.e1000_main 1.7143 47 expand_kiobuf 0.3092 46 uhci_free_pending_qhs 0.4600 46 tcp_parse_options 0.0833 46 kmem_cache_size 5.7500 45 rb_erase 0.2083 44 unmap_kiobuf 0.6111 41 tcp_cwnd_application_limited 0.3106 41 rh_int_timer_do 0.1165 41 init_or_cleanup 0.1424 40 sync_unlocked_inodes 0.0901 40 init_buffer 1.4286 39 .text.lock.ip_input 1.0000 38 vma_merge 0.1301 38 pfifo_fast_requeue 0.6786 38 ip_conntrack_get 0.9500 38 dev_watchdog 0.2209 37 .text.lock.ip_output 0.2803 36 do_check_pgt_cache 0.1731 35 tcp_retrans_try_collapse 0.0576 35 journal_add_journal_head 0.1306 34 ext3_get_inode_loc 0.0914 33 journal_write_revoke_records 0.1964 32 fsync_buffers_list 0.0860 31 filemap_fdatasync 0.1615 31 __pmd_alloc 1.5500 30 sys_wait4 0.0305 30 restore_sigcontext 0.0949 29 sys_sigreturn 0.1169 28 tcp_fastretrans_alert 0.0224 28 do_settimeofday 0.1628 28 do_ide_request 1.4000 27 unmap_fixup 0.0785 27 find_extend_vma 0.1350 27 eth_header_parse 0.8438 27 current_capacity 0.6750 26 save_i387 0.0478 26 __journal_clean_checkpoint_list 0.2407 25 update_atime 0.3125 25 tcp_v4_destroy_sock 0.0718 25 link_path_walk 0.0102 25 buffer_insert_inode_queue 0.2841 25 __journal_unfile_buffer 0.0665 24 sys_mmap2 0.1622 24 rh_send_irq 0.0896 24 rb_insert_color 0.1224 24 ext3_do_update_inode 0.0261 24 balance_dirty_state 0.3158 24 add_wait_queue_exclusive 0.4615 24 __try_to_free_cp_buf 0.4000 23 free_kiobuf_bhs 0.2396 22 tcp_rcv_synsent_state_process 0.0169 22 sys_munmap 0.2619 22 start_this_handle 0.0598 22 sock_rfree 1.3750 22 setup_sigcontext 0.0743 22 flush_tlb_mm 0.1964 22 do_exit 0.0301 22 alloc_kiobuf_bhs 0.1170 22 __rb_erase_color 0.0567 21 tcp_mem_schedule 0.0477 21 setup_frame 0.0482 21 __generic_copy_to_user 0.3500 20 unlock_buffer 0.3125 20 journal_write_metadata_buffer 0.0240 20 d_lookup 0.0704 20 copy_skb_header 0.0980 19 sync_old_buffers 0.1218 19 sock_mmap 0.4750 19 skb_split 0.0344 19 select_bits_alloc 0.7917 19 get_info_ptr 0.2065 17 tcp_write_wakeup 0.0363 17 ret_from_exception 0.6800 17 kiobuf_wait_for_io 0.1062 17 journal_unlock_journal_head 0.1518 17 bad_signal 0.1250 16 tcp_probe_timer 0.0952 16 tcp_close 0.0083 16 ip_route_output_slow 0.0099 16 __mark_inode_dirty 0.0952 16 .text.lock.timer 0.1250 16 .text.lock.tcp 0.0152 15 journal_cancel_revoke 0.0765 15 ext3_bmap 0.1500 15 do_fork 0.0074 15 blk_grow_request_list 0.0833 14 tcp_v4_conn_request 0.0145 14 sync_supers 0.0507 14 log_start_commit 0.0946 14 lock_vma_mappings 0.3500 14 journal_dirty_metadata 0.0354 14 file_read_actor 0.0625 14 __insert_vm_struct 0.1400 13 tcp_time_to_recover 0.0290 13 sys_ioctl 0.0259 13 lookup_swap_cache 0.1625 13 ip_build_xmit_slow 0.0099 13 invalidate_inode_pages 0.0739 13 ext3_dirty_inode 0.0478 13 bmap 0.2955 12 tcp_collapse 0.0143 12 sys_socketcall 0.0234 12 put_filp 0.1364 12 make_pages_present 0.0968 12 journal_get_write_access 0.1304 12 generic_file_write 0.0061 12 e1000_ioctl 0.3333 11 uhci_transfer_result 0.0316 11 tcp_try_to_open 0.0348 11 tcp_recvmsg 0.0045 11 tcp_create_openreq_child 0.0092 11 sys_kill 0.1250 11 schedule_tail 0.0786 11 osync_buffers_list 0.0859 11 journal_stop 0.0255 11 do_sigpending 0.0887 10 tcp_unhash 0.0397 10 tcp_send_probe0 0.0424 10 tcp_rcv_state_process 0.0040 10 sys_poll 0.0138 10 inet_shutdown 0.0208 10 execute_drive_cmd 0.0221 10 __put_unused_buffer_head 0.1136 9 tcp_write_timer 0.0395 9 tcp_send_skb 0.0191 9 tcp_make_synack 0.0082 9 set_buffer_flushtime 0.4500 9 raid0_status 0.2045 9 copy_page_range 0.0205 8 kupdate 0.0274 8 journal_get_descriptor_buffer 0.0741 8 get_empty_filp 0.0253 8 ext3_write_super 0.0741 8 count_active_tasks 0.1111 8 atomic_dec_and_lock 0.1111 8 __lock_page 0.0400 8 __journal_remove_journal_head 0.0250 8 __ip_conntrack_confirm 0.0115 8 __block_prepare_write 0.0105 7 tcp_invert_tuple 0.2188 7 ports_active 0.1346 7 pipe_write 0.0112 7 kjournald 0.0130 7 handle_signal 0.0273 7 grow_buffers 0.0254 7 ext3_get_block 0.0700 7 balance_classzone 0.0151 7 __jbd_kmalloc 0.0625 7 .text.lock.swap 0.1296 6 vsnprintf 0.0057 6 tcp_v4_send_reset 0.0176 6 tcp_accept 0.0105 6 sleep_on 0.0500 6 select_bits_free 0.3750 6 pipe_read 0.0118 6 number 0.0055 6 ip_route_output_key 0.0165 6 inet_accept 0.0136 6 get_unused_buffer_head 0.0375 6 dput 0.0176 6 cleanup_rbuf 0.0273 6 __journal_remove_checkpoint 0.0556 6 __journal_drop_transaction 0.0087 6 __find_get_page 0.0938 6 .text.lock.netfilter 0.0260 5 vmtruncate_list 0.0625 5 vfs_permission 0.0208 5 tcp_v4_hnd_req 0.0147 5 tcp_init_cwnd 0.0500 5 tcp_check_urg 0.0158 5 tcp_check_sack_reneging 0.0240 5 sys_fork 0.1786 5 sock_setsockopt 0.0034 5 sock_init_data 0.0161 5 sock_def_readable 0.0521 5 release_x86_irqs 0.0595 5 release_task 0.0109 5 refile_buffer 0.1389 5 pipe_release 0.0368 5 path_init 0.0129 5 nr_free_buffer_pages 0.0625 5 mprotect_fixup 0.0043 5 log_space_left 0.1562 5 ll_rw_block 0.0119 5 journal_start 0.0272 5 init_bh 0.2083 5 get_zeroed_page 0.1389 5 ext3_commit_write 0.0078 5 e1000_tx_timeout 0.2500 5 do_poll 0.0227 5 bdfind 0.1389 5 add_keyboard_randomness 0.1250 5 __wait_on_buffer 0.0338 5 __vma_link 0.0284 5 __tcp_mem_reclaim 0.0595 5 __rb_rotate_left 0.0781 4 write_profile 0.0244 4 tcp_v4_syn_recv_sock 0.0064 4 tcp_v4_search_req 0.0278 4 tcp_v4_route_req 0.0192 4 tcp_v4_init_sock 0.0169 4 tcp_cwnd_restart 0.0263 4 tcp_check_req 0.0043 4 tcp_check_reno_reordering 0.0500 4 sys_mprotect 0.0078 4 strncpy_from_user 0.0500 4 sock_def_wakeup 0.0625 4 sock_alloc 0.0208 4 skb_copy_datagram_iovec 0.0071 4 lookup_mnt 0.0476 4 locks_remove_posix 0.0096 4 invalidate_inode_buffers 0.0370 4 init_conntrack 0.0043 4 halfMD4Transform 0.0068 4 find_or_create_page 0.0164 4 filp_close 0.0238 4 ext3_reserve_inode_write 0.0233 4 ext3_find_goal 0.0213 4 do_fcntl 0.0059 4 dnotify_flush 0.0345 4 d_alloc 0.0105 4 add_blkdev_randomness 0.0526 4 _stext 0.0500 4 __journal_insert_checkpoint 0.0167 4 __find_lock_page_helper 0.0323 4 .text.lock.inode 0.0086 3 wait_for_tcp_connect 0.0054 3 tcp_v4_get_port 0.0045 3 tcp_put_port 0.0150 3 tcp_init_xmit_timers 0.0221 3 tcp_clear_xmit_timers 0.0234 3 tcp_add_reno_sack 0.0357 3 sys_sched_getscheduler 0.0288 3 sys_fcntl64 0.0221 3 sys_accept 0.0119 3 sock_ioctl 0.0268 3 sock_fasync 0.0038 3 sock_def_error_report 0.0312 3 rt_check_expire__thr 0.0077 3 rh_init_int_timer 0.0278 3 reset_hc 0.0167 3 register_gifconf 0.0938 3 read_chan 0.0016 3 put_unused_buffer_head 0.0833 3 pipe_ioctl 0.0375 3 permission 0.0227 3 open_namei 0.0024 3 mm_release 0.0833 3 locks_remove_flock 0.0163 3 ksoftirqd 0.0153 3 journal_file_buffer 0.0682 3 iput 0.0060 3 ip_build_and_send_pkt 0.0067 3 interruptible_sleep_on 0.0250 3 inet_sock_destruct 0.0080 3 inet_ioctl 0.0079 3 inet_create 0.0048 3 immediate_bh 0.1071 3 get_unused_fd 0.0077 3 get_empty_inode 0.0179 3 flush_tlb_all_ipi 0.0395 3 filemap_fdatawait 0.0214 3 fd_install 0.0441 3 ext3_prepare_write 0.0056 3 ext3_mark_iloc_dirty 0.0357 3 e1000_watchdog 0.0064 3 e1000_read_phy_reg 0.0179 3 d_invalidate 0.0214 3 create_buffers 0.0125 3 cp_new_stat64 0.0095 3 copy_mm 0.0040 3 copy_files 0.0043 3 bdget 0.0078 3 __insert_into_lru_list 0.0300 3 __global_restore_flags 0.0417 3 __get_user_4 0.1250 2 write_ldt 0.0037 2 walk_page_buffers 0.0161 2 tcp_try_undo_partial 0.0093 2 tcp_try_undo_dsack 0.0294 2 tcp_send_ack 0.0100 2 tcp_retransmit_skb 0.0034 2 tcp_new 0.0333 2 tcp_init_metrics 0.0063 2 tcp_fragment 0.0029 2 tcp_fixup_sndbuf 0.0455 2 tcp_enter_loss 0.0051 2 tcp_destroy_sock 0.0043 2 tcp_close_state 0.0104 2 tcp_child_process 0.0134 2 tcp_bucket_create 0.0263 2 tasklet_init 0.0500 2 sys_close 0.0179 2 sock_recvmsg 0.0116 2 sock_map_fd 0.0052 2 sk_free 0.0172 2 sk_alloc 0.0208 2 sem_exit 0.0038 2 reschedule 0.1667 2 put_files_struct 0.0109 2 path_release 0.0417 2 path_lookup 0.0556 2 mmput 0.0172 2 kiobuf_init 0.0238 2 journal_unfile_buffer 0.0556 2 journal_get_undo_access 0.0070 2 journal_dirty_data 0.0047 2 ip_mc_drop_socket 0.0156 2 idedisk_open 0.0156 2 grow_dev_page 0.0122 2 getname 0.0128 2 generic_unplug_device 0.0333 2 generic_file_llseek 0.0135 2 free_kiovec 0.0200 2 flush_signal_handlers 0.0333 2 filemap_nopage 0.0040 2 ext3_writepage_trans_blocks 0.0152 2 ext3_getblk 0.0030 2 do_generic_file_read 0.0017 2 destroy_inode 0.0455 2 deliver_to_old_ones 0.0114 2 copy_namespace 0.0023 2 clear_inode 0.0122 2 clean_inode 0.0109 2 block_prepare_write 0.0179 2 alloc_kiovec 0.0161 2 add_page_to_hash_queue 0.0455 2 activate_page 0.0139 2 __tcp_v4_lookup_listener 0.0208 2 __journal_refile_buffer 0.0088 2 __generic_copy_from_user 0.0227 2 __find_lock_page 0.0500 2 __down_trylock 0.0263 2 __down_failed_trylock 0.1667 2 __block_commit_write 0.0098 2 .text.lock.sched 0.0042 1 vt_console_device 0.0250 1 vgacon_save_screen 0.0114 1 udp_sendmsg 0.0010 1 tty_write 0.0015 1 tty_ioctl 0.0011 1 tcp_xmit_retransmit_queue 0.0010 1 tcp_xmit_probe_skb 0.0086 1 tcp_v4_synq_add 0.0063 1 tcp_v4_rebuild_header 0.0028 1 tcp_timewait_kill 0.0045 1 tcp_sync_mss 0.0081 1 tcp_reset_keepalive_timer 0.0250 1 tcp_reset 0.0039 1 tcp_recv_urg 0.0044 1 tcp_incr_quickack 0.0167 1 tcp_error 0.0139 1 sys_time 0.0119 1 sys_stat64 0.0086 1 sys_modify_ldt 0.0106 1 sys_lstat64 0.0089 1 sys_llseek 0.0034 1 sys_getppid 0.0250 1 sys_getpeername 0.0081 1 sys_fstat64 0.0104 1 sys_clone 0.0250 1 sys_brk 0.0042 1 sys_access 0.0034 1 svc_udp_recvfrom 0.0014 1 sock_wmalloc 0.0125 1 sock_release 0.0104 1 sock_read 0.0064 1 sock_create 0.0036 1 skb_recv_datagram 0.0042 1 show_mem 0.0033 1 setup_rt_frame 0.0015 1 setscheduler 0.0024 1 secure_tcp_sequence_number 0.0051 1 restart_request 0.0132 1 remove_inode_page 0.0192 1 remove_expectations 0.0208 1 proc_pid_lookup 0.0020 1 proc_lookup 0.0068 1 pdc202xx_reset 0.0074 1 path_walk 0.0357 1 opost 0.0023 1 old_mmap 0.0033 1 normal_poll 0.0035 1 nfs3svc_encode_attrstat 0.0020 1 n_tty_receive_buf 0.0002 1 move_addr_to_user 0.0119 1 mm_init 0.0051 1 memory_open 0.0050 1 kmem_cache_grow 0.0018 1 kill_fasync 0.0172 1 journal_free_journal_head 0.0500 1 journal_bmap 0.0089 1 journal_blocks_per_page 0.0312 1 journal_alloc_journal_head 0.0096 1 is_read_only 0.0147 1 ip_ct_gather_frags 0.0031 1 init_private_file 0.0093 1 init_once 0.0038 1 init_buffer_head 0.0182 1 inet_release 0.0125 1 inet_getname 0.0083 1 inet_autobind 0.0023 1 get_pipe_inode 0.0057 1 free_pgtables 0.0071 1 fn_hash_lookup 0.0045 1 find_inlist_lock 0.0035 1 file_move 0.0139 1 fcntl_dirnotify 0.0032 1 ext3_write_inode 0.0192 1 ext3_test_allocatable 0.0156 1 ext3_release_file 0.0357 1 ext3_read_inode 0.0014 1 ext3_open_file 0.0250 1 ext3_group_sparse 0.0104 1 ext3_file_write 0.0053 1 exit_sighand 0.0100 1 e1000_tbi_adjust_stats 0.0021 1 e1000_check_for_link 0.0020 1 do_timer 0.0125 1 do_tcp_sendpages 0.0004 1 do_sys_settimeofday 0.0064 1 do_readv_writev 0.0016 1 do_pollfd 0.0074 1 death_by_timeout 0.0068 1 d_instantiate 0.0139 1 cpu_raise_softirq 0.0154 1 copy_thread 0.0071 1 clear_page_tables 0.0046 1 clean_from_lists 0.0139 1 check_unthrottle 0.0208 1 change_protection 0.0027 1 cached_lookup 0.0119 1 add_to_page_cache_locked 0.0081 1 __user_walk 0.0156 1 __remove_inode_page 0.0104 1 __remove_from_lru_list 0.0119 1 __refile_buffer 0.0109 1 __rb_rotate_right 0.0156 1 __loop_delay 0.0250 1 .text.lock.super 0.0071 -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From perfume_store@lycos.co.kr Wed Oct 23 05:18:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 05:18:08 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NCI5uR018194 for ; Wed, 23 Oct 2002 05:18:05 -0700 Message-Id: <200210231218.g9NCI5uR018194@oss.sgi.com> Reply-To: perfume_store@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=B0=A1=C0=D4=B8=B8=20=C7=D8=B5=B5?= =?ISO-8859-1?Q?=C3=B5=BF=F8=C0=CC=20=B0=F8=C2=A5!?= =?ISO-8859-1?Q?=B4=EB=C7=D1=B9=CE=B1=B9=20=C3=D6=B0=ED=C0=C7?= =?ISO-8859-1?Q?=C8=AD=C0=E5=C7=B0=20=C7=D2=C0=CE=BC=EE=C7=CE=B8=F4?= =?ISO-8859-1?Q?=C5=BA=BB=FD!!"?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 23 Oct 2002 21:18:15 +0900 X-archive-position: 898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: perfume_store@lycos.co.kr Precedence: bulk X-list: netdev
 
- !!
- ,,LG,BC
- ~
- ~
- ~

                                                                    

From davem@rth.ninka.net Wed Oct 23 06:09:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:09:54 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ND9quR021972 for ; Wed, 23 Oct 2002 06:09:52 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9NDLnRU006006; Wed, 23 Oct 2002 06:21:49 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9NDLnqU006004; Wed, 23 Oct 2002 06:21:49 -0700 Subject: Re: [RESEND] tuning linux for high network performance? From: "David S. Miller" To: bert hubert Cc: Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list In-Reply-To: <20021023130101.GA646@outpost.ds9a.nl> References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2002 06:21:48 -0700 Message-Id: <1035379308.5950.3.camel@rth.ninka.net> Mime-Version: 1.0 X-archive-position: 899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@rth.ninka.net Precedence: bulk X-list: netdev On Wed, 2002-10-23 at 06:01, bert hubert wrote: > Also mention that you have an e1000 card which > does not do outgoing checksumming. The e1000 can very well do hardware checksumming on transmit. The missing piece of the puzzle is that his application is not using sendfile(), without which no transmit checksum offload can take place. From vda@port.imtp.ilyichevsk.odessa.ua Wed Oct 23 06:14:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:14:40 -0700 (PDT) Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NDERuR022616 for ; Wed, 23 Oct 2002 06:14:36 -0700 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g9ND9Bp03373; Wed, 23 Oct 2002 16:09:11 +0300 Message-Id: <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Roy Sigurd Karlsbakk , netdev@oss.sgi.com Subject: Re: [RESEND] tuning linux for high network performance? Date: Wed, 23 Oct 2002 16:01:49 -0200 X-Mailer: KMail [version 1.3.2] References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> In-Reply-To: <200210231306.18422.roy@karlsbakk.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On 23 October 2002 09:06, Roy Sigurd Karlsbakk wrote: > > I've got this video server serving video for VoD. problem is the P4 > > 1.8 seems to be maxed out by a few system calls. The below output > > is for ~50 clients streaming at ~4.5Mbps. if trying to increase > > this to ~70, the CPU maxes out. > > > > Does anyone have an idea? > > ...adding the whole profile output - sorted by the first column this > time... > > 905182 total 0.4741 > 121426 csum_partial_copy_generic 474.3203 Well, maybe take a look at this func and try to optimize it? > 93633 default_idle 1800.6346 > 74665 do_wp_page 111.1086 What's this? > 65857 ide_intr 184.9916 You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm... how large is your readahead? I assume you'd like to fetch more sectors from ide per interrupt. (I hope you do DMA ;) > 53636 handle_IRQ_event 432.5484 > 21973 do_softirq 107.7108 > 20498 e1000_intr 244.0238 I know zero about networking, but why 120 000 csum_partial_copy_generic and inly 20 000 nic interrupts? That may be abnormal. -- vda From ahu@outpost.ds9a.nl Wed Oct 23 06:27:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:27:59 -0700 (PDT) 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 g9NDRkuR023522 for ; Wed, 23 Oct 2002 06:27:47 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A755E4594; Wed, 23 Oct 2002 15:01:01 +0200 (CEST) Date: Wed, 23 Oct 2002 15:01:01 +0200 From: bert hubert To: Roy Sigurd Karlsbakk Cc: netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? Message-ID: <20021023130101.GA646@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210231306.18422.roy@karlsbakk.net> User-Agent: Mutt/1.3.28i X-archive-position: 901 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, Oct 23, 2002 at 01:06:18PM +0200, Roy Sigurd Karlsbakk wrote: > > I've got this video server serving video for VoD. problem is the P4 1.8 > > seems to be maxed out by a few system calls. The below output is for ~50 > > clients streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU > > maxes out. '50 clients *each* streaming at ~4.4MBps', better make that clear, otherwise something is *very* broken. Also mention that you have an e1000 card which does not do outgoing checksumming. You'd think that a kernel would be able to do 250megabits of TCP checksums though. > ...adding the whole profile output - sorted by the first column this time... > > 905182 total 0.4741 > 121426 csum_partial_copy_generic 474.3203 > 93633 default_idle 1800.6346 > 74665 do_wp_page 111.1086 Perhaps the 'copy' also entails grabbing the page from disk, leading to inflated csum_partial_copy_generic stats? Where are you serving from? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From roy@karlsbakk.net Wed Oct 23 06:29:10 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:29:12 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NDT9uR023935 for ; Wed, 23 Oct 2002 06:29:10 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9NDTLG12997; Wed, 23 Oct 2002 15:29:21 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: vda@port.imtp.ilyichevsk.odessa.ua, netdev@oss.sgi.com Subject: Re: [RESEND] tuning linux for high network performance? Date: Wed, 23 Oct 2002 15:36:24 +0200 User-Agent: KMail/1.4.1 References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> Cc: Kernel mailing list MIME-Version: 1.0 Message-Id: <200210231536.24269.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NDT9uR023935 X-archive-position: 902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev > > > > 905182 total 0.4741 > > 121426 csum_partial_copy_generic 474.3203 > > Well, maybe take a look at this func and try to optimize it? I don't know assembly that good - sorry. > > 93633 default_idle 1800.6346 > > 74665 do_wp_page 111.1086 > > What's this? do_wp_page is Defined as a function in: mm/memory.c comments from the file: /* * This routine handles present pages, when users try to write * to a shared page. It is done by copying the page to a new address * and decrementing the shared-page counter for the old page. * * Goto-purists beware: the only reason for goto's here is that it results * in better assembly code.. The "default" path will see no jumps at all. * * Note that this routine assumes that the protection checks have been * done by the caller (the low-level page fault routine in most cases). * Thus we can safely just mark it writable once we've done any necessary * COW. * * We also mark the page dirty at this point even though the page will * change only once the write actually happens. This avoids a few races, * and potentially makes it more efficient. * * We hold the mm semaphore and the page_table_lock on entry and exit * with the page_table_lock released. */ > > > 65857 ide_intr 184.9916 > > You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm... > how large is your readahead? I assume you'd like to fetch > more sectors from ide per interrupt. (I hope you do DMA ;) doing DMA - RAID-0 with 1MB chunk size on 4 disks. > > 53636 handle_IRQ_event 432.5484 > > 21973 do_softirq 107.7108 > > 20498 e1000_intr 244.0238 > > I know zero about networking, but why 120 000 csum_partial_copy_generic > and inly 20 000 nic interrupts? That may be abnormal. sorry I don't know -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From roy@karlsbakk.net Wed Oct 23 06:33:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:33:20 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NDXHuR024358 for ; Wed, 23 Oct 2002 06:33:18 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9NDXxG13049; Wed, 23 Oct 2002 15:34:00 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: bert hubert Subject: Re: [RESEND] tuning linux for high network performance? Date: Wed, 23 Oct 2002 15:41:02 +0200 User-Agent: KMail/1.4.1 Cc: netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> In-Reply-To: <20021023130101.GA646@outpost.ds9a.nl> MIME-Version: 1.0 Message-Id: <200210231541.02883.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NDXHuR024358 X-archive-position: 903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev > '50 clients *each* streaming at ~4.4MBps', better make that clear, > otherwise something is *very* broken. Also mention that you have an e1000 > card which does not do outgoing checksumming. just to clearify s/MBps/Mbps/ s/bps/bits per second/ > You'd think that a kernel would be able to do 250megabits of TCP checksums > though. > > > ...adding the whole profile output - sorted by the first column this > > time... > > > > 905182 total 0.4741 > > 121426 csum_partial_copy_generic 474.3203 > > 93633 default_idle 1800.6346 > > 74665 do_wp_page 111.1086 > > Perhaps the 'copy' also entails grabbing the page from disk, leading to > inflated csum_partial_copy_generic stats? I really don't know. Just to clearify a little more - the server app uses O_DIRECT to read the data before tossing it to the socket. > Where are you serving from? What do you mean? roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From roy@karlsbakk.net Wed Oct 23 06:35:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:35:16 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NDZDuR024793 for ; Wed, 23 Oct 2002 06:35:14 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9NDZjG13055; Wed, 23 Oct 2002 15:35:48 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: "David S. Miller" , bert hubert Subject: Re: [RESEND] tuning linux for high network performance? Date: Wed, 23 Oct 2002 15:42:48 +0200 User-Agent: KMail/1.4.1 Cc: netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <1035379308.5950.3.camel@rth.ninka.net> In-Reply-To: <1035379308.5950.3.camel@rth.ninka.net> MIME-Version: 1.0 Message-Id: <200210231542.48673.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NDZDuR024793 X-archive-position: 904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev > The e1000 can very well do hardware checksumming on transmit. > > The missing piece of the puzzle is that his application is not > using sendfile(), without which no transmit checksum offload > can take place. As far as I've understood, sendfile() won't do much good with large files. Is this right? We're talking of 3-6GB files here ... roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From morningmart@lycos.co.kr Wed Oct 23 06:56:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 06:56:41 -0700 (PDT) Received: from lycos.co.kr ([61.75.79.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NDucuR026375 for ; Wed, 23 Oct 2002 06:56:39 -0700 Message-Id: <200210231356.g9NDucuR026375@oss.sgi.com> Reply-To: morningmart@lycos.co.kr From: To: Subject: =?ISO-8859-1?Q?(=B1=A4=B0=ED)=20=B8=C6=B9=DD=BC=AE?= =?ISO-8859-1?Q?=BB=E7=BF=EC=B3=AA=B7=CE=20=BF=C2=B0=A1=C1=B7=C0=C7?= =?ISO-8859-1?Q?=C3=BC=C1=DF=C1=B6=C0=FD=20=B9=D7=20=B0=C7=B0=AD=C0=BB?= =?ISO-8859-1?Q?=C1=F6=C5=B0=BC=BC=BF=E4~?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 23 Oct 2002 22:56:47 +0900 X-archive-position: 905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: morningmart@lycos.co.kr Precedence: bulk X-list: netdev
copyright(c)2000 co.,Ltd. All rights reserved.
080-276-0007 webmaster@diet007.co.kr
[] .
.
[] . .
(Please click here to remove your address from our mailing list. Sorry for the trouble.)

                                                                    

From niv@us.ibm.com Wed Oct 23 07:57:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 07:57:11 -0700 (PDT) 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 g9NEv9uR002106 for ; Wed, 23 Oct 2002 07:57:09 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NEuXgW102810; Wed, 23 Oct 2002 10:56:33 -0400 Received: from us.ibm.com (sig-9-65-10-220.mts.ibm.com [9.65.10.220]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NEv0kW065292; Wed, 23 Oct 2002 08:57:01 -0600 Message-ID: <3DB6B798.1523042A@us.ibm.com> Date: Wed, 23 Oct 2002 07:52:08 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: vda@port.imtp.ilyichevsk.odessa.ua CC: Roy Sigurd Karlsbakk , netdev@oss.sgi.com Subject: Re: [RESEND] tuning linux for high network performance? References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 906 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 Denis Vlasenko wrote: > I know zero about networking, but why 120 000 csum_partial_copy_generic > and inly 20 000 nic interrupts? That may be abnormal. > -- > vda Because firstly, we pick up several packets per interrupt, and additionally, the function is also called on the send side. thanks, Nivedita From niv@us.ibm.com Wed Oct 23 08:04:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 08:04:25 -0700 (PDT) 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 g9NF4NuR003578 for ; Wed, 23 Oct 2002 08:04:23 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NF4N6k031254; Wed, 23 Oct 2002 11:04:23 -0400 Received: from us.ibm.com (sig-9-65-10-220.mts.ibm.com [9.65.10.220]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NF4oKN096716; Wed, 23 Oct 2002 09:04:51 -0600 Message-ID: <3DB6B96F.A0DE47BF@us.ibm.com> Date: Wed, 23 Oct 2002 07:59:59 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bert hubert CC: Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? References: <200210231218.18733.roy@karlsbakk.net> <200210231306.18422.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 907 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 bert hubert wrote: > > ...adding the whole profile output - sorted by the first column this time... > > > > 905182 total 0.4741 > > 121426 csum_partial_copy_generic 474.3203 > > 93633 default_idle 1800.6346 > > 74665 do_wp_page 111.1086 > > Perhaps the 'copy' also entails grabbing the page from disk, leading to > inflated csum_partial_copy_generic stats? I think this is strictly a copy from user space->kernel and vice versa. This shouldnt include the disk access etc. thanks, Nivedita From roy@karlsbakk.net Wed Oct 23 08:18:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 08:18:41 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NFIauR009789 for ; Wed, 23 Oct 2002 08:18:37 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9NFJGG13394; Wed, 23 Oct 2002 17:19:16 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: Nivedita Singhvi , bert hubert Subject: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) Date: Wed, 23 Oct 2002 17:26:21 +0200 User-Agent: KMail/1.4.1 Cc: netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <3DB6B96F.A0DE47BF@us.ibm.com> In-Reply-To: <3DB6B96F.A0DE47BF@us.ibm.com> MIME-Version: 1.0 Message-Id: <200210231726.21135.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9NFIauR009789 X-archive-position: 908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev On Wednesday 23 October 2002 16:59, Nivedita Singhvi wrote: > bert hubert wrote: > > > ...adding the whole profile output - sorted by the first column this > > > time... > > > > > > 905182 total 0.4741 > > > 121426 csum_partial_copy_generic 474.3203 > > > 93633 default_idle 1800.6346 > > > 74665 do_wp_page 111.1086 > > > > Perhaps the 'copy' also entails grabbing the page from disk, leading to > > inflated csum_partial_copy_generic stats? > > I think this is strictly a copy from user space->kernel and vice versa. > This shouldnt include the disk access etc. hm I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then. any chance of using O_DIRECT to the socket? -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From blueflux@koffein.net Wed Oct 23 08:52:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 08:52:08 -0700 (PDT) Received: from laptop1.agatha ([195.163.42.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NFq5uR017603 for ; Wed, 23 Oct 2002 08:52:06 -0700 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id g9NFl7u02248 for ; Wed, 23 Oct 2002 17:47:07 +0200 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Wed, 23 Oct 2002 17:47:07 +0200 (CEST) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: netdev@oss.sgi.com Subject: [release] ipsysctl tutorial 1.0.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 909 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 all, First of all, I hope this is no inconvenience to anyone, but I thought it may be of interest to some people on the netdev mailinglist as well. Just to inform people who may be interested, the ipsysctl tutorial has been released in a new version at http://ipsysctl-tutorial.frozentux.net. There are a lot of bugfixes in the new version, but no big additions at this time. I hope to spend more time the upcoming weeks with adding explanations about the route/ and neigh/ part of the sysctl's though. Comments are welcome, as always. Before anyone asks this time, no I will not add explanations of the IPv6 sysctl's at this time since I want to finish up what I have begun before I even think about that;). However, if anyone wants to, they are more than welcome to write those sections up themselves and send to me for inclusion. Sorry for taking your time, I hope this will be of some help. ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net From kquest@unital.com Wed Oct 23 08:53:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 08:53:58 -0700 (PDT) Received: from mango.he.net (mango.he.net [66.220.11.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NFruuR018072 for ; Wed, 23 Oct 2002 08:53:56 -0700 Received: from leachlap5328 (pool-151-203-61-117.bos.east.verizon.net [151.203.61.117]) by mango.he.net (8.8.6/8.8.2) with SMTP id IAA11354; Wed, 23 Oct 2002 08:53:52 -0700 Message-ID: <01b901c27aac$4bab0d20$0506330a@leachlap5328> From: "Kyle C Quest" To: Cc: References: <20021004.001929.03389091.yoshfuji@linux-ipv6.org><200210031552.TAA29921@sex.inr.ac.ru> <20021023.162439.114324450.yoshfuji@linux-ipv6.org> Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) Date: Wed, 23 Oct 2002 11:53:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-archive-position: 910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kquest@unital.com Precedence: bulk X-list: netdev I'm just curious... what happened to the generic option, SO_ONEFAMILY, that would replace the need for IPV6_V6ONLY? > In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > Actually, it would be great if you said what is wrong in that my patch? > > It looks so simple that I am not ready to agree that real one should be > > so complicated. :-) > > Well, I've refered alexey's patch and simplified many if-clauses. > Here's the new patch and test results. seems ok. > > -------------------- > Linux IPv6 stack provides the ability for IPv6 applications to > interoperate with IPv4 applications. Port space for TCP (or UDP) is > shared by IPv6 and IPv4. This conforms to RFC2553. > However, some kind of applications may want to restrict their use of > an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is > defined for such applications in RFC2553bis, which is successor of RFC2553. > This patch allows to bind both IPv6 and IPv4 sockets with the single > port number at the same time if IPV6_V6ONLY socket options is set to > the IPv6 socket. > > Packet delivery strategy is similar to one before, but we prefer > IPv4 a bit. > > Test results and patch against 2.4.20-pre11 follows. > > *** Test for bind(2) *** > > [SOCK_DGRAM w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x x x x > :: x x x x > 127.1 x x x o > ::1 x x o x > > ==> OK > > [SOCK_DGRAM w/ IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x o x o > :: o x o x > 127.1 x o x o > ::1 o x o x > > ==> OK > > [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_STREAM w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x x x x > :: x x x x > 127.1 x x x o > ::1 x x o x > > ==> OK > > [SOCK_STREAM w/ IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x o x o > :: o x o x > 127.1 x o x o > ::1 o x o x > > ==> OK > > [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > *** Test for Receiver *** > > [IPv6] > 1a. :: <- ::1 > received from ::1 > > 1b. :: w/IPV6_V6ONLY <- ::1 > received from ::1 > > 2a. :: <- 127.0.0.1 > received from ::1 > > 2b. :: w/IPV6_V6ONLY <- 127.0.0.1 > none received > > 3a. :: <- ff02::1 > received from fe80::EUI64 > > 3b. :: w/IPV6_V6ONLY <- ff02::1 > received from fe80::EUI64 > > 4a. :: <- 224.0.0.1 > received from ::ffff:ipv4addr > > 4b. :: w/IPV6_V6ONLY <- 224.0.0.1 > none received > > ==> OK > > [IPv4] > 1. 0.0.0.0 <- ::1 > none received > > 2. 0.0.0.0 <- 127.0.0.1 > received from 127.0.0.1 > > 3. 0.0.0.0 <- ff02::1 > none received > > 4. 0.0.0.0 <- 224.0.0.1 > received from ipv4addr > > ==> OK > > [IPv6 vs IPv4] > 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1 > ipv6 received from ::1 > > 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1 > ipv4 received from 127.0.0.1 > > 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1 > ipv6 received from fe80::EUI64 > > 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1 > ipv4 received from ipv4addra > > ==> OK > > ------------------------------------------------------------------- > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) - Rev.2 > Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023 > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > Credit: YOSHIFUJI Hideaki / USAGI Project > Reference: RFC2553bis > ------------------------------------------------------------------- > Index: Documentation/networking/ip-sysctl.txt > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt ,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.42.1 > diff -u -r1.1.1.1 -r1.1.1.1.42.1 > --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 1.1.1.1 > +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 1.1.1.1.42.1 > @@ -462,6 +462,15 @@ > IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ also > apply to IPv6 [XXX?]. > > +bindv6only - BOOLEAN > + Default value for IPV6_V6ONLY socket option, > + which restricts use of the IPv6 socket to IPv6 communication > + only. > + TRUE: disable IPv4-mapped address feature > + FALSE: enable IPv4-mapped address feature > + > + Default: FALSE (as specified in RFC2553bis) > + > conf/default/*: > Change the interface-specific default settings. > > Index: include/linux/in6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1 > +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -156,6 +156,7 @@ > #define IPV6_MTU_DISCOVER 23 > #define IPV6_MTU 24 > #define IPV6_RECVERR 25 > +#define IPV6_V6ONLY 26 > > /* IPV6_MTU_DISCOVER values */ > #define IPV6_PMTUDISC_DONT 0 > Index: include/linux/sysctl.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 > +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -345,7 +345,8 @@ > enum { > NET_IPV6_CONF=16, > NET_IPV6_NEIGH=17, > - NET_IPV6_ROUTE=18 > + NET_IPV6_ROUTE=18, > + NET_IPV6_BINDV6ONLY=20, > }; > > enum { > Index: include/net/ipv6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.38.1 > diff -u -r1.1.1.1 -r1.1.1.1.38.1 > --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1 > @@ -88,6 +88,9 @@ > > #include > > +/* sysctls */ > +extern int sysctl_ipv6_bindv6only; > + > extern struct ipv6_mib ipv6_statistics[NR_CPUS*2]; > #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field) > #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field) > Index: include/net/sock.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -171,7 +171,8 @@ > __u8 mc_loop:1, > recverr:1, > sndflow:1, > - pmtudisc:2; > + pmtudisc:2, > + ipv6only:1; > > struct ipv6_mc_socklist *ipv6_mc_list; > struct ipv6_fl_socklist *ipv6_fl_list; > @@ -188,6 +189,12 @@ > struct icmp6_filter filter; > }; > > +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only) > +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \ > + (sk)->net_pinfo.af_inet6.ipv6only) > +#else > +#define __ipv6_only_sock(sk) 0 > +#define ipv6_only_sock(sk) 0 > #endif /* IPV6 */ > > #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE) > Index: net/ipv4/tcp_ipv4.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.2 > diff -u -r1.1.1.2 -r1.1.1.2.16.2 > --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2 > +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 > @@ -45,9 +45,13 @@ > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > * Andi Kleen : Fix new listen. > * Andi Kleen : Fix accept error reporting. > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > */ > > #include > + > #include > #include > #include > @@ -182,6 +186,7 @@ > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > if (sk != sk2 && > sk2->reuse <= 1 && > + !ipv6_only_sock(sk2) && > sk->bound_dev_if == sk2->bound_dev_if) { > if (!sk_reuse || > !sk2->reuse || > @@ -418,23 +423,27 @@ > struct sock *result = NULL; > int score, hiscore; > > - hiscore=0; > + hiscore=-1; > for(; sk; sk = sk->next) { > - if(sk->num == hnum) { > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > __u32 rcv_saddr = sk->rcv_saddr; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = sk->family == PF_INET ? 1 : 0; > +#else > score = 1; > +#endif > if(rcv_saddr) { > if (rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if (sk->bound_dev_if) { > if (sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if (score == 3) > + if (score == 5) > return sk; > if (score > hiscore) { > hiscore = score; > @@ -456,6 +465,7 @@ > if (sk->num == hnum && > sk->next == NULL && > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > + (sk->family == PF_INET || !ipv6_only_sock(sk)) && > !sk->bound_dev_if) > goto sherry_cache; > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > Index: net/ipv4/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -61,6 +61,9 @@ > * return ENOTCONN for unconnected sockets (POSIX) > * Janos Farkas : don't deliver multi/broadcasts to a different > * bound-to-device socket > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * > * This program is free software; you can redistribute it and/or > @@ -85,6 +88,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -159,6 +163,7 @@ > sk2 = sk2->next) { > if (sk2->num == snum && > sk2 != sk && > + !ipv6_only_sock(sk2) && > sk2->bound_dev_if == sk->bound_dev_if && > (!sk2->rcv_saddr || > !sk->rcv_saddr || > @@ -215,29 +220,34 @@ > int badness = -1; > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { > - if(sk->num == hnum) { > - int score = 0; > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > + int score; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = sk->family == PF_INET ? 1 : 0; > +#else > + score = 1; > +#endif > if(sk->rcv_saddr) { > if(sk->rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if(sk->daddr) { > if(sk->daddr != saddr) > continue; > - score++; > + score+=2; > } > if(sk->dport) { > if(sk->dport != sport) > continue; > - score++; > + score+=2; > } > if(sk->bound_dev_if) { > if(sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if(score == 4) { > + if(score == 9) { > result = sk; > break; > } else if(score > badness) { > @@ -273,6 +283,7 @@ > (s->daddr && s->daddr!=rmt_addr) || > (s->dport != rmt_port && s->dport != 0) || > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > + ipv6_only_sock(s) || > (s->bound_dev_if && s->bound_dev_if != dif)) > continue; > break; > Index: net/ipv6/af_inet6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.36.1 > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > @@ -88,6 +88,8 @@ > extern void ipv6_sysctl_unregister(void); > #endif > > +int sysctl_ipv6_bindv6only; > + > #ifdef INET_REFCNT_DEBUG > atomic_t inet6_sock_nr; > #endif > @@ -173,6 +175,8 @@ > sk->net_pinfo.af_inet6.mc_loop = 1; > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only; > + > /* Init the ipv4 part of the socket since we can have sockets > * using v6 API for ipv4. > */ > Index: net/ipv6/ipv6_sockglue.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.36.1 > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > @@ -157,7 +157,8 @@ > break; > } > > - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > + if (ipv6_only_sock(sk) || > + !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > retv = -EADDRNOTAVAIL; > break; > } > @@ -203,6 +204,13 @@ > } > goto e_inval; > > + case IPV6_V6ONLY: > + if (sk->num) > + goto e_inval; > + np->ipv6only = valbool; > + retv = 0; > + break; > + > case IPV6_PKTINFO: > np->rxopt.bits.rxinfo = valbool; > retv = 0; > @@ -465,6 +473,10 @@ > return -ENOTCONN; > break; > } > + > + case IPV6_V6ONLY: > + val = np->ipv6only; > + break; > > case IPV6_PKTINFO: > val = np->rxopt.bits.rxinfo; > Index: net/ipv6/sysctl_net_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -17,6 +17,8 @@ > > ctl_table ipv6_table[] = { > {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, > + {NET_IPV6_BINDV6ONLY, "bindv6only", > + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, > {0} > }; > > Index: net/ipv6/tcp_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -14,6 +14,9 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -148,14 +151,23 @@ > !sk2->reuse || > sk2->state == TCP_LISTEN) { > /* NOTE: IPv6 tw bucket have different format */ > - if (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - sk2->state != TCP_TIME_WAIT ? > - &sk2->net_pinfo.af_inet6.rcv_saddr : > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > - sk->rcv_saddr==sk2->rcv_saddr)) > + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > + (sk2->family == AF_INET6 && > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > + (addr_type == IPV6_ADDR_ANY && > + (!ipv6_only_sock(sk) || > + !(sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED : 1))) || > + (sk2->family == AF_INET6 && > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > + sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) || > + (addr_type == IPV6_ADDR_MAPPED && > + !ipv6_only_sock(sk2) && > + (!sk2->rcv_saddr || > + !sk->rcv_saddr || > + sk->rcv_saddr == sk2->rcv_saddr))) > break; > } > } > @@ -601,6 +613,9 @@ > struct sockaddr_in sin; > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > + > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_port = usin->sin6_port; > Index: net/ipv6/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -11,6 +11,9 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -106,13 +109,21 @@ > if (sk2->num == snum && > sk2 != sk && > sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > + ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > + (sk2->family == AF_INET6 && > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > + (addr_type == IPV6_ADDR_ANY && > + (!ipv6_only_sock(sk) || > + !(sk2->family == AF_INET6 ? (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) : 1))) || > + (sk2->family == AF_INET6 && > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > + &sk2->net_pinfo.af_inet6.rcv_saddr)) || > (addr_type == IPV6_ADDR_MAPPED && > - sk2->family == AF_INET && > - sk->rcv_saddr == sk2->rcv_saddr)) && > + !ipv6_only_sock(sk2) && > + (!sk2->rcv_saddr || > + !sk->rcv_saddr || > + sk->rcv_saddr == sk2->rcv_saddr))) && > (!sk2->reuse || !sk->reuse)) > goto fail; > } > @@ -221,6 +232,8 @@ > int err; > > if (usin->sin6_family == AF_INET) { > + if (__ipv6_only_sock(sk)) > + return -EAFNOSUPPORT; > err = udp_connect(sk, uaddr, addr_len); > goto ipv4_connected; > } > @@ -256,6 +269,9 @@ > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > + > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > sin.sin_port = usin->sin6_port; > @@ -783,8 +799,11 @@ > fl.oif = 0; > > if (sin6) { > - if (sin6->sin6_family == AF_INET) > + if (sin6->sin6_family == AF_INET) { > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > return udp_sendmsg(sk, msg, ulen); > + } > > if (addr_len < SIN6_LEN_RFC2133) > return -EINVAL; > @@ -830,6 +849,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > + > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > From pekkas@netcore.fi Wed Oct 23 09:06:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 09:06:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NG6auR019652 for ; Wed, 23 Oct 2002 09:06:37 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NG68c01550; Wed, 23 Oct 2002 19:06:08 +0300 Date: Wed, 23 Oct 2002 19:06:08 +0300 (EEST) From: Pekka Savola To: Kyle C Quest cc: yoshfuji@linux-ipv6.org, Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) In-Reply-To: <01b901c27aac$4bab0d20$0506330a@leachlap5328> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 911 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 Wed, 23 Oct 2002, Kyle C Quest wrote: > I'm just curious... what happened to the generic option, SO_ONEFAMILY, that > would replace > the need for IPV6_V6ONLY? This kind of thing is only applicable to IPv4 and IPv6 (and badly even there), there is no use trying to generalize it -- the idea was discarded. > > In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002 > 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > > > Actually, it would be great if you said what is wrong in that my patch? > > > It looks so simple that I am not ready to agree that real one should be > > > so complicated. :-) > > > > Well, I've refered alexey's patch and simplified many if-clauses. > > Here's the new patch and test results. seems ok. > > > > -------------------- > > Linux IPv6 stack provides the ability for IPv6 applications to > > interoperate with IPv4 applications. Port space for TCP (or UDP) is > > shared by IPv6 and IPv4. This conforms to RFC2553. > > However, some kind of applications may want to restrict their use of > > an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is > > defined for such applications in RFC2553bis, which is successor of > RFC2553. > > This patch allows to bind both IPv6 and IPv4 sockets with the single > > port number at the same time if IPV6_V6ONLY socket options is set to > > the IPv6 socket. > > > > Packet delivery strategy is similar to one before, but we prefer > > IPv4 a bit. > > > > Test results and patch against 2.4.20-pre11 follows. > > > > *** Test for bind(2) *** > > > > [SOCK_DGRAM w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x x x x > > :: x x x x > > 127.1 x x x o > > ::1 x x o x > > > > ==> OK > > > > [SOCK_DGRAM w/ IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x o x o > > :: o x o x > > 127.1 x o x o > > ::1 o x o x > > > > ==> OK > > > > [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > [SOCK_STREAM w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x x x x > > :: x x x x > > 127.1 x x x o > > ::1 x x o x > > > > ==> OK > > > > [SOCK_STREAM w/ IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x o x o > > :: o x o x > > 127.1 x o x o > > ::1 o x o x > > > > ==> OK > > > > [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > *** Test for Receiver *** > > > > [IPv6] > > 1a. :: <- ::1 > > received from ::1 > > > > 1b. :: w/IPV6_V6ONLY <- ::1 > > received from ::1 > > > > 2a. :: <- 127.0.0.1 > > received from ::1 > > > > 2b. :: w/IPV6_V6ONLY <- 127.0.0.1 > > none received > > > > 3a. :: <- ff02::1 > > received from fe80::EUI64 > > > > 3b. :: w/IPV6_V6ONLY <- ff02::1 > > received from fe80::EUI64 > > > > 4a. :: <- 224.0.0.1 > > received from ::ffff:ipv4addr > > > > 4b. :: w/IPV6_V6ONLY <- 224.0.0.1 > > none received > > > > ==> OK > > > > [IPv4] > > 1. 0.0.0.0 <- ::1 > > none received > > > > 2. 0.0.0.0 <- 127.0.0.1 > > received from 127.0.0.1 > > > > 3. 0.0.0.0 <- ff02::1 > > none received > > > > 4. 0.0.0.0 <- 224.0.0.1 > > received from ipv4addr > > > > ==> OK > > > > [IPv6 vs IPv4] > > 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1 > > ipv6 received from ::1 > > > > 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1 > > ipv4 received from 127.0.0.1 > > > > 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1 > > ipv6 received from fe80::EUI64 > > > > 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1 > > ipv4 received from ipv4addra > > > > ==> OK > > > > ------------------------------------------------------------------- > > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number > (IPV6_V6ONLY Support) - Rev.2 > > Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023 > > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > > Credit: YOSHIFUJI Hideaki / USAGI Project > > Reference: RFC2553bis > > ------------------------------------------------------------------- > > Index: Documentation/networking/ip-sysctl.txt > > =================================================================== > > RCS file: > /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt > ,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.42.1 > > diff -u -r1.1.1.1 -r1.1.1.1.42.1 > > --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 > 1.1.1.1 > > +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 > 1.1.1.1.42.1 > > @@ -462,6 +462,15 @@ > > IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ > also > > apply to IPv6 [XXX?]. > > > > +bindv6only - BOOLEAN > > + Default value for IPV6_V6ONLY socket option, > > + which restricts use of the IPv6 socket to IPv6 communication > > + only. > > + TRUE: disable IPv4-mapped address feature > > + FALSE: enable IPv4-mapped address feature > > + > > + Default: FALSE (as specified in RFC2553bis) > > + > > conf/default/*: > > Change the interface-specific default settings. > > > > Index: include/linux/in6.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1 > > +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -156,6 +156,7 @@ > > #define IPV6_MTU_DISCOVER 23 > > #define IPV6_MTU 24 > > #define IPV6_RECVERR 25 > > +#define IPV6_V6ONLY 26 > > > > /* IPV6_MTU_DISCOVER values */ > > #define IPV6_PMTUDISC_DONT 0 > > Index: include/linux/sysctl.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.1 > > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > > --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 > > +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > > @@ -345,7 +345,8 @@ > > enum { > > NET_IPV6_CONF=16, > > NET_IPV6_NEIGH=17, > > - NET_IPV6_ROUTE=18 > > + NET_IPV6_ROUTE=18, > > + NET_IPV6_BINDV6ONLY=20, > > }; > > > > enum { > > Index: include/net/ipv6.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.38.1 > > diff -u -r1.1.1.1 -r1.1.1.1.38.1 > > --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > > +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1 > > @@ -88,6 +88,9 @@ > > > > #include > > > > +/* sysctls */ > > +extern int sysctl_ipv6_bindv6only; > > + > > extern struct ipv6_mib ipv6_statistics[NR_CPUS*2]; > > #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field) > > #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field) > > Index: include/net/sock.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > > +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -171,7 +171,8 @@ > > __u8 mc_loop:1, > > recverr:1, > > sndflow:1, > > - pmtudisc:2; > > + pmtudisc:2, > > + ipv6only:1; > > > > struct ipv6_mc_socklist *ipv6_mc_list; > > struct ipv6_fl_socklist *ipv6_fl_list; > > @@ -188,6 +189,12 @@ > > struct icmp6_filter filter; > > }; > > > > +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only) > > +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \ > > + (sk)->net_pinfo.af_inet6.ipv6only) > > +#else > > +#define __ipv6_only_sock(sk) 0 > > +#define ipv6_only_sock(sk) 0 > > #endif /* IPV6 */ > > > > #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE) > > Index: net/ipv4/tcp_ipv4.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.2 > > diff -u -r1.1.1.2 -r1.1.1.2.16.2 > > --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2 > > +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 > > @@ -45,9 +45,13 @@ > > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > > * Andi Kleen : Fix new listen. > > * Andi Kleen : Fix accept error reporting. > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > */ > > > > #include > > + > > #include > > #include > > #include > > @@ -182,6 +186,7 @@ > > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > > if (sk != sk2 && > > sk2->reuse <= 1 && > > + !ipv6_only_sock(sk2) && > > sk->bound_dev_if == sk2->bound_dev_if) { > > if (!sk_reuse || > > !sk2->reuse || > > @@ -418,23 +423,27 @@ > > struct sock *result = NULL; > > int score, hiscore; > > > > - hiscore=0; > > + hiscore=-1; > > for(; sk; sk = sk->next) { > > - if(sk->num == hnum) { > > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > > __u32 rcv_saddr = sk->rcv_saddr; > > > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > > + score = sk->family == PF_INET ? 1 : 0; > > +#else > > score = 1; > > +#endif > > if(rcv_saddr) { > > if (rcv_saddr != daddr) > > continue; > > - score++; > > + score+=2; > > } > > if (sk->bound_dev_if) { > > if (sk->bound_dev_if != dif) > > continue; > > - score++; > > + score+=2; > > } > > - if (score == 3) > > + if (score == 5) > > return sk; > > if (score > hiscore) { > > hiscore = score; > > @@ -456,6 +465,7 @@ > > if (sk->num == hnum && > > sk->next == NULL && > > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > > + (sk->family == PF_INET || !ipv6_only_sock(sk)) && > > !sk->bound_dev_if) > > goto sherry_cache; > > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > > Index: net/ipv4/udp.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -61,6 +61,9 @@ > > * return ENOTCONN for unconnected sockets (POSIX) > > * Janos Farkas : don't deliver multi/broadcasts to a different > > * bound-to-device socket > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > * > > * > > * This program is free software; you can redistribute it and/or > > @@ -85,6 +88,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -159,6 +163,7 @@ > > sk2 = sk2->next) { > > if (sk2->num == snum && > > sk2 != sk && > > + !ipv6_only_sock(sk2) && > > sk2->bound_dev_if == sk->bound_dev_if && > > (!sk2->rcv_saddr || > > !sk->rcv_saddr || > > @@ -215,29 +220,34 @@ > > int badness = -1; > > > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = > sk->next) { > > - if(sk->num == hnum) { > > - int score = 0; > > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > > + int score; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > > + score = sk->family == PF_INET ? 1 : 0; > > +#else > > + score = 1; > > +#endif > > if(sk->rcv_saddr) { > > if(sk->rcv_saddr != daddr) > > continue; > > - score++; > > + score+=2; > > } > > if(sk->daddr) { > > if(sk->daddr != saddr) > > continue; > > - score++; > > + score+=2; > > } > > if(sk->dport) { > > if(sk->dport != sport) > > continue; > > - score++; > > + score+=2; > > } > > if(sk->bound_dev_if) { > > if(sk->bound_dev_if != dif) > > continue; > > - score++; > > + score+=2; > > } > > - if(score == 4) { > > + if(score == 9) { > > result = sk; > > break; > > } else if(score > badness) { > > @@ -273,6 +283,7 @@ > > (s->daddr && s->daddr!=rmt_addr) || > > (s->dport != rmt_port && s->dport != 0) || > > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > > + ipv6_only_sock(s) || > > (s->bound_dev_if && s->bound_dev_if != dif)) > > continue; > > break; > > Index: net/ipv6/af_inet6.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.36.1 > > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > > --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > > @@ -88,6 +88,8 @@ > > extern void ipv6_sysctl_unregister(void); > > #endif > > > > +int sysctl_ipv6_bindv6only; > > + > > #ifdef INET_REFCNT_DEBUG > > atomic_t inet6_sock_nr; > > #endif > > @@ -173,6 +175,8 @@ > > sk->net_pinfo.af_inet6.mc_loop = 1; > > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > > > + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only; > > + > > /* Init the ipv4 part of the socket since we can have sockets > > * using v6 API for ipv4. > > */ > > Index: net/ipv6/ipv6_sockglue.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.36.1 > > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > > --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > > @@ -157,7 +157,8 @@ > > break; > > } > > > > - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > > + if (ipv6_only_sock(sk) || > > + !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > > retv = -EADDRNOTAVAIL; > > break; > > } > > @@ -203,6 +204,13 @@ > > } > > goto e_inval; > > > > + case IPV6_V6ONLY: > > + if (sk->num) > > + goto e_inval; > > + np->ipv6only = valbool; > > + retv = 0; > > + break; > > + > > case IPV6_PKTINFO: > > np->rxopt.bits.rxinfo = valbool; > > retv = 0; > > @@ -465,6 +473,10 @@ > > return -ENOTCONN; > > break; > > } > > + > > + case IPV6_V6ONLY: > > + val = np->ipv6only; > > + break; > > > > case IPV6_PKTINFO: > > val = np->rxopt.bits.rxinfo; > > Index: net/ipv6/sysctl_net_ipv6.c > > =================================================================== > > RCS file: > /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -17,6 +17,8 @@ > > > > ctl_table ipv6_table[] = { > > {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, > > + {NET_IPV6_BINDV6ONLY, "bindv6only", > > + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, > > {0} > > }; > > > > Index: net/ipv6/tcp_ipv6.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.1 > > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > > --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > > +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > > @@ -14,6 +14,9 @@ > > * > > * Fixes: > > * Hideaki YOSHIFUJI : sin6_scope_id support > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > * > > * This program is free software; you can redistribute it and/or > > * modify it under the terms of the GNU General Public License > > @@ -148,14 +151,23 @@ > > !sk2->reuse || > > sk2->state == TCP_LISTEN) { > > /* NOTE: IPv6 tw bucket have different format */ > > - if (!sk2->rcv_saddr || > > - addr_type == IPV6_ADDR_ANY || > > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > - sk2->state != TCP_TIME_WAIT ? > > - &sk2->net_pinfo.af_inet6.rcv_saddr : > > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > > - sk->rcv_saddr==sk2->rcv_saddr)) > > + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > > + (sk2->family == AF_INET6 && > > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > > + (addr_type == IPV6_ADDR_ANY && > > + (!ipv6_only_sock(sk) || > > + !(sk2->family == AF_INET6 ? > ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED : > 1))) || > > + (sk2->family == AF_INET6 && > > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > + sk2->state != TCP_TIME_WAIT ? > > + &sk2->net_pinfo.af_inet6.rcv_saddr : > > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) || > > + (addr_type == IPV6_ADDR_MAPPED && > > + !ipv6_only_sock(sk2) && > > + (!sk2->rcv_saddr || > > + !sk->rcv_saddr || > > + sk->rcv_saddr == sk2->rcv_saddr))) > > break; > > } > > } > > @@ -601,6 +613,9 @@ > > struct sockaddr_in sin; > > > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > > + > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > > > sin.sin_family = AF_INET; > > sin.sin_port = usin->sin6_port; > > Index: net/ipv6/udp.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.1 > > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > > --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > > +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > > @@ -11,6 +11,9 @@ > > * > > * Fixes: > > * Hideaki YOSHIFUJI : sin6_scope_id support > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > * > > * This program is free software; you can redistribute it and/or > > * modify it under the terms of the GNU General Public License > > @@ -106,13 +109,21 @@ > > if (sk2->num == snum && > > sk2 != sk && > > sk2->bound_dev_if == sk->bound_dev_if && > > - (!sk2->rcv_saddr || > > - addr_type == IPV6_ADDR_ANY || > > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > > + ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > > + (sk2->family == AF_INET6 && > > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > > + (addr_type == IPV6_ADDR_ANY && > > + (!ipv6_only_sock(sk) || > > + !(sk2->family == AF_INET6 ? > (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) : > 1))) || > > + (sk2->family == AF_INET6 && > > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > + &sk2->net_pinfo.af_inet6.rcv_saddr)) || > > (addr_type == IPV6_ADDR_MAPPED && > > - sk2->family == AF_INET && > > - sk->rcv_saddr == sk2->rcv_saddr)) && > > + !ipv6_only_sock(sk2) && > > + (!sk2->rcv_saddr || > > + !sk->rcv_saddr || > > + sk->rcv_saddr == sk2->rcv_saddr))) && > > (!sk2->reuse || !sk->reuse)) > > goto fail; > > } > > @@ -221,6 +232,8 @@ > > int err; > > > > if (usin->sin6_family == AF_INET) { > > + if (__ipv6_only_sock(sk)) > > + return -EAFNOSUPPORT; > > err = udp_connect(sk, uaddr, addr_len); > > goto ipv4_connected; > > } > > @@ -256,6 +269,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > > struct sockaddr_in sin; > > > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > + > > sin.sin_family = AF_INET; > > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > sin.sin_port = usin->sin6_port; > > @@ -783,8 +799,11 @@ > > fl.oif = 0; > > > > if (sin6) { > > - if (sin6->sin6_family == AF_INET) > > + if (sin6->sin6_family == AF_INET) { > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > return udp_sendmsg(sk, msg, ulen); > > + } > > > > if (addr_len < SIN6_LEN_RFC2133) > > return -EINVAL; > > @@ -830,6 +849,9 @@ > > > > if (addr_type == IPV6_ADDR_MAPPED) { > > struct sockaddr_in sin; > > + > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > > > sin.sin_family = AF_INET; > > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From kquest@unital.com Wed Oct 23 09:10:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 09:10:17 -0700 (PDT) Received: from mango.he.net (mango.he.net [66.220.11.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NGAFuR020345 for ; Wed, 23 Oct 2002 09:10:15 -0700 Received: from leachlap5328 (pool-151-203-61-117.bos.east.verizon.net [151.203.61.117]) by mango.he.net (8.8.6/8.8.2) with SMTP id JAA13233; Wed, 23 Oct 2002 09:10:17 -0700 Message-ID: <01ed01c27aae$93693900$0506330a@leachlap5328> From: "Kyle C Quest" To: "Pekka Savola" Cc: , References: Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) Date: Wed, 23 Oct 2002 12:09:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-archive-position: 912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kquest@unital.com Precedence: bulk X-list: netdev > > I'm just curious... what happened to the generic option, SO_ONEFAMILY, that > > would replace > > the need for IPV6_V6ONLY? > > This kind of thing is only applicable to IPv4 and IPv6 (and badly even > there), there is no use trying to generalize it -- the idea was discarded. > I see... Thanks for the info From niv@us.ibm.com Wed Oct 23 09:39:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 09:39:01 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NGcxuR009830 for ; Wed, 23 Oct 2002 09:39:00 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NGd1di013276; Wed, 23 Oct 2002 12:39:01 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NGdUKN118586; Wed, 23 Oct 2002 10:39:30 -0600 Message-ID: <3DB6CF9E.327E165F@us.ibm.com> Date: Wed, 23 Oct 2002 09:34:38 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roy Sigurd Karlsbakk CC: bert hubert , netdev@oss.sgi.com, Kernel mailing list Subject: Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <3DB6B96F.A0DE47BF@us.ibm.com> <200210231726.21135.roy@karlsbakk.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 913 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 Roy Sigurd Karlsbakk wrote: > I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then. > > any chance of using O_DIRECT to the socket? Hmm, I'm still not clear on why you cannot use sendfile()? I was not aware of any upper limit to the file size in order for sendfile() to be used? From what little I know, this is exactly the kind of situation that sendfile was intended to benefit. thanks, Nivedita From ahu@outpost.ds9a.nl Wed Oct 23 10:00:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 10:00:57 -0700 (PDT) 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 g9NH0tuR012336 for ; Wed, 23 Oct 2002 10:00:55 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5E88A44D7; Wed, 23 Oct 2002 19:01:02 +0200 (CEST) Date: Wed, 23 Oct 2002 19:01:02 +0200 From: bert hubert To: Roy Sigurd Karlsbakk Cc: "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? Message-ID: <20021023170102.GA5302@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <1035379308.5950.3.camel@rth.ninka.net> <200210231542.48673.roy@karlsbakk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210231542.48673.roy@karlsbakk.net> User-Agent: Mutt/1.3.28i X-archive-position: 914 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, Oct 23, 2002 at 03:42:48PM +0200, Roy Sigurd Karlsbakk wrote: > > The e1000 can very well do hardware checksumming on transmit. > > > > The missing piece of the puzzle is that his application is not > > using sendfile(), without which no transmit checksum offload > > can take place. > > As far as I've understood, sendfile() won't do much good with large files. Is > this right? I still refuse to believe that a 1.8GHz Pentium4 can only checksum 250megabits/second. MD Raid5 does better and they probably don't use a checksum as braindead as that used by TCP. If the checksumming is not the problem, the copying is, which would be a weakness of your hardware. The function profiled does both the copying and the checksumming. But 250megabits/second also seems low. Dave? Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From root@chaos.analogic.com Wed Oct 23 10:09:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 10:09:08 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NH96uR013525 for ; Wed, 23 Oct 2002 10:09:06 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id g9NHBZi14543; Wed, 23 Oct 2002 13:11:35 -0400 Date: Wed, 23 Oct 2002 13:11:35 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: bert hubert cc: Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? In-Reply-To: <20021023170102.GA5302@outpost.ds9a.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, bert hubert wrote: > On Wed, Oct 23, 2002 at 03:42:48PM +0200, Roy Sigurd Karlsbakk wrote: > > > The e1000 can very well do hardware checksumming on transmit. > > > > > > The missing piece of the puzzle is that his application is not > > > using sendfile(), without which no transmit checksum offload > > > can take place. > > > > As far as I've understood, sendfile() won't do much good with large files. Is > > this right? > > I still refuse to believe that a 1.8GHz Pentium4 can only checksum > 250megabits/second. MD Raid5 does better and they probably don't use a > checksum as braindead as that used by TCP. > > If the checksumming is not the problem, the copying is, which would be a > weakness of your hardware. The function profiled does both the copying and > the checksumming. > > But 250megabits/second also seems low. > > Dave? > Ordinary DUAL Pentium 400 MHz machine does this... Calculating CPU speed...done Testing checksum speed...done Testing RAM copy...done Testing I/O port speed...done CPU Clock = 400 MHz checksum speed = 685 Mb/s RAM copy = 1549 Mb/s I/O port speed = 654 kb/s This is 685 megaBYTES per second. checksum speed = 685 Mb/s Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Bush : The Fourth Reich of America From greearb@candelatech.com Wed Oct 23 10:11:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 10:11:25 -0700 (PDT) Received: from grok.yi.org (IDENT:i0jHxzWMIWw6+6PGhjj2d0w33YiORFLX@dhcp101-dsl-usw4.w-link.net [208.161.125.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NHBMuR014137 for ; Wed, 23 Oct 2002 10:11:23 -0700 Received: from candelatech.com (IDENT:LJM7J5SN8C539KR9xAHwiAHocKEBYyE6@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g9NHAtq20308; Wed, 23 Oct 2002 10:10:55 -0700 Message-ID: <3DB6D81F.2050309@candelatech.com> Date: Wed, 23 Oct 2002 10:10:55 -0700 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: bert hubert CC: Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <1035379308.5950.3.camel@rth.ninka.net> <200210231542.48673.roy@karlsbakk.net> <20021023170102.GA5302@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 916 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 bert hubert wrote: > I still refuse to believe that a 1.8GHz Pentium4 can only checksum > 250megabits/second. MD Raid5 does better and they probably don't use a > checksum as braindead as that used by TCP. For what it's worth, I have been able to send and receive 400+ Mbps of traffic, by directional, on the same machine (ie, about 1600 Mbps of payload across the PCI bus) So, it's probably not the e1000 or networking code that is slowing you down. (This was on a 64/66 PCI, Dual-AMD 2Ghz machine though, are you running only 32/33 PCI? If not, where did you find this motherboard!) Have you tried just reading the information from disk and doing everying except the final 'send/write/sendto' ? That would help determine if it is your file reads that are killing you. Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From niv@us.ibm.com Wed Oct 23 10:18:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 10:18:07 -0700 (PDT) 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 g9NHI5uR015172 for ; Wed, 23 Oct 2002 10:18:05 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NHI2TZ035568; Wed, 23 Oct 2002 13:18:02 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NHHEKN105552; Wed, 23 Oct 2002 11:17:15 -0600 Message-ID: <3DB6D877.3D5489DA@us.ibm.com> Date: Wed, 23 Oct 2002 10:12:23 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bert hubert CC: Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <1035379308.5950.3.camel@rth.ninka.net> <200210231542.48673.roy@karlsbakk.net> <20021023170102.GA5302@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 917 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 bert hubert wrote: > I still refuse to believe that a 1.8GHz Pentium4 can only checksum > 250megabits/second. MD Raid5 does better and they probably don't use a > checksum as braindead as that used by TCP. > > If the checksumming is not the problem, the copying is, which would be a > weakness of your hardware. The function profiled does both the copying and > the checksumming. Yep, its not so much the checksumming as the fact that this is done over each byte of data and copied. thanks, Nivedita From root@chaos.analogic.com Wed Oct 23 10:54:50 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 10:54:52 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NHsnuR019521 for ; Wed, 23 Oct 2002 10:54:49 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id g9NHuko15105; Wed, 23 Oct 2002 13:56:46 -0400 Date: Wed, 23 Oct 2002 13:56:46 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Nivedita Singhvi cc: bert hubert , Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? In-Reply-To: <3DB6D877.3D5489DA@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, Nivedita Singhvi wrote: > bert hubert wrote: > > > I still refuse to believe that a 1.8GHz Pentium4 can only checksum > > 250megabits/second. MD Raid5 does better and they probably don't use a > > checksum as braindead as that used by TCP. > > > > If the checksumming is not the problem, the copying is, which would be a > > weakness of your hardware. The function profiled does both the copying and > > the checksumming. > > Yep, its not so much the checksumming as the fact that this is > done over each byte of data and copied. > > thanks, > Nivedita No. It's done over each word (short int) and the actual summation takes place during the address calculation of the next word. This gets you a checksum that is practically free. A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second. It will copy at 1,549 megabytes per second. Those are megaBYTES! If you have slow network performance it has nothing to do with either copy or checksum. Data transmission acts like a low-pass filter. The dominant pole of that transfer function determines the speed, that's why it's called dominant. If you measure a data-rate of 10 megabytes/second. Nothing you do with copy or checksum will affect it to any significant extent. If you have a data-rate of 100 megabytes per second, then any tinkering with copy will have an effective improvement ratio of 100/1,559 ~= 0.064. If you have a data rate of 100 megabytes per second and you tinker with checksum, you get an improvement ratio of 100/685 ~=0.14. These are just not the things that are affecting your performance. If you were to double the checksumming speed, you increase the throughput by 2 * 0.14 = 0.28 with the parameters shown. The TCP/IP checksum is quite nice. It may have been discovered by accident, but it's still nice. It works regardless of whether you have a little endian or big endian machine. It also doesn't wrap so you don't (usually) show a good checksum when the data is bad. It does have the characteristic that if all the bits are inverted, it will checksum good. However, there are not too many real-world scenarios that would result in this inversion. So it's not "brain-dead" as you state. A hardware checksum is really quick because it's really easy. Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Bush : The Fourth Reich of America From niv@us.ibm.com Wed Oct 23 11:12:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 11:12:32 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NICUuR021459 for ; Wed, 23 Oct 2002 11:12:30 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9NIC4di012732; Wed, 23 Oct 2002 14:12:04 -0400 Received: from us.ibm.com (dyn9-47-18-188.beaverton.ibm.com [9.47.18.188]) by westrelay05.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9NICWKN120464; Wed, 23 Oct 2002 12:12:32 -0600 Message-ID: <3DB6E56D.8D930A1D@us.ibm.com> Date: Wed, 23 Oct 2002 11:07:41 -0700 From: Nivedita Singhvi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: root@chaos.analogic.com CC: bert hubert , Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 919 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 "Richard B. Johnson" wrote: > No. It's done over each word (short int) and the actual summation > takes place during the address calculation of the next word. This > gets you a checksum that is practically free. Yep, sorry, word, not byte. My bad. The cost is in the fact that this whole process involves loading each word of the data stream into a register. Which is why I also used to consider the checksum cost as negligible. > A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second. > It will copy at 1,549 megabytes per second. Those are megaBYTES! But then why the difference in the checksum/copy and copy? Are you saying the checksum is not costing you 864 megabytes a second?? thanks, Nivedita From ehh7894@netian.com Wed Oct 23 11:26:15 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 11:26:16 -0700 (PDT) Received: from netian.com ([211.225.221.185]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NIQEuR023596 for ; Wed, 23 Oct 2002 11:26:14 -0700 Message-ID: <268090-2200210323181952980@netian.com> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 Reply-To: ehh7894@netian.com From: "" To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?[=BC=BA=C0=CE=B1=A4=B0=ED].....=C7=D1=B9=F8=B0=A1=C0=D4?= =?ISO-8859-1?Q?=C6=F2=BB=FD=C8=B8=BF=F8=C0=B8=B7=CE............?= Date: Thu, 24 Oct 2002 03:19:52 +0900 MIME-Version: 1.0 Content-Type: text/html; charset=KS_C_5601-1987 Content-Transfer-Encoding: quoted-printable X-archive-position: 920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ehh7894@netian.com Precedence: bulk X-list: netdev

=C1=A4=BA=B8=C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF= =A1 =C0=C7=B0=C5 =C1=A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3=B0=ED =C7=A5=B1=E2=C7=D1 =B1=A4=B0=ED =B8=DE=C0= =CF=C0=D4=B4=CF=B4=D9=2E
=BC=F6=BD=C5=C0=BB =BF=F8=C4=A1 =BE=CA=C0=B8=BD= =C3=B8=E9 <= b>=BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4

            = ;& nbsp;           &nb= sp ;            &= nb sp;            = ;& nbsp;           &nb= sp ;            &= nb sp;            = ;& nbsp;           &nb= sp ;=20  Reject/Remove

       =B9=CC=BC=BA=B3=E2=C0=DA=B4=C2 =C0= =A7=BF=A1 =BC=F6=BD=C5=B0=C5=BA=CE =B8=A6 =C5=AC=B8=AF=C7=CF=BC= =BC=BF=E4

=C5=AC=B8=AF=C7=D1=B9=F8=C0=B8=B7=CE =C6= =F2=BB=FD=C0=BBVIP=B7=CE

 =B8=F0=BD=C3=B0=DA=BD=C0=B4=CF=B4=D9=

=C7=D4=BA=B8=BC=BC=BF=E4 =BE=C6=C1=D6= =C0=EB=C0=D6=B0=ED =BD=BA=B8=B1=C0=D6=BC=AD=BF=E4

=B4=DC=C7=D1=B9=F8=BF=A1=B0=A1=C0=D4=C0=B8= =B7=CE =C6=F2=BB=FD=C0=BB =C1=F1=B1=E6=BC=F6=C0=D6=BC=AD=BF=E4=20

=BE=C6=C1=F7=B5=B5=B4=D9=B4=DE=C0=CC=20 =C8=B8=BF=F8=B5=EE=B7=CF=C0=BB=C7=CF=B0=ED=C0=D6=C1=F6=B4=C2=BE=CA=B0=DA=C1= =D2?

 

From root@chaos.analogic.com Wed Oct 23 11:27:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 11:27:54 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NIRquR024098 for ; Wed, 23 Oct 2002 11:27:53 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id g9NIUMT15327; Wed, 23 Oct 2002 14:30:22 -0400 Date: Wed, 23 Oct 2002 14:30:22 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Nivedita Singhvi cc: bert hubert , Roy Sigurd Karlsbakk , "David S. Miller" , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? In-Reply-To: <3DB6E56D.8D930A1D@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, Nivedita Singhvi wrote: > "Richard B. Johnson" wrote: > > > No. It's done over each word (short int) and the actual summation > > takes place during the address calculation of the next word. This > > gets you a checksum that is practically free. > > Yep, sorry, word, not byte. My bad. The cost is in the fact > that this whole process involves loading each word of the data > stream into a register. Which is why I also used to consider > the checksum cost as negligible. > > > A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second. > > It will copy at 1,549 megabytes per second. Those are megaBYTES! > > But then why the difference in the checksum/copy and copy? > Are you saying the checksum is not costing you 864 megabytes > a second?? Costing you 864 megabytes per second? Lets say the checksum was free. You are then able to INF bytes/per/sec. So it's costing you INF bytes/per/sec? No, it's costing you nothing. If we were not dealing with INF, then 'Cost' is approximately 1/N, not N. Cost is work_done_without_checksum - work_done_with_checksum. Because of the low-pass filter pole, these numbers are practically the same. But, you can get a measurable difference between any two large numbers. This makes the 'cost' seem high. You need to make it relative to make any sense, so a 'goodness' can be expressed as a ratio of the cost and the work having been done. Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Bush : The Fourth Reich of America From rgpo1@spils.com Wed Oct 23 11:55:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 11:55:51 -0700 (PDT) Received: from emumail.com (200-204-150-166.dsl.telesp.net.br [200.204.150.166]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NIteuR027945; Wed, 23 Oct 2002 11:55:44 -0700 Message-Id: <200210231855.g9NIteuR027945@oss.sgi.com> From: "RGPO INFORMATICA LTDA" Subject: =?iso-8859-1?Q?Autoriza=E7ao?= Date: Mon, 21 Oct 2002 17:30:01 -0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 406 X-archive-position: 922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rgpo1@spils.com Precedence: bulk X-list: netdev Somos uma empresa que revedemos produtos de Informatica, e gostariamos de e= nviar nossa Tabela de Pre=E7os, para isso precisamos de sua AUTORIZA=C7AO, = nos envie caso tenha interesse para o e-mail rgpo1@spils.com com o assunto = AUTORIZA=C7AO ou REMOVER se nao interessar R.G.P.OLIVEIRA RGPO INFORMATICA LTDA. Tel/Fax. (11) 6239-8517/5003 e-mail rgpo1@spils.com [[HTML alternate version deleted]] From maxk@qualcomm.com Wed Oct 23 12:41:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 12:41:37 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NJfYuR000379 for ; Wed, 23 Oct 2002 12:41:35 -0700 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g9NJfInS001147; Wed, 23 Oct 2002 12:41:18 -0700 (PDT) Received: from MAXK.qualcomm.com (maxk.qualcomm.com [129.46.176.80]) by crowley.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id g9NJfG38020337; Wed, 23 Oct 2002 12:41:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20021023123707.09b5b168@mail1.qualcomm.com> X-Sender: maxk@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 23 Oct 2002 12:41:15 -0700 To: jamal , David Woodhouse From: "Maksim (Max) Krasnyanskiy" Subject: Re: rtnetlink interface state monitoring problems. Cc: , In-Reply-To: References: <24818.1035226670@passion.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Hi Jamal, >> But Bluetooth devices are not network devices, it seems. There exists no >> current mechanism for notifying anyone of state changes. Should we invent a >> new method of notification using netlink, or should Bluetooth interfaces in >> fact be normal network devices just like IrDA devices are? >> > >I think the only time you should go netdev is when it makes sense to run IP. Totally agree. >Is there IP over bluttooth? Yep. It's called BNEP (Bluetooth Network Encapsulation Protocol) which is bascially an Ethernet emulation. That thing is the netdev of course. >Then you could take advantage of all the nice features provided by netdevices (other >than being IP devices;->). >If not, it probably time for someone to write a generic notification >scheme via netlink. Might be interesting. Max From maxk@qualcomm.com Wed Oct 23 12:42:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 12:42:56 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NJgsuR000782 for ; Wed, 23 Oct 2002 12:42:54 -0700 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g9NJgmnS001222; Wed, 23 Oct 2002 12:42:48 -0700 (PDT) Received: from MAXK.qualcomm.com (maxk.qualcomm.com [129.46.176.80]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id g9NJgjhx008314; Wed, 23 Oct 2002 12:42:46 -0700 (PDT) Message-Id: <5.1.0.14.2.20021023124123.09b83e00@mail1.qualcomm.com> X-Sender: maxk@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 23 Oct 2002 12:42:45 -0700 To: jamal , Tim Hockin From: "Maksim (Max) Krasnyanskiy" Subject: Re: rtnetlink interface state monitoring problems. Cc: David Woodhouse , , In-Reply-To: References: <200210230144.g9N1iDx11822@www.hockin.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev >netlink is a messaging system; so what i am thinking is creating >a event notifier for other devices other than network devices. >Something other non-network devices could use (eg bluetooth). What kind of events are we taking about ? Max From bamex@chol.com Wed Oct 23 13:32:27 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 13:32:29 -0700 (PDT) Received: from localhost ([211.106.148.235]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NKWOuR004810 for ; Wed, 23 Oct 2002 13:32:26 -0700 Message-Id: <200210232032.g9NKWOuR004810@oss.sgi.com> Reply-To: bamex@chol.com From: To: netdev@oss.sgi.com Subject: =?ISO-8859-1?Q?(=BC=BA=C0=CE=B1=A4=B0=ED)=209,900=BF=F8=C0=CC=B8=E9?= =?ISO-8859-1?Q?=BC=F6=B8=B9=C0=BA=20=BE=D6=B7=CE=20=BF=B5=C8=AD=B8=A6?= =?ISO-8859-1?Q?=B4=D9=20=BA=BB=B4=D9?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 24 Oct 2002 05:32:02 +0900 X-archive-position: 925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bamex@chol.com Precedence: bulk X-list: netdev
From 7979@4videostudy.co.kr Wed Oct 23 14:13:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 14:13:18 -0700 (PDT) Received: from 4videostudy.co.kr ([211.214.179.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NLDBuR007951 for ; Wed, 23 Oct 2002 14:13:14 -0700 Message-Id: <200210232113.g9NLDBuR007951@oss.sgi.com> Reply-To: 7979@4videostudy.co.kr From: 7979 <7979@4videostudy.co.kr> To: Subject: =?ISO-8859-1?Q?[=BC=BA=C0=CE=B1=A4=B0=ED]id:samsam?= =?ISO-8859-1?Q?=BA=F1=B9=D0=B9=F8=C8=A3:56328?= =?ISO-8859-1?Q?(=C0=FD=B4=EB=20=BC=BA=C0=CE=B8=B8=20=C5=AC=B8=AF)?= Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 24 Oct 2002 06:13:39 +0900 X-archive-position: 926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: 7979@4videostudy.co.kr Precedence: bulk X-list: netdev Sexydesk.co.kr
50 () .


19 .
.
19 .
. .
82444.com !

.

: sexydesk.co.kr / 363-25
: 109-02-01988
: sexydesk@sexydesk.co.kr

From mauro@ferrara.linux.it Wed Oct 23 14:31:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 14:31:44 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NLVcuR009493 for ; Wed, 23 Oct 2002 14:31:39 -0700 Received: from trantor.ferrara.linux.it (151.26.186.155) by smtp2.libero.it (6.5.028) id 3DA310EC0071FD87; Wed, 23 Oct 2002 13:49:02 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 1D3C42870C; Wed, 23 Oct 2002 13:29:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 0D7352847D; Wed, 23 Oct 2002 13:29:00 +0200 (CEST) Date: Wed, 23 Oct 2002 13:29:00 +0200 (CEST) From: Mauro Tortonesi To: michael@albog.dk Cc: netdev@oss.sgi.com Subject: Re: Fwd: Question about kernel and IPv6... In-Reply-To: <1035360350.3db6585e0bdce@webmail.debianlinux.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mauro@ferrara.linux.it Precedence: bulk X-list: netdev On Wed, 23 Oct 2002 michael@albog.dk wrote: > - What kernel version have most IPv6 features build-in ?? (Maybe a feature is > missing in 2.4.19. I have read an article about patching the kernel: > http://project6.ferrara.linux.it/papers/best_ipv6_support_4_linux/best_ipv6_supp > ort_4_linux.html, it is necessary?). micheal, that article is a bit obsolete. i will update it as soon as possible, but until next week there is no chance i can do it (friday i will get my MS degree in electronic engineering and i am __very__ busy now). however, the choice of the kernel to use is quite simple: if you need the advanced features in usagi kernel (e.g. ISATAP, drop packets with fake ipv4-mapped address, RFC 3041 support, anycast support, allow default route when forwarding is enabled, Node Information Queries, IPSEC, MIPv6, IPv6-in-IPv6 tunneling) you should install the usagi kit. if not, use the standard vanilla kernel. p.s. i wouldn't spend too much time working on ripng. if you wish to analyze routing protocols, perhaps OSPF and BGP4+ would be better choices. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it mauro.tortonesi@ing.unife.it Ferrara Linux Users Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it From ph@digitalquake.com Wed Oct 23 15:32:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 15:32:30 -0700 (PDT) Received: from sun4.digitalquake.com (digitalquake.com [63.205.237.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9NMWSuR019392 for ; Wed, 23 Oct 2002 15:32:28 -0700 Received: from phpc (netscreen-dmz.digitalquake.com [192.168.0.1]) by sun4.digitalquake.com (8.10.2+Sun/8.10.2) with SMTP id g9NMWEM13370; Wed, 23 Oct 2002 15:32:14 -0700 (PDT) From: "Paul Hernandez" To: "Donald Becker" , "Felipe W Damasio" Cc: "Jeff Garzik" , "Linux-net" , Subject: RE: NIC on 2.4.19 SMP (mii-diag output) Date: Wed, 23 Oct 2002 15:32:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-archive-position: 928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ph@digitalquake.com Precedence: bulk X-list: netdev All, Just tried 2.4.20-pre11 and all NIC issues seem to be resolved. Both eepro100 and e100 drivers work correctly. Paul -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Tuesday, October 22, 2002 7:21 PM To: Felipe W Damasio Cc: Paul Hernandez; Jeff Garzik; Linux-net; netdev@oss.sgi.com Subject: RE: NIC on 2.4.19 SMP (mii-diag output) On 22 Oct 2002, Felipe W Damasio wrote: > On Mon, 2002-10-21 at 15:16, Paul Hernandez wrote: > > I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD > > 10baseT > > Advertising no additional info pages. > > IEEE 802.3 CSMA/CD protocol. > > Link partner capability is 0000:. > > Negotiation did not complete. > > The link partner is not advertising it's capabilities. No! There is not link partner. 0000 is the default value for the register when there is no negotiation going on. If you have link beat _and_ the register is 0000, then no autonegotiation took place. If the link partner advertised "not capable of anything", the register will report 0001. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From jgarzik@pobox.com Wed Oct 23 18:23:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 18:23:24 -0700 (PDT) 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 g9O1NHuR029631 for ; Wed, 23 Oct 2002 18:23:18 -0700 Received: from rdu74-160-016.nc.rr.com ([24.74.160.16] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 184Wia-00018s-00; Thu, 24 Oct 2002 02:23:25 +0100 Message-ID: <3DB74B86.3090007@pobox.com> Date: Wed, 23 Oct 2002 21:23:18 -0400 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: Marcelo Tosatti CC: Linux Kernel Mailing List , netdev@oss.sgi.com, Alan Cox Subject: [BK/GNU] net driver series 11 Content-Type: multipart/mixed; boundary="------------030200030504030706050608" X-archive-position: 929 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. --------------030200030504030706050608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------030200030504030706050608 Content-Type: text/plain; name="net-drivers-2.4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.4.txt" Marcelo, please do a bk pull http://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: Documentation/networking/e100.txt | 99 ++++------ Documentation/networking/e1000.txt | 22 +- drivers/net/e100/e100.h | 8 drivers/net/e100/e100_main.c | 220 ++++++++--------------- drivers/net/e100/e100_proc.c | 22 +- drivers/net/e1000/e1000.h | 10 + drivers/net/e1000/e1000_ethtool.c | 29 --- drivers/net/e1000/e1000_hw.c | 56 ++++- drivers/net/e1000/e1000_hw.h | 33 ++- drivers/net/e1000/e1000_main.c | 167 +++++++++++------ drivers/net/e1000/e1000_osdep.h | 2 drivers/net/e1000/e1000_param.c | 105 +++++------ drivers/net/e1000/e1000_proc.c | 30 +-- drivers/net/eepro100.c | 349 +++++++++++++++++++------------------ drivers/net/ewrk3.c | 320 ++++++++++++++++++++++++++++----- drivers/net/mii.c | 11 - drivers/net/natsemi.c | 6 drivers/net/pcnet32.c | 36 +++ 18 files changed, 892 insertions(+), 633 deletions(-) through these ChangeSets: (02/10/23 1.746.1.5) drivers/net/eepro100.c: set phy_id_mask and reg_num_mask in mii_if (02/10/23 1.746.1.4) drivers/net/mii.c: fix flipped logic (02/10/23 1.746.1.3) drivers/net/eepro100.c: set the PHY ID correctly (02/10/21 1.749.1.7) Add link status checking to pcnet32 net driver (02/10/21 1.749.1.5) Last ewrk3 for now. Updates the changelog to cover previous patches, bumps the revision number, and replaces the horrific EthwrkSignature function with something (slightly) less horrific. (02/10/21 1.749.1.4) This patch adds some locking fixups to the ewrk3 ioctl routine. None of these are critical since the ioctls AFAIK are used only by the EEPROM config utility. (02/10/21 1.749.1.3) Remove cli/sti from ewrk3 net driver. Also, comment out ETHTOOL_PHYS_ID until its sleeping is fixed. Originally by Denis Vlasenko, then via Adam Kropelin, and finally cleaned up by me. (02/10/21 1.746.1.2) drivers/net/eepro100.c: cleanup messages that pop up since netif_msg_xxx change (02/10/21 1.749.1.2) The following patch adds support for ethtool to the ewrk3 driver. It is against 2.5-BK but should apply to any recent 2.5 and 2.4 as well. In addition to adding ethtool support, it also removes the cli/sti fixup attribution from the changelog since that didn't actually go in yet and fixes a small style issue I introduced in the multi-card support patch. This has been tested on an SMP x86 box containing 3 DE205 NICs. (02/10/18 1.742.1.18) e100 5/5: * updates to Documentation/networking/e100.txt (02/10/18 1.742.1.17) e100 4/5: * Updated change log * Adding notifier to track ifname change for /proc info (02/10/18 1.742.1.16) e100 3/5: * Added meaningful message for self-test failures * Removed confusing messages from probe when link isn't detected (02/10/18 1.742.1.15) e100 2/5: * Remove broken home-grown Rx polling mode (make way for NAPI) (02/10/18 1.742.1.14) e100 1/5: * C99 struct initializer format (02/10/18 1.742.1.13) e1000 11/11: * Documentation/networking/e1000.txt updates (02/10/18 1.742.1.12) e1000 10/11: * C99 struct initializer format (02/10/18 1.742.1.11) e1000 9/11: * Added bullets to changelog * Whitespace cleanup (02/10/18 1.742.1.10) e1000 8/11: * Forcing 1000/fd is easier to undo with ethtool * Adapters supporting WoL capabilities are now an inclusive versus exclusive list (02/10/18 1.742.1.9) e1000 7/11: * Added software interrupt to ensure rx ring is cleaned in case of previous allocation failures * Filled netdev->mem_end member (02/10/18 1.742.1.8) e1000 6/11: * Adding notifier to track ifname change for /proc info (02/10/18 1.742.1.7) e1000 5/11: * 2/3 wire downshift phy bits changed in newer phy revs (02/10/18 1.742.1.6) e1000 4/11: * Newer controllers required manual phy PM enable for WoL to work (02/10/18 1.742.1.5) e1000 3/11: * Set interrupt delay timer default to 0 across all adapters (02/10/18 1.742.1.4) e1000 2/11: * Changed flow control defaults to minimize packet drops (02/10/18 1.742.1.3) e1000 1/11: * add new pci ids (02/10/17 1.742.1.2) drivers/net/eepro100.c: eliminate speedo_intrmask (02/10/17 1.737.3.8) drivers/net/eepro100.c: compile bugs (02/10/16 1.737.3.7) drivers/net/natsemi.c: init msg_enable in proper way (02/10/16 1.737.3.6) drivers/net/eepro100.c: mask the interrupt and do a small delay on close() (02/10/16 1.737.3.5) drivers/net/eepro100.c: only set priv->last_rx_time if we did work (02/10/16 1.737.3.4) drivers/net/eepro100.c: simplify wait_for_cmd_done(), better errors (02/10/16 1.737.3.3) drivers/net/eepro100.c: * use netif_msg_xxx() instead of speedo_debug * better default debug mask, proper use of debug module param * add ETHTOOL_[GS]MSGLVL (02/10/14 1.737.3.2) drivers/net/mii.c: only call netif_carrier_{on,off} if there is a state change (02/10/14 1.737.3.1) drivers/net/eepro100.c: * mii cleanups * use mii_check_link() * check link every timer --------------030200030504030706050608 Content-Type: application/x-bzip2; name="netdrvr-11.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="netdrvr-11.tar.bz2" QlpoOTFBWSZTWTiXGk4AvOR//////oh7//////////////8gAUAYAIABBBIs AAIJABOIYJkX16vKBQAFFUAAUGUNCIvNN77OPt9VLjfdqXDGt89jPM89nre7 ldPk+nbXfbvlxOQRHN6c6emhQoPXk9AH0uZQFdANJABpqEo+2cTR776V83vr V2+SvQAAB3x8pwAB4Aw++h71TvLvd618e9n3u9ztZ9fB7uzzfdc8twS83tzr QMjtgB0UOXTp7b0PeZunpKgB747dFPS133s9be22ttOsV6Zbu7rB7NPTUlBX Vle2ONZvvu62NVQvX3dFzbdt29dJ2zdve7vsZ0ZsGpljtnNM7a6aTV72DV5n n3feN4L33j69wDSvsO5s64LR9t7U8b73k9991ek1fMbst00lzruyWUCVe+be ZJbfXX27und9t97lfdb23te++718u3czd7tFOt4fe45nuO7lbV7u7TVeuc9N e28ze67un23H0W8vee+93td9uVeLbzwDXXvb3eqr53Vay3d4JAKNq9Rjam1Z ts19NdHXXfXV326u67vbx2PPdsJTSBACaACAEaGgENBoBGUw0BFN4SPUeqNA eptTamgDQaNon6oJTQIQQgmgTTJTynqYwCTSeo9T0J6mepNpNBpk9QaaDI0A yABoAACTRSREpNtUyegh4UaND1Gg9T0mj0ZJkAA9TNR6jQ09TTIaDQNNAaBo DQJNJIQIJohkaaNBTyNNIj0T9U9NR6J6J6CMmgDT1NBkBoAAAAACJIggJgia aNAymVPZT0NJgaRiT01MnpohqP0mSeoeKeoGgD1NNBkAACJEgQEA0TKeiaVP 9U81TyaKfqntRqNijajagNNBk9Q0ADIA0DQAABt/+/dZgEOL6Pr+j5vr+v6p +v67l3+utPOHzetaWMzeM43+vgyEDdgtYROKgU0QJBCAzkqoN+WfoITgwekY H7d3PaIjeOk891YHaRK7aTBVXbnCdYdRh1tMYiCCTcgHRJAOs4dJQbRup3my HWCqw+IqbIhIelcXNTbzgk1g61m+uMwz084TnJAGdUOrVIAilZSQEFqAIqDB UIwSQERFgIwWoslYIKrYEhdMFCLCQWQGILFIpIIgUIyoj9jIaALIiJNBFD3P t0iwmeMCCydnQJCDJ8NBjPUKNFWfDH8UNRE5VK0qIhShCoIxS2lSLD812tLI lAaii2Iy1PyBmZJBN1qWGRTCwbCgmIoWlraxClFsQUBttkYosiBW2tqVLWJG lpFgypBrZEYiMIxEEBQF5bQZFI60EGPhdSWlgXMWGS6kSWlhM7FEYIz9QtmQ Cdi9YzVE5NNsOYhpa0TMrs2iO5bdwYu/mOezw7IuK9Wb1gYVknDlq6wQ2xsW VLGyZha0zSiQPgMmMziYYJXIqixjA9hpi8lR1xdgzDS7YhkubG7S0KXUjlXR FYXW2sbCmtFSl2WW4vTOZGUYROZS2lSjUNGWrBudtgpaZDDjFEztbag5LddE zc2hqJcUqq1QiJMsdqYoFtRtDCO2uaOurXOJYrdYZGJbYGs0kZFRSzVCWS4i JaYwOCmns/pex7K6DfegcWyUpUKZlKUlEmDCUe5N5q9Tr3a9UOuWEUDCmu1g Vr8hBtIVhC8WnsT9FHgzEn7yQnQMgkiEfJVB62X3T4odHXLgOpinGQeU4hnq i6H9L07TjhuxufTQxYY0G2xdZcGLOq7fTZxHUvE8eubj2ip7X8RAL7n3/9Z4 H0R6ZzZFhQvW4kYOIfvED1n9ugoooUZJVEFVSKKqhDo51bWz0owlGHdKxtgR CgiJB4CxltmogVGjYsVVK5mbqQjRuF21o2HmByjzlNkomtYlTJTKNCV2rbJn NbbnbY1xMChcq4TXbCzREdNU1hq0JborgGzGFJTRtEc0WAqqJXYRmGgxGJbV laKee7nLZpLGCJRK4xgwtpmZdaiCVlbWlGNua10X3ch3LOddCXabYqRQxRGY xJjJQVuEa2jboQURgKuQzUXA2lGMJFyGawmVl12MJiJqSjLSlYSZLEiJS0Eq 7YVKzMw9QtnLy0MFtVJnWbAs9KU5zmKupmEYgC5u2CXCYrpUJtQHFtjiUmDc Ky5EQw+g2PtnL7c2nx8QleQoq0bYeLplowZWU1yYlpK0ytLY3WrmopNDFsNB 8rg1jZBVJyY+AJ5zW8snXWFhpEllKyJCpQ1zVpdCyUaVBENJYUGbYDRNplKX Qn1Pwvse132vo8vHiehy1LfPujx6l/1fafqAg/hR/aD9jbPGn4cxbpSpcW8T Q6RwiyZD4sEQFGodQuLhm/hRLZ2T4Ehap/ZDzTRkL2p5OdPXBHvdg7J1IcvD W0duNjJnRCt7YQtjzx/gP8ZRCb6R89dOJ4NzinQ9PLod55PLoxTbZHyZdoUI MtLhbCNKVRNJ3UaiEvKYuYydzsGUilUBBTMgQIUEOO76fUu1XF5T4sKp0h0J W27zDssjthJKKskWH7fKGJHWs7BryevM9Xq5Zwk3HQ1NKYlHCkkHVJornlXQ n3jgwIqppHVGEbXY7tM5SeoJKgiKSTw8Jdh3UHLwmruOS5Z5akhNp5hxRUQk o1X7k0mI4h1C6YclGRPSZ1Gpm6aVOEfKPELOB1ApQ0KBMsu62htLMbLODWj7 gXfC7UFG54W762DUsrU5ZfDKq7vWLs10bmAxNUmyZGaYsCukxLfqcIjpCVFV ZR7W49GNCa0M6Ek0p2Z3HjEDr9n/L98x4X4/kNipmNT71T+ZVGVdE5mFgkhC +1OIPeULprxdupqY3kn0fpkQueMkmzbo8l4wPLuk2BM6zj4pbtmo5WcuyZJG KUtlSopFAUNeXl3am3LbPxcH7G/kMKqpQsap/D/CMUminQ5UnWadkgjmu7bS PoWbQHudzse3TKHEm55s8MInHqf7as50v3A6Yk7hVVOQ5T5ZMTShbW6qaqHQ 0iZdDifdk33MtSNkRBIuuCfyydkVVQk69O3+7RPZ5jL/XtlDxDvyZySdpPGw mQh7jXouyKU1wjDiIpDzwdJcJniq6pd2NULyp3+FbpuBJfht9fHWeza7TWap g+1RSqYMFPK2faZbpbUPfoez0DAXHwT9OuGJQ0bqsuSN23E6+r9un4/3avXs 0OuE3Q8Vt3kWc0ZiS7N1HuZ2s2tePzmKWTB9tpvGmrKOK4IV4sxDuNmENpUW IzTJ6mCgn3L60Rtp+QgHdzOffmeLuw/aJ/LvTeNMQTRQ/seNcYSTsw6C/Zx+ +VHf3crw9NKo6BgMvfTpw9/g/faR9EvKvHUSoRseMoTnNTnOc/6uVe7j/O/6 fax/4cYrpQuaHph/JxjtNvlv3yZgPb4hivv9ae/Ep5HK+48tmzzrnGLGDw62 lMUsk74HCaMs+905fo3oTgZwbcPIuaLNkLbCqipOmTGhm2x9sq0JFxiO5MSI Ml1SlsP9EVdUjE4tmbtUF3k2zCYMKhjJ06+b8lG9YgN+M6Y3S0fRMbuhMy4P J26m+iMLWzvlw5+AnGaugqY08s1+hqff0LuzGFeTcp1KU0iulGoOg5QcqYxB lkk0G0QEodDpK1MOxlkBhBhMFMhl5ffgpLh++MX1igSBIFkUj17WZBRR5WH7 /l8efJ258jXK517VuwVsxG+WTKQr3bj/L16raH5qiovsdoL237PTb7ew+Zpm re+KHy2zqhL3whGPO3+HseW72P4JnUO6CJe7LZ0XaA8nb6vX6/b4q/bv9v/N Z+FKdraMNejNjufu7fpq6+kt5ua4YGsaYoq4q80lCZUV8lE/BJA8A8aW1aq1 8b1QykpSdUuIM9cnUWOCo9hPXN++S9jgVXy7WffxeaNbjKxO/B2zWpL9WZJm ul1V1IcjDUg8mPbZTXNh40u7ZTpIMPUkkPDM5HGnalEA8jzA5SmIma3fWwMM uxbmlZ+bz36PRdk6hgkM5tMs6UCKliBGB4jUXH1RiB5uSB5Tj28IhW/1LClD mRDmcVQRpw80yIa1geMZ+uaImExR3vfzL2EBeaFNm9PqyYAqkU5Pb8O0zi4m K2U1ogeGbsR0JO396L9HpPPmx0zME/HwjHmXYrUNH1ZauqRHyvIlSupu1Bzo HQ2R+1P6eu3w4t3+Xn1bNNPDw9PnpS7Zph1B3eObdG8+M94yECEAkzMRbyI2 9rWEEioXv4fV7ozO00VfXGQVqfEeNqcgmHEkJN3ozTTK0fv4jC+f4HwefT/L t57edbRUO6p3HWMKpd8RKaEOLCjT/So+RUo0hGJmRKREqFrX3KxH23q81Eb1 WMfDZPX6ds5ztxFZfUxMelEr8lVI97Xi3Vqzrs6TWhqa661tdpUR4y/mXTg/ XeZda9kCN3xL+brJheb7Txy7jrbfVN6UOPEeT8RS/fq8P5h3Ka1u4yd3VaF6 lgKOMhgrJDJMkB7qoaUCKCp9goC6oKFBAZEWEUJEJFVkBkUJEVhCQBX7cO6A EIAh8kGHTwlsj8k6eOL0iO0VPGB0JjoQxOMh4EUw0UFOY97+Wfiqj7+Gxma5 YfHe66loQyX0pu/6OmGG7NQZta0J9M4B70M2CBghNtnyPZslZtwqu88s7LvR Y2EfJJmwQ32TeVUIMHrqcYkmYqTDWh1Iq7FAiCrTFRU6og8j2z0j29uTfAkZ Q+TumXsvy/F8x8Jy0Bp1UGiJshVlZIV86ZhENmsp5ZhpVt0oiOAcDNeEu1JY AxF4TBhuwdUeVLq0QtsiqA+79LF13KTWtaTD16e12xJk1Qvxa/V5tfy2UpYg 1QHNNtjUdiiYEgD3Yfsic1zlmSztppwaQhMrP1vC/P1cCrpaVFpoEN7wm9Qk JxfZobCRz+SI7vAxEicd9ukKGdJC8uO/AUrMOYvbiWIQ7uZrQ9uKIXGRkk28 BQyswaZWht+OdSm4JFCDi69o+AwyX3+l2CDDzHDWtoIr/7Hz7mbvIIEl1/CM WQRacIDfb6HaMHYlC754/907IExkT7gdsEBeU0SOHTZZUpGoontxrKhNBe9p 6nE3ynyt8YaPkAzyIiVhEhr1LRcvyuV5rZV4vOego37WjNC0rwGCh+YP19cH 7XgbgnHL9GN3CgzGstqUEqiqqq9EPb1Zv0609Xw9N+U5guJ3S90vGPYiJxEN XdyOuLzyLkG51fu+O1tsMfp/uLKtZf9y5qw0Nrb8YYftn/shdD63DrQdke0H UJQIh+Yh0FkwwZFdI/prW/7hQnR/2VOm+f2wUKxM1fXzMksYJITGl4K/hHSr 0evLeSYDKXu2fZA1l4nJekcC/sf7D5V8Y1xa30V934tnb7MdpgO64o4yD/VN PydCgTq0oJD1hUX6Z1+JX2ylNJwtDgwsPWnrkOFaYpW4zBD0NGAXLii1B3Yj 785QqbSOwBhmPMgHWiaCaEp/XtqjIdmv4FGSXBz3LfH1Vi5lEFijRLFFBUW0 WMpbX5H5PNytnCHqievzrrgd08EMffX32LO+5d2kHd3TCg7BAtoQPbFzWFP9 fxSVPv/b/ljkxZ2cneNaIeNGRC2UoH5lrxtsekitdabt9JB6UVqJjV1n5Pkf 3uu+dq/S4Js0/d70nIZnn55wcJ0i1ysoXjOv0f09zf6/P7sOVd6tevGO+ELl EXa9KcJWLg76FRUnDjN4zm3yd1mzturi1Ez8yIQx0ONC92dkWI3C9yjN/299 XbzadPgZCdSGGAEInjQ39Rx+q6xn8oHx1tM/P66T89wmWs/knmTD8SwYCg43 F1+5X883bBwSD2ahyHJeYcGYlmvz6C7nPCJNLg/xiPYPCHlUUk0ZR9UpFJfL DqRyJ+VOs3EDiQql8omncy+FBhM6fUQ7mObw2zznZ5uW9+24zmq13VzOPO/G 5MdJrbi60q2zji64bu3ji3ml1dWq3BO6QkO5aiREw96czp4zNqXToe1anNQk QTPVnjg7Fmjt6kEjVEpqXWavQSPYDAXWdLHOD/Kgj2aIFiwKBquBeEiEiPaR aH3hB/SH0j5HDK1sDhY+r53XYtEMaCgjiUWgdms7BfQMBNqzbiP+J3RQeRra Uv7kyd3EGCCCGVKKLbkmJvaVqjE90sAvkUKk1Ic5sHvEA2mkDcSoWMrSJVZA /bZ9h+h7+CIx5dXOvr56/WFmqqGxwi4Z70WWMv9Qv76pgWHNZUaWPipQChr7 DX+OshM0o40rbjOTwvsb6Yeu/VHuwws8/PYxagvG03iYKiEfummXbZd05zWT 7n0fNK+d/ph47/o+mUlCqvpxVU7wqxVPrOc6qIjVrRsRODOrMadQ+pTyorG2 s0PmyidW+Ke7uZjORrlP8TbTVYDA2gGBstmzb088QNZWmvP69xCxptODQDgl Q5j3+FTeORl1eSrqjLt7MYKb+mvQ69ufcRcds5QeCgk6FVOr3szWn2HHxedG 0Xp671qBDYfR/3/Jm7BqPPHnKVG/+FX+yv59e7HrkziYasxPPnVEUX7fzlBQ dnk7N0QZB5/prIOL6q28ttTa3wtgsQsEEsFvnZRNiB5zoPPHH59YzV+nGfVT xXo6UThLp4LONJmKN9xzGW/U8OvPGskRGpNdNuuLsrlqQtjJPn1+m+n29XB3 6NX6qo28+/MEXwx3yP33wcB4t+xtLTzqGhCTehqLrjMpQsdEh7jFJnHxWVGZ tTYzbAeUAe01UtWVhQseUiyORoUiX2kIbI1jIw1bDVQzq1ybGs1S0bY1tgOO zCHebeulW0YiQ6H0UhxSvt1xLMFzNpfE3Xj3XNhrMN4MctfzAazLZQjCitJA i2sFSvo/gKeb2wdLZxPAei2JJ8b658Uh7JT8cLyEPXDAwHoQpJjKxVPDRDuh qiKmftvPzvmi4dUoh1ixe7Mhxmu3SeDoxFQ8QrevDxwvSYsd9O1plUTGrusu QoVip8FTm6zNBcTIoRcPnNZodIhyqeFlZtzKJfWImleZuR0eQPu9uH+RsvgA 7dNXV8PcqcEku55z66iCPnexklYj6FG4rnG6r6mljAl5UxFGYmPVWwHZq7NU PHFPVOowMPiMEbmWmc23nvWej90ajPxnMu7UBtWP3tmmzw5XPgDDjrgV7DMs /QwT0N8MWgu5PaSReLRBz63HXMmTtFM2bPEvpoGntYSYMfghDUO6S1GOlFZX IH9BVpv8Z97xeRoUGQIelqrr8V98YfW7CzbVlRvbrHOwi2S04DhW05/VFISm ghSVzxKIiMdRAg0EmQO8pNPUKbayvMs90IFQK1lu+ow3RmegMEpM/LybOmPf 4uVlz018uvVbM20ms4W7dey/5+em4bn6y03Qe+ZXHTdG/AQgTI6h7pl2dVfs NZDIizUQQQJMrSxkRvLVXl6L7GOsy9p0kTVf4aGdtMsUsXPOZ1wNl5wHdoHS nZWCQkx40X3tHhN01SmQQkwP0tiMeKWSMTmtLrB+HJzwPNKTWPjruPtY8Yma X3psNW/rTRpgnKEiZHMdpDjuOHkytsBB8YULUWbeaFq8trX+SPrPWR0MBayE YauGNcjfR9/n6NhJFSmEwj2N2Mmzx/woXzRLg6TBayOiL2DZ8kT2n+DHaCKS Zm7c4YJujHBQ5llzfqg89jWG61uNMILSdraokn69Gx+o3OsazBp7gZh/UxDZ AvbB7vO/9lB6hNldowLNJnHnXeW5sEbQ4GDjfE0eo6MR4+wk2fUfi/Fheb7n KGEG6APyi6gR6KxszLqgOKA6BZEYEHhDicxh0UJ1DYCCK6qwpuJg526N0z4O uqyKvRcXsEeQxt529F7/6a/u6hnr5OOK8NQnt2Th6+9nal+S+Y0VT2mgKkzW Ske5sUNrC2ClYTkw/1uO5ke3yj705ymzeux9bTsaaJXkp1c9VStIHf+hJCEC BCERWMREBAVjERIJBBBESSskRbsuOstzpthc0L3PcLVF6McwCZcS2StTRzMQ uU3yJoNbHrYvhqzfP43c0/2D3t8E+H3fjwcTyjY2l9zwxcVSIePjrmpa7v2V 7N8RonvOPd9/8MOm+/69v1uv7BbywfiTwNT/tpqqzqw3WW2NOGx5soY8IG3s 3ccba7qoJkehyBBz9MMq28cseqf0zld7tc5YP9aZ9Pik0azVoBJ/lqp6BDoC IlGsYlECgNZYiIwhhAgQhJL66TX0vTgaTuTB7kxLToMeUUbCwi/zFDn4SxKV uH6rf1eyfZjQx8r6z4ajqZVaOz+rNtEZfAY3eHnN2dteRTsPKavorloFHbbD hidAiERbHw1VN3PtIEVaVXePT9+2D5Tx2X/Fqw6LyqowqLIwSsH22fkr21Nd adltmrYUad0m1yxbEWXhMwRNq0Cqb4RkN4xN7hdNp5sKrGJcJmqol5tGj80a 0adblome242hN3K+xquqvCFFjGyLs0nJsh/m2ZU7m9muHjtxsiQpPRv37qYl DvbE+NzMWlGzA611YnNhph6l+HQ+jIWZSLYv2GvCVTFXb0vGLnd8X3q2I1aK m43VosDs0j824YSHsDLRDr7sBKltTQ251tjimYmK2kIKRSz7JCElzUz5x5+2 jatGUOmZYz2cSpzS3ZPI3hjYpwMtTOvRlXjbCepuiTSJPpmEL4ugMB/F3sNO F9obNCT10YRAHZjNi/s/JJewmb17rZiJCvOvD+JgSzsSqkID0runjne3d3Nx NKetqtJlERW/SyJltsRl63bBpQ/jWKYDZx4byN87YvKxk3gzz45L+9+J4NCb I427IhZ+S224/taCGCwnYjzyb3W14mZ4/z13nEq7DM68cN7tFXbSBrtmm8Lo VSram+WUTPJ8IdyrWJ0TrvvYNW3rizI9m9qMBAhMNk7BvN+HOIfxPQTabu8h 4yvOoVGgs2+cP3ZSNl+qw7GNuJwrXiWOtq2Ae7fA9ifOgw0Ah34PVyhGhv9h E3Tk1y1PLJRdHtlH51F+onGaJQ5ZHSSknUkPYEdkYCFn6yE/M9JJ6gTYVFi5 6GwujUV1kF7jpXOXVc+6H5ziWmCZXGs5Ye2RLHIQ5+Pseuoey/uUdVhNTbTb zVHGpuFDG3q2xQr4tVeRFZAfoiPynxqcqTTC4eNl1bY/E1U4YHHRja6n4mYm B59JBmZ4dEx20A4Ej95i2jls0569NuuWEdBGngjGBeOEOzZMR36s19eGfx2j pr8zJik3Dwmjuc3PIYJLDDBGuN1ibgTKK2qGeC6YlZUGRojUTaq7O6sEgRk4 QRIeaMjgVClkaXPM93s8Ovn7K/UtEPIi8STWZXeEYo65vsppRAOjzR1Db6sG gAXliYdn6rKZ7ZtUEVefatvEwhZPyR2SJGWQ/KMEWyrjGYrIvpUSEE0HUS7z Uj9v21XWWrhjn4lJdYYdxANZKkfZJ14+3p08bDZn7QKzt26slFVRgn4msjXi U1c2MG9TlsPkLzdv8XdNCa9TFWiAmQkxoDWHDUq58VQiVgwpRPm4PZwFszPO KBIEKqEi23YfvgGWjRttrYJ3OvRxkGmaOuwqIyqHRgjXzw2THWtyX7rGrF7a XfGnN+x3Vix4bwtY0dTDQ3aq6dND3aLPX9cDCxEfosaXQc4rXTb2NLdcyYJo RmfPwS2e4x82AGPHVu3eHq0JN9WDPv9tIV5Wb43Tr7o9xpHNMbiohYJ1JAnu EzNrgZPDiB2y9uh7O14unEvVox9YzBi0vFezDkO+JikcWrI08xjNQJHcsY+P vHzRWNHkdTG3n5gjOdh6io2WTExHs+yD20y2OQ6V4rgZsFb37I2oOUZO/Kwp iTL4RxqFK5GgC8qhtK9XZHxV2oW6JAWr0whaEdz9EtuzzW+nKg2l2nXVB8br 4s2KB9Ia7NMO6ey+UDIJtR7acZ6Vvscqbxu3goMrT4dMcGRi3RnrWhtFWE7r nfBPLfCsjyeC2ansxoa8apwFdzO0WamGPSadG4mqioLtm6Wti13MexhoGYks czANMBkNffhp/HSOhfprK8jjPU+BovS20ZGJCpEsnMFTXR0ouTWvcLGEgqlp IZFeJZVjCfjn5y19mQ/zW153BSMLoodZzL5F/uur6ejkzZJlVgbPTr0xibuN RUdiIKbuZ/QdMdlRRGva7w4XJtZriEZZYEsOJXCt48yqa0X3O8vRiW77Lfj2 SLEd8MspSgajqrYjQ1OZVX2d+yarzXRfdnXQuTMGB1056fFL8nU/1546S8w5 m8pGC9Ggo0FrhV3XNBsRwdulk4JkMoYZKZaiDhawp6tznzvj6TqeHy3cOEcP MTiQZtdohyZosN8DoWJyypXGuvvZhmm3svM8S6s8gi9Wj9Cb0IiNPCecb4dF 7bWkubQ0A+0WYQMuxDGG8fJq8T66TnYSmaPraX/aqzv7u5a76e6d7rMc408s H4Jo2vU44gK61AEK9RR4qrqcpVli69Unt68cevLtPO4er2XYsh3dt+DtPYJw ItpMHU7tZja+1bq9xPsXJszPWu1M8NeMlDnXO5iaW0zFdY00Pxgz0O1Gw+zS Kdu7EY3JnfbKSQ7Qh9jsoJmo1bKjLu5ouYbo3W+Wuf5c2Y+zH5+a6N1HM/aB XWHLE8G3Zywd2TCuNHqrLyRbWtUFX2O9cbE2SO03a3pVcPUUbOyCmo82v1Sk sLIcVEqMJQKlSvy83MSpz371sO18NiUnPZdjnd6sujCEOmxw3zVkycxtFZlY XYFNDzvseOJGrhe63EdhGMd/TwbQbL4HajnM95z/FWZZCZrObRS6LXM23uqv Kx98B9UWFuevnE2Jp7JmT0er7qi1FuLSIwbGyUjlOianKRFC3ksd3N00+oyc 1b48beO2w1bgwtfMrO/SPXMkYt4hCxUgOGPAw2mU+THje7e1NTpvDy/NisD7 dN9OvBVXZofpg44VLbJ+bD99KVVtV9xSEt+HywQ3CzCOfz3Qt0drtClpM7ES oj+vVSPGWixWUW3HZZrvslXovuy8SdMcEwONB3SQlCYnV5a9ZU3QNBbYaRSK TeT4SkNjffIYMgyDuxEJ03u02BK7UrBUTfj9vci1VUkFVRVVmg6fl/T+uv5/ j9ofzPxhTZMXx6t3UVwYgbBHiUuG076qtJ08uAwHvOdnGb6NunMNppB0CdCV QcArXxphLQdB96ZmavPQOESkMkJIkyz+P1n2H0zHmqPx2fq/ci6LXl67qf3U x+pBj4M7Mc32lnOeqz76MYSH4hzboMfcmGMEAJM027OTnns/IaLI0p5ag8Sw hGC+Pq98bUMHrQOnDsD418K0YYlPfUEwqVSqqqKqk1ag39S0I+v8hppmVANc j5/tKfF/RWfUQdMH5/y9e+qwUXV5r8IHrE3QkAoeilGMGHNpP3OTKuKJEv3e n8LIdz8FA1AT3hBf+4gRVD+2/YfjwkMqkolRV7y1QUVVVEVVWaW0KyVJbVhU iVbAWiFiRpZKMFbbRQ1CQbn1tCHOQ8frWlCASRkfmk+ioeenYRQEGhIctZA9 UVYMGQQgIow7CQPPIMgyQY/2rUgqAIohlCgAiKMBgIn1+nJJ+P9I+nsVZCqJ 4Ph/FnmiSLb6r3S6vGOrs0V5DyA9QIH9UCg6Yo7+ZvKj9n5fAz+8/EFJMbRH t9FhlhmjAWf62GHr8rwpDJDCSz+2KwGyTb6iWoKM/V1Pqya6TazsNXZvsscg QHHu/D9AVdX5n+6ghxjYJDIaET4yk/ptgkDuCSlP6KcdwK0Yn2uJ/FjziY6o ORZfGeU/h0fU26fQSJtmXbvfvxVrrkM+0W0hdf4z9kPya9fdu3ta17w4WG3q PnvtNVUF3jdoIhzHcp3J+uzzKwK5C2wZwPsHidmTh9CTGYnYfcNBn1scfEFv 2rcW3iaA47Ou92Z2aGRDbJsoYxqIB5j4j53ttvsHWO0fYQxA7vYNzAYdYdHy 1Up6WOHcwO9gZ6Unyx3jPMlE9kfYXOdmOZIz19qgdJRgB0NcJqlgLbLL82sw zHqdmxRJPpsr8zyC+MECC9xwtZHlbv8hgTsuVMWOpK/ngBwJi7sk6XXXNPa+ j3W9u8Z720/pzoRVwQh0jtneVCSy09LOhT4ZCQhSUVCLUwefIpyidFOArViP WSaiwfbZIRMLTu4b+vzdivW9sjT/op1zorYT8TvhxQrIgmz2yCtNVbvVZaq0 3s53Gb8nxfP/asi0qoRTD/eyfQ57eEI79vwHLKiNMtOnl1QcewFB+mTx3udH 4cj9vXq/DoW82Ab/dwPN/A+T5yvr+ewUi2uKd7Q6aiU6lW5TcL0rf1PVZz8e iHMueJCUNtWaesgbnCO6yq17rLZUqoqEILBFG5iZAWyw7so3e35vX12W+c/s 7SPLfVtwcsM5Y9JV42+e3qJgrP0mwbnqxNTLPj4jvr00jJFS/PWR/j1mgPZB 8+bdr/s3beyqr0RcIeTveEr5w8fO5t+zLvNd900FMNPmiRkKeWUonl8UPNE7 1vxyUwg+M5zkaoUHUq8ISaX/IQ5/CfG0O8sOeQdXks6adyYaGxOAmBNZs/lH xz20Fb6rdZzcuVWk1X9cSMQcfVrjOu7f1ebb7joy8DDzp0sMeU4atVRAPanF SCZWbbcfAWU4D9Bj0FsnLW8IGMAFyieNuVYvpK1x+W6sraDL1X9OGjTvhbqm iouBMoO71w5SK+1Hq19Wm21nLqZkuXU/7PT1WVXfFk1SPP/l1Ipsr2vWsdFo 35KtNt72ArUpdm4sicNDzj2wvv39kZ1KOBfK2uW943d90Ko12lWicspfZzSN dbtb9Fd0vHPujOGTWLzXxt0EYY6yyrg9dUdhj7tcvJWk2BnrxpXCDyAlfBPi SM0a3aPQosT2V379HdjfSpKHd6DTHRx2FmmAP0W7saWek+Tqial33VV800YZ VeLdUV7bY9GgLOe3XgtmymvXPTVZ04xwNTjwvnS0kTXbCJE7IbO/tnOOxIs9 cCHBXTKHTs9NerpM7yHWV9scfRTHLLZPh0T4yxnynlx8XYKy4laW48Svu1XZ mNVIvKt7Lcn0VVvhwfZx3b1xsxNA7U4XXwyv19VOqhDX6bdajujhjUaljy+7 9Hxebq3j2+e8yVKP4vcn2T8cZotRERtJJKkYwQYxIh6AMMYpUKyRREgsFkFh GMkUhVYBRAUgKALIsio/L2o6sCmoFcJU9JlRJYqoQKKa+IYPsRUs/FU+b5yW voClRP2floAqCGUEMoKDgQUdMXRFW8UB1M5KwD5RCQkGdiyEQsAiQGCUilAE fceb2S4g+e6nk/XRkIOTx6cecwHUIj91iiBqAgFk8ZAUPj/R2+17HaHMehq4 HkR1o9CAitq0qH8Rzt2HmnGlJ0+GftgM7+l51eJnQkl6vLJS8EJBaJguZhVC UFfS00R8F4G2hMyaqvLKtR2Sxq+qbUQjPOtaKkJBWJgzBlS13wquM45rM0Ft bYq7qKb4qOzGJ6QW7SlVRvo2lmjr1YYe+3bVheJmcbuXPn8d2/mLcI69p7bj hLkaMeQzdjxb5BXv1QSmpnuwhrsGrZuIXa5R/Ej5xkGKYrwwfDzniwCqA0q/ GvzQYkmjaRnx5vkZuVfby6+Hu01FOpGYhsTT0fwuarEO0cYz+lI7u7qwGtyw 3cMeGW1kY25uM9deo0khucsPq4NvrKGvb48ujpKcdLS4GkZCtmEp9VCR7Ow9 xCvZ47qzpOkPRVv7+CaEAYSLPM0LY55ryx3k8DNlHm1+YYaZbbGqPmj5LGt6 tBQzDAlupIZL2Wc7QybBuUqI1ZyjlqMDt+B24cbes/GwVa9FNDt2LE0AWL6a Gdbfaarq7qUyjPThx1dG+szCwzkI4Lq3l+FUk14kBpIQdtcdIRI6SRvw0zyF b352NHNB0Vslm8TsjSHVUb2iEpG7YFvSGDNX9JftmbuSb0wL/3ns8/o8z+yE fPDsb3EIJ6PRRp8mIgQ8RNHN51cu2rfCeDMqppPp9PKi8vNajMvWHM4cqZt8 a1qKEojGHfFXWqs1eNRF2RnOnrEOi1hrnWidRi86mNZfL1iZqS5jSe6fWFi3 qFeE9vhXlYq8XFa1OYi3t9PF40amdZoitZuK1p6rViVxUGSHI1AqrU1gznKd 7nWZ08XEkmJWsXJEzb5y9KFOXcV4zEJ5qnt3U3q8EXiruTGsXE5udarOcxlO 0iqpzSpEaMK6VVFEPTvOYzGrRpyKzMa1hPjF3nTXiqlPejCuJt81gkysazmZ dXaeaeNKFExT5nSu8XyxxxqjC2GWGk9J2fb45eP4lUAPaP4CJjQg0rZAKRVO r9JYQbAgXUQo4cO9kPuHRrX2XZ+g1IHHGl61AgBsign0hA7kAQ0wAMaaFfJE 8yPWeYkN4NtRjR7VFAPo7A+P3HUyE2ip9HSgOGFr7A6e0yMHNQMFKvNmIIxV iP2hIdjU+hJkFkM755k6dDHDMY57jXCEDakWlqBIoQIJCLYG+nClkWQcwooX 7hhGwsM62i2SANUtQMj0JZiOCKaRaMgz8j1nrA9vitEUSeZ76fXAg+jTtg0i cfv12HrN+vF/O+Mvh4aeQn0WnT0mvoi3600haup7LNxIr9LTaiqt5U42zZgv EYQHpYQ2Ma7/q3Jy+66rMP0v4oPVfw6us06/HxET8UQwpC5PW+2dfO8Th6au tS+Cd1jy7NNai0eGzNc8tdrPUSDPKInf1UUbNXkIPqry1jvd9tZw3ly4lBvm Zylmck1sffWPY5GGZZZZGaU6zRfGT6e2BGv5DfuRfcUoKsVkZPKF5vkRlO+B 3xCkX0mrH+0c6jHP2wZjv73Z3tttsqGg+RWbDMQszfWiaT6dhRI7YXwhV24s QteF2qZFAk6AZvDo/DNvX4m1qSNVCU9DS0VDceJz+gTunePJk4B3OJ5yHE85 KJ8HwCCIc1+G3LczqalHBmhlR3DIgEI+3IWYtoAw0ljGQy2rCjOWgDVwaiah q62NEkC9BOLqw2QkWB8khptz4lFyQL4B8SnsF4cFuPE9PDkcqxXFTO2zQGIj EQhAh3Bx9E1lmUwg7O93ZpfAVhge6TWbPbUxKAsVqCxmjsL0HM+c4ZJgUOAc jucZYCtyEHwO81IsDI4GVx3iYU2PEOjxdzw5ZtfEKh92AqHqC+v/BYNh9Fe7 AsQIyETWxh9H1blGKCIcifmDxnEQ52xxiMDjbeu+MC8QFqcoWVkzAyZLEYyT GuENEKxRQqEKH7M+F8Ht8fyp0KBmD9wYiq+e78fn8/nimGaUwUaKyyucSnTY fnPs9Hhz+MQhVN+NH6Ty/q/RWqVJMmSSSTCYSxisYiKqCCsYqqqqrAYCIqoI KxiqqqqqrIMgqqwYKxiIj8fID7cOQAUCwoESgEYIOSQAo5zcewXEwIldiKDb 0jG0YCQcw3kHJHnDLwIHvy5WZc1wwGjnlMlDnpKcDAzeBlo/gc9tE1/BTfF+ zy5XufM1FzJ8j9Z/rfM5pP5PB3MF4aM/a3JZhqi0uSHloMdC6hOPEZouZBJ+ +fiYYGc98/WYGteYwxDqqLVUYnoKGn9FIfigOJBIkXEzMbOuBgmb0X6Zvr28 9Tp5jGXe+Xy7lkirGcTFKh/1t2YhyprVH5vdS59Er7pUxAEw1GQiWJFUXVC2 1iqqh3NEVFkVRF0W59rv79pITYEREYIisSCBIIET2pAW7BITEAR4CgaVc9+F kFkRlVWVgBCcJ9hoM3gElCo6OX62GSAImi06SdAnBJQBSCRJCRWDIEWIxAYq oqAjIoIJJEiCAgCCAgyCiKiqsRVRVVRVABCDEEEREWEUgpEkYrJGCRiqqDBV BzC+btju/EOr2zZAsZg+wYCqGSaeI6ziHKoYCIJdwSJJDGmIfQsBGEEHgBwK Tll0hvO3GXcgiALA7V3Z23SzGroM5jnO+7vpm87krBb7uUUSy8HsTWpU3JGa d6XmUjALKecmxqjszAVbWNZkqT83bJ1Gd/3KbR3vOxuYFI71ZB+ItQ43pGED CdsBhDviXDCBiCEP0psoAQ9ggHwwFQceRVSQObT9n5v82SQ/eH/Bn3c3VrX9 H1fl/l7bKbopvu3d4ZJWfSMivrKWRZjDd0vo29J0xcUFKY1OurlN4u6uGU4A yxAnqmoGiORE/YE/clj30fCOOISX0r7pkZnazyaO21LOPWsqRkaiMaicrCp8 4zU6nX2FlvVeUrfZUV8/plI98QI7DEggY7b0eL6we0YOR+zA6Wc2mtxxt4XM 5tnntDtigSjvjZIzxU21beH0qDkAZEADoRTUPjRpEeEAUzNjwpzDASLBESKA uoeWYgUFpuoDJGxbQGERR1kynX3shyY8NPXYJVFQjU3U7oci47Y61cYaUbgG VfJV5JmAs4kIx2SdITodkl5MxjIX3LeBG4esTMX24tY9KruNPw3OU6OkvCQv 20PNRG3C/g+Jzxw28WzdhMdK93Tg4HXV/GJUO6SSV+JxszbgmxxwcZPR4qbf pNMwD+MdI82cdZBFCTsh3DWJld22eri6B1ATN79End7duTnv5hlLi8JHgqhx 9HXFWlZbxHSIMP0AjaxZzXxxaZI3oiZpdGGWOOGUCUXyJWaZzaO+DwrToWAM zHgx72MdRpdaQgQrz2PovuvEJ3nKMVFIEId3XfMNU50Ab7nQEROxx6fFuNkL hISKogqIiqinHPoRM27em+rlzM3xV6D7ri6oc9aDKha+7tIYECdTTE0CqEm3 ghv3H4MH58ivgFQby5q5NPpZsWKENOM9ZqJ5YzrHfnbdVMD4eIXbIKM2oQas mRYG3o32hzLsW5RgKOTIbsCd5tYXRSkLlxUieTLvmHNm1hbvmZ4wPjUS74zh 8ZysTqZxUqsQTl9PrKU50iFsbMk3xIHdwdMucjhIN8BmCBJPSu7h8fAOAJp6 da12WsDDQWIgefB73iIyn+EhFYHCr6WYJvbsNxyL8HkVpt+m+826zM7NXTRV VOwQJxv1DrLwm/Hlq4mjwjaXeXKkda6NuDA22jTK1l8paIeFpu5cBp89F5Xr 2rcXm4nh+XN724ORr8/4nuH1EMMM2odhjtEeqvXx48NwIN+RJY227TpYyc57 9jCzn0d3HFD14NmWZRttvnfT455FnWaxhLuP3/aU3h389UwzfnM3p1zNZ6Gf RR6FNlYbxCCPvagDDunsGBtpZ0RF/0cN9JlHvI9heBsoB9RzG5PPph11xL1e LuCOHg5ST1bY0KZA17MCuwVd0d28k+N199eFppOHDgklPRgQjNOklk7qf8CY gb3obxpmZd7qqi2V4aj2Vhgpku93y7pUFDMfOm6XrzdTy4muOeead3dyjE+k 8i/NjF+ZKpQhbBwTnzzlleIzJkubt8zgh1wArtLZRG97S7HQq7a1SdXVaTi2 93Y96APkGggqeiD6bt2mhwJwnIBG7ldVUVoZ8+qxoqPJWlqXXnrjKpmsg6UB DlNjIIGKjC3ChLnqbjDymzqO3bZD8bnn2V6j1vrZawoxNKtXtN1TinBVaxlR C2ozOsLocHxoEvc37yZKYNY7+WNp536V0Z8+bM+Pq+bLDBvllVO7uzAR4O6o Fu+/D2wCsVnV2qPB6jjsPrDA4ZcB+EOursMSJoKnhmAclhpagfnEw3IRnFOq Zkxg7I6RjQ80qM6cfpvyZ22S3MZz0aGUPsxeMoftv63YD4Wt26N3Ib2812rs cypijplrSNChrel3J0ISREpRAItzuTFRhz0m4QW2cbm6Irq7xVE1ffxveJnG FhXk1xo+H1ujnzflvzsOuYfzZFvmCl0x1WfK9tthtINkwPabbBI1pi1lBjAd lnuzm+QO80M5vVO3NHUN2BB3skAt2hgsFYdzMBMZZgKZ0FoBxJvccxg2wQTn EswCfJUJZKDFuFuUO6eitGsRTgqHDkRuWPnsxgDfhhl0iGttTw72rG2n5u0+ CSc2mb77e4EOdshWVAqEvXNY3OLsKLAUwFdqcVPAy0h98I4bBslM56wURUpU 6nMJb6zVZi9ZfELGMM22Y1naMZ8Tw7vCzAjmphunBjpxMXbFIyMBoZgHVzjf jkvoZJZgNoW+1OhMQ97YbnAwGMC5rHJrS4ReKzoqYfHF5xkKpkvRpJvocbsg xVVv1y2xodZJNCfR2K7otwxBF1xpUq1QygjIgSAltGRm6NGu4dLceB1pRmcH MbxGL2EOkS+cTWFBEDVnn8CkWFSrEXX54SwmOi+swjbbMUyvTmBdOjbQ9MMS mOXa7DTMBnVBKD5xmAw807bbPlSTwsc7ZwaSVvcyZnxPxmGrdxwBdesL5Z2X vvuhWG7AWGpTvta3IsAWbF1t6PB+t12WvDwzOcQ8PSvbCxOJxjMPjMaxoeM2 XeKd8vpJ4na8Nkye0Grr66MH72s8bRzHq9CyXxA3mhvOr9uhNRp1GnfxOnRo faIqFVKkkVkkRIwYxkYfjGIiDO04d2d3vwved1N9zfBq64eJd3yu1DYMkh0l 85frLymP0GZie3ipYxfu3ZTt3egM11uz2eZlHKA4pvfdly8NxbgEhBND9yjs P0E/aFOaEScK6qCZe5uStu/OcZtYxiszi1Ssp42FDoxLHv7/YVnvHS70um3M ymOmN4SDL5jojCUV00RBOU9mrTpUpp3tOaecjyEmcz0rdZa3s99oKxR94+YP L9f9uY/BH5A++GPZzuH56B4QXrkFgwssDUhJhJJfF4Fdh2V1sJjVhr2ftwDM IQcMZjYkeM1YG8nywMiHyL8geNcOc+DEHANM7Fftt0oikSD8JHSJhc2Ucuzy golg/XYaD9qXJdwdBpM3gRMuIo2IsRsd70W8u8J6UEySPLP+T9SAmrce5ZtU chZJQHrP4wJRDRw+gu+j6iPZyDNht4Ds3/Px1Yt6AY/WhT94BCAqQT7dttKw KHwA8PyB8r5ebvnu639zkW6f8/wVbiXq8TW6Jy219HS98uyaxKWfhOkdFlKm sVKx4I6oznlJYP7EY4dNnp8ffp21wEMfvQOyGjruz9ucxiXTL5xkObwH5PtJ knizntKiF4pfui0XoflUvRK2ZOI35UMbRQDxcYNUKpNq9PjbntU5z87/6EXI /yUIw7Cs4C1Yt2eajW+TOqckSJQaWvv25w7lvnfVusKoCqdf3afAzh9zLaVn zfR011HzdrzdV1geCdE0z3HGGz7jO3nO1W5CxPJ8md+rPYhiLOz7Eeu3TG5H k5vs480mq9zty2uHxZuy5u72ZFXLXZw6H8Nv+ZkYJnJPSngnpbZanzIHsBBd apAeLOvanzokFfTG2khJ+NnnnphvqqrXl1nfA4RXnoR/jKXjiAfQ7nkp17Yh 1o5v5+Voa59+qJd9HpgwZXUYgJAVHHbK2QRQdXCF0fNzOeZc0h2x+YfrWmty 3qfpRwk7Yd7kb+JSLWVZ8bHUVW9dVRrKOXoohOgepfNF2DevIt4guUeBMeHO q0c3Q7XXj4PgreOT8tdTYgpQrgF032pjxCQi/1OHcr9OLvqr2zdNSt9qfT5o NuRRG0W8o/mTbpF6W6yR5lBVJjoEG1Nq4S5othDhO4g/zYUI4Q6SLUWC6UbJ PNWJk7job3JmOYW2xwkjnzfJHP+V9CZvhn44dHtdWvDmcuTV2vnupB3qULSC eGj4Hwj6q/Nlnv7qGQm59j6KSimYRGbdiY+J4yaSj4/BdQN+5hCGMTzMT3j9 8pcGAHWffKDCeWBSRE/sxgVH6EsbfaFGeDIVIG9g+fjTs4VZQtok0kh4cKcE Kwgq9kQsoGTEYjJ3cgc4t2ERR7mJV1ODi4XMSb8U0n8pJKyQyLy/r5ORzG/S n4dtc+m37UQvBH80U2RNcR+eCZEVhiVBhFhg7gkwDf6WY8RxPGcP5iOcbq3s sO783zc9reTIoIbIEYJAOooPgIHaJmO8+hnvyhj6JRa1H16fJENcQkGESQPu fGbzUXRPbImYooEVf5xEViIr+1EVhngaoJ74RItHWGrH7vbewfAVM+qVZ6/v Pr8XI+77D8dT1Mfg4feB9X7QP8f+GlT6sYSl+VdPMZn1Zga/rEzQ+pxx41rT Vmg/QFxzzIDaOtw4DsHCDsDDEgG2ZhoQvVoOw0CPAy1jvYrs3yFHelG4mHse ITWI0iaQMbJxMUMonZz0WgPgrwHW3PzQyY/SQviagX8p+RW1ly2dal/k0arN GTKhAoacgKA9THmIsCakXAmYyE/CUC6xEj0kty4f5xXIxaD72Ze0veUqkKBP +uxla1KTKsb0xfzdCt4AHN2Wyd5Nj1DgeqDodgEyDE1BCwBhA28z6tRWKzUJ 16o4f2K2LgIeZljdoGKpITdib35Pf9yQnMaQJgQgmeMDu35fWBg7mgzaKSJz 4GhdxFOcFnp6U+Z+JntBn1JFj9t3mcxD3GsDxx+GvkXApQvjaMMJ+V+qZgbe 4U9ftppG7E4ycjCet7WO8N/RMlZa7u5PI8ZGLUZgrGJDDGA7n3n9/6n6mwfq 7yFHigjGJS1USh3HiqKqRhCUh7G97bWIiJZ6Tkadxl4gyTemrM0dASYsEwdV 5Njzmzuabdpm2jz+CgDcjxg2TA1RE7DKMi96UoJHekq1s9cFIdxm7pvhISet iSQCIRidpEiR1Hl4tqJBlo4pgv2PsoOHA4N+v3m5u72LXyi5QKv+kdMNJhDS R7fqLs9K1z0p1N37ePafsdRCD96AKUh4LEoekO2NWofyQKI9iB5fZJLAVAzM HyAax5vPXXCd/S68LT0sCwNRF3fmXofB+Jl7McWlDqMwxCCIGuQOBuRBFEH6 fE6Vg14zIGDRiwsbD98DOzDBEwK8KHJaPsRsh5N5I7SSQhNoefUY4r405Fob 3YaTuAcIcsA9qeMCJwooSBAkzzpOfmVXQDUQ9tDWk9ghcJibzYh0nODwOfTM UjHib0/ZEbImt2hS+s6E5wZIQ3PCCe1ERUWCQO8RIay4w6wx42JpKd4c/Evc xibMiiQZs5imueQPXy2NduI/Egb2AfNE/CdE9hNpmHD8jPr1+QUcuBYUFQrh yr6n6gvev3TUpNE1V80CGglBseYYDEkIAS6PWJty4lgGrFHth6Ywmh56v45Q 4H1DQZBt00i0QIRDhaJYkAid+JD8HzyQhAicTwNtAt/yQ2OzWUaBHuJpj0Y6 2flb4OhkNh0xAMhMnArzaDZSHhtRUCi/U+bfDiWPvNENApCEAInkAmpRY4DY vCmfAIs0f33N295e5kYdau5469D2B1ys77co2hCRghcgIlQIHAZUTgeVCxgi U8NaBrB7mA7LJDQ4nAPcAmHA9BzQ+eDc7Tgc/SFAcAkGRcbHmMQHqVE6z0Kf kAorQDYLutmAbz+gIg+AXmYGBnKefu6QD4/bfv2xgigaGEhIgYnFaE9zsNuq OEOjwkpriiNrB03NL7AVtcdh4p0oDkahfjD8PlK0Mi6svbKy4edM0O2OkjUh 0gpMrCiymhhC7tqXTjkMspr6vWFw0XRZF3HCSoUP0cw1TQZ5kGEEwcjM8NT0 FmCTbjiRFkmzJMIg4EMFR8Jnujr6OYNMGcgOTEsTW6iKyFzRmDgHCMiV/NQc yTFvQ9Ygd7Qd0P9P7f9X+jAHM2JEYQ3FRg23HeKaUIGn+Pyhe4HVHvJxzMB7 4fo2ZYr44BztXWBWRbAHQkV8tseYvipg6vO4QGL0dRUDn7emSgAYDGTEMFWd GzBgg+9ZQVVIcLg2PoZ7MD9b+bUxH9YbLgPKOqfcN9MYQ5tBQd6Qq9C8sFPb E47AdEseUTU8Nw62Ed4aNQkbbTWmb1kF2JAyQMgkFiZkOFiuA1CnF4XOgjE4 oZmOQG81N5sUGp+Minp+3RVQoDgmQ8Qd87QvMoEESdEpbNGwBQ44H7cT1jD0 VUEHPuPvfPdX5m4TBV2WMfbm/n0VEHh+nNQ+s4alHSodhUFh7UgMiRWb131g IvATURMNKYhxQdcMBsAfCGfJDBBw2m49R5i7uCJtqf1Dd7QhOSnWZ8dL4gg+ A/Ch4QPSXpPCY6+JuNNbJs6aqXuvRmmaZ4sG2nxbQaYQV63Zs9hc0HSmRk9Y Qa+WLUZBkJ+GncHMo/pR6PEMWDpBOtDgNgZIWgweVZYQNZScUCFUvuqkLfEz Ne5AwenhpztoGku/j0yH0seXV5rW736+qXxw0ZXYGLXjiPxEeYfy6FHVHqQ9 rAoYldp3HrjM95g46uZQwfM26NhHzjV1PIg+VenEUyMiufXNE6jiBgwMYFkX hBA+YdxraazTYShXcfBFC0HNNtBgFZxsKKBW1fAyKUO2Abt9avIDUGgIA9gy qA156qnpzDig1BCkczE5goyIFfDVDx4lBDgYrT2XSnEoLWK2UPYQhCMH5obB H8TOjFyi+MQkfbHQdA45UvKhvwKAcWNhhkYxY9+wx8iIqLPKG1vOns2W+QLz g9bRQSAfRdQiX8mZEPah8mRbIR02xMLK2hgd9a0vEVjHTxGYgQEEbgJBWk60 NhmBdUIYYMS0CAVAgXubBIwTPCYsxszrJSlwywLC0AfIbUMVuSF0IQY24yA3 IQSJl2UBg8SDy+DgSTWob9Aj3Rg+Egehfsgbe8BcXPE6DpTHp6DvPB6cAnUZ L9hPus+ixUbTbNUIGdew6M26TMDg/WmhvKYYjYlQYgNUXFgz2MMcrrGqmOxI Aca46DQYlGu/SpudebL5hzAF7sTb2JNxKTWJpQgQG5jc0JtQ14G8ujimkEhA kiBOIaQDcni0M4Bwl+7TkGsvzkurGEozozeDkGAicF9Iz5qH1ikhI/CA/cJ5 khIRU9kaIZcPl7AfGHeheXxW59efV+I2Mn3Aj5xDuD0QfFF8iwT0ggWvoZho ZnZqGSt0jpMM0yC/S17ZlrnAwoAiqwCQHbRmuM8Qsj9odg0FcUK1X3aJqQ5B 51XGg0IiJkod/WyB1yiqR8eroo2deA0EjdOClWIA6UR5zzN2XokwMyndrKT9 4EGKc8IkW4YZBuDW7+kzNmyBTSKlEkIRYhwSSSSTKxiixFPdTom6jxkjExpM OlirFBFYglIpNhnjCMDmwKHoQ0UUmxIPSDEwAjhg0bVUqEsen8r5ZEh7U7es ZfrmP7RGfe41R/CX6j0fJNo8VGQSvj6Mfmq9kMPYfpnCtU0hc3xptLRsbzAL 33H3PVwzMjkD8q/Hzzqfk5ejPO7Q2YiB3iehh+6hwbA0MRVNlaj4uAZQPv/g xx/KfoF+Jm7XXl/SmjMlA1VO0ivzEpNFsv410kw+l0mHXQnrHD8Lv0UijHL+ Yg75jiyt0RqDQUs5bvKYYr5GEer1B9f3EIhIZgTIB+uAO8GA9LEbxdgHq6dK J7oer5jmDvJsuDHL3vk12NnCryZSwtBVIStPqeOkp7210IDFpjRV/S8FCDiI FFl1mp0iYQTD78NwmvvfyvYZGwBIdAbzMKxCtLssRsWRNmBiXFNkxw0lBCKr jhw8xz85f4tRp9fg1dBqM0NjYYlLwS5RCPufoPAGFx7nPbnhCEIDkCGBXzmN G2dDSOTIa7EyoccTPKG01SguDGwTDI5MMMScqKkWGRcajVoRedzafbe31WGt BmVsdqIa9CVSB07DjiLoDb5Fuy+stbdW2lJFQSLp3SjomFMafKMPLpGC7cBo YvrbYx8Zx17MPm2Um8eJ3iuK8Gjp7PatuNHcNSdYO7U7OKeDBL5Rs9Oz08uh ocYhF4c5GRkEhGQ8ibzece02Vb+Eo4Gk406zEhhaMeizoGGU4NG0sZk5HRWZ QN0AQBjAWeJ5Wy1S9oCaxjYKOxhLkjVrq4BEeP2xFs3TJmbbOho6kygXiMxy IbjBZjR6Z6IbQ8kK0DzdNBH0e/6PggfrwA/heBGgx1bjj5SDetQZfyTedA79 w9XgfQef2VN/ob1syEBhlUyGrUQKnMAP5sNoAndY4OPsLQxtAC3+5JsB72Y0 srWVlvxtFmmSmF5pAtEpSM6w1CRd7zHLe7gMAfeAyBDljEsMKah3uTJJIpvy YZZ60XTHvWLu00WHjDZF+cKLZnAlQkPevXHjMi5tQ1gdLsHePLZvB4Gy2Nbh 4quWqT5sJqi+YAayIpw1QZM5obMbApQsLwsx39RsbknGhKSV1uaLwrPBYZw3 wM4EdkQ4rxTT0pvzOBqec59+twOQHJ0Q1O9Ka2jBw8QlmnTBB4yOcHIJmG6G tZmTwu2SPxPjbsDU5bVKpON32ld816Xyq7vjeCGDBKivcdmL7S4rir3VwMjh zgjlqMN0SU19EOBtx4EczTjBDapmbbWYBz7bxg3ggQIL7SRYIEQpAOmbHLe6 PhHoHUdx1mA378mHjAb4nfKUYsVGLONBnCFCfAHf571JvtPQPM8Y65G3GVRV Zs7bHzcJkEBp5ltW3qbFoPW7qG6QCEiheVtOctu1STDUu4jjYNryYECAY32M 2vYMwD2SapbZiBo9Tue9UKKLN6QmYY66MOE4di+zlw5HFcm15Rs4y4HGkv0E hfBSSHA6q5hL8WBxdWCUhDDq2srli3hzCcCxHmKmTKeWuVJubBy3stTHM1zx BXkGjKWTMFZFskgEBtiaqvlZ1vcuQF4oul2m++1Tg9bzyluRG5VFZlZrUM54 h1hhppHmCMY8IBRGJDnMh6eLgcANvEoe7EkCjEN2Em6yhuTHQdAa90aiWN6S JU21YBCNvKt2bdqkj47EsqBpQOXsUC+Rf9LMB8fl5uhTC9hhkTSXUgjBYjIF EqUPXH78ZAjHBhRAD9T0mIINhw8JstaYQfQeXsDr8l+rJbwod3d2Scv1DlS0 JyGVQQql5JbKuyLlFyhIEeza3j7IThgIg2OJ6jqi9ffM9vSPc5CH4IzkedF4 Iepk3SiAyIOoT83lxeqAWXpGRov+tUqwQIVfoacPa1n7vW6p26ELjWaP1GxY cofPPHyzQD9hDsnd4FKMBlAjGAIwH8B457i6PnwMDs2aXoVyctTTFG3Q0n7K 8rNiiMbS3f3hu5x+upxNjsb+o5U16vZI+up8BYZh4LFV4DQq5Gj70PSs8Xzk A2dtzUAMCq+k+TSd0XqjIInIVry6LmZFvMLhXVbxv8Y0JuOU+Pz7zHhlPo5m DSrycmZDZ9L+SHr4fhV0TQtmoavdL6+yqbtFJGpFoZ9Jzlgu9kkTA4aTfY3x wDvhOIk5kd0FgkUpMfTEdCsIfclRJRQglMFkQIIm8PUlAHh6Eze4KNrWF9ym PjJdRL5Q0e4e3PjZPdA2qiERkViBs0ZBGAyIogYccgL31s3sYD4ZC0EflVpG kcgz/LsFGQht3eLLATXRGOClsXRgH5cA6ABTSoGCJlBAhBi+YR80ZECjq9kM 8YUUymvHHUm1hJ2ymBIzMu6B8gPap0ZcciHFyfm9bjtQgcEeDkZCHn6OtUDX vN6TS1KmoOd84UCBjBKmdi6ATeXhSaxE2yROtpQ1cjx8e7pPw9WwrIgsDp0P n7HGh62yqsi4yp+OOZLPeB+9N8RZFc9hv1lKBxFmHB6ViwBBt8U+Qr33x+fg E7rwaYAjDOCk5cCbSDQ1bQ6B9w1wm1JxO9ACJQ6lmssuP7pVOQkj1wReKc7o 4wiyEQwoh070B3dPq7S37Ny6fefluyyl8ntIeovwKNqMRYe6Cd+B5egRVPNY FkYCKhz9LYNESioUqFEjf4vGkoDnUsRKEgwKWmJ0KcwINBvCqDlT7Ck9uiPx 84P2zCCy/4lue6oe/54HtpI5QAohaf37ymmxUlJYJ+/g03ptDII2/jd9DzBg IgxIyMh+FnqPodIBRxJSyeGtgw8bd0sQXAhw7gYqjnAZBTdMUTG5nQcCF+hU /DkF+/ln8+/jFPpIMCBkHlOHUa9ewodrcZoEPIjVmQqUQCRYXQ0D7fTFjzin lA+YgYgZKCZRBPU1ny+/Ll8aNEEj1aVw57paJAiIBNf3IAhk+8PgZf4dfpy5 8PbSmzv9bAOQR5581cbpjdzTTqrDYAQhAgBCDCb97ReAc7QdFSdb4VrZ2kGD GkikjU3pArxVzRshOp86QiQ61YJUCJAXrq+gTuwkNprpnDB4b96GDgmNtpLI Bfe2F8eYKxrxu4piUJmiGghGLijJB1jDAUdHc65zbDCZU0d4Z9B0JnmaSwA6 cVDfE4Q5PEakZYaTl9lVVWu0UECRNRYGVoUmoYOaHAwHhLPepJ5bCB4eJmxD EDUSiXxHDBGSBoYgWhJajSlQtoZ7kNThEIxnIKD30UtyE7wHuknbjaij6baD MuwWWgFhdN2NW3IGBwgcHvicMSTjKOGxsGRiCNKNsYEYz8HVlZuiUpG4EgVE 84lEQuBZE4i4CnJJlc5y/2JV4szgeAX5h2BuCgxc3q+3Tol4XlNjcpM0mhje ltsBL91Nd6HHMMiAUmNt/1gg8qYiKUMrbGvMtKgx6eHoPZSyNuuXboJ8R2DD Jabc+odhoU3Hi3aPs6EqKE34FajedeDyW9TXNdXxjhgiKJ83ueJo1+OTcmT5 uZjibVXJJvBhnPZZ1gYmy+URbwhpZGS1UynHJPPRqGJ1opIEx4SRrCyDTsJU J26RMYRraUkKb9jCa1MDiAczY0Cu9oJosuUgcb7ddzYTo2ENNSvCaZ02ShUW TpuFOZrWWCxI6qggWcOG1sd2jLQMYYiAi8qWC7b3NrM3KXq02ENMF3vJhqIn O74b4calOppeQywncmnaywSaEEJrfZWZCsQ0mTYxvgewuLQYC3fffkxtr21Y I5E4WcxKnEgN22C8mYZT2GlcDoMWepmwXkdsMAYGuHEChgzQXRUjI6FjjJzv NeO81xgNv0PoMAyKSIIyKRgkgwIyJ0PP3Ek75sd+TqZ04Bm59W7ocMwmreEz TOvyCMNw7HU4HsgqCiKjHewhCsIHdM+CUjCIVjlYp0NgjIi9SUh95lEXeuc1 QJIbUeCBUInWuIfzRQ0ssk9ZD+cRTfV+yONmyAdhzFejNv1dgdGOtNyE6Gna EBWhYeNRExa+Z7OfgejcT2RDIabuhNJKu7LqEZG5wDzrxEar09cClBEUk6Bs RE2G3UzVkvotdtAlwGTq1gLBBPSMm6LNaP7OW2lopui8x6nz0690EnBQCYRF 3gXl5GacCg2yHlEGfWPs9/2iAcyBDshlIC/tCD3llnuhqHSyrjsrvM/mUKVo iQNikhqhRE4wpH24aQ0ujS0CdTBvOrUveTDUGGg3xqUKGMAG1h2T0iwMEA24 JYOwJ6Y7wQdNGg4hzCqeyRB0OGpkIvXCoJEN9GxsprABLCQBhAkCGVguMelQ N9+bTRwOM493ExCmRbOqQYwZDglbzldFcvK8c4XaVweRBNyJvJ1bVwffMi+n 1EJCCKeNFqiy1uOpHkdxQr4xfWXJisPCdRv4hkMtkW25YO27b6pFibytiQYo Ii6NTkyszLbZYGiQYMGce1OhZtOITsEu+I9+aNgvBaJ/E0UOBJUqTt3duPCd r3XLXvIG2g12DUGRGRYLBYIIiIiIiIxGREREWEoFAtpKzpOXAb5vAaKqLZyz gw7ihUZrRexY5uH7M6YxYEiYwBx3GDEd/DMAa4rsO8857HM881w8aMW95Yfc xUxj+P2fOdqO0zsbEQ4R2w0bphtI3EYR0kuAffqsZKZizfqQ2mOz7ps8vHA4 X0IdJ1DhjDQuBODn4R99d2/O3G2R3c6JxM4Q8c47D4KtNUNvA05HFVaJ7ge4 C0YXIoh20ilsdGVQx0VY1XM8Wxs3N9oU2dt4Oai7bccnm+/PQyb9E8kqJN4Z 874JYJZBDQ+kPON87iOTDm3dnVDkkUm06IMwZJnvyWxFdr2zqto56Ts2+Gw1 wxrF9onu8Lrp052vKcpDqyJ11znanHih3eLJxAVUQWu2+cATjdGVbQIZJG7J iLkGjlIZNAQ44SENgnIpVNqewp754JHTMTfSIExLvHgp5MDfxpLaHgwNxDsh yEJzQxhzE0gsnJA3AhHSrNuVqeJ2pHFA8O3WUlw98DZpyNnljWH2ajuIel74 FMRCKUUiDSQ+NgfZGsMBAEIPzBQAs0IiI/O6FVhNADK9nAMsWKiCqD8/2hLk VQ2Z9OBdTn0hrSmi2HQQ/v/bs/PewA7CiiB872YBoDlOZlkTbvp+a6ZmvAwG AP4FNco9vQ+Wevr45dKuVEfVPMGEISq9G/c5TOzENqNe+Uvf+CdocpZiBI1o lmKvLCDSZhLJEg3I/Bi2T7HBklsA9GD3QEoIOm6RSUm6jFYoKqI+1u027suB q3kVxJeRzteo+ZdifqUbmNwCKxJdAFT6PdRpEQ+EBpTugNQTiRKhNxGG+lfq f4Bn51LKmg6VU+iKGn3NHcTLejADpy6gO0U5+9+DPWXK91FS58LKIkvy+7OD 1r33Z0rnWUQ6aqrwe49r4ZeGaa3ubtemIZI74c8PlBgb5/b7W3NgbYW2tcyc kmAas8jtGIf3W1kTxw58FlM1m3ZcyzA/CKnjocdNkkcaz2PwPol1wxA51RkU C0bG8lO0PkzeOXDLW9q6asuzvFUDl6iyH101FbXHXQ9O/XgUQ66TTIaMRAID xPMHkFdCBg4mw/jIyAagKW+YV+mFsim/tKTt9qO4d7+GFCgzwYnkO0h0b/SI nswCdHOfl9x1j5GQTyzAvsrEPNFPnEgDILQdRQKk5hHsWdxBqSfPdlp15UZR kVOmSUB5HuRfX5VgkhrWdrURPYhOAckIQUyBkwySQlzHV3MXF5s1QgBpa2zl bkU3NobR4rPk6rWoJYlQEzOKdyPJnZajsUplRDZs7nFMOA8iIkYHhoBjyN4b jwjIBCh90zLyt11wDGChWCam8iMgbjUeweAdAZAiQiwfTrO8YmEnbMbI7uZq uQLDEmw1H81AvcH6iJ69/dOwUvgd3K/0MrME9lmAycXvWwUuHI6w0ZXDiSJC JGH0AYmZngehBh06i4PLu7Ams7wUqOcVdrjgBhny16Zp8JWB0VN8BWKdMxhz 4PXHv0xWnNvYIhQlnf1kNLU2me5a1uIkXBnabQeJbOyaENipY5W9UJ0QO7o2 8TDMOsU0LGT01waMYB9GUzOcMI5NuM7wyXnxZXk6ixdiKTpAvUpLqd3cUOjx tYnQU7mNTQ2617LSQh3cPQ1kCjfaEyKI2VnSnN2NlTXMrgFkMynARu0kCBk0 LQG1L4BsKDDWJqC/PQVJJqQk0J+Gxflo9WKYGNKcxmH5zl6F8xB74PwXmPOB Yw8B3gId5A8I9LqoSS6HuiFQ7UUGMBfMkgFYTvnWY7551M5v/D5cHzxg9Ty8 eho18+io1jrq32jmsCz49TTHGQ9HDrqHEK3SW6LaNjhKxy6ykSTYxyyU8K1S o4xZsWC28brBlndNQ9gwYk0w5sPAeKNEpal0dCFDYQMhK51A4bIUAYRNohGA cSB0YXwnufj493Y2+e3Fm+XV2Z5k062pKUrWwdiEDaqIORqII6kQMsokoxkU AmVBeqKYMabBVbu7dRS9nejIPWYHtFqEPQLaaGDoIO5TdtEoZ5H3CNKHKSIn IBSzT6iKHerrzEzgiEgihIoxgaVNRaeHc0u2HYTIFOohIKQipkJF6TXabDxB SSJU3GYe0cgCND5trSzxnaJDskMA8F+MPquOBQ7Hs1QrLEC2HwVVbzn4HWAd vz01AJ7KwSlAIMQR0QIyUOeebYnzw33Di6AMYxtRWPiZDG5agKTuzbDjMsoy TCGikR8qSmSIgjWI2QYlvimJ+X65TrgaKlrJCCcj8BqWzkaMqbUZB6fDdAdL F3pmh4Y+9qQGjf3A+cscikz6yDpVI4BtPSkG8QskKEHYCbSCRdZFbms+cuYv 4JwLwJRn18/A36MWIgAKnwyGp7yHQ+GkNMYEUuEET9qInxlzUYp2wNwAblEo HoFgIHPCg1ABY+S5kEO3SnQ6LsYZyBpZlZYE+KBuh9ImCeSBNoVczCmkGDzQ tDuOj8i2WH16e7WpVVD5/kpNHruzJA66Oc9dL5yGYLJiHoGLMC21ClsALAFh UCFkBAlVsVGIKRe9kmkAG2V4Q2YIpHJdnINlXZoky0ic7jDY34MJGQ3s1T6T JN0gmdNilyBtSloEMwIOUJs/iVA4mZidGVBIqgIAkZA8DpsZNUO4noZubIJs qUGAe3U3h7+u47E8AKMsFArbfZuChWjO5ImMYUA7YJZuG5hO4OmgO3LfbmES GwjJKoYhz3rpngqztF+EkT4o+E9GYMdSWVZjalie801L9aBuO+CBgTBGUXPt mDkXBoDvzjByPqIhIBURWXictfuFlzEOylpyFgv5IKyDFICwBBgLCMSCMILI AoqJ1CNgDSxcC4ep+ZkgNFFMnNapnAeqJbMyLoRim2OCmVktWzJyd0aDUBYx IrATphmxEghxASdnElZiCabqZEoCAJc65imOpDxX3UMPAxhCDGQGVwCos/fh onHLMEzRSqJJqOCpKE44Cc+WlirPe4PFsvnw9F+LBbtDeKc0k5PJmnEs3T80 QUVZyJoPqDLwwOSfaBc76sRKAdpSIU0QE1xLj6oJ4vCFGolxKCfBs6X6nVj2 GZkyKDMUqldkyt4t0JuklGe8VDBR9n6BkXmOyRzk96B2xTuwCLirQLDsoatS G+jXZnCixUHeR8jNNDuz23O7bY1xwOS89ig7iKh2xYsWZVKlUENwb9lN0U3Q nJVfKKRgSCsgFQqIEgJIth+Jwravn+TOrPWIGqLxAiRQPWLsoWFbhB+Lz6yd MjLASUgs5GwpDYfdZYexTe7vHZA7g/Bgc/1Y0ehHSHI8bh80kEogqQk4Abl+ 8aiIfIqBs0+goiGtfHmeiWZEl18FXDHxs9q79FVKrJ8cNgdh3EzB85JBCRR4 p18jnhozPfAu+RSfnwbI/RATb72AB38kYaicvAQNutJMXSpqgRjtDxAFC4JH k0qJ85DmkHi7csQs0HjvK6WHYeJkBcD8mdHwhWC6fa8sztreB9CCPB2iJaFn kM9Y+UIghiJFpgobnknMFqD0PX3TNtLyQedneMJNUy7SyaWkRKJZEmvm6xia bpngs0qtNMkx6goYc3E2BkBCIRTTRbB0HdDn06gO6SdtCfT30YwHkXsNwZDJ AE4hsLHbqE3mQXWgOHvQX1t0QnmDIWIyTZKiMGPqajDmhT1gwrBRREQZE3lG zAz5CKE6SdZvT84A9z9O8NQXJIMD7KTSQBD6hoftmQ2weBFL8uidEbAvwylv GV8okYmoWMAiKqqgyO0fKFJkyRUyUMke3rhzggMD4QQoMgCIjJBEIfHSyIwC RYx6sgOenyJZz9U+MzNXF5CHNEK91HkG416uoatgwPGim1HNPcwQNsMInkgU YKRBEGCxZEUixgIIhIKo/QhkCY+xtgX8tDoZxaQzaVpiYlkIiMgAPBF1fD49 aSSSe/TihsRIOI4vGMYy06m6vLyHDqWbDQLOhnRVgBqoWnJWPgOpATQJ25A1 kE4OuuOKSHw32YqoH3Duujwt27sNJsdOom7SUEkJ9AHiwsU6mF1IVVFBZIDG Kqv3b8UTnF1L2grRNfXHwKQ9/vKeZQP6FArHANXwCgaNvus8jHIG5h0vLD5z ik4HWGDDG2UE4qBk6aJvsqdJwQSKBSw4U9bqHA6hQK4DNuywow52UQhCSa7d MnAjkkd7T5wuCOFgiEopMJlEdmD8uLp4GWfTAAxkUBRCnRENgC5nOWQWW4UZ 2N+p6mQOcgmqhnmGxqp17tYxsSD9SrOs89oebcuk0Yw8HbO7nlM0O8R4ciFI IrqylW0wdY5nduvgpxna2I2U5ihmosSuAgFRgE9SfpM8X6C2lmTcpjV5jUu8 1y6m5k6lJRiqc6lBkC2WBSd4D37PR4vDoSYMVgqcDYwJO3DUNDjEJVM2HJgD skS/SoiOLdoCfC3WjnIOR+ExBr4AnHmaXoyBRIPrL/VDFJGzt8Z83cNJIzUZ M6zYD0m+wjJfwWuDC8cZitQ4j6XfeMsGGwZMmw6TcfFJZBdpSjUDy3H4kikI xgPEPDJ8ZrU3VLI0UlFHr4p2b+DO2/Q30G5RT2R9cxlKGhWMsq0Q1aYQTm1k hp35dffJ7yhy0c2J2EG6p3m8YqNZeIJXzcUgYWn8IMVNoFO8F8N7FibNb3dJ QzTzmQBQExo/Gju6sm+MjIEEO5Vd2dCZBkEBH0xfModYzzJ5CaPmpLEO5Cii DTkc9VSWJPQsQ6OHKIaCwvAAoGJBdrho5Wej0b0MIdO1A5iiZyLJ5MBSLAUu WUAQjubPSMO3lPJyBo0kKSETmETINgrTI/SHhzAwWFLgwwX4E1Fo/w0etF2W ly9im5ehpve3xwue0aO96Tp6dnIsrrBygpGEz8MdyCZzISDIC2JqAaDANE0w CY0WP47/eIMKk+8xEy7ch5tI4rcLouikodWbMwG0OyTdMO+XCKkHx1UxhJSh RJkv4DKQ1CzluS69A+ZQXpOosC+u9DAmQRjEgUQybT3AWcDGBIekOcLUGxKs ANzpudiHpGeV0pnmepTw+xF7P0Qw97Zx+BVJ0hGGSTKquGCWoGJZcjylnmOu iHmGooHxs9z0Kwg2/gp7X29jn5abA68wPl+M+4wRWMRVZIkiLCQiiaGRy1sq Nkdvk5HXVSQHzCGalaltI7qmNGQikUAGMA5zRo0iVqoSsIZ7xhrcmpwU2D2H hEEwNR88N8yu1k/a4HTLW1g7BQ2qQYhmZxaUOeqSw8IPdzewuP6QO1wJDOjI craVtC5sER3PjwuuXCBZROr10IJlErJF0PymGBwcJXcDz9+2hGIqfs+FAwiT yikUJOvrPUlBIIwevjB7pm+47AguqUiGFcAzCaFA+PI4+5fEGXAmRmkPXKl6 ofI11nvAIbhZC2WwODwScshd+IaPTExd2ErzNEYQOythFO8WmicJRKoIHcrs 7GZi6UZcjkZq2auSz1bFhNHI8dccHVwJ2ocxubsbrHS6ongU4bgrzljhW3eT m5reJccKbYh/hIQL8z6V2LwMGIiKhzDrkmDGIgMikgiIs5WxmZem1NkNAE2j SDCdNcN0iqLacCchZD7DYGSO4GkBkPlKikBGaNtt3cnBafGTwZPh+s9XnOw6 17wsUUVFSLDhg57utQVTEuWBYMDD4JJsD68Bs1qfAm4WhTJ3vwSBvprgYBwu BQjZGeofh4Jv5F4mODclgYlEJmxSGnUarETmpJxkDkgkxR1wh5hOBz27Dt+c w56RANWjNkFiRLMP3nGRJJaCkIQhAIMBYzT5kvHULWt2qzOk5VoMUntZZk6c hYR3qa2ZOZMw7BUH5UD2GQCTxe96PkRCSTKihs8soZEppyI65hKPs/9/f//f 7v+H9P8f9/6v6f7vh/47fR/w/xz/f/P+n/L/j/SHV/T+n9OPx/0//Pi6jtdx 9DAEP1UfEXup5RIv0S96POQMWwfyT0ej3VPaURYoHojAlElGUE9RCVA0aAoM UjIyCwFUVFGECtZGIogkkFhCh6aSQwgwDQk0CmDhuP1J9mh9rlnA1wh+CBax E2KMktUKyqiB+KUCTIGnPW0t2fywtc/tzEw9cPwQTBCAEV4nBON0W7phLnPC 2fSamwHLaptXxcSltISQxJbjU4uCKWugYIUxSYBSai2P2WjambaKqwikFAFF AiyIkFJy2AZik2DjgdWiDItkC49aScOEUO1Ieu7kgJIcGoGBlJGERICMDsPB 4KGlmYQDGKYMACiAWANKBNLs614EisZ3YCZ4qGUWySet+6Q+dIFLFZmlRAtA LGD3lKNzIV+Rg5YcJ+75qpE29X7hohyf5DO59fdfYrQQ6Mh3J1QFkm8Z1EON VOJjKZmbISIVAvO/g6bfURKVHLWfqcXDQiXmLADGAYyeqMlIKwBE1ApP1Q1K AAoepZmJZgXL+Pzsc2JkhAWogkIBGCkeTSv5iygP1iRzxE/ZE4bgLhvYT9kp ohIkP3PdyOhkPKC7PjE3I+EYPg/PQgWRLeILMX+l1SDBsH8XlMD7aV9AfyNx ehAhMCOoWjk/IGGM/6/oEYHUmqoKz5rKKCIgwWHwWUWY2kSgrbSUAckt/X+U PCNbBoJupCARTN96d3UGOqtQ4qBdRIjBgRGeRt2w1y2DgdohIr8vyyHgggk9 aUiCgLPAtgEk+1ApcOkKTi+BqMEDXB/qiAcY57FMqzn72k13S8BaNKmQG0j3 zqB3wGQAqFhiAQKPebCe0ySj5WHd1CHDINpCDFhIpAgRIpetfhNf7OlugZwQ 8USuaypZcfTrE5fcfBbLZ1Q6oWD908xaMwYRRn5SNcv2luYNBogByI+NEtFM JzEWRG0JgYfLLaMo0ZUUhUKx1h9pQoAVwKMCISeQTEp70matTwAXoO3kBl6Y QWRFioBwQ7zv9R+5Tn4qR+hCxiM8SfQgp60ApylRFJQTElmFkDE+7Dedn0w8 g0y6O8KrsLu867zhU9XvwHwYtwIoTI6JkloIRNu1J9yBxE6ip5FBT0MxCZ5G NHrNQ4yvSEBzeEGhsF1MMe3BiUANe0MRPYRU9kLz6pd+x6RZXusCyvgbseNu X52KwJSmdCU/J6AaFpltpTviGDl06HLpd/J31rq5InBmiHAIbt4LH3Q3yTef YpzqGmEFWkaCC7N1TaUWgxSCkAnDAAaSYjMlk0moVgMQRgLCqmAQDIFgWSFB KwlKhuf1enUPjNd4KRhCnc2bbS33A2GaOuKORPvtpgu1ND3NCHmgsJvBgeEY tBIecCJxMnHBwgwgemB6xAmRt5WMr0BUPFAixPX5KbAaSm8w0nY13dQuP1pH 7/kKuunYohUUIg27lfypANHdmBNMnmnkh8XoYUMUURIRETtBLlIFaSWdhPzQ 6Ya27yWHIYfF+/allqk10wpBJs1BBEaI6JDnjCxr8hgOeGSGK5h4iMIGGHfc h7ipy+3a3gS516vjjIZ5j86AyxEEngWHU2MIrtLrBCBQ0Jxgkma/sFMQPMK7 RWfA8tcAbw9no4LO62UkgmZy0/HEz/NTzncI+kZGR9IA0QvsKD8c7zER3ABT JxVHE6S0JdxJXawoEpiPZYaRkaDUuFVZYQRpdQAhv8K8ydXf9GKrwDppgzBg uzFfGA2QYLDYIGNBWGHkASGYHMAFcgqoSE0m3tr5Pa3UMtgrBkV1msIouVQM IR65QWX3YYkISHJQNFsuO/Y8p6BVBHCZA0XRoGEpIUA95SSHbRpRRktRxh+d b4lA6nXnDpD0hrib2FJ0WDEF62ik4y4XyHHDsmMjlllC0ErBUiyyWID1ZCiG tBKWEaUs8ywRk2LFlBIC2NZWodbQxrIJEiCwqUkW2rYMlOmucR1MGGhIHAoY kuCHSHNKlgldSUhsabMQsZWW2v3maEOM4OVrMnkcCmai+E8YbCMFCP31AlRQ ZFA3zhENYF70KOE18yhJZvEBw8GGQbHeut9YLL6ijaRxRiIQrIkA/dYyWHAU UzMOAHcO2BlfDlIbsyMJAQyKDnauFIlksKCgsWLKaE7mux69RYwDJG3CCblI hZQL5BigR9YRJ8GuxsVnrSh3J3tLfVv2zUmyDEepR6B6T3+nR3m7EiPnpTZl OZQ28hFsOgmzOjURCvd3D29WdNTgIls1kmdZkNCoo3IcBGLnBIUfKuvGLdMf 80e8gdp4NuZmbgJg8QTc1FCLxgPeeVdne4Id1j35fGPodOJAzs7/uGALh3NY fELPQqiqrZgfAFDfDEuGKQGw8xvIEKNQQN26b4yIWHRjzCgo9z9kfb85QY/c VzrlScyJYWQj5eNLL4LPh/JRiKYQDxxAKIJHzE2PwxNRZLBuTDlOD4Qm0m3j DVcDTHgwODuJ+5CPUxx9mebN2yggIRuvW+S2gclrBSO1oGbuDKIxiIF4BmbB Dg/KEhEDTaAYIDkR5h2h8YECISKQioLeSDoIOxRRBoIpwQa3+3AQpwtjRzVW MFjBJZaoeqtlthDSqPaQU78UR7UNFXoAd5cZASCsHQ6+X2Ift5vZ2VNu1Q5p j3p0c4RLOHk6DnOwE8BA/nIgHSo9KEA/ukJxwHaBRDJoGRiYhJFUgqxYk0WS pBRkYPi0BRVgEJ4WcoYSRjZwkUWEirIxBRGRZGlIwGmoUUBSBTLCB90QdG9F U7pv3E9ChAN33kOINLAQwcC2kMyQIAfWDej5HyrX7C1+beTiHBttocukc4P4 WEhohCU5xZHm6oxDQGpM2D+JzEi6GCIDBr26vQmOShVDXykR6XZ7DJWw9quj 7IfBEe2qd3GZgxagdBJMaBGYbWPfjlET1UHV6p7zg/DmmrEQfCnsEzokdxNw 2TrLgyzbQKDv65oyvy7iMUr74qRdILguO08akQdX0ZlEEfIaznGGhTDwmVu2 0jhBOYDuWFKYft3hpfBsawWPahKVvMa05v6jMIykbp1SaXNs01IElSFS0RD9 oGur2dwuihNi07NRc9oMy4RVrMu2YLCqbzSOT4ON3LSR1Wx4bYFZWZIHOu+S DG73sRFdOHDmOvjoznhEG4OyZc98bNzQ6ZTMK02w8LqPbCGiNoCioMrKxS0t nNN9Dty0cd5RHg2HIQgTdtQJaz5v0ZmeIHO3MEUed42auOXIs6uRemKOQYgS tKFMhUG/xAXGRAJfX+rpBiMTeXi9EJnFw8OZwUPYXPf4FmLfGdkvCE1v6sLT cx06dN7tyx0CEqJIRj4feBuhz0H4i2oTRygZ0aNkfGxQYPmIHWG5ooCaF77D /oOwwxCmYqJmQtFS8JuIihgqURESVUk2Ogs3BMm4hNTxEpz3xzRufosncd1J 5bOMJmo7GzmWl7G2OFUtEJEIbodpLifu7gbMHrDjacCI5CHxh2HxN4KcTno8 nI+4EPReENwRLEQ7BKE+HlpMcQ2hzNTeB5RELHyNYa8gC5ZCyrMG9PkExJGQ ZFl4ZeEzC4aerjNIpaMJqRTyEA2H6GDkfXtqmM6KqNZys4ehTRqocud5wSwG 98rvTCQLJuGuUOSZHLYGpAJMHsIhTCBTFk9xZwEdPwZsOODeBasI8S0lGzht LrdS0/DMbHQ9cpLzXuePl087vP0/w30et3w4gzoILlCTofDqGhOfSgGMnagS jzQOGEAud3KvpBuAfLOSGQekF74EN0uUMQTE9T10aF0aLMClgim2sxeAKIDY wgQEkA3d3TC4MduXrlCYdgOp1kATDpQowe+vPJkgMQGeR5DVqdXZuLopFmtk qEtpSUlJbSUQbSagjIe/7xWIIxVjMIXgWSrLO7VcA2E6MgQDg7+qB2Q5fWpg 6giYQgp6BvNNsNVrmAcjg0IZNOgZhUGj4UN8tAQVkQiAsiFYWMqeVk31/r06 nvigUZA6spZbJ7zvxbTHx2PA7ebqsZkxqgjQQLwvxwDdLKHkNwdXYP+0sF4A ZH0uip4SHs9jLqeceIemC9VOZVlltz8aPCQn3jzwxAx+kN2rbx4Eqmh4kY7l BQT7sEN9v8BO5bZ0/nndRsm0qBgbFoKEp717tU1c04iUDu0m/uEzCiUEsUmX RWM0NObirRtDK2gW9VuMUxpkEbP/G22IIqiM1jYzviwhw4Lc21qCdcNQqMwV vFlE56YMOOxy0URVucHVNyNxDaigdSrg2gQMsFcNKKmSF00sjN8sJscOFmSG XC7HZo4cabyeFTbmX02wzOiOQ2OJfMjwWmP18yPzp+mKsMsZJ5B+bdFMbbQT IDC6NxDM0bcjFOiA0t1K2DDMSjXaZoUqsQSoZjjk4egjkH6Lsgwjk67CN8nW uMMZYEco6cXfKrpOd+WOFwI3TZEyHMzfTBrRXTZimWTAUQa26YvffF42BdR4 0mWKY32I43NwOGNsbddcoEpd8D7Ehu2iy+jYJ1zAnhAb3QYZwNaOMdljfVvp FZl0oFT2O6jacLeWxDJt3NSB0GWtK8aM5iHhMUJxsLB+tM2wBHZILBY8g0TT dNpg0kW/fnCtBrGOGm/tENEWOJmam9jMdxOV0svqaKQSM4DEouTTACHQB4TR btsxT4Ed4D1IGICm7kxmNgtpTMmQgNvmhq608MYvBRePHiVvqkx42ljvadpv DFMgecIAOSPlGOLBQMhIoflCQkZIIxiASAESQgBK2cBTJ26tzgMEigSCyYaf DCinz5KGIiQkZoN1bEJFhCJIKaYUVEZFBgyCPSJk5XO+FnZdlvgXRlwtkvKB XSZS3bNBMwwuswEfQczmcG+wkLwFK5Ojxhalwgo4DwJtbM2pA0wJBtjAYiDA LD3kODjze6TUJJwaSWqUi8Mgtthm/fHslC1q0R6o1i4HvhEkSBZR78NTEQPP AXsgJ0wANMCeWkQyivENh96BPlNThlYMcLuG6gNME20JQ9TAwATM4nPAjwO4 6AnALnfzdIgDnDQHcmE9ayd4g67EQWDJGe/x0O4OSh8yUYMVYwYfEMogkDLk aJq+ZfpTieZyytOt6zFg6+OW2VFbgqiB0tPAI27JdtZFoUSgS6E1GQ1oQzWV HTTAZznQDaZsvOEAZyRiQ6EM7+OJUU5zaebdCUc9ieii/l5kCkzYibCAvgEB ou7AGx2U44t6tKUz5AJ2J1sENxSPacG7fZ8DFxSpGlc05BuoOWYG2eCRsOpQ g2sWCDAVTKlMQE59Et9Q+DPGHyze2nR3NouwnDjpXptrLSdwzm4g6Gc2FZYJ jDgpQJvyuwox4JMMiIcGEjRBJfg4cNm1yEaLrIMilKrZAGlEJqniGLIMFO5T yg2MIehHKRy+kz0fXSGxsWWpv5qYem6IeY5056EoV6MMgMZBILqBi97n+EMx B08bPdjp2aU8XXSXgsiTAKRNh69+jcofe2+B/ePCcuXIzAVM4GQhfFaG55Ju KRogcItMRj8dKUUAe+L/CQZBBiBBD8ETaCDaChd/0UjA8iP97mKSPNF95QOv /idxeMaxg1ndxf4YvN4w6fCoEIJ5n64DRT4goveJBh3yu1pJYpB/z0CblPVT uTsmGze4PcNy8UaTrDMfVSFvd9NFeZ5FifNNVTgwyQoLpYx78aWOMCBEwo1A lzCcCHE00e7KbF+TKZTxiGBio0Is6GHnkPQIC3sPychIRjFCRc9W4VeY2ovQ FJsaIZEhBK7CgdewpBTzaPo0yOnTiiFJAkYEHuQE+GJTuTZ11IsjCbonFWen 7vOlgx406+cYW1eKLyDJgLv6MwHTPM2LQy6Bx9cWdhCEDSOqkvhQeczkYxCQ MwsnIQ6utYxA1/3vmFpEgvzQkVB0gDURAxwq4RZCRyaQcQgQcjSvQaDM6pqh 1ECIwk5s6kgfp9S8hikL0lmFKBaUWISgWYskuSo4xTDHsQqY7+ncAO0N2isk 3SKBUFIaGqCScmEQdBoPSPAt+eNkJw5gbt0gGIihvzvG8OuzuENzR85wT7qd pP+loJJgxGGhkqoWmWyga4iG6Q7pEINEB+yiiBGBCQJOIY8yysQFwgGDAYJ1 lKGgx80QUDiZrKe5YAUkDHtRO/AIOWE33Yfui0/EQoJLiQCHcHNkpMsB0XOg wHpBAN0R6ncigWEKM39rKoofV3zjIbapXWdYfGCWDgAzTibnlkWENifMUFG9 YUYLQoUh7T0GaEXw9OGMeTXv8xAdxbaW6Jxn9Rku1SwUUlN6MD+N/Efut8Mu X0aDXz1vpvgP9+K4Q/8JfBtSzvDcM2UCHGcku2/q7c5GoXpyzte7JPkCnM3G 4vdwYmL5Q2GM5oxDdqjxVQxBOzhziEAPs38THEs0NynMjYITnm5Nju2mkWcc hGG1oRdxoxREYwsYPlKjmTRsRBYCsILGDvgUxiQ/G5l2ShiQwlpvcwMJnEN+ 3kiJEIRphISEAkwGjvLJM7oS3SEx8bjkDsOyPm9FStiYvCHPw49+WM6MwhGE iPtfH+du1DYw2NTVRWyzJtBMDrL/BEJoB9Bahr5zLqB0QOhoGQy0+Xg2NIbW pevXjMxDjQ6F6Vz4rVgb7U4mw0rYEYsQ1WDaFKk+1Dw3ExzX67bVHT2OqcB0 T6CBwQ6ugIbpzVA+21EfjF+5GBGREfTAhEtFdXvWtFi/KWpRLLCLO/FPxMVs pX8hZB4d82WDEk+OJ/4U/BStyIT1VX7FsiZoIRgKIlD9DQ+8+Z4ENJPNBkE6 U5jKwnoiGIHRFVGEPanTVDR0Pl1SkhZLgaiqCinVEwh6p/YjcxvZUNiEh/+L uSKcKEgcS40nAA== --------------030200030504030706050608-- From jmorris@intercode.com.au Wed Oct 23 20:41:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 20:41:45 -0700 (PDT) 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 g9O3ffuR005342 for ; Wed, 23 Oct 2002 20:41:42 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id NAA12364; Thu, 24 Oct 2002 13:41:36 +1000 Date: Thu, 24 Oct 2002 13:41:36 +1000 (EST) From: James Morris To: "David S. Miller" cc: David Woodhouse , Subject: [PATCH] Re: rtnetlink interface state monitoring problems. In-Reply-To: <1035219674.4817.5.camel@rth.ninka.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 930 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 21 Oct 2002, David S. Miller wrote: > On Mon, 2002-10-21 at 06:48, James Morris wrote: > > Forgot to add that it might be possible to get Andi's solution into 2.6. > > Send me the patch for 2.5.x > Patch below, for 2.5.44. - James -- James Morris diff -urN -X dontdiff linux-2.5.44.orig/include/linux/netlink.h linux-2.5.44.w1/include/linux/netlink.h --- linux-2.5.44.orig/include/linux/netlink.h Fri Aug 2 07:16:34 2002 +++ linux-2.5.44.w1/include/linux/netlink.h Thu Oct 24 13:24:33 2002 @@ -162,6 +162,10 @@ int (*done)(struct netlink_callback*)); +#define NL_NONROOT_RECV 0x1 +#define NL_NONROOT_SEND 0x2 +extern void netlink_set_nonroot(int protocol, unsigned flag); + #endif /* __KERNEL__ */ #endif /* __LINUX_NETLINK_H */ diff -urN -X dontdiff linux-2.5.44.orig/net/core/rtnetlink.c linux-2.5.44.w1/net/core/rtnetlink.c --- linux-2.5.44.orig/net/core/rtnetlink.c Fri Aug 2 07:17:32 2002 +++ linux-2.5.44.w1/net/core/rtnetlink.c Thu Oct 24 13:25:35 2002 @@ -523,6 +523,7 @@ rtnl = netlink_kernel_create(NETLINK_ROUTE, rtnetlink_rcv); if (rtnl == NULL) panic("rtnetlink_init: cannot initialize rtnetlink\n"); + netlink_set_nonroot(NETLINK_ROUTE, NL_NONROOT_RECV); register_netdevice_notifier(&rtnetlink_dev_notifier); rtnetlink_links[PF_UNSPEC] = link_rtnetlink_table; rtnetlink_links[PF_PACKET] = link_rtnetlink_table; diff -urN -X dontdiff linux-2.5.44.orig/net/netlink/af_netlink.c linux-2.5.44.w1/net/netlink/af_netlink.c --- linux-2.5.44.orig/net/netlink/af_netlink.c Wed Oct 16 17:45:49 2002 +++ linux-2.5.44.w1/net/netlink/af_netlink.c Thu Oct 24 13:28:58 2002 @@ -69,6 +69,7 @@ static struct sock *nl_table[MAX_LINKS]; static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait); +static unsigned nl_nonroot[MAX_LINKS]; #ifdef NL_EMULATE_DEV static struct socket *netlink_kernel[MAX_LINKS]; @@ -317,6 +318,11 @@ return 0; } +static inline int netlink_capable(struct socket *sock, unsigned flag) +{ + return (nl_nonroot[sock->sk->protocol] & flag) || capable(CAP_NET_ADMIN); +} + static int netlink_bind(struct socket *sock, struct sockaddr *addr, int addr_len) { struct sock *sk = sock->sk; @@ -328,7 +334,7 @@ return -EINVAL; /* Only superuser is allowed to listen multicasts */ - if (nladdr->nl_groups && !capable(CAP_NET_ADMIN)) + if (nladdr->nl_groups && !netlink_capable(sock, NL_NONROOT_RECV)) return -EPERM; if (nlk->pid) { @@ -368,7 +374,7 @@ return -EINVAL; /* Only superuser is allowed to send multicasts */ - if (nladdr->nl_groups && !capable(CAP_NET_ADMIN)) + if (nladdr->nl_groups && !netlink_capable(sock, NL_NONROOT_SEND)) return -EPERM; if (!nlk->pid) @@ -590,7 +596,7 @@ return -EINVAL; dst_pid = addr->nl_pid; dst_groups = addr->nl_groups; - if (dst_groups && !capable(CAP_NET_ADMIN)) + if (dst_groups && !netlink_capable(sock, NL_NONROOT_SEND)) return -EPERM; } else { dst_pid = nlk->dst_pid; @@ -743,6 +749,12 @@ return sk; } +void netlink_set_nonroot(int protocol, unsigned flags) +{ + if ((unsigned)protocol < MAX_LINKS) + nl_nonroot[protocol] = flags; +} + static void netlink_destroy_callback(struct netlink_callback *cb) { if (cb->skb) diff -urN -X dontdiff linux-2.5.44.orig/net/netsyms.c linux-2.5.44.w1/net/netsyms.c --- linux-2.5.44.orig/net/netsyms.c Sat Oct 19 19:57:49 2002 +++ linux-2.5.44.w1/net/netsyms.c Thu Oct 24 13:29:22 2002 @@ -411,6 +411,7 @@ EXPORT_SYMBOL(netlink_kernel_create); EXPORT_SYMBOL(netlink_dump_start); EXPORT_SYMBOL(netlink_ack); +EXPORT_SYMBOL(netlink_set_nonroot); EXPORT_SYMBOL(netlink_register_notifier); EXPORT_SYMBOL(netlink_unregister_notifier); #if defined(CONFIG_NETLINK_DEV) || defined(CONFIG_NETLINK_DEV_MODULE) From davem@rth.ninka.net Wed Oct 23 20:58:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 20:59:00 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O3wvuR007598 for ; Wed, 23 Oct 2002 20:58:58 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9O4BARU009684; Wed, 23 Oct 2002 21:11:10 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9O4B9iM009682; Wed, 23 Oct 2002 21:11:09 -0700 Subject: Re: [RESEND] tuning linux for high network performance? From: "David S. Miller" To: Roy Sigurd Karlsbakk Cc: bert hubert , netdev@oss.sgi.com, Kernel mailing list In-Reply-To: <200210231542.48673.roy@karlsbakk.net> References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <1035379308.5950.3.camel@rth.ninka.net> <200210231542.48673.roy@karlsbakk.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2002 21:11:09 -0700 Message-Id: <1035432669.9628.1.camel@rth.ninka.net> Mime-Version: 1.0 X-archive-position: 931 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@rth.ninka.net Precedence: bulk X-list: netdev On Wed, 2002-10-23 at 06:42, Roy Sigurd Karlsbakk wrote: > As far as I've understood, sendfile() won't do much good with large files. Is > this right? There is always a benefit to using sendfile(), when you use sendfile() the cpu doesn't touch one byte of the data if the network card support TX checksumming. The disk DMAs to ram, then the net card DMAs from ram. Simple as that. From yoshfuji@linux-ipv6.org Wed Oct 23 21:50:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 21:50:58 -0700 (PDT) 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 g9O4oruR012651 for ; Wed, 23 Oct 2002 21:50:54 -0700 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 g9O4pBHT010082; Thu, 24 Oct 2002 13:51:11 +0900 Date: Thu, 24 Oct 2002 13:50:55 +0900 (JST) Message-Id: <20021024.135055.10632889.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Sysctl for ICMPv6 Rate Limitation 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-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Oct_24_13:50:55_2002_573)--" Content-Transfer-Encoding: 7bit X-archive-position: 932 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 ----Next_Part(Thu_Oct_24_13:50:55_2002_573)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! This patch add sysctl for icmp6 rate limit. This patch is against 2.4.20-pre11 (see below). Thanks in advance. Note: This inlined patch conflicts with IPV6_V6ONLY patch. So, I attach another patch depend on the IPV6_V6ONLY patch. ------------------------------------------------------------------- Patch-Name: Sysctl for ICMPv6 Rate Limitation Patch-Id: FIX_2_4_20_pre11_ICMP_SYSCTL-20021024 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- Index: Documentation/networking/ip-sysctl.txt =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.44.1 diff -u -r1.1.1.1 -r1.1.1.1.44.1 --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 1.1.1.1 +++ Documentation/networking/ip-sysctl.txt 23 Oct 2002 17:50:19 -0000 1.1.1.1.44.1 @@ -560,8 +560,14 @@ routers are present. Default: 3 +icmp/*: +ratelimit - INTEGER + Limit the maximal rates for sending ICMPv6 packets. + 0 to disable any limiting, otherwise the maximal rate in jiffies(1) + Default: 100 + IPv6 Update by: -Pekka Savola -pekkas@netcore.fi +Pekka Savola +YOSHIFUJI Hideaki / USAGI Project $Id: ip-sysctl.txt,v 1.19.2.1 2001/12/13 08:59:27 davem Exp $ Index: include/linux/sysctl.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.18.1 diff -u -r1.1.1.2 -r1.1.1.2.18.1 --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 +++ include/linux/sysctl.h 23 Oct 2002 17:50:19 -0000 1.1.1.2.18.1 @@ -345,7 +345,8 @@ enum { NET_IPV6_CONF=16, NET_IPV6_NEIGH=17, - NET_IPV6_ROUTE=18 + NET_IPV6_ROUTE=18, + NET_IPV6_ICMP=19 }; enum { @@ -371,6 +372,11 @@ NET_IPV6_RTR_SOLICITS=8, NET_IPV6_RTR_SOLICIT_INTERVAL=9, NET_IPV6_RTR_SOLICIT_DELAY=10 +}; + +/* /proc/sys/net/ipv6/icmp */ +enum { + NET_IPV6_ICMP_RATELIMIT=1 }; /* /proc/sys/net//neigh/ */ Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.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/icmp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/icmp.c 23 Oct 2002 17:50:19 -0000 1.1.1.2.14.1 @@ -25,6 +25,7 @@ * add more length checks and other fixes. * yoshfuji : ensure to sent parameter problem for * fragments. + * YOSHIFUJI Hideaki @USAGI: added sysctl for icmp rate limit. */ #define __NO_VERSION__ @@ -40,6 +41,10 @@ #include #include +#ifdef CONFIG_SYSCTL +#include +#endif + #include #include #include @@ -715,3 +720,12 @@ return fatal; } + +#ifdef CONFIG_SYSCTL +ctl_table ipv6_icmp_table[] = { + {NET_IPV6_ICMP_RATELIMIT, "ratelimit", + &sysctl_icmpv6_time, sizeof(int), 0644, NULL, &proc_dointvec}, + {0}, +}; +#endif + Index: net/ipv6/sysctl_net_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.42.1 diff -u -r1.1.1.1 -r1.1.1.1.42.1 --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 +++ net/ipv6/sysctl_net_ipv6.c 23 Oct 2002 17:50:19 -0000 1.1.1.1.42.1 @@ -1,5 +1,8 @@ /* * sysctl_net_ipv6.c: sysctl interface to net IPV6 subsystem. + * + * Changes: + * YOSHIFUJI Hideaki @USAGI: added icmp sysctl table. */ #include @@ -12,11 +15,13 @@ #include extern ctl_table ipv6_route_table[]; +extern ctl_table ipv6_icmp_table[]; #ifdef CONFIG_SYSCTL ctl_table ipv6_table[] = { {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, + {NET_IPV6_ICMP, "icmp", NULL, 0, 0500, ipv6_icmp_table}, {0} }; ----Next_Part(Thu_Oct_24_13:50:55_2002_573)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linux24-FIX_2_4_20_pre11_DOUBLEBIND+ICMP_SYSCTL-20021024.patch" Index: Documentation/networking/ip-sysctl.txt =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt,v retrieving revision 1.1.1.1.42.1 retrieving revision 1.1.1.1.42.1.2.1 diff -u -r1.1.1.1.42.1 -r1.1.1.1.42.1.2.1 --- Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 1.1.1.1.42.1 +++ Documentation/networking/ip-sysctl.txt 23 Oct 2002 18:39:55 -0000 1.1.1.1.42.1.2.1 @@ -569,8 +569,14 @@ routers are present. Default: 3 +icmp/*: +ratelimit - INTEGER + Limit the maximal rates for sending ICMPv6 packets. + 0 to disable any limiting, otherwise the maximal rate in jiffies(1) + Default: 100 + IPv6 Update by: -Pekka Savola -pekkas@netcore.fi +Pekka Savola +YOSHIFUJI Hideaki / USAGI Project $Id: ip-sysctl.txt,v 1.19.2.1 2001/12/13 08:59:27 davem Exp $ Index: include/linux/sysctl.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v retrieving revision 1.1.1.2.16.1 retrieving revision 1.1.1.2.16.1.2.2 diff -u -r1.1.1.2.16.1 -r1.1.1.2.16.1.2.2 --- include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 +++ include/linux/sysctl.h 24 Oct 2002 04:38:38 -0000 1.1.1.2.16.1.2.2 @@ -346,7 +346,8 @@ NET_IPV6_CONF=16, NET_IPV6_NEIGH=17, NET_IPV6_ROUTE=18, - NET_IPV6_BINDV6ONLY=20, + NET_IPV6_ICMP=19, + NET_IPV6_BINDV6ONLY=20 }; enum { @@ -372,6 +373,11 @@ NET_IPV6_RTR_SOLICITS=8, NET_IPV6_RTR_SOLICIT_INTERVAL=9, NET_IPV6_RTR_SOLICIT_DELAY=10 +}; + +/* /proc/sys/net/ipv6/icmp */ +enum { + NET_IPV6_ICMP_RATELIMIT=1 }; /* /proc/sys/net//neigh/ */ Index: net/ipv6/icmp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/icmp.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.16.1 diff -u -r1.1.1.2 -r1.1.1.2.16.1 --- net/ipv6/icmp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/icmp.c 23 Oct 2002 18:39:20 -0000 1.1.1.2.16.1 @@ -25,6 +25,7 @@ * add more length checks and other fixes. * yoshfuji : ensure to sent parameter problem for * fragments. + * YOSHIFUJI Hideaki @USAGI: added sysctl for icmp rate limit. */ #define __NO_VERSION__ @@ -40,6 +41,10 @@ #include #include +#ifdef CONFIG_SYSCTL +#include +#endif + #include #include #include @@ -715,3 +720,12 @@ return fatal; } + +#ifdef CONFIG_SYSCTL +ctl_table ipv6_icmp_table[] = { + {NET_IPV6_ICMP_RATELIMIT, "ratelimit", + &sysctl_icmpv6_time, sizeof(int), 0644, NULL, &proc_dointvec}, + {0}, +}; +#endif + Index: net/ipv6/sysctl_net_ipv6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v retrieving revision 1.1.1.1.40.1 retrieving revision 1.1.1.1.40.1.2.1 diff -u -r1.1.1.1.40.1 -r1.1.1.1.40.1.2.1 --- net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 +++ net/ipv6/sysctl_net_ipv6.c 23 Oct 2002 18:39:20 -0000 1.1.1.1.40.1.2.1 @@ -1,5 +1,8 @@ /* * sysctl_net_ipv6.c: sysctl interface to net IPV6 subsystem. + * + * Changes: + * YOSHIFUJI Hideaki @USAGI: added icmp sysctl table. */ #include @@ -12,11 +15,13 @@ #include extern ctl_table ipv6_route_table[]; +extern ctl_table ipv6_icmp_table[]; #ifdef CONFIG_SYSCTL ctl_table ipv6_table[] = { {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, + {NET_IPV6_ICMP, "icmp", NULL, 0, 0500, ipv6_icmp_table}, {NET_IPV6_BINDV6ONLY, "bindv6only", &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, {0} ----Next_Part(Thu_Oct_24_13:50:55_2002_573)---- From pekkas@netcore.fi Wed Oct 23 22:50:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 22:50:30 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O5oQuR016315 for ; Wed, 23 Oct 2002 22:50:27 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9O5oPB08989; Thu, 24 Oct 2002 08:50:26 +0300 Date: Thu, 24 Oct 2002 08:50:25 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: linux-kernel@vger.kernel.org, , Subject: Re: [PATCH] IPv6: Sysctl for ICMPv6 Rate Limitation In-Reply-To: <20021024.135055.10632889.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 933 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, 24 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > This patch add sysctl for icmp6 rate limit. > This patch is against 2.4.20-pre11 (see below). ... > +icmp/*: > +ratelimit - INTEGER > + Limit the maximal rates for sending ICMPv6 packets. > + 0 to disable any limiting, otherwise the maximal rate in jiffies(1) > + Default: 100 > + Does this rate-limit all ICMPv6 packets or just ICMPv6 error messages (as specified in ICMPv6 specifications). If all, I believe the default of rate-limiting everything is unacceptable. Note that in the patch does not seem to add the rate-limit sysctl to any functions -- was that to happen in some other patch? -- 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 yoshfuji@linux-ipv6.org Wed Oct 23 22:55:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 22:55:56 -0700 (PDT) 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 g9O5touR017019 for ; Wed, 23 Oct 2002 22:55:54 -0700 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 g9O5ttHT010529; Thu, 24 Oct 2002 14:55:55 +0900 Date: Thu, 24 Oct 2002 14:55:51 +0900 (JST) Message-Id: <20021024.145551.130454003.yoshfuji@linux-ipv6.org> To: usagi@linux-ipv6.org, pekkas@netcore.fi Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6: Sysctl for ICMPv6 Rate Limitation From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021024.135055.10632889.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-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: 934 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, 24 Oct 2002 08:50:25 +0300 (EEST)), Pekka Savola says: > > +icmp/*: > > +ratelimit - INTEGER > > + Limit the maximal rates for sending ICMPv6 packets. > > + 0 to disable any limiting, otherwise the maximal rate in jiffies(1) > > + Default: 100 > > + > > Does this rate-limit all ICMPv6 packets or just ICMPv6 error messages (as > specified in ICMPv6 specifications). > > If all, I believe the default of rate-limiting everything is unacceptable. This patch just adds sysctl. It is my documentation error... is s/ICMPv6 packets/ICMPv6 error packets/ ok? (I need to do s/100/HZ/, too; This also lives in ICMP(v4)). --yoshfuji From pekkas@netcore.fi Wed Oct 23 22:59:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 23 Oct 2002 22:59:21 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O5xIuR017613 for ; Wed, 23 Oct 2002 22:59:19 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9O5xGh09052; Thu, 24 Oct 2002 08:59:16 +0300 Date: Thu, 24 Oct 2002 08:59:16 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: usagi@linux-ipv6.org, , Subject: Re: [PATCH] IPv6: Sysctl for ICMPv6 Rate Limitation In-Reply-To: <20021024.145551.130454003.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 935 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, 24 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Thu, 24 Oct 2002 08:50:25 +0300 (EEST)), Pekka Savola says: > > > > +icmp/*: > > > +ratelimit - INTEGER > > > + Limit the maximal rates for sending ICMPv6 packets. > > > + 0 to disable any limiting, otherwise the maximal rate in jiffies(1) > > > + Default: 100 > > > + > > > > Does this rate-limit all ICMPv6 packets or just ICMPv6 error messages (as > > specified in ICMPv6 specifications). > > > > If all, I believe the default of rate-limiting everything is unacceptable. > > This patch just adds sysctl. It is my documentation error... > is s/ICMPv6 packets/ICMPv6 error packets/ ok? > > (I need to do s/100/HZ/, too; This also lives in ICMP(v4)). That change fine with me, thanks. -- 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 sree_mu@yahoo.com Thu Oct 24 00:02:49 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 00:02:51 -0700 (PDT) Received: from web41106.mail.yahoo.com (web41106.mail.yahoo.com [66.218.93.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O72nuR021814 for ; Thu, 24 Oct 2002 00:02:49 -0700 Message-ID: <20021024070255.81999.qmail@web41106.mail.yahoo.com> Received: from [165.228.130.12] by web41106.mail.yahoo.com via HTTP; Thu, 24 Oct 2002 00:02:55 PDT Date: Thu, 24 Oct 2002 00:02:55 -0700 (PDT) From: Sreedharamurthy K Subject: Changes in source? To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sree_mu@yahoo.com Precedence: bulk X-list: netdev Hi Techies, I am experimenting some of the networking things with different versions namely 2.4.7 and 2.4.18 (Red Hat distribution). Found some good improvements in the later kernel over the former. Since I'm not member of the linux.kernel or netdev mailing lists finding the changes in these networking source is difficult. Was curious to know what changes have gone in the code, if any, specific in the networking code. Of course, the change not necessarily be in the networking part, if so, what has made this improvement in the 2.4.18 kernel? Tried looking in the 'changelog', not much information on know 'what' changes have gone in there. Please let me know the changes or pointers where to look at. Thanks in Advance. Regards, -- Sree PS: please cc to my id, not a member of the list yet. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ From yoshfuji@linux-ipv6.org Thu Oct 24 00:23:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 00:23:45 -0700 (PDT) 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 g9O7NfuR023339 for ; Thu, 24 Oct 2002 00:23:42 -0700 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 g9O7NuHT010986; Thu, 24 Oct 2002 16:23:56 +0900 Date: Thu, 24 Oct 2002 16:23:55 +0900 (JST) Message-Id: <20021024.162355.127875447.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: pekkas@netcore.fi, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Sysctl for ICMPv6 Rate Limitation From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021024.145551.130454003.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-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: 937 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, 24 Oct 2002 08:59:16 +0300 (EEST)), Pekka Savola says: > > > Does this rate-limit all ICMPv6 packets or just ICMPv6 error messages (as > > > specified in ICMPv6 specifications). > > > > > > If all, I believe the default of rate-limiting everything is unacceptable. > > > > This patch just adds sysctl. It is my documentation error... > > is s/ICMPv6 packets/ICMPv6 error packets/ ok? > > > > (I need to do s/100/HZ/, too; This also lives in ICMP(v4)). > > That change fine with me, thanks. Please apply the following patch on top of the previous "Sysctl for ICMPv6 Rate Limitation" patch. Thanks. Index: Documentation/networking/ip-sysctl.txt =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt,v retrieving revision 1.1.1.1.44.1 retrieving revision 1.1.1.1.44.1.2.2 diff -u -r1.1.1.1.44.1 -r1.1.1.1.44.1.2.2 --- Documentation/networking/ip-sysctl.txt 23 Oct 2002 17:50:19 -0000 1.1.1.1.44.1 +++ Documentation/networking/ip-sysctl.txt 24 Oct 2002 07:03:46 -0000 1.1.1.1.44.1.2.2 @@ -316,7 +316,7 @@ Limit the maximal rates for sending ICMP packets whose type matches icmp_ratemask (see below) to specific targets. 0 to disable any limiting, otherwise the maximal rate in jiffies(1) - Default: 100 + Default: HZ icmp_ratemask - INTEGER Mask made of ICMP types for which rates are being limited. @@ -562,9 +562,9 @@ icmp/*: ratelimit - INTEGER - Limit the maximal rates for sending ICMPv6 packets. + Limit the maximal rates for sending ICMPv6 error packets. 0 to disable any limiting, otherwise the maximal rate in jiffies(1) - Default: 100 + Default: HZ IPv6 Update by: Pekka Savola -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From shaeffer@neuralscape.com Thu Oct 24 02:47:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 02:47:25 -0700 (PDT) Received: from synapse.neuralscape.com ([198.144.200.85]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9O9lNuR001461 for ; Thu, 24 Oct 2002 02:47:23 -0700 Received: (from shaeffer@localhost) by synapse.neuralscape.com (8.11.6/8.11.6) id g9O9bpP26085; Thu, 24 Oct 2002 02:37:51 -0700 Date: Thu, 24 Oct 2002 02:37:51 -0700 From: Karen Shaeffer To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [RESEND] tuning linux for high network performance? Message-ID: <20021024023751.A26024@synapse.neuralscape.com> References: <200210231218.18733.roy@karlsbakk.net> <20021023130101.GA646@outpost.ds9a.nl> <1035379308.5950.3.camel@rth.ninka.net> <200210231542.48673.roy@karlsbakk.net> <1035432669.9628.1.camel@rth.ninka.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1035432669.9628.1.camel@rth.ninka.net>; from davem@rth.ninka.net on Wed, Oct 23, 2002 at 09:11:09PM -0700 X-archive-position: 938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shaeffer@neuralscape.com Precedence: bulk X-list: netdev On Wed, Oct 23, 2002 at 09:11:09PM -0700, David S. Miller wrote: > On Wed, 2002-10-23 at 06:42, Roy Sigurd Karlsbakk wrote: > > As far as I've understood, sendfile() won't do much good with large files. Is > > this right? > > There is always a benefit to using sendfile(), when you use > sendfile() the cpu doesn't touch one byte of the data if > the network card support TX checksumming. The disk DMAs > to ram, then the net card DMAs from ram. Simple as that. Referring to: $ rpm -qf /usr/include/sys/sendfile.h glibc-devel-2.2.5-40 quoting "sendfile.h" #ifdef __USE_FILE_OFFSET64 # error " cannot be used with _FILE_OFFSET_BITS=64" #endif So, how does one use sendfile() for large files that are greater than 2 GBytes? Am I missing something? Thanks, Karen -- Karen Shaeffer Neuralscape; Santa Cruz, Ca. 95060 shaeffer@neuralscape.com http://www.neuralscape.com From roy@karlsbakk.net Thu Oct 24 03:06:53 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:06:54 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OA6puR002965 for ; Thu, 24 Oct 2002 03:06:52 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9OA7YG16583; Thu, 24 Oct 2002 12:07:37 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: Nivedita Singhvi Subject: Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) Date: Thu, 24 Oct 2002 12:14:59 +0200 User-Agent: KMail/1.4.1 Cc: bert hubert , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210231726.21135.roy@karlsbakk.net> <3DB6CF9E.327E165F@us.ibm.com> In-Reply-To: <3DB6CF9E.327E165F@us.ibm.com> MIME-Version: 1.0 Message-Id: <200210241214.59812.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9OA6puR002965 X-archive-position: 939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev > Hmm, I'm still not clear on why you cannot use sendfile()? > I was not aware of any upper limit to the file size in order > for sendfile() to be used? From what little I know, this > is exactly the kind of situation that sendfile was intended > to benefit. I can't use sendfile(). I'm working with files > 4GB, and from man 2 sendfile: ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); int main() { ssize_t s1; off_t offset; size_t count; printf("sizeof ssize_t: %d\n", sizeof s1); printf("sizeof size_t: %d\n", sizeof count); printf("sizeof off_t: %d\n", sizeof offset); return 0; } running it $ ./sendfile_test sizeof ssize_t: 4 sizeof size_t: 4 sizeof off_t: 4 $ as far as I'm concerned, this will not allow me to address files past the 4GB limit (or was it 2?) roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From roy@karlsbakk.net Thu Oct 24 03:22:38 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:22:40 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OAMbuR004486 for ; Thu, 24 Oct 2002 03:22:38 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9OANLG16651; Thu, 24 Oct 2002 12:23:21 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: "David S. Miller" Subject: sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) Date: Thu, 24 Oct 2002 12:30:46 +0200 User-Agent: KMail/1.4.1 Cc: bert hubert , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210231542.48673.roy@karlsbakk.net> <1035432669.9628.1.camel@rth.ninka.net> In-Reply-To: <1035432669.9628.1.camel@rth.ninka.net> MIME-Version: 1.0 Message-Id: <200210241230.46848.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9OAMbuR004486 X-archive-position: 940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev On Thursday 24 October 2002 06:11, David S. Miller wrote: > On Wed, 2002-10-23 at 06:42, Roy Sigurd Karlsbakk wrote: > > As far as I've understood, sendfile() won't do much good with large > > files. Is this right? > > There is always a benefit to using sendfile(), when you use > sendfile() the cpu doesn't touch one byte of the data if > the network card support TX checksumming. The disk DMAs > to ram, then the net card DMAs from ram. Simple as that. Are there any plans of implementing sendfile64() or sendfile() support for -D_FILE_OFFSET_BITS=64? (from man 2 sendfile) ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); int main() { ssize_t s1; size_t count; off_t offset; printf("sizeof ssize_t: %d\n", sizeof s1); printf("sizeof size_t: %d\n", sizeof count); printf("sizeof off_t: %d\n", sizeof offset); return 0; } $ make ... $ ./sendfile_test sizeof ssize_t: 4 sizeof size_t: 4 sizeof off_t: 4 $ and - when attempting to build this with -D_FILE_OFFSET_BITS=64 [roy@roy-sin micro_httpd-O_DIRECT]$ make sendfile_test gcc -D_DEBUG -Wall -W -D_GNU_SOURCE -D_NO_DIR_ACCESS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DUSE_O_DIRECT -DINETD -Wno-unused -O0 -ggdb -c sendfile_test.c In file included from sendfile_test.c:1: /usr/include/sys/sendfile.h:26: #error " cannot be used with _FILE_OFFSET_BITS=64" make: *** [sendfile_test.o] Error 1 -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From davem@redhat.com Thu Oct 24 03:33:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:33:33 -0700 (PDT) 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 g9OAXVuR005404 for ; Thu, 24 Oct 2002 03:33:32 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id DAA16475; Thu, 24 Oct 2002 03:24:35 -0700 Date: Thu, 24 Oct 2002 03:24:34 -0700 (PDT) Message-Id: <20021024.032434.55079439.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, usagi@linux-ipv6.org Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both IPv6 and IPv4 Sockets on the Same Port) From: "David S. Miller" In-Reply-To: <20021023.162439.114324450.yoshfuji@linux-ipv6.org> References: <20021004.001929.03389091.yoshfuji@linux-ipv6.org> <200210031552.TAA29921@sex.inr.ac.ru> <20021023.162439.114324450.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 941 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 I've added this patch to both of my trees. Thank you. From davem@rth.ninka.net Thu Oct 24 03:34:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:34:42 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OAYeuR005672 for ; Thu, 24 Oct 2002 03:34:40 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9OAktRU010853; Thu, 24 Oct 2002 03:46:55 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9OAkr8c010851; Thu, 24 Oct 2002 03:46:53 -0700 Subject: Re: O_DIRECT sockets? (was [RESEND] tuning linux for high network performance?) From: "David S. Miller" To: Roy Sigurd Karlsbakk Cc: Nivedita Singhvi , bert hubert , netdev@oss.sgi.com, Kernel mailing list In-Reply-To: <200210241214.59812.roy@karlsbakk.net> References: <200210231218.18733.roy@karlsbakk.net> <200210231726.21135.roy@karlsbakk.net> <3DB6CF9E.327E165F@us.ibm.com> <200210241214.59812.roy@karlsbakk.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 03:46:53 -0700 Message-Id: <1035456413.10558.5.camel@rth.ninka.net> Mime-Version: 1.0 X-archive-position: 942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@rth.ninka.net Precedence: bulk X-list: netdev On Thu, 2002-10-24 at 03:14, Roy Sigurd Karlsbakk wrote: > I can't use sendfile(). I'm working with files > 4GB, and from man 2 sendfile: That's what sendfile64() is for. In fact every vendor I am aware of is shipping the sys_sendfile64() patch in their kernels and an appropriately fixed up glibc. From davem@rth.ninka.net Thu Oct 24 03:35:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:35:26 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OAZNuR006075 for ; Thu, 24 Oct 2002 03:35:24 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9OAlhRU010869; Thu, 24 Oct 2002 03:47:43 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9OAlhJ0010867; Thu, 24 Oct 2002 03:47:43 -0700 Subject: Re: sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) From: "David S. Miller" To: Roy Sigurd Karlsbakk Cc: bert hubert , netdev@oss.sgi.com, Kernel mailing list In-Reply-To: <200210241230.46848.roy@karlsbakk.net> References: <200210231218.18733.roy@karlsbakk.net> <200210231542.48673.roy@karlsbakk.net> <1035432669.9628.1.camel@rth.ninka.net> <200210241230.46848.roy@karlsbakk.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 03:47:43 -0700 Message-Id: <1035456463.10555.7.camel@rth.ninka.net> Mime-Version: 1.0 X-archive-position: 943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@rth.ninka.net Precedence: bulk X-list: netdev On Thu, 2002-10-24 at 03:30, Roy Sigurd Karlsbakk wrote: > Are there any plans of implementing sendfile64() or sendfile() support for > -D_FILE_OFFSET_BITS=64? This is old hat, and appears in every current vendor kernel I am aware of and is in 2.5.x as well. From davem@redhat.com Thu Oct 24 03:50:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:51:01 -0700 (PDT) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OAosuR007587 for ; Thu, 24 Oct 2002 03:50:57 -0700 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9OB31RU011264; Thu, 24 Oct 2002 04:03:01 -0700 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9OB30Yv011262; Thu, 24 Oct 2002 04:03:00 -0700 X-Authentication-Warning: rth.ninka.net: davem set sender to davem@redhat.com using -f Subject: Re: [PATCH] IPv6: Sysctl for ICMPv6 Rate Limitation From: "David S. Miller" 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@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: <20021024.135055.10632889.yoshfuji@linux-ipv6.org> References: <20021024.135055.10632889.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Oct 2002 04:02:58 -0700 Message-Id: <1035457378.10555.21.camel@rth.ninka.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9OAosuR007587 X-archive-position: 944 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 On Wed, 2002-10-23 at 21:50, YOSHIFUJI Hideaki / wrote: > This patch add sysctl for icmp6 rate limit. > This patch is against 2.4.20-pre11 (see below). I've applied this patch to my 2.4.x and 2.5.x trees, thank you. From roy@karlsbakk.net Thu Oct 24 03:59:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 03:59:32 -0700 (PDT) Received: from mail.pronto.tv (213-187-164-2.dd.nextgentel.com [213.187.164.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OAxSuR008366 for ; Thu, 24 Oct 2002 03:59:29 -0700 Received: from roy-sin ([192.168.144.247]) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g9OB0AG16823; Thu, 24 Oct 2002 13:00:10 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: ProntoTV AS To: "David S. Miller" Subject: Re: sendfile64() anyone? (was [RESEND] tuning linux for high network performance?) Date: Thu, 24 Oct 2002 13:07:36 +0200 User-Agent: KMail/1.4.1 Cc: bert hubert , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210241230.46848.roy@karlsbakk.net> <1035456463.10555.7.camel@rth.ninka.net> In-Reply-To: <1035456463.10555.7.camel@rth.ninka.net> MIME-Version: 1.0 Message-Id: <200210241307.36134.roy@karlsbakk.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9OAxSuR008366 X-archive-position: 945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roy@karlsbakk.net Precedence: bulk X-list: netdev On Thursday 24 October 2002 12:47, David S. Miller wrote: > On Thu, 2002-10-24 at 03:30, Roy Sigurd Karlsbakk wrote: > > Are there any plans of implementing sendfile64() or sendfile() support > > for -D_FILE_OFFSET_BITS=64? > > This is old hat, and appears in every current vendor kernel I am > aware of and is in 2.5.x as well. then where can I find these patches? I cannot use 2.5, and I usually try to stick with an official kernel. and - if this patch has been around all this time... why isn't it in the official kernel yet? -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From vda@port.imtp.ilyichevsk.odessa.ua Thu Oct 24 04:35:02 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 04:35:05 -0700 (PDT) Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OBYsuR011870 for ; Thu, 24 Oct 2002 04:34:57 -0700 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g9OBTpp09266; Thu, 24 Oct 2002 14:29:51 +0300 Message-Id: <200210241129.g9OBTpp09266@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Roy Sigurd Karlsbakk , netdev@oss.sgi.com Subject: Re: [RESEND] tuning linux for high network performance? Date: Thu, 24 Oct 2002 14:22:25 -0200 X-Mailer: KMail [version 1.3.2] Cc: Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> <200210231536.24269.roy@karlsbakk.net> In-Reply-To: <200210231536.24269.roy@karlsbakk.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On 23 October 2002 11:36, Roy Sigurd Karlsbakk wrote: > > > 905182 total 0.4741 > > > 121426 csum_partial_copy_generic 474.3203 > > > > Well, maybe take a look at this func and try to optimize it? > > I don't know assembly that good - sorry. Well, I like it. Maybe I can look into it. Feel free to bug me :-) > > > 93633 default_idle 1800.6346 > > > 74665 do_wp_page 111.1086 > > > > What's this? > > do_wp_page is Defined as a function in: mm/memory.c > > comments from the file: > [snip] Please delete memory.o, rerun make bzImage, capture gcc command used for compiling memory.c, modify it: gcc ... -o memory.o -> gcc ... -S -o memory.s ... and examine assembler code. Maybe something will stick out (or use objdump to disassemble memory.o, I recall nice option to produce assembler output with C code intermixed as comments!) (send disasmed listing to me offlist). > > > 65857 ide_intr 184.9916 > > > > You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm... > > how large is your readahead? I assume you'd like to fetch > > more sectors from ide per interrupt. (I hope you do DMA ;) > > doing DMA - RAID-0 with 1MB chunk size on 4 disks. You should aim at maxing out IDE performance. Please find out how many sectors you read in one go. Maybe: # cat /proc/interrupts # dd bs=1m count=1 if=/dev/hda of=/dev/null # cat /proc/interrupts and calculate how many IDE interrupts happened. (1mb = 2048 sectors) -- vda From rmk@arm.linux.org.uk Thu Oct 24 04:50:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 04:50:35 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OBoUuR012879 for ; Thu, 24 Oct 2002 04:50:33 -0700 Received: from flint.arm.linux.org.uk ([3ffe:8260:2002:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 184gVU-0005Zt-00; Thu, 24 Oct 2002 12:50:32 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.04) id 184gVT-0001zV-00; Thu, 24 Oct 2002 12:50:31 +0100 Date: Thu, 24 Oct 2002 12:50:31 +0100 From: Russell King To: Denis Vlasenko Cc: Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list Subject: Re: [RESEND] tuning linux for high network performance? Message-ID: <20021024125030.A7529@flint.arm.linux.org.uk> Mail-Followup-To: Denis Vlasenko , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> <200210231536.24269.roy@karlsbakk.net> <200210241129.g9OBTpp09266@Port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200210241129.g9OBTpp09266@Port.imtp.ilyichevsk.odessa.ua>; from vda@port.imtp.ilyichevsk.odessa.ua on Thu, Oct 24, 2002 at 02:22:25PM -0200 X-archive-position: 947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev On Thu, Oct 24, 2002 at 02:22:25PM -0200, Denis Vlasenko wrote: > Please delete memory.o, rerun make bzImage, capture gcc > command used for compiling memory.c, modify it: > > gcc ... -o memory.o -> gcc ... -S -o memory.s ... Have you tried make mm/memory.s ? -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From ahu@outpost.ds9a.nl Thu Oct 24 05:42:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 05:42:14 -0700 (PDT) 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 g9OCgBuR017503 for ; Thu, 24 Oct 2002 05:42:12 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8EDB74071; Thu, 24 Oct 2002 14:42:22 +0200 (CEST) Date: Thu, 24 Oct 2002 14:42:22 +0200 From: bert hubert To: Denis Vlasenko , Roy Sigurd Karlsbakk , netdev@oss.sgi.com Subject: Re: [RESEND] tuning linux for high network performance? Message-ID: <20021024124222.GA32488@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Denis Vlasenko , Roy Sigurd Karlsbakk , netdev@oss.sgi.com References: <200210231218.18733.roy@karlsbakk.net> <200210231309.g9ND9Bp03373@Port.imtp.ilyichevsk.odessa.ua> <200210231536.24269.roy@karlsbakk.net> <200210241129.g9OBTpp09266@Port.imtp.ilyichevsk.odessa.ua> <20021024125030.A7529@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021024125030.A7529@flint.arm.linux.org.uk> User-Agent: Mutt/1.3.28i X-archive-position: 948 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, Oct 24, 2002 at 12:50:31PM +0100, Russell King wrote: > > gcc ... -o memory.o -> gcc ... -S -o memory.s ... > > Have you tried make mm/memory.s ? or even make mm/memory.lst -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From vda@port.imtp.ilyichevsk.odessa.ua Thu Oct 24 06:11:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 06:12:02 -0700 (PDT) Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ODBhuR019479 for ; Thu, 24 Oct 2002 06:11:51 -0700 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g9OCnOp09750; Thu, 24 Oct 2002 15:49:31 +0300 Message-Id: <200210241249.g9OCnOp09750@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Russell King Subject: Re: [RESEND] tuning linux for high network performance? Date: Thu, 24 Oct 2002 15:41:59 -0200 X-Mailer: KMail [version 1.3.2] Cc: Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210241129.g9OBTpp09266@Port.imtp.ilyichevsk.odessa.ua> <20021024125030.A7529@flint.arm.linux.org.uk> In-Reply-To: <20021024125030.A7529@flint.arm.linux.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On 24 October 2002 09:50, Russell King wrote: > On Thu, Oct 24, 2002 at 02:22:25PM -0200, Denis Vlasenko wrote: > > Please delete memory.o, rerun make bzImage, capture gcc > > command used for compiling memory.c, modify it: > > > > gcc ... -o memory.o -> gcc ... -S -o memory.s ... > > Have you tried make mm/memory.s ? No ;) but I have a feeling it will produce that file ;))) I'm experimenting with different csum_ routines in userspace now. -- vda From Larry.Sendlosky@storigen.com Thu Oct 24 06:46:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 06:46:23 -0700 (PDT) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ODkJuR021580 for ; Thu, 24 Oct 2002 06:46:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Changes in source? Date: Thu, 24 Oct 2002 09:46:26 -0400 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A03C06D@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes in source? Thread-Index: AcJ7K3qzHAvSq0NLQfOjdiVwGmEUvgANz4UQ From: "Larry Sendlosky" To: "Sreedharamurthy K" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9ODkJuR021580 X-archive-position: 950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev http://linux.bkbits.net the linux-2.4 tree will show all the changes and then some.... -----Original Message----- From: Sreedharamurthy K [mailto:sree_mu@yahoo.com] Sent: Thursday, October 24, 2002 3:03 AM To: netdev@oss.sgi.com Subject: Changes in source? Hi Techies, I am experimenting some of the networking things with different versions namely 2.4.7 and 2.4.18 (Red Hat distribution). Found some good improvements in the later kernel over the former. Since I'm not member of the linux.kernel or netdev mailing lists finding the changes in these networking source is difficult. Was curious to know what changes have gone in the code, if any, specific in the networking code. Of course, the change not necessarily be in the networking part, if so, what has made this improvement in the 2.4.18 kernel? Tried looking in the 'changelog', not much information on know 'what' changes have gone in there. Please let me know the changes or pointers where to look at. Thanks in Advance. Regards, -- Sree PS: please cc to my id, not a member of the list yet. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ From Larry.Sendlosky@storigen.com Thu Oct 24 06:49:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 06:49:49 -0700 (PDT) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9ODnkuR022137 for ; Thu, 24 Oct 2002 06:49:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Changes in source? Date: Thu, 24 Oct 2002 09:49:53 -0400 Message-ID: <7BFCE5F1EF28D64198522688F5449D5AC63248@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes in source? Thread-Index: AcJ7K3qzHAvSq0NLQfOjdiVwGmEUvgANz4UQAABTW/A= From: "Larry Sendlosky" To: "Sreedharamurthy K" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9ODnkuR022137 X-archive-position: 951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev oops forgot one thing... Redhat adds patches to the "stock" linux kernel. You may have to get the RedHat kernel source rpm and look at the patch files against 2.4.18. -----Original Message----- From: Larry Sendlosky Sent: Thursday, October 24, 2002 9:46 AM To: Sreedharamurthy K; netdev@oss.sgi.com Subject: RE: Changes in source? http://linux.bkbits.net the linux-2.4 tree will show all the changes and then some.... -----Original Message----- From: Sreedharamurthy K [mailto:sree_mu@yahoo.com] Sent: Thursday, October 24, 2002 3:03 AM To: netdev@oss.sgi.com Subject: Changes in source? Hi Techies, I am experimenting some of the networking things with different versions namely 2.4.7 and 2.4.18 (Red Hat distribution). Found some good improvements in the later kernel over the former. Since I'm not member of the linux.kernel or netdev mailing lists finding the changes in these networking source is difficult. Was curious to know what changes have gone in the code, if any, specific in the networking code. Of course, the change not necessarily be in the networking part, if so, what has made this improvement in the 2.4.18 kernel? Tried looking in the 'changelog', not much information on know 'what' changes have gone in there. Please let me know the changes or pointers where to look at. Thanks in Advance. Regards, -- Sree PS: please cc to my id, not a member of the list yet. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ From jlcooke@megaman.certainkey.com Thu Oct 24 07:51:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 07:51:11 -0700 (PDT) Received: from megaman.certainkey.com (megaman.certainkey.com [134.117.69.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OEp7uR001288 for ; Thu, 24 Oct 2002 07:51:07 -0700 Received: (from jlcooke@localhost) by megaman.certainkey.com (8.11.6/8.11.2) id g9OEoQK01264; Thu, 24 Oct 2002 10:50:26 -0400 Date: Thu, 24 Oct 2002 10:50:26 -0400 From: Jean-Luc Cooke To: Jari Ruusu Cc: Herbert Valerio Riedel , "David S. Miller" , Sandy Harris , Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec Message-ID: <20021024105026.C1170@certainkey.com> References: <3DB41338.3070502@storm.ca> <1035168066.4817.1.camel@rth.ninka.net> <1035185654.21824.11.camel@janus.txd.hvrlab.org> <3DB4DBC8.8647E32E@pp.inet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DB4DBC8.8647E32E@pp.inet.fi>; from jari.ruusu@pp.inet.fi on Tue, Oct 22, 2002 at 08:02:00AM +0300 X-archive-position: 952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jlcooke@certainkey.com Precedence: bulk X-list: netdev On Tue, Oct 22, 2002 at 08:02:00AM +0300, Jari Ruusu wrote: > kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other > people are able to see the limitations/sillyness of kerneli.org/cryptoapi: > > 1) You are trying to replace link/insmod time overhead with runtime > overhead + unnecessary bloat. > 2) No direct link access to low level cipher functions or higher level > functions. > 3) No clean way to replace cipher code with processor type optimized > assembler implementations. Jari has a few points here. But the "killer" functionalities are all there IMHO. Low-level assembler implementations are over-rated, again IMHO. The performance difference between C and ASM is at most 50%. 1ms vs 1.5 ms. Even if you've got a large payload on the rare occation (>5MB) block ciphers are quite fast for 95% of applications JLC -- http://www.certainkey.com Suite 4560 CTTC 1125 Colonel By Dr. Ottawa ON, K1S 5B6 C: 613.263.2983 From ytaketu@livedoor.com Thu Oct 24 08:25:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 08:25:49 -0700 (PDT) Received: from mail531.nifty.com (mail531.nifty.com [202.248.37.220]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OFPiuR006471 for ; Thu, 24 Oct 2002 08:25:45 -0700 Received: from pc3 by mail531.nifty.com (8.12.6/3.7W-07/15/02) with SMTP id g9OFMKxA029491 for ; Fri, 25 Oct 2002 00:22:20 +0900 Date: Fri, 25 Oct 2002 00:22:20 +0900 Message-Id: <200210241522.g9OFMKxA029491@mail531.nifty.com> From: =?ISO-2022-JP?B?GyRCTDVOQSVXJWwlPCVzJUgbKEI=?= To: Subject: =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoTDVOQSVXJWwlPCVzJUgbKEI=?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-archive-position: 953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ytaketu@livedoor.com Precedence: bulk X-list: netdev ＜事業者＞ジュエリーノン　２度と配信いたしませんので配信不要の方はこのままご返信くださいtaketu55@nifty.com ＜送信者＞mcco taketu yosi 拒否taketu55@nifty.com http://www6.plala.or.jp/taketu ＜内容＞無料プレゼント　●リニューアルオープン記念につきシルバーリングまたは18金ピアスを５００名様にプレゼントいたします。応募方法はこちらからどうぞ http://www.paw.hi-ho.ne.jp/taketu/ From kuznet@ms2.inr.ac.ru Thu Oct 24 09:25:14 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 09:25:20 -0700 (PDT) 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 g9OGPDuR010709 for ; Thu, 24 Oct 2002 09:25:14 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id UAA02873; Thu, 24 Oct 2002 20:24:11 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200210241624.UAA02873@sex.inr.ac.ru> Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both To: pekkas@netcore.fi (Pekka Savola) Date: Thu, 24 Oct 2002 20:24:11 +0400 (MSD) Cc: yoshfuji@linux-ipv6.org, davem@redhat.com, netdev@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: from "Pekka Savola" at Oct 23, 2 01:15:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 X-archive-position: 954 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! Late question: > ::, at least previously. That worked e.g. on BSD. Does that work now, > too? Provided it uses IPV6_V6ONLY. > tcp4 0 0 127.0.0.1.53 *.* LISTEN > tcp4 0 0 193.166.4.206.53 *.* LISTEN > tcp4 0 0 193.166.187.10.53 *.* LISTEN > tcp6 0 0 *.53 *.* LISTEN ... > Will this work too? No. The question follows: what the hell does it make this? What is special in ipv4 that it needs to bind to its addresses? With IPV6_V6ONLY connections to all the IPv4 addresses but listed ones will be refused. I guess it is not _that_ thing which bind expects. Alexey From J_Fraser@bit-net.com Thu Oct 24 13:59:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 14:00:04 -0700 (PDT) Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OKxwuR028830 for ; Thu, 24 Oct 2002 13:59:59 -0700 Received: from CONCORDIA (mail1.crossbeamsys.com [63.96.67.254]) by mail.bit-net.com (8.9.3/8.9.2) with SMTP id RAA29556 for ; Thu, 24 Oct 2002 17:00:06 -0400 (EDT) (envelope-from J_Fraser@bit-net.com) Reply-To: From: "Jon Fraser" To: Subject: RE: [Question] SMP for Linux Date: Thu, 24 Oct 2002 17:00:51 -0400 Message-ID: <001701c27ba0$6ff02c70$3701020a@CONCORDIA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15793.3958.926796.634263@robur.slu.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-archive-position: 955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: J_Fraser@bit-net.com Precedence: bulk X-list: netdev > Hope to verify this for "kfree-route" test. Did you use oprofile > for performance counters? I used perfctr-2.4.0-pre2 to grab the CPU performance counters. I was interested in cache invalidates, etc. I guess I'll try using oprofile to see where in the code I'm really spending the time. > > > 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. From J_Fraser@bit-net.com Thu Oct 24 14:11:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 14:11:21 -0700 (PDT) Received: from mail.bit-net.com (mail.bit-net.com [208.146.132.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9OLBIuR029436 for ; Thu, 24 Oct 2002 14:11:18 -0700 Received: from CONCORDIA (mail1.crossbeamsys.com [63.96.67.254]) by mail.bit-net.com (8.9.3/8.9.2) with SMTP id RAA31552 for ; Thu, 24 Oct 2002 17:11:30 -0400 (EDT) (envelope-from J_Fraser@bit-net.com) Reply-To: From: "Jon Fraser" To: "Netdev List \(E-mail\)" Subject: intel 82543 gig-e and vlans Date: Thu, 24 Oct 2002 17:12:16 -0400 Message-ID: <001801c27ba2$086684d0$3701020a@CONCORDIA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-archive-position: 956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: J_Fraser@bit-net.com Precedence: bulk X-list: netdev Hello, I tried turning on vlan support for an intel 82543 based gig-e card. This is under linux 2.4.20-pre11. The card is connected to an ixia test box. I captured some arps and Ixia claims the header is a CISCO ISL header instead of getting an 802.1q header. I've copied the header below. I've tried to break it up by fields. CISCO ISL header 01 00 0C 00 00 00 Dst address 00 03 47 9B 67 CB Src Address 00 3A Len AA AA 03 Magic number? 00 03 47 01 90 Vlan ID (200) 00 00 00 00 Ethernet header FF FF FF FF FF FF 00 03 47 9B 67 CB 08 06 Arp Header 00 01 08 00 06 04 00 01 00 03 47 9B 67 CB Sender Address C8 01 02 01 Sender IP 200.1.2.1 00 00 00 00 00 00 Target Address C8 01 02 02 Target IP 200.1.2.2 Has anybody else seen anything like this? I tried the same test on an intel eep100 with vlans enabled and everything looks fine. I've tried to different gig-e cards, both 82543, and both act the same way. Thanks, Jon From yoshfuji@linux-ipv6.org Thu Oct 24 17:44:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 17:45:01 -0700 (PDT) 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 g9P0iquR003863 for ; Thu, 24 Oct 2002 17:44:55 -0700 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 g9P0j9HT016226; Fri, 25 Oct 2002 09:45:09 +0900 Date: Fri, 25 Oct 2002 09:44:59 +0900 (JST) Message-Id: <20021025.094459.116783443.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: ndisc_rcv() 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-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: 957 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, This patch just adds new ndisc_recv_ns() and ndisc_recv_na() to make switch / case in ndisc_rcv() (and ndisc_rcv() itself) small. This patch is against linux-2.4.20-pre11. Thanks in advance. ------------------------------------------------------------------- Patch-Name: ndisc_rcv() clean-up Patch-Id: FIX_2_4_20_pre11_NDISC_CLEANUP Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- Index: net/ipv6/ndisc.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ndisc.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.20.1 diff -u -r1.1.1.2 -r1.1.1.2.20.1 --- net/ipv6/ndisc.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/ndisc.c 24 Oct 2002 09:50:42 -0000 1.1.1.2.20.1 @@ -583,6 +583,253 @@ } } +void ndisc_recv_ns(struct sk_buff *skb) +{ + struct nd_msg *msg = (struct nd_msg *)skb->h.raw; + struct in6_addr *saddr = &skb->nh.ipv6h->saddr; + struct in6_addr *daddr = &skb->nh.ipv6h->daddr; + u8 *lladdr = NULL; + int lladdrlen = 0; + u32 ndoptlen = skb->tail - msg->opt; + struct ndisc_options ndopts; + struct net_device *dev = skb->dev; + struct inet6_ifaddr *ifp; + struct neighbour *neigh; + + if (skb->len < sizeof(struct nd_msg)) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP NS: packet too short\n"); + return; + } + + if (ipv6_addr_type(&msg->target)&IPV6_ADDR_MULTICAST) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP NS: target address is multicast\n"); + return; + } + + if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP NS: invalid ND option, ignored.\n"); + return; + } + + if (ndopts.nd_opts_src_lladdr) { + lladdr = (u8*)(ndopts.nd_opts_src_lladdr + 1); + lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; + if (lladdrlen != NDISC_OPT_SPACE(dev->addr_len)) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP NS: bad lladdr length.\n"); + return; + } + } + + /* XXX: RFC2461 7.1.1: + * If the IP source address is the unspecified address, there + * MUST NOT be source link-layer address option in the message. + * + * NOTE! Linux kernel < 2.4.4 broke this rule. + */ + + /* XXX: RFC2461 7.1.1: + * If the IP source address is the unspecified address, the IP + * destination address MUST be a solicited-node multicast address. + */ + + if ((ifp = ipv6_get_ifaddr(&msg->target, dev)) != NULL) { + int addr_type = ipv6_addr_type(saddr); + + if (ifp->flags & IFA_F_TENTATIVE) { + /* Address is tentative. If the source + is unspecified address, it is someone + does DAD, otherwise we ignore solicitations + until DAD timer expires. + */ + if (addr_type == IPV6_ADDR_ANY) { + if (dev->type == ARPHRD_IEEE802_TR) { + unsigned char *sadr = skb->mac.raw ; + if (((sadr[8] &0x7f) != (dev->dev_addr[0] & 0x7f)) || + (sadr[9] != dev->dev_addr[1]) || + (sadr[10] != dev->dev_addr[2]) || + (sadr[11] != dev->dev_addr[3]) || + (sadr[12] != dev->dev_addr[4]) || + (sadr[13] != dev->dev_addr[5])) + { + addrconf_dad_failure(ifp) ; + } + } else { + addrconf_dad_failure(ifp); + } + } else + in6_ifa_put(ifp); + return; + } + + if (addr_type == IPV6_ADDR_ANY) { + struct in6_addr maddr; + + ipv6_addr_all_nodes(&maddr); + ndisc_send_na(dev, NULL, &maddr, &ifp->addr, + ifp->idev->cnf.forwarding, 0, + ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, + 1); + in6_ifa_put(ifp); + return; + } + + if (addr_type & IPV6_ADDR_UNICAST) { + int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; + + if (inc) + nd_tbl.stats.rcv_probes_mcast++; + else + nd_tbl.stats.rcv_probes_ucast++; + + /* + * update / create cache entry + * for the source adddress + */ + + neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); + + if (neigh || !dev->hard_header) { + ndisc_send_na(dev, neigh, saddr, &ifp->addr, + ifp->idev->cnf.forwarding, 1, + ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, + 1); + if (neigh) + neigh_release(neigh); + } + } + in6_ifa_put(ifp); + } else { + struct inet6_dev *in6_dev = in6_dev_get(dev); + int addr_type = ipv6_addr_type(saddr); + + if (in6_dev && in6_dev->cnf.forwarding && + (addr_type & IPV6_ADDR_UNICAST) && + pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { + int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; + + if (skb->stamp.tv_sec == 0 || + skb->pkt_type == PACKET_HOST || + inc == 0 || + in6_dev->nd_parms->proxy_delay == 0) { + if (inc) + nd_tbl.stats.rcv_probes_mcast++; + else + nd_tbl.stats.rcv_probes_ucast++; + + neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); + + if (neigh) { + ndisc_send_na(dev, neigh, saddr, &msg->target, + 0, 1, 0, 1); + neigh_release(neigh); + } + } else { + struct sk_buff *n = skb_clone(skb, GFP_ATOMIC); + if (n) + pneigh_enqueue(&nd_tbl, in6_dev->nd_parms, n); + in6_dev_put(in6_dev); + return; + } + } + if (in6_dev) + in6_dev_put(in6_dev); + } + return; +} + +void ndisc_recv_na(struct sk_buff *skb) +{ + struct nd_msg *msg = (struct nd_msg *)skb->h.raw; + struct in6_addr *saddr = &skb->nh.ipv6h->saddr; + struct in6_addr *daddr = &skb->nh.ipv6h->daddr; + u8 *lladdr = NULL; + int lladdrlen = 0; + u32 ndoptlen = skb->tail - msg->opt; + struct ndisc_options ndopts; + struct net_device *dev = skb->dev; + struct inet6_ifaddr *ifp; + struct neighbour *neigh; + + if (skb->len < sizeof(struct nd_msg)) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP NA: packet too short\n"); + return; + } + + if (ipv6_addr_type(&msg->target)&IPV6_ADDR_MULTICAST) { + if (net_ratelimit()) + printk(KERN_WARNING "NDISC NA: target address is multicast\n"); + return; + } + + if ((ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST) && + msg->icmph.icmp6_solicited) { + ND_PRINTK0("NDISC: solicited NA is multicasted\n"); + return; + } + + if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) { + if (net_ratelimit()) + printk(KERN_WARNING "ICMP NS: invalid ND option, ignored.\n"); + return; + } + if (ndopts.nd_opts_tgt_lladdr) { + lladdr = (u8*)(ndopts.nd_opts_tgt_lladdr + 1); + lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; + if (lladdrlen != NDISC_OPT_SPACE(dev->addr_len)) { + if (net_ratelimit()) + printk(KERN_WARNING "NDISC NA: invalid lladdr length.\n"); + return; + } + } + if ((ifp = ipv6_get_ifaddr(&msg->target, dev))) { + if (ifp->flags & IFA_F_TENTATIVE) { + addrconf_dad_failure(ifp); + return; + } + /* What should we make now? The advertisement + is invalid, but ndisc specs say nothing + about it. It could be misconfiguration, or + an smart proxy agent tries to help us :-) + */ + ND_PRINTK0("%s: someone advertises our address!\n", + ifp->idev->dev->name); + in6_ifa_put(ifp); + return; + } + neigh = neigh_lookup(&nd_tbl, &msg->target, dev); + + if (neigh) { + if (neigh->flags & NTF_ROUTER) { + if (msg->icmph.icmp6_router == 0) { + /* + * Change: router to host + */ + struct rt6_info *rt; + rt = rt6_get_dflt_router(saddr, dev); + if (rt) { + /* It is safe only because + we aer in BH */ + dst_release(&rt->u.dst); + ip6_del_rt(rt); + } + } + } else { + if (msg->icmph.icmp6_router) + neigh->flags |= NTF_ROUTER; + } + + neigh_update(neigh, lladdr, + msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, + msg->icmph.icmp6_override, 1); + neigh_release(neigh); + } +} + static void ndisc_router_discovery(struct sk_buff *skb) { struct ra_msg *ra_msg = (struct ra_msg *) skb->h.raw; @@ -990,12 +1237,7 @@ int ndisc_rcv(struct sk_buff *skb) { - struct net_device *dev = skb->dev; - struct in6_addr *saddr = &skb->nh.ipv6h->saddr; - struct in6_addr *daddr = &skb->nh.ipv6h->daddr; struct nd_msg *msg = (struct nd_msg *) skb->h.raw; - struct neighbour *neigh; - struct inet6_ifaddr *ifp; __skb_push(skb, skb->data-skb->h.raw); @@ -1015,244 +1257,12 @@ switch (msg->icmph.icmp6_type) { case NDISC_NEIGHBOUR_SOLICITATION: - { - struct nd_msg *msg = (struct nd_msg *)skb->h.raw; - u8 *lladdr = NULL; - int lladdrlen = 0; - u32 ndoptlen = skb->tail - msg->opt; - struct ndisc_options ndopts; - - if (skb->len < sizeof(struct nd_msg)) { - if (net_ratelimit()) - printk(KERN_WARNING "ICMP NS: packet too short\n"); - return 0; - } - - if (ipv6_addr_type(&msg->target)&IPV6_ADDR_MULTICAST) { - if (net_ratelimit()) - printk(KERN_WARNING "ICMP NS: target address is multicast\n"); - return 0; - } - - if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) { - if (net_ratelimit()) - printk(KERN_WARNING "ICMP NS: invalid ND option, ignored.\n"); - return 0; - } - - if (ndopts.nd_opts_src_lladdr) { - lladdr = (u8*)(ndopts.nd_opts_src_lladdr + 1); - lladdrlen = ndopts.nd_opts_src_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(skb->dev->addr_len)) { - if (net_ratelimit()) - printk(KERN_WARNING "ICMP NS: bad lladdr length.\n"); - return 0; - } - } - - /* XXX: RFC2461 7.1.1: - * If the IP source address is the unspecified address, there - * MUST NOT be source link-layer address option in the message. - * - * NOTE! Linux kernel < 2.4.4 broke this rule. - */ - - /* XXX: RFC2461 7.1.1: - * If the IP source address is the unspecified address, the IP - * destination address MUST be a solicited-node multicast address. - */ - - if ((ifp = ipv6_get_ifaddr(&msg->target, dev)) != NULL) { - int addr_type = ipv6_addr_type(saddr); - - if (ifp->flags & IFA_F_TENTATIVE) { - /* Address is tentative. If the source - is unspecified address, it is someone - does DAD, otherwise we ignore solicitations - until DAD timer expires. - */ - if (addr_type == IPV6_ADDR_ANY) { - if (dev->type == ARPHRD_IEEE802_TR) { - unsigned char *sadr = skb->mac.raw ; - if (((sadr[8] &0x7f) != (dev->dev_addr[0] & 0x7f)) || - (sadr[9] != dev->dev_addr[1]) || - (sadr[10] != dev->dev_addr[2]) || - (sadr[11] != dev->dev_addr[3]) || - (sadr[12] != dev->dev_addr[4]) || - (sadr[13] != dev->dev_addr[5])) - { - addrconf_dad_failure(ifp) ; - } - } else { - addrconf_dad_failure(ifp); - } - } else - in6_ifa_put(ifp); - return 0; - } - - if (addr_type == IPV6_ADDR_ANY) { - struct in6_addr maddr; - - ipv6_addr_all_nodes(&maddr); - ndisc_send_na(dev, NULL, &maddr, &ifp->addr, - ifp->idev->cnf.forwarding, 0, - ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, - 1); - in6_ifa_put(ifp); - return 0; - } - - if (addr_type & IPV6_ADDR_UNICAST) { - int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; - - if (inc) - nd_tbl.stats.rcv_probes_mcast++; - else - nd_tbl.stats.rcv_probes_ucast++; - - /* - * update / create cache entry - * for the source adddress - */ - - neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, skb->dev); - - if (neigh || !dev->hard_header) { - ndisc_send_na(dev, neigh, saddr, &ifp->addr, - ifp->idev->cnf.forwarding, 1, - ipv6_addr_type(&ifp->addr)&IPV6_ADDR_ANYCAST ? 0 : 1, - 1); - if (neigh) - neigh_release(neigh); - } - } - in6_ifa_put(ifp); - } else { - struct inet6_dev *in6_dev = in6_dev_get(dev); - int addr_type = ipv6_addr_type(saddr); - - if (in6_dev && in6_dev->cnf.forwarding && - (addr_type & IPV6_ADDR_UNICAST) && - pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { - int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; - - if (skb->stamp.tv_sec == 0 || - skb->pkt_type == PACKET_HOST || - inc == 0 || - in6_dev->nd_parms->proxy_delay == 0) { - if (inc) - nd_tbl.stats.rcv_probes_mcast++; - else - nd_tbl.stats.rcv_probes_ucast++; - - - neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, skb->dev); - - if (neigh) { - ndisc_send_na(dev, neigh, saddr, &msg->target, - 0, 1, 0, 1); - neigh_release(neigh); - } - } else { - struct sk_buff *n = skb_clone(skb, GFP_ATOMIC); - if (n) - pneigh_enqueue(&nd_tbl, in6_dev->nd_parms, n); - in6_dev_put(in6_dev); - return 0; - } - } - if (in6_dev) - in6_dev_put(in6_dev); - - } - return 0; - } + ndisc_recv_ns(skb); + break; case NDISC_NEIGHBOUR_ADVERTISEMENT: - { - struct nd_msg *msg = (struct nd_msg *)skb->h.raw; - u8 *lladdr = NULL; - int lladdrlen = 0; - u32 ndoptlen = skb->tail - msg->opt; - struct ndisc_options ndopts; - - if (skb->len < sizeof(struct nd_msg)) { - if (net_ratelimit()) - printk(KERN_WARNING "ICMP NA: packet too short\n"); - return 0; - } - - if (ipv6_addr_type(&msg->target)&IPV6_ADDR_MULTICAST) { - if (net_ratelimit()) - printk(KERN_WARNING "NDISC NA: target address is multicast\n"); - return 0; - } - - if ((ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST) && - msg->icmph.icmp6_solicited) { - ND_PRINTK0("NDISC: solicited NA is multicasted\n"); - return 0; - } - - if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) { - if (net_ratelimit()) - printk(KERN_WARNING "ICMP NS: invalid ND option, ignored.\n"); - return 0; - } - if (ndopts.nd_opts_tgt_lladdr) { - lladdr = (u8*)(ndopts.nd_opts_tgt_lladdr + 1); - lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; - if (lladdrlen != NDISC_OPT_SPACE(skb->dev->addr_len)) { - if (net_ratelimit()) - printk(KERN_WARNING "NDISC NA: invalid lladdr length.\n"); - return 0; - } - } - if ((ifp = ipv6_get_ifaddr(&msg->target, dev))) { - if (ifp->flags & IFA_F_TENTATIVE) { - addrconf_dad_failure(ifp); - return 0; - } - /* What should we make now? The advertisement - is invalid, but ndisc specs say nothing - about it. It could be misconfiguration, or - an smart proxy agent tries to help us :-) - */ - ND_PRINTK0("%s: someone advertises our address!\n", - ifp->idev->dev->name); - in6_ifa_put(ifp); - return 0; - } - neigh = neigh_lookup(&nd_tbl, &msg->target, skb->dev); - - if (neigh) { - if (neigh->flags & NTF_ROUTER) { - if (msg->icmph.icmp6_router == 0) { - /* - * Change: router to host - */ - struct rt6_info *rt; - rt = rt6_get_dflt_router(saddr, skb->dev); - if (rt) { - /* It is safe only because - we aer in BH */ - dst_release(&rt->u.dst); - ip6_del_rt(rt); - } - } - } else { - if (msg->icmph.icmp6_router) - neigh->flags |= NTF_ROUTER; - } - - neigh_update(neigh, lladdr, - msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, - msg->icmph.icmp6_override, 1); - neigh_release(neigh); - } + ndisc_recv_na(skb); break; - } case NDISC_ROUTER_ADVERTISEMENT: ndisc_router_discovery(skb); From vda@port.imtp.ilyichevsk.odessa.ua Thu Oct 24 23:49:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 24 Oct 2002 23:49:11 -0700 (PDT) Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P6mxuR010286 for ; Thu, 24 Oct 2002 23:49:02 -0700 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g9P6hop13980; Fri, 25 Oct 2002 09:43:59 +0300 Message-Id: <200210250643.g9P6hop13980@Port.imtp.ilyichevsk.odessa.ua> From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Russell King , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list Subject: Csum and csum copyroutines benchmark Date: Fri, 25 Oct 2002 09:36:22 -0200 X-Mailer: KMail [version 1.3.2] Cc: libc-alpha@sources.redhat.com References: <200210231218.18733.roy@karlsbakk.net> <20021024125030.A7529@flint.arm.linux.org.uk> <200210241249.g9OCnOp09750@Port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200210241249.g9OCnOp09750@Port.imtp.ilyichevsk.odessa.ua> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_M8CJKWOO7ADE2Z7MBTJ3" X-archive-position: 958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev --------------Boundary-00=_M8CJKWOO7ADE2Z7MBTJ3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit /me said: > I'm experimenting with different csum_ routines in userspace now. Short conclusion: 1. It is possible to speed up csum routines for AMD processors by 30%. 2. It is possible to speed up csum_copy routines for both AMD and Intel three times or more. Roy, do you like that? ;) Tests: they checksum 4MB block and csum_copy 2MB into second 2MB. POISON=0/1 controls whether to perform correctness tests or not. That slows down test very noticeably. What does glibc use for memset/memcmp? for() loop?!! With POISON=1 ntqpf2_copy bugs out, see its source. I left it in to save repeating my work by others. BTW, i do NOT understand why it does not work. ;) Anyone with cluebat? IMHO the only way to make it optimal for all CPUs is to make these functions race at kernel init and pick the best one. tests on Celeron 1200 (100 MHz, x12 core) ========================================= Csum benchmark program buffer size: 4 Mb Each test tried 16 times, max and min CPU cycles are reported. Please disregard max values. They are due to system interference only. csum tests: kernel_csum - took 717 max, 704 min cycles per kb. sum=0x44000077 kernel_csum - took 4760 max, 704 min cycles per kb. sum=0x44000077 kernel_csum - took 722 max, 704 min cycles per kb. sum=0x44000077 kernelpii_csum - took 539 max, 528 min cycles per kb. sum=0x44000077 kernelpiipf_csum - took 573 max, 529 min cycles per kb. sum=0x44000077 pfm_csum - took 1411 max, 1306 min cycles per kb. sum=0x44000077 pfm2_csum - took 875 max, 762 min cycles per kb. sum=0x44000077 copy tests: kernel_copy - took 5738 max, 3423 min cycles per kb. sum=0x99aaaacc kernel_copy - took 3517 max, 3431 min cycles per kb. sum=0x99aaaacc kernel_copy - took 4385 max, 3432 min cycles per kb. sum=0x99aaaacc kernelpii_copy - took 2912 max, 2752 min cycles per kb. sum=0x99aaaacc ntqpf_copy - took 2010 max, 1700 min cycles per kb. sum=0x99aaaacc ntqpfm_copy - took 1749 max, 1701 min cycles per kb. sum=0x99aaaacc ntq_copy - took 2218 max, 2141 min cycles per kb. sum=0x99aaaacc BAD copy! <-- ntqpf2_copy is buggy :) see its source 'copy tests' above are with POISON=1 These are with POISON=0: kernel_copy - took 2009 max, 1935 min cycles per kb. sum=0x44000077 kernel_copy - took 2240 max, 1959 min cycles per kb. sum=0x44000077 kernel_copy - took 2197 max, 1936 min cycles per kb. sum=0x44000077 kernelpii_copy - took 2121 max, 1939 min cycles per kb. sum=0x44000077 ntqpf_copy - took 667 max, 548 min cycles per kb. sum=0x44000077 ntqpfm_copy - took 651 max, 546 min cycles per kb. sum=0x44000077 ntq_copy - took 660 max, 545 min cycles per kb. sum=0x44000077 ntqpf2_copy - took 644 max, 548 min cycles per kb. sum=0x44000077 Done Tests on Duron 650 (100 MHz, x6,5 core) ======================================= Csum benchmark program buffer size: 4 Mb Each test tried 16 times, max and min CPU cycles are reported. Please disregard max values. They are due to system interference only. csum tests: kernel_csum - took 1090 max, 1051 min cycles per kb. sum=0x44000077 kernel_csum - took 1080 max, 1052 min cycles per kb. sum=0x44000077 kernel_csum - took 1178 max, 1058 min cycles per kb. sum=0x44000077 kernelpii_csum - took 1614 max, 1052 min cycles per kb. sum=0x44000077 kernelpiipf_csum - took 976 max, 962 min cycles per kb. sum=0x44000077 pfm_csum - took 755 max, 746 min cycles per kb. sum=0x44000077 pfm2_csum - took 749 max, 745 min cycles per kb. sum=0x44000077 copy tests: kernel_copy - took 1251 max, 1072 min cycles per kb. sum=0x99aaaacc kernel_copy - took 1363 max, 1072 min cycles per kb. sum=0x99aaaacc kernel_copy - took 1352 max, 1072 min cycles per kb. sum=0x99aaaacc kernelpii_copy - took 1132 max, 1014 min cycles per kb. sum=0x99aaaacc ntqpf_copy - took 514 max, 480 min cycles per kb. sum=0x99aaaacc ntqpfm_copy - took 495 max, 482 min cycles per kb. sum=0x99aaaacc ntq_copy - took 1153 max, 948 min cycles per kb. sum=0x99aaaacc BAD copy! <-- ntqpf2_copy is buggy :) see its source 'copy tests' above are with POISON=1 These are with POISON=0: kernel_copy - took 1145 max, 871 min cycles per kb. sum=0x44000077 kernel_copy - took 879 max, 871 min cycles per kb. sum=0x44000077 kernel_copy - took 876 max, 871 min cycles per kb. sum=0x44000077 kernelpii_copy - took 1019 max, 845 min cycles per kb. sum=0x44000077 ntqpf_copy - took 2972 max, 229 min cycles per kb. sum=0x44000077 ntqpfm_copy - took 248 max, 245 min cycles per kb. sum=0x44000077 ntq_copy - took 460 max, 452 min cycles per kb. sum=0x44000077 ntqpf2_copy - took 390 max, 340 min cycles per kb. sum=0x44000077 Done -- vda --------------Boundary-00=_M8CJKWOO7ADE2Z7MBTJ3 Content-Type: application/x-bzip2; name="timing_csum_copy.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="timing_csum_copy.tar.bz2" QlpoOTFBWSZTWbxlnuQAOIl/vPu3PcB////////f//////8AEAIBAAFQAoUI YCK++faaUEABqQtWmaSqIpeWAu2waw7g7gi1llV2yABZmzGlURCWsFF2amho BVRM2qtAwpKBQpVJUB6aDg2sQqEYRgmm1NGBMmmEGBGEwEwTEwAEYAI0xGjE w9QaBNBNKeVNAepkA0AD1AGhoAB6gAAAGmgA0ABwAAAAAAAAAAAAAAAAAAAD ICoioUGmiT9U/VGh6j9U0Gjyj0gyAGjygAAAAPUGg000AAwiUSYJppDSbQEw KZGMmqn6ZGqe1T0jyR6nlPU9Mpp6npPTSA0NADTag0BEkIIEyMhGhGmmpsp6 aJ4qIfiTNCamg9T9U9T1AaAGgG9SeSNA01/90in/0/IfLKSkJPzWeP217YN7 ZIT9GCnKWWJJtBEOsSCx9n0zWfRX03+mXxjIzrfzk1sMLVYEosZX/FRKq2tp a+y95kXl7tqv35UK+8diLU/CkzyPBZGRJZH5XJE7n4Jg4ItLoHwGxS09z8pX /L+jQUaqBA+AfdGq7p6aH+5t1FW2Oqkidht5smW1shzrb9nZIYpKKsilJaez wx2k5bv8HF5/77wTjI6ynbbAQaQR3DGKwdxsZHAWChsEaa2m0yYwqvQT0vR9 KNfsVNR3J6E2OPA6xzlixatjhndr+SejFvP24sN3EbSkR6LBz885jE3QTIcK B4DA3CXKuh22d0lJR504VU2KOYeSqMQxYi2SCqKVK2MGFMW2WxMUY1MlhjFW 2pYWpBiLJUxiqxN9rLVxWjYsnnq2tKyXKWlstW1ZMUqovBFl0xZs4kVLq3SJ TCChBiJRAsRQtFKIQiFJGiLklaQ8v03vu8hGH6GkdQcJB/acA/44rzNH4XIc yBEgcWBQRTYnpoyjhjgEyiBT4pIB4ppcezTP+K9fm4lk4EIwhJGhIUwCc8uv v22v2hbaVv6eW8ITjBOghvNShIOC5YLjvkgQ+QPOfEfMTWihzIBqhA1CAMD9 8aBOJepDUyNT+UucdcjuLhsIfeQ39OprivQMBqGAvMqGofWcjILEMggcijeW MF+HWXA+syysBRxKNJnCppCDNp1HUfMHYYNhsCt5YrNnRgHfUNS1zMm4z3H1 PNsH8pxo2ZjY2Bs9BzwFi5lYsVWXWejJ+aGHTBmNbg9Bgoy6oO3tOBYvpsIr v0hgohvuOE5O8pMGRp6uldXuNnTM422GT934nkepLuVGrjkWGk9dLLTQ3nZw 5fTTMakU8Qe+80kDeKEooookSpCSP4IUQ+N4Pkfa+4Gnix7WnqOczhxx2PNR SicHJoPrLjxlzrfgHEr4GjQb2QpQht08jidB18+wqGBUwPsqWBeZUTeLLCb+ 2HnyTwMXbIbw8DQ3BkceR4jgbMSQnF2TjuueI1K03ybD8l+cynlOp8ji5PLx qDAzkX/lK/19o5p5x8QB8EiJIkUnqTSRkBwQcJZasNGRZ2QXfG5G8ByfozsX KsZpc+elwonxCxUNtReMqBtocFR88CwhgcrfUUcRbA67RWSSGCjnsSMHPODm arnKHiNA85zlFE2DrULsR8hZYoXllCkpKUzGKtLlMlVV8CmSrwnRHafcZ7me snF+Q7degxEyaaGhgWTXgqBtiNxF3lHxJejgza1WLEibKJUlVZFIVZYeWlJh KKlSYqMSUlJAYBf0Yf4qmxLRDAwGSELwpShb/F5R1htPB3mt6BOYmiKn1cgP mjwRkZalGhHlCnaNxiF3+Ygw/j9Xx3cIZIEQ3lC0h0t1fWnOQIkJIRkYRSTv LR1HCC8RBQvveuScZbzivi7EfCchdPgg+8ZnsLcfPRaHIf2NA+4v1pb0ram/ zFsJfdYrJKDh6x4GbggekyHqvkf5i+SamCWgSxRZLFix+0LEPK6TJ/f1M82F CwyHVtLbNJDlOydGBiaCBjKngOKFRPCGkc0sGQQHByDG4osFxOY/N1KcH4zL usflNx1G90n5/8x+Lw9V0nMPNg4nGaEaPAA9Rdwm7ul7oOp73Dq0R+LGAtps tdHfh3uj/A4D2HwyDUercG/YH0HqE3EB0LEMR5PqKc3HpNIlQqBs5PseJSY7 N4TbVnmPuAfiN/W8Xe/xnFu3fVOvqwV8DB42NXHvbo/JX8vW6jW6kwDdQxv4 jcSHtmt6NwwuvTEyeI+I+gwNQZuLc+LvdwDmUzhEKF9rc6jMaJHf+X5rvWGP H2tFwYO+He/odgqZu31N71h+5H6qNtx8juWnvO92lzd/J2FtYav1Z9htNQ9b ydDhR2vS+QOV0Ya3W0NK1aNdwq+S0mz0m9Cm94QcQyMRDB5xOVqeViVQIhpe DtLsdhTTDhhqP4dlHtMjB3ipx5e+SYN2Q7QgB3jd9ZtKQJgwFfFyPIkovKRb HybAYev1ts2357yZXiDwmkld4nNYTDSE1V3Np5I0o0AMC0lDxnbayitGV0NW gaODO9t2MXTfpg0uWym03PTxvR6xvzCfQQvLvkhg9HPosDa8oOk7W8VMT3DP qZypQyLeZyG8obxU3TRaZMNx7KNh5mnSF543wamzuLUagENwgda+UVLNbswb Tdkm8PCSbnqvfSeB3jS3pXyOp4Ty6a8j4jx1PnZj4DrzTY4ufSKl7vNpQ8J0 VbnppkNq9EPMUdCZNxNB7r4IULG41D1tQ0hwGdTmb5kGgNQ06W88PekV6THe OiSeC/mLj5N/jE/CIbRiiSAm5EairiknfsYlxYolOQMw4/CykBvuMAY+wOny l1OBDY7VOCm0eVDGc0hluSSyXFGSiVMniYlsTw20gfr8bcchtS5UtOBoP65U CDpQoMEZEQhBYEQYEIMWLFNoJTuLNDsSYlFPCrsKlKls8cXLEqWLKEqwWWRV kTCMMlWIqpHfLJxTXA1BpWtZJhaVCqqmJSVKyKSq2ErFKqKqVWFkmJSrLQqk ySJKMZEFCqhKhzGB0hwOxv7n4SIRYEcFTxtqF7GV0470ebHmx1oubToS008y 2KcRxmwOYXxngLafC90tUSi8BsUXMFixYoowXLli5C5cuUXLlFy5jBcuYKKM FzIMsrVRllljEtLYxCNpI4Cx8C314cm2L2cxul0iYeRoT0dnOk+BggwgEIO4 hzDwTGALwXHxYtplMThFqBIYQYwNByUyZiBthIxIE0HIqNlQOkjXS6WlKUm9 nozZC4dYeEIHhxDAuUuIDvGwub2z3h4zjOI4j1AHOBtNvuPbwpyxDzenqPwu BipVh9JIe8dWnRo1EdLY0uJCBz1bCFIHfknu6nsSDvB4iezt4DhIaDhOIqVL CpUsNgd9hU1nxnyNCgQ5S09nzG1G89f4tuZOh4CcdB5YnXPJiQ6koY6WasLZ GFYlEVhBmXmIT2HZnRJ5OPXe/fXm8aZJp73b4amaVkBl2UYGRLEoSOtZ9uaX CK9ac+HtD8AxgwYDEkIkGMBhAYu2CD3cUpffEU8Z2n0gdsUNB2vXsr8RxzwS vdgMzwAcLmPg1opA16g7BsGZBINQ20FgjBbVqLChMGZZMMWMhcIY9iyMcGqb 4nBr27wmupwnK2NYw7LHXcnFxvQrjpa1VzJk1rsnmRp7uq6WQMHwOssngQPm GdCd3dkcVPM8DNCkPclzNDsyedlU0hn4ihvgxyIw+wqGwsCgHAcJRO8galih sTBRyNTu+XQMiG7xyUdCxoGXUU8p4FIniyPpvYRwSd5UVzdV1qqquphjxsYq qqqqqqqqqqiqTYdpkZGQ4sHUcz7SFpGz7z977fV5g4uCnm5uR0FuBa1wo9D2 CpUWpYPX7XVSUxs9gx8UmdJKRmx1ugdjqncPWWNBjB8dHD3RBwHuBMklYUIK xzGov9J9tAGnxh4RA11P4g/I19eewqNJAhAnLQ5L7PjmtHm7uvy7QKVeyogG r5LGe/HMrLVLFixkXEuUfwm0/OCeocbbMbCED8ZQPWY68R96VEApmaqiAaRX eES53bAUgC90iBSYBlm2QOTm8o8481WzvbUCd4FTBBQhguNAUO9oqBxoHlZc 7Zi2HtLVc0MyxnjvKcRxBU+840dIwYz9KtxfgTIxHSc2WRyJBWj9xGpUXPlK mOMNzkM8zgI4mktK377XXjh8BiHNF8xtDGWREdLnWEh7MFlwFFdGewhy4hsl n82ZMEsSWLFP4fRKuZFH6AI2D059InHhgy0YmtiiHPFpg0qxM9KveGJJsun6 7yk0ydk2GRRmxsV3hsvrO7dRLVtNXdVkK5Fj8dSfwpbHePBoPzkLu46Ta9b6 /OVmY4W45x5GLwt57dyZFaMDIsXIZEMGCBSlixRqeBxD4igxYMyu1E8pTgS4 O2anYUd7Gi1E7+4sdL1JA7K0h2BJ0MFoalGx0LETQLlYpM+u2Ib7bsqulR0K KCjK9zud+wlOpRbkH1Acx8Y6GHMohs5bibuq/MDM6rQ4FjrsUEqjUIQ/Lnax jIscSBbuqtlsg1vJurdjPV8KPAhwzSUhracWbk5DlkYKDI8ZwMy5kEe5uUGR goOVBhalTZaGVwrjmXFdUm5fhCGjSOIYit20zQsdZ3TadQYhVgkWrVnhA5MM e0CBTB0AkUVIMImTHFUWyxAKXBw9bKB0DNZdAPRDUUjaBAOJJNkqFzgWoXVM gtkLDIxpw69+0hkFHYHCuE1N9bTjcxfdMO9I3MG8sXIBchROJAwsupMb9YYr m5sY6cbrqiVwyssSzTS5MQyHShZ5KWmp1iLQLGAd6nlICIpPjHUVQTK4jpcc XK0NCNwtVTBuQxUUQaBgiV6PSgWEUxgRFoSaN4F7mGCBnbLhv3YaTtEzo4ED ecjeZmWJE7RyKLnnTtTmGy+RyNRtYrhahseTz5kI9Ac8+vsrHZ1ZSWrJNhHb nVi1XrUB7BoeYthdv6cja3ngDIyIdxbmWlLqFpUaLafDUtKlCyUwSaB/Ntcy 6cB+ziNMGMBoinueD7YHkHZtNE94+kdRcGw4PKdUbkPNP7MLnEp9P3kK/wal CbSWY0eHRS/batUD6El0APiOUoFkRxL4U/HX5DoWtQezGpqXAPejAD7CEPuM HAVKLo8K+YvOwqvCUHjNByhzfAOKhiLvkRqi/QhRh9ZuD5EW/sh66DX4AfQN z59Ec/5kA2lH3Cfc00hE/Rwz5AfeMEdCD/kcxyAOoKSjPzv8/+FQpSorAHUs 5PjGg4KGehh/Oc37CFR1CMExpvItKi/vh0BpDu/ADzO8I3LfoK4gngUP0ukN 29vxBou6xg3gJZs+UHSDsE3QE15fG0LHTyc40CgVcxKpma8g3IByRcHiGAsI cw/vh3EIYReAjjiDB2gENBjxRc1Dgh2u5Fg4DKISL5QqvYYUKdSD1PW+hR+c 4oZocwEzTi6CdoUI/S+p1SSJGnLgCwIEbPmGQfmaIfQMalzRoegfYFEsfpC3 k66+hLVih2jExtsMWqv7I/nQzeRVMDH973bKVr1qH2BuqnEBnMB2CuoDoY/k 12c8YrFXtVrXMEtFjZkY0VCgJ6MIzxgbMxqaKoInIRSDMyoFY1s2vWWZli1V J+UX9ZgkEiGwftxJHcYCyHEi/ehtG4B7RfyC3fXmUEhEhj95VKiRKr+DzpBi 0O9Lz7iC5EF+UW8eK4Dvd87A32w/bPMjcCrWJII7pH8R3kPwFTYGDxPPR+1m 0ToYsYQf7fIPrDXAi7GI+y/oLG5yfjXnbGXoeqDugH2Bwru4M5BaqJk+00dE Tg7h7D9IPDYWbswZekB9Rd7kl9hDPedcuAaNj5kbXcS8PqjCJIABCIDkJ42C pRgwEzPnPQfQYnukgeRsNBylhyqdgeV8w/aKnX5xv6zgPtGHWQ8RiUfKPio+ 0h/SXj4B9I3ZiH7CpE2+X8p85gN4UEArC/q+u99E8qDtWRbEOylJiiWka6Iq qO5et9sXQBwviNFmyyq49S2Wjep0HWdRVCwhxQGGp0saDA5xe3iG0uEt9IUN wfJjc8rpR7jx0qQauW7WDnqwR7R1MimEH2o98WQBGAXHqQGDep5DIKlYuRIJ zsS5Cx9ACdf+wyDyYDC+yZjFSWpglD1OxuiZmdOcchghMxepDNDsSUal2gHc qFpOxFDKNgnumJylipye8bESxHvaaYQsF0aHmQwxx81JnoF80VDap1gZXGHU qZDQAxE6dtPAyAukGIkKIBe45EDiHyIUxDgtJr02DQAbCCwgcHaG18Rq5oXP A4nYewuXKHBaWCd7AONjiUesyK9zpbzzvc6G5wdDoP1Xmbsu8eRRq606mg8H 2mjuw5LwNp43aXDAUbafICb5onIg7CjBRZw9z7XAbkN45AOwIgH6SJnGd6KA doHW8QeKGm3IFMyANg7TPk63RDqGG2I+lquTfM1AGoIO43Ycly1AuiwR5ga2 HAdnCgXlFDzGzkxyD3jB0gaqc2ClhuMNrt72GbchlA+1IGsbjvDLnqOzN3Bt YVteIqbTJvBgwAgXgUDgYkKd51OfRVMdwaf7w4fKA9j+oNN7k7xpxQGzaaA3 GBm1eV3LQ4lU1kFBNo3x26wiviYpbpQlx2Lleg6KPBybVDYOpwbG09PmkCNO 4P5Kn1h9Zoqes3SFkMmqPM+cfg00R3vwMyyOxPEA8R9A9BuKG+4otDNFIdhq sEfS2mIJZgYi2gdo0GsYP1Y6NXmQPVxl4Q85QNzFufCg7xA3WbqEFyfR5wq5 PQGWLkwdbgukaNVQNDsY8f59TqJ4l9AE2NmGY3FSNyME/QxLED9RQlLkYadh AvkUe5pmuXi+r7LGAMnNzVdeJOMxr1WBk72FLVFq22ypZZLLIqqp3675mkbJ JFiiePrYOko1zKiXg38jTdfJ0mwyRLXLwmoYhIF246Gh2iZKhEgEQ1UI2A2g PiypQ9iI1hD0UCr76nWqX4GgPPa0dcFtdaiaxi+imk/dH7wtQ3iD548Wa7ET rCIdCJqQ4FtHfJIyMOs5nBv0A8DYByw7HhdBkny9r2vF5gpkQTwOyCp4JKaS EKLip2Tk+Lr2R6ZLKm616Za3Wu66ebmSWPIyTYMQ8RGu47IXGwpQ0eYMzF5P MUaWuXLWIQcEuEGL4jwDIIQo1MBEdA1QsGNSrCSzm0ZBcCxdgRowN6cigDII KlhNiwULjsFsx2EouEbhjIh4yJEC7EOBzAe9JkdGETRCAPagGp9To7sV8ZGE Ed2obtEB4ugXwCfrIZvk7BqMIJr7gockTSPAOk9wcU4oTYNB5itN1Qthepg1 SubwK2EQCrHMZR1UT1vwsY0RWw6EWgahiK33ANQKiwYpk4M9BDYw3AgI+Q3S hkXOlZUsMxoGtzidj4s2JtDJAdpDU0XAtg9YFxppTPqXUMNTQcRLiBCHSVor UIqBAgj3CFocBCBehkNwee/JsLC4iFo6jpNwa1SK8GhUpDNwBmfeqLo5QAhk woZRAp4G4yuwTXAtlLC2ALUtANjIzCiJRkTeyQXUuIZKpi29dbxqrAkENjAp 0AmjhmhhHbhCIjBSk1IIWGIlQhESEQY6QtaJR0EbuMDdJ6A5ewNnPuv8xdve /7QveXvgLXvqmzsOIdaesYHNloYZ5SNmNoXePxC7g0zfGdZc1VSFAPmwGwdq 5ibBzisimD8hwZ7AxvBwQpzzQgDqINwMCm5e5/AAZCh7mILc5mMF34Buh6QL fLg/X1Dm6XMU6Hbmw8jyNzugPcc0PUYNAezgCaELEQV6JggabxlxDvgedYWR Cm9zvdGDZ/O5PSisCp22eo/UBCIR+P9xly+PIDHoMYxRyUOQ8ACPpAOT6crC PahGmFw7AH4kLK+QfBCDGTAahiIDp6m0IsQDCFjApkLUiUMVapYsjEKYKkYl BN6t6ixTzVKMQSyFikMQKiwBibXzOTvThRDjKjjuDe4mg0A1ajjjacajg0dk bl4tDADCFk1QjwGWdl2AeAMYbhMADk+cKBc7+bW3pPQp/wp0uhFyjqAgXsqF gZwTiF3gNxxjaTcUtNH4z4na5Gho6jjQpoP0utV0apjcVJfDazho2vyuLH5q GktiNJSgFtzzDYbgcaGTct5m2tDmPChsNZa45DkHGMLuQuVsG9IDDi0gCmOC qcww2MRBpTCoRP3jzqe1SzEOLgDtJAucRKxi0KIUKowIDAyFuPf+c8bhqmYu bwdHYlwepC3gtFB1HUXFugexpwrFupGkqmjwYhQRFYi06FtsfDxqbyKbrEDg OVksXfW5AOghccHV4roWhpglhLIEhHUoozLmV1TyuyhyIoZBAoWEM/2M2bAx gJEIlyGVNgSwj5hpAxtgjRzsRsxNHJvhrc0QWnVyA4YIw7KkSKQTwcncBYB2 tU/d1NJYgngATwgArgMCTdCIr3EKnGtZCenOKUeQekBAGAAWESh6BDJO4g36 A3g/sLurYQaGkbohoA3G46XYFVDAVQHqXQ8XgJoJ6iOxD5z4OqGb5nBO1TJj aetVPTfQ9/BKqDvRVWBAA0P6Q/GbQ3+UTjH7EJs9w3QOwhB9fpGwFCWMA7rj 9DY4G0TFkOtyO1X/+L4nBYBhOjF8rZGgi9M2keOGiQgMPCeCEEB4ntAaFOfU fWECDZNIEJCXdnXBD1R6J3tCdFibuzdDaEalRj2BCJQRzWsabbLtmwooS1jV aY1rCmJWKVWTF1uzZspZLKyVqo0ZNYkzc1iYk1qsRVmxkX5jkMTziuRyExyS o1mRMMKYyLFxot2ply5Zc2msxko5SJMSVGitSJ+Y3h0EfPwNTMCtjY7QLiCv QdJhsNPyFLtOj05jcIMVya5DVlTrGJyQHfAucEDoDjIPEbrgu2LFP+UaI+Ar VFimO38eJPUF3JFOFCQvGWe5AA== --------------Boundary-00=_M8CJKWOO7ADE2Z7MBTJ3-- From webmaster@lapromocion.com Fri Oct 25 00:03:19 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 00:03:21 -0700 (PDT) Received: from lapromocion.com ([200.68.135.70]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P73HuR010831 for ; Fri, 25 Oct 2002 00:03:18 -0700 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, 25 Oct 2002 01:45:51 -0500 Message-Id: <5.1.0.14.0.20021024102937.03750368@200.68.135.70> X-Sender: webpro@200.68.135.70 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 24 Oct 2002 19:04:00 -0500 To: (Recipient list suppressed) From: Corralito Subject: Adios al Corralito !!!!! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MDRemoteIP: 200.68.135.70 X-Return-Path: webmaster@lapromocion.com X-MDaemon-Deliver-To: netdev@oss.sgi.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9P73HuR010831 X-archive-position: 959 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 EL MENSAJERO MILLONARIO Si te ganaras La LOTTO de La Florida, podrias decirle adios al Corralito!!!! Si quieres jugarla puedes usar los servicios de El Mensajero Millonario para comprar tus tiquetes!!!! Haciendo click aqu www.elmensajeromillonario.com Prueba tu suerte !!!!! El Mensajero Millonario www.elmensajeromillonario.com *****Si desea ser borrado de nuestra lista de correo, por favor reenvienos este correo con asunto remove***** From pekkas@netcore.fi Fri Oct 25 00:46:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 00:46:59 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P7ksuR011479 for ; Fri, 25 Oct 2002 00:46:55 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9P7kix24170; Fri, 25 Oct 2002 10:46:44 +0300 Date: Fri, 25 Oct 2002 10:46:44 +0300 (EEST) From: Pekka Savola To: kuznet@ms2.inr.ac.ru cc: yoshfuji@linux-ipv6.org, , , Subject: Re: [PATCH] IPV6_V6ONLY Support, v2 (is Re: [PATCH] IPv6: Allow Both In-Reply-To: <200210241624.UAA02873@sex.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 960 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, 24 Oct 2002 kuznet@ms2.inr.ac.ru wrote: > > tcp4 0 0 127.0.0.1.53 *.* LISTEN > > tcp4 0 0 193.166.4.206.53 *.* LISTEN > > tcp4 0 0 193.166.187.10.53 *.* LISTEN > > tcp6 0 0 *.53 *.* LISTEN > ... > > Will this work too? > > No. > > The question follows: what the hell does it make this? What is special > in ipv4 that it needs to bind to its addresses? With IPV6_V6ONLY connections > to all the IPv4 addresses but listed ones will be refused. I guess it is > not _that_ thing which bind expects. I'm not sure I understand what you mean. Note that the last line is _tcp6_: tcp6 0 0 *.53 *.* LISTEN So, I belive using IPV6_V6ONLY it should indeed work. (The reasoning in Bind is that you can bind to addresses _only_ in IPv4 but you don't have to. It's done in these cases. For IPv6, it's all-or-nothing.) -- 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 velco@fadata.bg Fri Oct 25 00:48:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 00:48:11 -0700 (PDT) Received: from fadata.bg (sun.fadata.bg [80.72.64.67]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P7m4uR011598 for ; Fri, 25 Oct 2002 00:48:07 -0700 Received: (qmail 17344 invoked by uid 1000); 25 Oct 2002 07:48:10 -0000 To: vda@port.imtp.ilyichevsk.odessa.ua Cc: Russell King , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list , libc-alpha@sources.redhat.com Subject: Re: Csum and csum copyroutines benchmark References: <200210231218.18733.roy@karlsbakk.net> <20021024125030.A7529@flint.arm.linux.org.uk> <200210241249.g9OCnOp09750@Port.imtp.ilyichevsk.odessa.ua> <200210250643.g9P6hop13980@Port.imtp.ilyichevsk.odessa.ua> X-No-CC: Reply to lists, not to me. From: Momchil Velikov In-Reply-To: <200210250643.g9P6hop13980@Port.imtp.ilyichevsk.odessa.ua> Date: 25 Oct 2002 10:48:10 +0300 Message-ID: <87n0p3x8lh.fsf@fadata.bg> Lines: 70 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: velco@fadata.bg Precedence: bulk X-list: netdev >>>>> "Denis" == Denis Vlasenko writes: Denis> /me said: >> I'm experimenting with different csum_ routines in userspace now. Denis> Short conclusion: Denis> 1. It is possible to speed up csum routines for AMD processors by 30%. Denis> 2. It is possible to speed up csum_copy routines for both AMD and Intel Denis> three times or more. Roy, do you like that? ;) Additional data point: Short summary: 1. Checksum - kernelpii_csum is ~19% faster 2. Copy - lernelpii_csum is ~6% faster Dual Pentium III, 1266Mhz, 512K cache, 2G SDRAM (133Mhz, ECC) The only changes I made were to decrease the buffer size to 1K (as I think this is more representative to a network packet size, correct me if I'm wrong) and increase the runs to 1024. Max values are worthless indeed. Csum benchmark program buffer size: 1 K Each test tried 1024 times, max and min CPU cycles are reported. Please disregard max values. They are due to system interference only. csum tests: kernel_csum - took 941 max, 740 min cycles per kb. sum=0x44000077 kernel_csum - took 748 max, 742 min cycles per kb. sum=0x44000077 kernel_csum - took 60559 max, 742 min cycles per kb. sum=0x44000077 kernelpii_csum - took 52804 max, 601 min cycles per kb. sum=0x44000077 kernelpiipf_csum - took 12930 max, 601 min cycles per kb. sum=0x44000077 pfm_csum - took 10161 max, 1402 min cycles per kb. sum=0x44000077 pfm2_csum - took 864 max, 838 min cycles per kb. sum=0x44000077 copy tests: kernel_copy - took 339 max, 239 min cycles per kb. sum=0x44000077 kernel_copy - took 239 max, 239 min cycles per kb. sum=0x44000077 kernel_copy - took 239 max, 239 min cycles per kb. sum=0x44000077 kernelpii_copy - took 244 max, 225 min cycles per kb. sum=0x44000077 ntqpf_copy - took 10867 max, 512 min cycles per kb. sum=0x44000077 ntqpfm_copy - took 710 max, 403 min cycles per kb. sum=0x44000077 ntq_copy - took 4535 max, 443 min cycles per kb. sum=0x44000077 ntqpf2_copy - took 563 max, 555 min cycles per kb. sum=0x44000077 Done HOWEVER ... sometimes (say 1/30) I get the following output: Csum benchmark program buffer size: 1 K Each test tried 1024 times, max and min CPU cycles are reported. Please disregard max values. They are due to system interference only. csum tests: kernel_csum - took 958 max, 740 min cycles per kb. sum=0x44000077 kernel_csum - took 748 max, 740 min cycles per kb. sum=0x44000077 kernel_csum - took 752 max, 740 min cycles per kb. sum=0x44000077 kernelpii_csum - took 624 max, 600 min cycles per kb. sum=0x44000077 kernelpiipf_csum - took 877211 max, 601 min cycles per kb. sum=0x44000077 Bad sum Aborted which is to say that pfm_csum and pfm2_csum results are not to be trusted (at least on PIII (or my kernel CONFIG_MPENTIUMIII=y config?)). ~velco From vda@port.imtp.ilyichevsk.odessa.ua Fri Oct 25 02:12:16 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 02:12:17 -0700 (PDT) Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P9C2uR022637 for ; Fri, 25 Oct 2002 02:12:13 -0700 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g9P96Yp14775; Fri, 25 Oct 2002 12:06:34 +0300 Message-Id: <200210250906.g9P96Yp14775@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Momchil Velikov Subject: Re: Csum and csum copyroutines benchmark Date: Fri, 25 Oct 2002 11:59:06 -0200 X-Mailer: KMail [version 1.3.2] Cc: Russell King , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list References: <200210231218.18733.roy@karlsbakk.net> <200210250643.g9P6hop13980@Port.imtp.ilyichevsk.odessa.ua> <87n0p3x8lh.fsf@fadata.bg> In-Reply-To: <87n0p3x8lh.fsf@fadata.bg> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev [please drop libc from CC:] On 25 October 2002 05:48, Momchil Velikov wrote: >> Short conclusion: >> 1. It is possible to speed up csum routines for AMD processors >> by 30%. >> 2. It is possible to speed up csum_copy routines for both AMD >> andd Intel three times or more. > Additional data point: > > Short summary: > 1. Checksum - kernelpii_csum is ~19% faster > 2. Copy - lernelpii_csum is ~6% faster > > Dual Pentium III, 1266Mhz, 512K cache, 2G SDRAM (133Mhz, ECC) > > The only changes I made were to decrease the buffer size to 1K (as I > think this is more representative to a network packet size, correct > me if I'm wrong) and increase the runs to 1024. Max values are > worthless indeed. Well, that makes it run entirely in L0 cache. This is unrealistic for actual use. movntq is x3 faster when you hit RAM instead of L0. You need to be more clever than that - generate pseudo-random offsets in large buffer and run on ~1K pieces of that buffer. > HOWEVER ... > > sometimes (say 1/30) I get the following output: Csum benchmark program buffer size: 1 K Each test tried 1024 times, max and min CPU cycles are reported. Please disregard max values. They are due to system interference only. csum tests: kernel_csum - took 958 max, 740 min cycles per kb. sum=0x44000077 kernel_csum - took 748 max, 740 min cycles per kb. sum=0x44000077 kernel_csum - took 752 max, 740 min cycles per kb. sum=0x44000077 kernelpii_csum - took 624 max, 600 min cycles per kb. sum=0x44000077 kernelpiipf_csum - took 877211 max, 601 min cycles per kb. sum=0x44000077 Bad sum Aborted > which is to say that pfm_csum and pfm2_csum results are not to be > trusted (at least on PIII (or my kernel CONFIG_MPENTIUMIII=y > config?)). No, it's my fault. Those routines are fast-hacked together, they are actually can csym too little. I didn't get to handle arbitrary buffer length, assuming it it a large power of two. See the source. -- vda From velco@fadata.bg Fri Oct 25 02:47:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 02:47:04 -0700 (PDT) Received: from fadata.bg (sun.fadata.bg [80.72.64.67]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9P9kuuR025206 for ; Fri, 25 Oct 2002 02:46:58 -0700 Received: (qmail 19454 invoked by uid 1000); 25 Oct 2002 09:47:05 -0000 To: vda@port.imtp.ilyichevsk.odessa.ua Cc: Russell King , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Kernel mailing list Subject: Re: Csum and csum copyroutines benchmark References: <200210231218.18733.roy@karlsbakk.net> <200210250643.g9P6hop13980@Port.imtp.ilyichevsk.odessa.ua> <87n0p3x8lh.fsf@fadata.bg> <200210250906.g9P96Yp14775@Port.imtp.ilyichevsk.odessa.ua> X-No-CC: Reply to lists, not to me. From: Momchil Velikov In-Reply-To: <200210250906.g9P96Yp14775@Port.imtp.ilyichevsk.odessa.ua> Date: 25 Oct 2002 12:47:05 +0300 Message-ID: <87znt297fq.fsf@fadata.bg> Lines: 65 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: velco@fadata.bg Precedence: bulk X-list: netdev --=-=-= >>>>> "Denis" == Denis Vlasenko writes: Denis> [please drop libc from CC:] Denis> On 25 October 2002 05:48, Momchil Velikov wrote: >>> Short conclusion: >>> 1. It is possible to speed up csum routines for AMD processors >>> by 30%. >>> 2. It is possible to speed up csum_copy routines for both AMD >>> andd Intel three times or more. >> Additional data point: >> >> Short summary: >> 1. Checksum - kernelpii_csum is ~19% faster >> 2. Copy - lernelpii_csum is ~6% faster >> >> Dual Pentium III, 1266Mhz, 512K cache, 2G SDRAM (133Mhz, ECC) >> >> The only changes I made were to decrease the buffer size to 1K (as I >> think this is more representative to a network packet size, correct >> me if I'm wrong) and increase the runs to 1024. Max values are >> worthless indeed. Denis> Well, that makes it run entirely in L0 cache. This is unrealistic Denis> for actual use. movntq is x3 faster when you hit RAM instead of L0. Oops ... Denis> You need to be more clever than that - generate pseudo-random Denis> offsets in large buffer and run on ~1K pieces of that buffer. Here it is: Csum benchmark program buffer size: 1 K Each test tried 1024 times, max and min CPU cycles are reported. Please disregard max values. They are due to system interference only. csum tests: kernel_csum - took 8678 max, 808 min cycles per kb. sum=0x400270e8 kernel_csum - took 941 max, 808 min cycles per kb. sum=0x400270e8 kernel_csum - took 11604 max, 808 min cycles per kb. sum=0x400270e8 kernelpii_csum - took 28839 max, 664 min cycles per kb. sum=0x400270e8 kernelpiipf_csum - took 9163 max, 665 min cycles per kb. sum=0x400270e8 pfm_csum - took 2788 max, 1470 min cycles per kb. sum=0x400270e8 pfm2_csum - took 1179 max, 915 min cycles per kb. sum=0x400270e8 copy tests: kernel_copy - took 688 max, 263 min cycles per kb. sum=0x400270e8 kernel_copy - took 456 max, 263 min cycles per kb. sum=0x400270e8 kernel_copy - took 11241 max, 263 min cycles per kb. sum=0x400270e8 kernelpii_copy - took 7635 max, 246 min cycles per kb. sum=0x400270e8 ntqpf_copy - took 5349 max, 536 min cycles per kb. sum=0x400270e8 ntqpfm_copy - took 769 max, 425 min cycles per kb. sum=0x400270e8 ntq_copy - took 672 max, 469 min cycles per kb. sum=0x400270e8 ntqpf2_copy - took 8000 max, 579 min cycles per kb. sum=0x400270e8 Done Ran on a 512K (my cache size) buffer, choosing each time a 1K piece. (making the buffer larger (2M, 4M) does not make any difference). And the modified 0main.c is attached. ~velco --=-=-= Content-Type: text/x-csrc Content-Disposition: attachment; filename=0main.c #include #include #define NAME(a) \ unsigned int a##csum(const unsigned char * buff, int len, \ unsigned int sum); \ unsigned int a##copy(const char *src, char *dst, \ int len, int sum, int *src_err_ptr, int *dst_err_ptr) /* This makes adding/removing test functions easier */ /* asm ones... */ NAME(kernel_); NAME(kernelpii_); NAME(kernelpiipf_); /* and C */ #include "pfm_csum.c" #include "pfm2_csum.c" #include "ntq_copy.c" #include "ntqpf_copy.c" #include "ntqpf2_copy.c" #include "ntqpfm_copy.c" const int TRY_TIMES = 1024; const int NBUFS = 512; const int BUFSIZE = 1024; const int POISON = 0; // want to check correctness? typedef unsigned int csum_func(const unsigned char * buff, int len, unsigned int sum); typedef unsigned int copy_func(const char *src, char *dst, int len, int sum, int *src_err_ptr, int *dst_err_ptr); static inline long long rdtsc() { unsigned int low,high; __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high)); return low + (((long long)high)<<32); } int die(const char *msg) { puts(msg); abort(); return 1; } unsigned test_one_csum(csum_func *func, char *name, char *buffer) { int i; unsigned long long before,after,min,max; unsigned sum; // pick fastest run min = ~0ULL; max = 0; for (i=0;iafter) die("timer overflow"); else { after-=before; if(min>after) min=after; if(maxafter) die("timer overflow"); else { after-=before; if(min>after) min=after; if(max; Fri, 25 Oct 2002 03:02:43 -0700 Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id g9PAJwbg013228; Fri, 25 Oct 2002 11:19:59 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id g9PAJqY0013226; Fri, 25 Oct 2002 11:19:52 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Csum and csum copyroutines benchmark From: Alan Cox To: vda@port.imtp.ilyichevsk.odessa.ua Cc: Momchil Velikov , Russell King , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <200210250906.g9P96Yp14775@Port.imtp.ilyichevsk.odessa.ua> References: <200210231218.18733.roy@karlsbakk.net> <200210250643.g9P6hop13980@Port.imtp.ilyichevsk.odessa.ua> <87n0p3x8lh.fsf@fadata.bg> <200210250906.g9P96Yp14775@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 25 Oct 2002 11:19:51 +0100 Message-Id: <1035541191.12995.12.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 X-archive-position: 964 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev On Fri, 2002-10-25 at 14:59, Denis Vlasenko wrote: > Well, that makes it run entirely in L0 cache. This is unrealistic > for actual use. movntq is x3 faster when you hit RAM instead of L0. > > You need to be more clever than that - generate pseudo-random > offsets in large buffer and run on ~1K pieces of that buffer. In a lot of cases its extremely realistic to assume the network buffers are in cache. The copy/csum path is often touching just generated data, or data we just accessed via read(). The csum RX path from a card with DMA is probably somewhat different. From vda@port.imtp.ilyichevsk.odessa.ua Fri Oct 25 04:14:18 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 04:14:23 -0700 (PDT) Received: from Port.imtp.ilyichevsk.odessa.ua (167.imtp.Ilyichevsk.Odessa.UA [195.66.192.167] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PBDouR027965 for ; Fri, 25 Oct 2002 04:13:57 -0700 Received: from there ([172.16.42.177]) by Port.imtp.ilyichevsk.odessa.ua (8.10.2/8.10.2) with SMTP id g9PB86p15344; Fri, 25 Oct 2002 14:08:07 +0300 Message-Id: <200210251108.g9PB86p15344@Port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="us-ascii" From: Denis Vlasenko Reply-To: vda@port.imtp.ilyichevsk.odessa.ua To: Alan Cox Subject: Re: Csum and csum copyroutines benchmark Date: Fri, 25 Oct 2002 14:00:37 -0200 X-Mailer: KMail [version 1.3.2] Cc: Momchil Velikov , Russell King , Roy Sigurd Karlsbakk , netdev@oss.sgi.com, Linux Kernel Mailing List References: <200210231218.18733.roy@karlsbakk.net> <200210250906.g9P96Yp14775@Port.imtp.ilyichevsk.odessa.ua> <1035541191.12995.12.camel@irongate.swansea.linux.org.uk> In-Reply-To: <1035541191.12995.12.camel@irongate.swansea.linux.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 965 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On 25 October 2002 08:19, Alan Cox wrote: > On Fri, 2002-10-25 at 14:59, Denis Vlasenko wrote: > > Well, that makes it run entirely in L0 cache. This is unrealistic > > for actual use. movntq is x3 faster when you hit RAM instead of L0. > > > > You need to be more clever than that - generate pseudo-random > > offsets in large buffer and run on ~1K pieces of that buffer. > > In a lot of cases its extremely realistic to assume the network > buffers are in cache. The copy/csum path is often touching just > generated data, or data we just accessed via read(). The csum RX path > from a card with DMA is probably somewhat different. 'Touching' is not interesting since it will pump data into cache, no matter how you 'touch' it. Running benchmarks against 1K static buffer makes cache red hot and causes _all writes_ to hit it. It may lead to wrong conclusions. Is _dst_ buffer of csum_copy going to be used by processor soon? If yes, we shouldn't use movntq, we want to cache dst. If no, we should by all means use movntq. If sometimes, then optimal strategy does not exist. :( -- vda From minuevonegocio@minuevonegocio.com Fri Oct 25 06:00:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 06:00:28 -0700 (PDT) Received: from 192.168.0.16 (mailcorr753.winstar.net.ar [200.61.6.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9PD0NuR031756 for ; Fri, 25 Oct 2002 06:00:25 -0700 Date: Fri, 25 Oct 2002 06:00:23 -0700 Message-Id: <200210251300.g9PD0NuR031756@oss.sgi.com> Received: from minuevonegocio.com [192.168.0.16] by 192.168.0.16 [192.168.0.16] with SMTP (MDaemon.v3.5.0.R) for ; Fri, 25 Oct 2002 09:42:29 -0300 From: minuevonegocio@minuevonegocio.com To: minuevonegocio@minuevonegocio.com Subject: OPORTUNIDAD DE NEGOCIO X-archive-position: 966 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: minuevonegocio@minuevonegocio.com Precedence: bulk X-list: netdev TRABAJA DESDE TU CASA SIN JEFES s patrn de tu tiempo X-MDRemoteIP: 192.168.0.16 X-Return-Path: minuevonegocio@minuevonegocio.com X-MDaemon-Deliver-To: netdev@oss.sgi.com *Te invitamos a desarrollar tu propio negocio con el apoyo de nuestro grupo internacional. *No necesitas experiencia previa ni inversiones de dinero *El costo de todo el material para comenzar est a tu alcance *Apoyo logstico y humano a tu disposicin *Productos, Capacitacin, y Herramientas de primer nivel *Gestin de actividad en 55 pases Para informaciones NO responder a este mail. Pedir informacin a: minuevonegocio03@hotmail.com Su direccin de correo electrnico fue extrada de un lugar pblico de Internet (sin violacin del Habeas Data). Usted recibir este mensaje por nica vez. NOTA: NO RESPONDA A ESTA DIRECCION, su mensaje se perder. SI ESTA INTERESADO A LA OPORTUNIDAD, POR FAVOR CONTACTENOS A minuevonegocio03@hotmail.com Muchas Gracias From jgarzik@pobox.com Fri Oct 25 15:50:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 15:50:46 -0700 (PDT) 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 g9PModuR024705 for ; Fri, 25 Oct 2002 15:50:40 -0700 Received: from rdu74-160-016.nc.rr.com ([24.74.160.16] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 185DI8-00089X-00; Fri, 25 Oct 2002 23:50:56 +0100 Message-ID: <3DB9CAC1.2010000@pobox.com> Date: Fri, 25 Oct 2002 18:50:41 -0400 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: Marcelo Tosatti CC: Alan Cox , LKML , netdev@oss.sgi.com Subject: [BK/GNU] net driver series 12 Content-Type: multipart/mixed; boundary="------------050902010002000309090606" X-archive-position: 967 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. --------------050902010002000309090606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marcelo, I have pushed a tulip bug fix out to gkernel. Please do a bk pull http://gkernel.bkbits.net/net-drivers-2.4 to retrieve the simple tulip patch, which is attached to this email for your review. The BK repository also contains the previous 34 patches I sent to you yesterday, or the day before... --------------050902010002000309090606 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.759 -> 1.760 # drivers/net/tulip/tulip_core.c 1.35 -> 1.36 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/25 jgarzik@redhat.com 1.760 # Fix tulip net driver multi-port board irq assignment # -------------------------------------------- # diff -Nru a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c --- a/drivers/net/tulip/tulip_core.c Fri Oct 25 18:22:30 2002 +++ b/drivers/net/tulip/tulip_core.c Fri Oct 25 18:22:30 2002 @@ -1482,7 +1482,6 @@ tp->timer.function = tulip_tbl[tp->chip_id].media_timer; dev->base_addr = ioaddr; - dev->irq = irq; #ifdef CONFIG_TULIP_MWI if (!force_csr0 && (tp->flags & HAS_PCI_MWI)) @@ -1655,6 +1654,7 @@ for (i = 0; i < 6; i++) last_phys_addr[i] = dev->dev_addr[i]; last_irq = irq; + dev->irq = irq; /* The lower four bits are the media type. */ if (board_idx >= 0 && board_idx < MAX_UNITS) { --------------050902010002000309090606-- From yoshfuji@linux-ipv6.org Fri Oct 25 19:28:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 19:28:17 -0700 (PDT) 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 g9Q2SAuR027647 for ; Fri, 25 Oct 2002 19:28:11 -0700 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 g9Q2SNr5001516; Sat, 26 Oct 2002 11:28:28 +0900 Date: Sat, 26 Oct 2002 11:28:13 +0900 (JST) Message-Id: <20021026.112813.43505001.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Garbage scope-id in MSG_ERRQUEUE message 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-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: 968 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, This patch clears sin6_scope_id in sockaddr_in6 in MSG_ERRQUEUE message. Without this we would see garbage there. This patch is against linux-2.4.20-pre11. Thanks in advance. ------------------------------------------------------------------- Patch-Name: Garbage scope-id in MSG_ERRQUEUE message Patch-Id: FIX_2_4_20_pre11_ICMP_ERROR-20021026 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- Index: net/ipv6/datagram.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/datagram.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.22.1 diff -u -r1.1.1.2 -r1.1.1.2.22.1 --- net/ipv6/datagram.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/datagram.c 25 Oct 2002 16:55:56 -0000 1.1.1.2.22.1 @@ -158,6 +158,7 @@ if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) { sin->sin6_family = AF_INET6; sin->sin6_flowinfo = 0; + sin->sin6_scope_id = 0; if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP6) { memcpy(&sin->sin6_addr, &skb->nh.ipv6h->saddr, 16); if (sk->net_pinfo.af_inet6.rxopt.all) From jmorris@intercode.com.au Fri Oct 25 19:35:05 2002 Received: with ECARTIS (v1.0.0; list netdev); Fri, 25 Oct 2002 19:35:07 -0700 (PDT) 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 g9Q2Z2uR028427 for ; Fri, 25 Oct 2002 19:35:03 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id MAA22796; Sat, 26 Oct 2002 12:35:14 +1000 Date: Sat, 26 Oct 2002 12:35:13 +1000 (EST) From: James Morris To: linux-kernel@vger.kernel.org cc: netdev@oss.sgi.com Subject: Re: The return of the return of crunch time (2.5 merge candidate list 1.6) (crypto api info) In-Reply-To: <200210251557.55202.landley@trommello.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 969 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 Fri, 25 Oct 2002, Rob Landley wrote: > 4) New CryptoAPI (James Morris) This is currently available for review at: http://samba.org/~jamesm/crypto/ The patch there tracks Dave Miller's tree. There's not much documentation yet, so here's a brief rundown: The API takes page vectors (scatterlists) as arguments, and works directly on pages. This is required to support a clean IPsec implementation (which is being worked on by Dave Miller and Alexey Kuznetzov), and is also a requirement from Linus. In some cases (e.g. ECB mode ciphers), this will allow for pages to be encrypted in place with no copying. At the lowest level are algorithms, which register dynamically with the API. 'Transforms' are user-instantiated objects, which maintain state, handle all of the implementation logic (e.g. manipulating page vectors), provide an abstraction to the underlying algorithms, and handle common logical operations (e.g. cipher modes, HMAC for digests). However, at the user level they are very simple. Conceptually, the API layering looks like this: [transform api] (user interface) [transform ops] (per-type logic glue e.g. cipher.c, digest.c) [algorithm api] (for registering algorithms) The idea is to make the user interface and algorithm registration API very simple, while hiding the core logic from both. Many good ideas from existing APIs such as Cryptoapi and Nettle have been adapted for this. The API currently supports three types of transforms: Ciphers, Digests and Compressors. The compression algorithms especially seem to be performing very well so far. An asynchronous scheduling interface is in planning but not yet implemented, as we need to further analyze the requirements of all of the possible hardware scenarios (e.g. IPsec NIC offload). Here's an example of how to use the API: #include struct scatterlist sg[2]; char result[128]; struct crypto_tfm *tfm; tfm = crypto_alloc_tfm(CRYPTO_ALG_MD5); if (tfm == NULL) fail(); /* ... set up the scatterlists ... */ crypto_digest_init(tfm); crypto_digest_update(tfm, &sg, 2); crypto_digest_final(tfm, result); crypto_free_tfm(tfm); Many real examples are available in the regression test module (tcrypt.c). - James -- James Morris From yoshfuji@linux-ipv6.org Sat Oct 26 09:10:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Oct 2002 09:10:12 -0700 (PDT) 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 g9QGA5uR009227 for ; Sat, 26 Oct 2002 09:10:06 -0700 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 g9QGAPGR002466; Sun, 27 Oct 2002 01:10:25 +0900 Date: Sun, 27 Oct 2002 01:10:25 +0900 (JST) Message-Id: <20021027.011025.86893867.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: usagi@linux-ipv6.org Subject: [PATCH] IPv6: Fix for Refine IPv6 Address Validation Timer 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-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: 970 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, We sent a patch to refine timing of IPv6 address validation timer. However, timer was not recalculated on receipt of RA. This patch fixes this bug. Patch is for 2.4.20-pre11. Thanks. Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.26.1 diff -u -r1.1.1.2 -r1.1.1.2.26.1 --- net/ipv6/addrconf.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 +++ net/ipv6/addrconf.c 26 Oct 2002 15:55:14 -0000 1.1.1.2.26.1 @@ -947,6 +947,7 @@ ipv6_ifa_notify((flags&IFA_F_DEPRECATED) ? 0 : RTM_NEWADDR, ifp); in6_ifa_put(ifp); + addrconf_verify(0); } } in6_dev_put(in6_dev); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From scott.feldman@intel.com Sat Oct 26 21:59:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Oct 2002 21:59:17 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9R4xBuR010030 for ; Sat, 26 Oct 2002 21:59:11 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id g9R4w3X21648 for ; Sun, 27 Oct 2002 04:58:03 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id g9R4tfb27914 for ; Sun, 27 Oct 2002 04:55:41 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002102621581222811 ; Sat, 26 Oct 2002 21:58:12 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Oct 2002 21:59:33 -0700 Message-ID: <288F9BF66CD9D5118DF400508B68C44604758C6A@orsmsx113.jf.intel.com> From: "Feldman, Scott" To: "'Paul Hernandez'" , Donald Becker , Felipe W Damasio Cc: Jeff Garzik , Linux-net , netdev@oss.sgi.com Subject: RE: NIC on 2.4.19 SMP (mii-diag output) Date: Sat, 26 Oct 2002 21:59:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Paul wrote: > Just tried 2.4.20-pre11 and all NIC issues seem to be > resolved. Both eepro100 and e100 drivers work correctly. Just for kicks, go back to 2.4.19.SuSE-SMP, but this time disable ACPI. (Set acpi=off in the kernel parameters SuSE's bootloader). Do the nics work? We've seen issues on some of these newer systems with multiple IO-APICS where the interrupts get masked off when ACPI is enabled. -scott From chengjin@cs.caltech.edu Sat Oct 26 22:43:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Oct 2002 22:43:45 -0700 (PDT) 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 g9R5hfuR011096 for ; Sat, 26 Oct 2002 22:43:42 -0700 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id E91BDDF260 for ; Sat, 26 Oct 2002 22:44:04 -0700 (PDT) Received: from localhost (chengjin@localhost) by fast2.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id g9R5i4n04411 for ; Sat, 26 Oct 2002 22:44:04 -0700 X-Authentication-Warning: fast2.cs.caltech.edu: chengjin owned process doing -bs Date: Sat, 26 Oct 2002 22:44:03 -0700 (PDT) From: Cheng Jin To: Subject: struct sock size limit? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 972 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, I have been adding members to struct sock (by changing struct tcp_opt) in linux 2.4.18-3 kernel. I haven't had problems with the kernel until today. When I added a few more bytes (~ 20 bytes) on top of my old addition (around 80 bytes), the kernel would crash calling udp_sendmsg (syslogd initialization). I suspect that there may be some kind of size limit with struct sock/tcp_opt. The TCP connected state is checked from within udp_sendmsg (no idea why that is so). I searched around on google, but didn't find anything on struct sock or struct tcp_opt. Does anyone know whether the size of struct sock/tcp_opt is capped? Thanks a lot, Cheng Lab # 626 395 8820 From acme@conectiva.com.br Sat Oct 26 23:18:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Sat, 26 Oct 2002 23:18:31 -0700 (PDT) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9R6IQuR011650 for ; Sat, 26 Oct 2002 23:18:27 -0700 Received: from [200.181.170.228] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 185fpm-0002OJ-00; Sun, 27 Oct 2002 03:19:34 -0200 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 488031966C; Sun, 27 Oct 2002 06:18:41 +0000 (UTC) Date: Sun, 27 Oct 2002 03:18:40 -0300 From: Arnaldo Carvalho de Melo To: Cheng Jin Cc: netdev@oss.sgi.com Subject: Re: struct sock size limit? Message-ID: <20021027061840.GA4720@conectiva.com.br> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme X-archive-position: 973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Sat, Oct 26, 2002 at 10:44:03PM -0700, Cheng Jin escreveu: > Hi, > > I have been adding members to struct sock (by changing struct tcp_opt) in > linux 2.4.18-3 kernel. I haven't had problems with the kernel until > today. When I added a few more bytes (~ 20 bytes) on top of my old > addition (around 80 bytes), the kernel would crash calling udp_sendmsg beware the data dependencies of struct sock and tcp_tw_bucket, etc, I bet you're adding new struct members at the start of struct sock, see the comment in include/net/tcp.h, just above struct tcp_tw_bucket definition... and also study current include/net/sock.h in 2.5, this thing was all changed (for the better 8) ). > (syslogd initialization). I suspect that there may be some kind of size > limit with struct sock/tcp_opt. The TCP connected state is checked > from within udp_sendmsg (no idea why that is so). so look at other protocols such as decnet that also uses the TCP_ state macros :-) its just reusing those macros. > I searched around on google, but didn't find anything on struct sock or > struct tcp_opt. Does anyone know whether the size of struct sock/tcp_opt > is capped? > > Thanks a lot, > > Cheng > > Lab # 626 395 8820 > From chengjin@cs.caltech.edu Sun Oct 27 01:27:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Sun, 27 Oct 2002 01:27:27 -0700 (PDT) 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 g9R8RNuR013080 for ; Sun, 27 Oct 2002 01:27:23 -0700 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 31DA7DF260 for ; Sun, 27 Oct 2002 01:27:47 -0700 (PDT) Received: from localhost (chengjin@localhost) by fast2.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id g9R8RlG10795 for ; Sun, 27 Oct 2002 01:27:47 -0700 X-Authentication-Warning: fast2.cs.caltech.edu: chengjin owned process doing -bs Date: Sun, 27 Oct 2002 01:27:47 -0700 (PDT) From: Cheng Jin To: Subject: Linux SMP on 2.4.18-3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 974 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, Please excuse me for asking questions on a rather old kernel. We decided to do kernel modificatios against 2.4.18-3 so we can't back it out now. On the SMP test machine we have at the lab (Dual 2.4 Ghz Xeons with one SysKonnect Gigabit Ethernet card, SuperMicro P4DP6 MB), I observed TCP functions being called simultaneously by both processors. What I did was to simply increment a counter (init to zero) and check whether it is one in the functions under suspicion. Sure enough, I see a lot of messages printed out saying it is two. Admittedly, my counter var is not protected either, but seeing it becoming 2 is proof enough that the functions are entered simultaneously (yes I decrement the counter before functions return). I looked at the code fairly extensively, and I didn't see any lock for these functions, tcp_send_skb, tcp_push_one, update_send_head, where packets_out gets incremented. The problem I was having was that tp->packets_out got out of sync with the number of unacked packets on the sk->write_queue. I would like to confirm with people that are involved with kernel developement that what I observed was indeed correct. Thanks, Cheng Lab # 626 395 8820 From davem@redhat.com Mon Oct 28 04:04:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 04:04:43 -0800 (PST) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SC4duR014285 for ; Mon, 28 Oct 2002 04:04:39 -0800 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9SCIRRU008314; Mon, 28 Oct 2002 04:18:27 -0800 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9SCIQlK008312; Mon, 28 Oct 2002 04:18:26 -0800 X-Authentication-Warning: rth.ninka.net: davem set sender to davem@redhat.com using -f Subject: Re: [PATCH] IPv6: ndisc_rcv() clean-up From: "David S. Miller" 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@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: <20021025.094459.116783443.yoshfuji@linux-ipv6.org> References: <20021025.094459.116783443.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 28 Oct 2002 04:18:26 -0800 Message-Id: <1035807506.7701.1.camel@rth.ninka.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SC4duR014285 X-archive-position: 975 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 On Thu, 2002-10-24 at 17:44, YOSHIFUJI Hideaki / wrote: > This patch just adds new ndisc_recv_ns() and ndisc_recv_na() to > make switch / case in ndisc_rcv() (and ndisc_rcv() itself) small. I've applied this patch. Thank you. Can I ask that you CC: me and Alexey directly on future USAGI patches? That helps me work more efficiently. Thank you. From davem@redhat.com Mon Oct 28 04:07:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 04:07:39 -0800 (PST) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SC7auR014686 for ; Mon, 28 Oct 2002 04:07:36 -0800 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9SCLPRU008333; Mon, 28 Oct 2002 04:21:25 -0800 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9SCLP3V008331; Mon, 28 Oct 2002 04:21:25 -0800 X-Authentication-Warning: rth.ninka.net: davem set sender to davem@redhat.com using -f Subject: Re: [PATCH] IPv6: Garbage scope-id in MSG_ERRQUEUE message From: "David S. Miller" 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@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: <20021026.112813.43505001.yoshfuji@linux-ipv6.org> References: <20021026.112813.43505001.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 28 Oct 2002 04:21:24 -0800 Message-Id: <1035807684.7702.3.camel@rth.ninka.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SC7auR014686 X-archive-position: 976 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 On Fri, 2002-10-25 at 19:28, YOSHIFUJI Hideaki / wrote: > This patch clears sin6_scope_id in sockaddr_in6 in MSG_ERRQUEUE > message. Without this we would see garbage there. I've applied this patch, thank you. From davem@redhat.com Mon Oct 28 04:10:07 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 04:10:11 -0800 (PST) Received: from rth.ninka.net (rth.ninka.net [216.101.162.244]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SCA7uR015085 for ; Mon, 28 Oct 2002 04:10:07 -0800 Received: from rth.ninka.net (localhost.localdomain [127.0.0.1]) by rth.ninka.net (8.12.5/8.12.5) with ESMTP id g9SCNuRU008354; Mon, 28 Oct 2002 04:23:56 -0800 Received: (from davem@localhost) by rth.ninka.net (8.12.5/8.12.5/Submit) id g9SCNuSa008352; Mon, 28 Oct 2002 04:23:56 -0800 X-Authentication-Warning: rth.ninka.net: davem set sender to davem@redhat.com using -f Subject: Re: [PATCH] IPv6: Fix for Refine IPv6 Address Validation Timer From: "David S. Miller" 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@oss.sgi.com, usagi@linux-ipv6.org In-Reply-To: <20021027.011025.86893867.yoshfuji@linux-ipv6.org> References: <20021027.011025.86893867.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 28 Oct 2002 04:23:55 -0800 Message-Id: <1035807835.7702.5.camel@rth.ninka.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SCA7uR015085 X-archive-position: 977 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 On Sat, 2002-10-26 at 09:10, YOSHIFUJI Hideaki / wrote: > We sent a patch to refine timing of IPv6 address validation timer. > However, timer was not recalculated on receipt of RA. > This patch fixes this bug. I've applied this patch, thank you. From hadi@cyberus.ca Mon Oct 28 04:42:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 04:42:05 -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 g9SCg3uR018580 for ; Mon, 28 Oct 2002 04:42:03 -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 HAA10257; Mon, 28 Oct 2002 07:42:31 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9SCZ1j10771; Mon, 28 Oct 2002 07:35:02 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 28 Oct 2002 07:35:01 -0500 (EST) From: jamal To: "Maksim (Max) Krasnyanskiy" cc: Tim Hockin , David Woodhouse , , Subject: Re: rtnetlink interface state monitoring problems. In-Reply-To: <5.1.0.14.2.20021023124123.09b83e00@mail1.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 978 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, 23 Oct 2002, Maksim (Max) Krasnyanskiy wrote: > > >netlink is a messaging system; so what i am thinking is creating > >a event notifier for other devices other than network devices. > >Something other non-network devices could use (eg bluetooth). > > What kind of events are we taking about ? > Currently, for net events, notifier_call_chain() calls from the same routines which also send netlink announcements. I am thinking actually having notifier_call_chain make the netlink advertisements. There are not that many subsystems that use notifier block calls (seems the network subsytem is their best customer ;->) i think it is the best async notification scheme in the kernel. Too bad someone had to invent hotplug the way it is right now. As i said earlier, the advantage with netlink is that you could easily add a distributed event notification scheme since it is already in packet format. cheers, jamal From hadi@cyberus.ca Mon Oct 28 04:54:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 04:54:49 -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 g9SCsjuR028611 for ; Mon, 28 Oct 2002 04:54:45 -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 HAA13892; Mon, 28 Oct 2002 07:55:13 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g9SCliV10798; Mon, 28 Oct 2002 07:47:45 -0500 (EST) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 28 Oct 2002 07:47:44 -0500 (EST) From: jamal To: Cheng Jin cc: 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: 979 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 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. In non-NAPI based NICs such as yours, you could have reordering within the system (this is described in the NAPI paper). Either get it NAPIfied or get yourself a NAPI capable NIC such as tg3 based, e1000, Dlink gige etc. cheers, jamal On Sun, 27 Oct 2002, Cheng Jin wrote: > Hi, > > Please excuse me for asking questions on a rather old kernel. We decided > to do kernel modificatios against 2.4.18-3 so we can't back it out now. > > On the SMP test machine we have at the lab (Dual 2.4 Ghz Xeons with one > SysKonnect Gigabit Ethernet card, SuperMicro P4DP6 MB), I observed TCP > functions being called simultaneously by both processors. What I did was > to simply increment a counter (init to zero) and check whether it is one > in the functions under suspicion. Sure enough, I see a lot of messages > printed out saying it is two. Admittedly, my counter var is not protected > either, but seeing it becoming 2 is proof enough that the functions are > entered simultaneously (yes I decrement the counter before functions > return). > > I looked at the code fairly extensively, and I didn't see any lock for > these functions, tcp_send_skb, tcp_push_one, update_send_head, where > packets_out gets incremented. The problem I was having was that > tp->packets_out got out of sync with the number of unacked packets on the > sk->write_queue. > > I would like to confirm with people that are involved with kernel > developement that what I observed was indeed correct. > > Thanks, > > Cheng > > Lab # 626 395 8820 > > From davem@redhat.com Mon Oct 28 04:58:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 04:58:45 -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 g9SCwguR031497 for ; Mon, 28 Oct 2002 04:58:42 -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 EAA29435; Mon, 28 Oct 2002 04:50:00 -0800 Date: Mon, 28 Oct 2002 04:50:00 -0800 (PST) Message-Id: <20021028.045000.117518979.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [Patch 2.5.43] IpInDelivers, IpInDiscards From: "David S. Miller" In-Reply-To: <3DAF5172.8EDC0F1A@us.ibm.com> References: <20021017.164326.60506862.davem@redhat.com> <3DAF5172.8EDC0F1A@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: 980 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: Thu, 17 Oct 2002 17:10:26 -0700 "David S. Miller" wrote: > Thanks a lot for your work, I'll post what I end up applying > to my tree. Great :). Thanks much! Here is what I applied. Thanks again. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.835 -> 1.836 # net/ipv4/raw.c 1.17 -> 1.18 # net/ipv4/ip_input.c 1.7 -> 1.8 # net/ipv4/udp.c 1.23 -> 1.24 # net/ipv6/udp.c 1.16 -> 1.17 # net/ipv4/tcp_ipv4.c 1.33 -> 1.34 # net/ipv6/raw.c 1.17 -> 1.18 # net/ipv6/tcp_ipv6.c 1.29 -> 1.30 # net/ipv6/ip6_input.c 1.3 -> 1.4 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/28 niv@us.ibm.com 1.836 # [IPV{4,6}]: Clean up SNMP counter bumping. # -------------------------------------------- # diff -Nru a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c --- a/net/ipv4/ip_input.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv4/ip_input.c Mon Oct 28 04:54:10 2002 @@ -237,11 +237,13 @@ protocol = -ret; goto resubmit; } + IP_INC_STATS_BH(IpInDelivers); } else { if (!raw_sk) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); - } + } else + IP_INC_STATS_BH(IpInDelivers); kfree_skb(skb); } } @@ -304,8 +306,10 @@ --ANK (980813) */ - if (skb_cow(skb, skb_headroom(skb))) + if (skb_cow(skb, skb_headroom(skb))) { + IP_INC_STATS_BH(IpInDiscards); goto drop; + } iph = skb->nh.iph; if (ip_options_compile(NULL, skb)) @@ -353,8 +357,10 @@ IP_INC_STATS_BH(IpInReceives); - if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) { + IP_INC_STATS_BH(IpInDiscards); goto out; + } if (!pskb_may_pull(skb, sizeof(struct iphdr))) goto inhdr_error; diff -Nru a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv4/raw.c Mon Oct 28 04:54:10 2002 @@ -227,12 +227,11 @@ /* Charge it to the socket. */ if (sock_queue_rcv_skb(sk, skb) < 0) { - IP_INC_STATS(IpInDiscards); + /* FIXME: increment a raw drops counter here */ kfree_skb(skb); return NET_RX_DROP; } - IP_INC_STATS(IpInDelivers); return NET_RX_SUCCESS; } diff -Nru a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv4/tcp_ipv4.c Mon Oct 28 04:54:10 2002 @@ -1700,8 +1700,6 @@ goto discard; #endif /* CONFIG_FILTER */ - IP_INC_STATS_BH(IpInDelivers); - if (sk->state == TCP_ESTABLISHED) { /* Fast path */ TCP_CHECK_TIMER(sk); if (tcp_rcv_established(sk, skb, skb->h.th, skb->len)) diff -Nru a/net/ipv4/udp.c b/net/ipv4/udp.c --- a/net/ipv4/udp.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv4/udp.c Mon Oct 28 04:54:10 2002 @@ -951,8 +951,6 @@ if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if (__udp_checksum_complete(skb)) { UDP_INC_STATS_BH(UdpInErrors); - IP_INC_STATS_BH(IpInDiscards); - ip_statistics[smp_processor_id()*2].IpInDelivers--; kfree_skb(skb); return -1; } @@ -962,8 +960,6 @@ if (sock_queue_rcv_skb(sk,skb)<0) { UDP_INC_STATS_BH(UdpInErrors); - IP_INC_STATS_BH(IpInDiscards); - ip_statistics[smp_processor_id()*2].IpInDelivers--; kfree_skb(skb); return -1; } @@ -1046,8 +1042,6 @@ u32 saddr = skb->nh.iph->saddr; u32 daddr = skb->nh.iph->daddr; int len = skb->len; - - IP_INC_STATS_BH(IpInDelivers); /* * Validate the packet and the UDP length. diff -Nru a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c --- a/net/ipv6/ip6_input.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv6/ip6_input.c Mon Oct 28 04:54:10 2002 @@ -60,8 +60,10 @@ IP6_INC_STATS_BH(Ip6InReceives); - if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) { + IP6_INC_STATS_BH(Ip6InDiscards); goto out; + } /* Store incoming device index. When the packet will be queued, we cannot refer to skb->dev anymore. @@ -175,11 +177,13 @@ nexthdr = -ret; goto resubmit; } + IP6_INC_STATS_BH(Ip6InDelivers); } else { if (!raw_sk) { IP6_INC_STATS_BH(Ip6InUnknownProtos); icmpv6_param_prob(skb, ICMPV6_UNK_NEXTHDR, nhoff); - } + } else + IP6_INC_STATS_BH(Ip6InDelivers); kfree_skb(skb); } diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv6/raw.c Mon Oct 28 04:54:10 2002 @@ -275,7 +275,7 @@ #if defined(CONFIG_FILTER) if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } @@ -284,12 +284,11 @@ #endif /* Charge it to the socket. */ if (sock_queue_rcv_skb(sk,skb)<0) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } - IP6_INC_STATS_BH(Ip6InDelivers); return 0; } @@ -327,7 +326,7 @@ if (inet->hdrincl) { if (skb->ip_summed != CHECKSUM_UNNECESSARY && (unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { - IP6_INC_STATS_BH(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ kfree_skb(skb); return 0; } @@ -427,7 +426,7 @@ as some normal condition. */ err = (flags&MSG_DONTWAIT) ? -EAGAIN : -EHOSTUNREACH; - IP6_INC_STATS_USER(Ip6InDiscards); + /* FIXME: increment a raw6 drops counter here */ goto out_free; } diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv6/tcp_ipv6.c Mon Oct 28 04:54:10 2002 @@ -1497,8 +1497,6 @@ * is currently called with bh processing disabled. */ - IP6_INC_STATS_BH(Ip6InDelivers); - /* Do Stevens' IPV6_PKTOPTIONS. Yes, guys, it is the only place in our code, where we diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c Mon Oct 28 04:54:10 2002 +++ b/net/ipv6/udp.c Mon Oct 28 04:54:10 2002 @@ -545,7 +545,6 @@ if (sk->filter && skb->ip_summed != CHECKSUM_UNNECESSARY) { if ((unsigned short)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum))) { UDP6_INC_STATS_BH(UdpInErrors); - IP6_INC_STATS_BH(Ip6InDiscards); kfree_skb(skb); return 0; } @@ -554,11 +553,9 @@ #endif if (sock_queue_rcv_skb(sk,skb)<0) { UDP6_INC_STATS_BH(UdpInErrors); - IP6_INC_STATS_BH(Ip6InDiscards); kfree_skb(skb); return 0; } - IP6_INC_STATS_BH(Ip6InDelivers); UDP6_INC_STATS_BH(UdpInDatagrams); return 0; } From jjo-ipsec@mendoza.gov.ar Mon Oct 28 05:57:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 05:57:48 -0800 (PST) Received: from mail.mendoza.gov.ar ([200.80.39.216]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SDvXuR017714 for ; Mon, 28 Oct 2002 05:57:39 -0800 Received: (qmail 26546 invoked by uid 240); 28 Oct 2002 13:55:43 -0000 Date: Mon, 28 Oct 2002 10:55:25 -0300 To: Jean-Luc Cooke Cc: Jari Ruusu , Herbert Valerio Riedel , "David S. Miller" , Sandy Harris , Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org Subject: Re: [CryptoAPI-devel] Re: [Design] [PATCH] USAGI IPsec Message-ID: <20021028105525.C18414@mendoza.gov.ar> Mail-Followup-To: JuanJo Ciarlante , Jean-Luc Cooke , Jari Ruusu , Herbert Valerio Riedel , "David S. Miller" , Sandy Harris , Mitsuru KANDA , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cryptoapi-devel@kerneli.org, design@lists.freeswan.org, usagi@linux-ipv6.org References: <3DB41338.3070502@storm.ca> <1035168066.4817.1.camel@rth.ninka.net> <1035185654.21824.11.camel@janus.txd.hvrlab.org> <3DB4DBC8.8647E32E@pp.inet.fi> <20021024105026.C1170@certainkey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021024105026.C1170@certainkey.com>; from jlcooke@certainkey.com on Thu, Oct 24, 2002 at 10:50:26AM -0400 X-Delivery-Agent: TMDA v0.41/Python 1.5.2 (linux-i386) From: "JuanJo Ciarlante" X-archive-position: 981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jjo-ipsec@mendoza.gov.ar Precedence: bulk X-list: netdev On Thu, Oct 24, 2002 at 10:50:26AM -0400, Jean-Luc Cooke wrote: > On Tue, Oct 22, 2002 at 08:02:00AM +0300, Jari Ruusu wrote: > > kerneli.org/cryptoapi _is_ useless joke for many needs. Fortunately other > > people are able to see the limitations/sillyness of kerneli.org/cryptoapi: > > > > 1) You are trying to replace link/insmod time overhead with runtime > > overhead + unnecessary bloat. > > 2) No direct link access to low level cipher functions or higher level > > functions. > > 3) No clean way to replace cipher code with processor type optimized > > assembler implementations. > > Jari has a few points here. But the "killer" functionalities are all there > IMHO. Low-level assembler implementations are over-rated, again IMHO. The > performance difference between C and ASM is at most 50%. 1ms vs 1.5 ms. > Even if you've got a large payload on the rare occation (>5MB) block ciphers > are quite fast for 95% of applications According to my tests, AES ASM has given me _2x_ speed boost over C; this fact has re-written freeswan CPU/bandwidth empirical formula to peak at CPU [MHz] ~= BW [Mbit/s] * 10 (instead of 25) This boost has allowed my old Cyrix-6x86 120MHz to be my 802.11b gateway =) --Juanjo freeswan algo: AES (+others), SHA2, MODP2048-4096 selectable algorithms support for Phase1 and 2. http://www.irrigacion.gov.ar/juanjo/ipsec/ # Juan Jose Ciarlante (JuanJo PGP) jjo ;at; mendoza.gov.ar # # Key fingerprint = 76 60 A5 76 FD D2 53 E3 50 C7 90 20 22 8C F1 2D # From Larry.Sendlosky@storigen.com Mon Oct 28 07:44:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 07:44:48 -0800 (PST) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SFiiuR021191 for ; Mon, 28 Oct 2002 07:44:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: via-rhine "reset did not complete" errors MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 10:45:08 -0500 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A03C079@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: via-rhine "reset did not complete" errors Thread-Index: AcJ+mP4fWfB3it7RQsm3REXMGEnFWA== From: "Larry Sendlosky" To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SFiiuR021191 X-archive-position: 982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev Hi, We're using VIA EPIA mini-ITX with 800Mhz C3 and the VT6103 PHY. (via-rhine driver says VT6102). We have made sure power supply is "big enough". Our kernel is 2.4.18 with via-rhine.c patches to fix TX timeout. Our TX timeout issues seem to have gone away with the recent patches. However we are still plagued with the "reset did not complete in 10ms" errors. Once it this state, a warm restart of the system is necessary (and we have seen this problem at boot time, which is more confusing). Anyway, we can make this problem occur easily by doing 'ifconfig down eth0' followed by 'ifconfig up eth0'. The error happens on the 'open' of the device. However, when we do this with 'no link' (cable not plugged in), the problem does not happen. It only seems to happen when there is activity on the wire and plugged in. When the reset does not happen, the CR0/CR1 state after the reset is always 0x8008 now matter what the current state of those regs going into the reset. So it appears the problem is actually in the 'close' when possibly in the process of receiving a packet. Especially given that via_rhine_close puts the device in loopback mode to void hardware races. Does via_rhine_close need to be a little smarter/paranoid? :)) Besides register definitions, the docs are pretty useless. Are there hardware issues that are still not fixed? eg. a reset does not reset the chip regardless of state. Any help or ideas would be appreciated. thanks larry From riel@conectiva.com.br Mon Oct 28 08:10:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 08:10:13 -0800 (PST) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.250.58.156]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SGA7uR022712 for ; Mon, 28 Oct 2002 08:10:08 -0800 Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id D35164751F for ; Mon, 28 Oct 2002 14:10:33 -0200 (BRST) Received: (qmail 20424 invoked by uid 0); 28 Oct 2002 16:12:00 -0000 Received: from duckman.distro.conectiva (10.0.17.2) by burns.conectiva with SMTP; 28 Oct 2002 16:12:00 -0000 Received: (from localhost user: 'riel', uid#500) by duckman.distro.conectiva with ESMTP id ; Mon, 28 Oct 2002 14:10:24 -0200 Date: Mon, 28 Oct 2002 14:10:24 -0200 (BRST) From: Rik van Riel X-X-Sender: riel@duckman.distro.conectiva To: netdev Cc: Arnaldo Carvalho de Melo Subject: multipath routing doesn't work with netlink Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: riel@conectiva.com.br Precedence: bulk X-list: netdev Hi, Am I doing something wrong or is there a kernel bug that prevents multipath routing from working with NETLINK ? # ip route add default via 10.0.16.1 # ip route add default via 10.0.17.2 RTNETLINK answers: File exists # route add default gw 10.0.17.2 # ... of course, this last command just works and results in a routing table like this: # ip route 10.0.16.0/21 dev eth0 proto kernel scope link src 10.0.17.3 127.0.0.0/8 dev lo scope link default via 10.0.17.2 dev eth0 default via 10.0.16.1 dev eth0 Is there a fundamental reason that iproute2 (using NETLINK) should fail here, or is this a bug for which patches will be accepted ? regards, Rik -- A: No. Q: Should I include quotations after my reply? http://www.surriel.com/ http://distro.conectiva.com/ From chengjin@cs.caltech.edu Mon Oct 28 10:26:29 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 10:26:34 -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 g9SIQTuR027400 for ; Mon, 28 Oct 2002 10:26:29 -0800 Received: from fast2.cs.caltech.edu (fast2.cs.caltech.edu [131.215.45.55]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 00345DF263; Mon, 28 Oct 2002 10:26:58 -0800 (PST) Received: from localhost (chengjin@localhost) by fast2.cs.caltech.edu (8.11.6/8.9.3) with ESMTP id g9SIQwf29131; Mon, 28 Oct 2002 10:26:58 -0800 X-Authentication-Warning: fast2.cs.caltech.edu: chengjin owned process doing -bs Date: Mon, 28 Oct 2002 10:26:58 -0800 (PST) From: Cheng Jin To: jamal 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: 984 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 Jamal, Thanks for writing me back. > 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? 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. > In non-NAPI based NICs such as yours, you could have reordering within > the system (this is described in the NAPI paper). Either get it NAPIfied > or get yourself a NAPI capable NIC such as tg3 based, e1000, Dlink gige > etc. Out of curiosity, what is the maximum send rate (pps) under Linux 2.4.18-3? I read in the paper that sending across two Intel Gbe with one CPU gets up to 36o Kpps. Thanks, Cheng From becker@scyld.com Mon Oct 28 11:37:54 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 11:37:58 -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 g9SJbruR028426 for ; Mon, 28 Oct 2002 11:37:53 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id g9SJcJ413220; Mon, 28 Oct 2002 14:38:19 -0500 Date: Mon, 28 Oct 2002 14:38:18 -0500 (EST) From: Donald Becker To: Larry Sendlosky cc: linux-net@vger.kernel.org, , Subject: Re: via-rhine "reset did not complete" errors In-Reply-To: <7BFCE5F1EF28D64198522688F5449D5A03C079@xchangeserver2.storigen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 985 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 Mon, 28 Oct 2002, Larry Sendlosky wrote: > We're using VIA EPIA mini-ITX with 800Mhz C3 and the > VT6103 PHY. (via-rhine driver says VT6102). We have made sure > power supply is "big enough". Our kernel is 2.4.18 with > via-rhine.c patches to fix TX timeout. Those are evil patches... > Our TX timeout issues seem to have gone away with the recent > patches. However we are still plagued with the "reset did not > complete in 10ms" errors. A driver _really_, _really_ shouldn't be busy-waiting for link negotiation to complete. That happened a lot with MS-DOS drivers, but it wasn't even reasonable there. Yet it's far easier for someone to get a horribly flawed patch like that accepted, while my patches went completely ignored. > Once it this state, a warm restart of > the system is necessary (and we have seen this problem at > boot time, which is more confusing). Look at the what the code is doing. It is easier to write drivers when you make the rest of the kernel single threaded on your code... -- 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 Larry.Sendlosky@storigen.com Mon Oct 28 13:03:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 13:03:04 -0800 (PST) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SL2xuR029821 for ; Mon, 28 Oct 2002 13:03:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: via-rhine "reset did not complete" errors MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 16:03:25 -0500 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A03C07A@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: via-rhine "reset did not complete" errors Thread-Index: AcJ+uZPu+xV8gPSeT3yf3Ory50izAQACltgg From: "Larry Sendlosky" To: "Donald Becker" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SL2xuR029821 X-archive-position: 986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev Hi Donald, Thanks for the reply. The "reset timeout" happens on the initial reset in the 'open' routine. The reset bit (bit 7 of CR1) is not clearing after being written. This usually happens after the 'close' routine (on a previous 'ifconfig eth0 down') writes the stop cmd to CR0 and the "start" bit is still on after writing the stop cmd to CR0. What is the proper way to "stop" this little beast? thanks again, larry -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Monday, October 28, 2002 2:38 PM To: Larry Sendlosky Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; rl@hellgate.ch Subject: Re: via-rhine "reset did not complete" errors On Mon, 28 Oct 2002, Larry Sendlosky wrote: > We're using VIA EPIA mini-ITX with 800Mhz C3 and the > VT6103 PHY. (via-rhine driver says VT6102). We have made sure > power supply is "big enough". Our kernel is 2.4.18 with > via-rhine.c patches to fix TX timeout. Those are evil patches... > Our TX timeout issues seem to have gone away with the recent > patches. However we are still plagued with the "reset did not > complete in 10ms" errors. A driver _really_, _really_ shouldn't be busy-waiting for link negotiation to complete. That happened a lot with MS-DOS drivers, but it wasn't even reasonable there. Yet it's far easier for someone to get a horribly flawed patch like that accepted, while my patches went completely ignored. > Once it this state, a warm restart of > the system is necessary (and we have seen this problem at > boot time, which is more confusing). Look at the what the code is doing. It is easier to write drivers when you make the rest of the kernel single threaded on your code... -- 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 dlstevens@us.ibm.com Mon Oct 28 13:05:42 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 13:05:46 -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 g9SL5guR030231 for ; Mon, 28 Oct 2002 13:05:42 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9SL65GV038328; Mon, 28 Oct 2002 16:06:05 -0500 Received: from d03nm035.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 g9SL62bm108190; Mon, 28 Oct 2002 14:06:03 -0700 From: "David Stevens" Importance: Normal Sensitivity: To: kuznet@ms2.inr.ac.ru, davem@redhat.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Date: Mon, 28 Oct 2002 14:06:00 -0700 Subject: [PATCH] anycast support for IPv6, updated to 2.5.44 X-MIMETrack: Serialize by Router on D03NM035/03/M/IBM(Release 5.0.10 |March 22, 2002) at 10/28/2002 02:06:02 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE6F3DFE120F28f9e8a93df938690918c07BBE6F3DFE120F2" Content-Disposition: inline X-archive-position: 987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE6F3DFE120F28f9e8a93df938690918c07BBE6F3DFE120F2 Content-type: text/plain; charset=us-ascii Below is a patch to add anycast support for IPv6. It's the same patch as I've posted previously, but updated with comments from Chris Hellwig and for kernel version 2.5.44. My mailer mangles tabs, so I'm including it in-line (for easy viewing) and as an attachment at the end (for applying to kernels). A fuller description is available at: http://marc.theaimsgroup.com/?l=linux-net&m=103057141321548&w=2 Currently, IPv6 mobile code is the only user of anycasting, but there won't be users if it isn't supported. Please consider for inclusion in 2.5. +-DLS diff -ruN linux-2.5.44/include/linux/in6.h linux-2.5.44AC/include/linux/in6.h --- linux-2.5.44/include/linux/in6.h Fri Oct 18 21:01:59 2002 +++ linux-2.5.44AC/include/linux/in6.h Mon Oct 28 12:38:09 2002 @@ -56,6 +56,8 @@ int ipv6mr_ifindex; }; +#define ipv6mr_acaddr ipv6mr_multiaddr + struct in6_flowlabel_req { struct in6_addr flr_dst; @@ -156,6 +158,9 @@ #define IPV6_MTU_DISCOVER 23 #define IPV6_MTU 24 #define IPV6_RECVERR 25 +/* 26 is IPV6_V6ONLY in USAGI code */ +#define IPV6_JOIN_ANYCAST 27 +#define IPV6_LEAVE_ANYCAST 28 /* IPV6_MTU_DISCOVER values */ #define IPV6_PMTUDISC_DONT 0 diff -ruN linux-2.5.44/include/linux/ipv6.h linux-2.5.44AC/include/linux/ipv6.h --- linux-2.5.44/include/linux/ipv6.h Fri Oct 18 21:02:26 2002 +++ linux-2.5.44AC/include/linux/ipv6.h Mon Oct 28 12:38:09 2002 @@ -155,6 +155,7 @@ pmtudisc:2; struct ipv6_mc_socklist *ipv6_mc_list; + struct ipv6_ac_socklist *ipv6_ac_list; struct ipv6_fl_socklist *ipv6_fl_list; __u32 dst_cookie; diff -ruN linux-2.5.44/include/linux/netdevice.h linux-2.5.44AC/include/linux/netdevice.h --- linux-2.5.44/include/linux/netdevice.h Fri Oct 18 21:02:31 2002 +++ linux-2.5.44AC/include/linux/netdevice.h Mon Oct 28 12:38:09 2002 @@ -464,6 +464,10 @@ extern void dev_add_pack(struct packet_type *pt); extern void dev_remove_pack(struct packet_type *pt); extern int dev_get(const char *name); +extern struct net_device *dev_getany(unsigned short flags, + unsigned short mask); +extern struct net_device *__dev_getany(unsigned short flags, + unsigned short mask); extern struct net_device *dev_get_by_name(const char *name); extern struct net_device *__dev_get_by_name(const char *name); extern struct net_device *dev_alloc(const char *name, int *err); diff -ruN linux-2.5.44/include/net/addrconf.h linux-2.5.44AC/include/net/addrconf.h --- linux-2.5.44/include/net/addrconf.h Fri Oct 18 21:01:18 2002 +++ linux-2.5.44AC/include/net/addrconf.h Mon Oct 28 12:38:09 2002 @@ -58,7 +58,15 @@ extern int ipv6_get_saddr(struct dst_entry *dst, struct in6_addr *daddr, struct in6_addr *saddr); +extern int ipv6_dev_get_saddr(struct net_device *dev, + struct in6_addr *daddr, + struct in6_addr *saddr, + int onlink); extern int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *); +extern void addrconf_join_solict(struct net_device *dev, + struct in6_addr *addr); +extern void addrconf_leave_solict(struct net_device *dev, + struct in6_addr *addr); /* * multicast prototypes (mcast.c) @@ -88,6 +96,26 @@ extern void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len); +/* + * anycast prototypes (anycast.c) + */ +extern int ipv6_sock_ac_join(struct sock *sk, + int ifindex, + struct in6_addr *addr); +extern int ipv6_sock_ac_drop(struct sock *sk, + int ifindex, + struct in6_addr *addr); +extern void ipv6_sock_ac_close(struct sock *sk); +extern int inet6_ac_check(struct sock *sk, struct in6_addr *addr, int ifindex); + +extern int ipv6_dev_ac_inc(struct net_device *dev, + struct in6_addr *addr); +extern int ipv6_dev_ac_dec(struct net_device *dev, + struct in6_addr *addr); +extern int ipv6_chk_acast_addr(struct net_device *dev, + struct in6_addr *addr); + + /* Device notifier */ extern int register_inet6addr_notifier(struct notifier_block *nb); extern int unregister_inet6addr_notifier(struct notifier_block *nb); diff -ruN linux-2.5.44/include/net/if_inet6.h linux-2.5.44AC/include/net/if_inet6.h --- linux-2.5.44/include/net/if_inet6.h Fri Oct 18 21:02:34 2002 +++ linux-2.5.44AC/include/net/if_inet6.h Mon Oct 28 12:38:09 2002 @@ -69,6 +69,25 @@ spinlock_t mca_lock; }; +/* Anycast stuff */ + +struct ipv6_ac_socklist +{ + struct in6_addr acl_addr; + int acl_ifindex; + struct ipv6_ac_socklist *acl_next; +}; + +struct ifacaddr6 +{ + struct in6_addr aca_addr; + struct inet6_dev *aca_idev; + struct ifacaddr6 *aca_next; + int aca_users; + atomic_t aca_refcnt; + spinlock_t aca_lock; +}; + #define IFA_HOST IPV6_ADDR_LOOPBACK #define IFA_LINK IPV6_ADDR_LINKLOCAL #define IFA_SITE IPV6_ADDR_SITELOCAL @@ -96,6 +115,7 @@ struct inet6_ifaddr *addr_list; struct ifmcaddr6 *mc_list; + struct ifacaddr6 *ac_list; rwlock_t lock; atomic_t refcnt; __u32 if_flags; diff -ruN linux-2.5.44/net/core/dev.c linux-2.5.44AC/net/core/dev.c --- linux-2.5.44/net/core/dev.c Fri Oct 18 21:01:54 2002 +++ linux-2.5.44AC/net/core/dev.c Mon Oct 28 12:38:09 2002 @@ -541,6 +541,50 @@ } /** + * dev_getany - find any device with given flags + * @if_flags: IFF_* values + * @mask: bitmask of bits in if_flags to check + * + * Search for any interface with the given flags. Returns NULL if a device + * is not found or a pointer to the device. The device returned has + * had a reference added and the pointer is safe until the user calls + * dev_put to indicate they have finished with it. + */ + +struct net_device * dev_getany(unsigned short if_flags, unsigned short mask) +{ + struct net_device *dev; + + read_lock(&dev_base_lock); + dev = __dev_getany(if_flags, mask); + if (dev) + dev_hold(dev); + read_unlock(&dev_base_lock); + return dev; +} + +/** + * __dev_getany - find any device with given flags + * @if_flags: IFF_* values + * @mask: bitmask of bits in if_flags to check + * + * Search for any interface with the given flags. Returns NULL if a device + * is not found or a pointer to the device. The caller must hold either + * the RTNL semaphore or @dev_base_lock. + */ + +struct net_device *__dev_getany(unsigned short if_flags, unsigned short mask) +{ + struct net_device *dev; + + for (dev = dev_base; dev != NULL; dev = dev->next) { + if (((dev->flags ^ if_flags) & mask) == 0) + return dev; + } + return NULL; +} + +/** * dev_alloc_name - allocate a name for a device * @dev: device * @name: name format string diff -ruN linux-2.5.44/net/ipv6/Makefile linux-2.5.44AC/net/ipv6/Makefile --- linux-2.5.44/net/ipv6/Makefile Fri Oct 18 21:02:27 2002 +++ linux-2.5.44AC/net/ipv6/Makefile Mon Oct 28 12:38:09 2002 @@ -6,7 +6,7 @@ obj-$(CONFIG_IPV6) += ipv6.o -ipv6-objs := af_inet6.o ip6_output.o ip6_input.o addrconf.o sit.o \ +ipv6-objs := af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o sit.o \ route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o raw.o \ protocol.o icmp.o mcast.o reassembly.o tcp_ipv6.o \ exthdrs.o sysctl_net_ipv6.o datagram.o proc.o \ diff -ruN linux-2.5.44/net/ipv6/addrconf.c linux-2.5.44AC/net/ipv6/addrconf.c --- linux-2.5.44/net/ipv6/addrconf.c Fri Oct 18 21:02:31 2002 +++ linux-2.5.44AC/net/ipv6/addrconf.c Mon Oct 28 12:49:03 2002 @@ -137,21 +137,15 @@ int ipv6_addr_type(struct in6_addr *addr) { + int type; u32 st; st = addr->s6_addr32[0]; - /* Consider all addresses with the first three bits different of - 000 and 111 as unicasts. - */ - if ((st & htonl(0xE0000000)) != htonl(0x00000000) && - (st & htonl(0xE0000000)) != htonl(0xE0000000)) - return IPV6_ADDR_UNICAST; - - if ((st & htonl(0xFF000000)) == htonl(0xFF000000)) { - int type = IPV6_ADDR_MULTICAST; + if ((st & __constant_htonl(0xFF000000)) == __constant_htonl(0xFF000000)) { + type = IPV6_ADDR_MULTICAST; - switch((st & htonl(0x00FF0000))) { + switch((st & __constant_htonl(0x00FF0000))) { case __constant_htonl(0x00010000): type |= IPV6_ADDR_LOOPBACK; break; @@ -166,29 +160,53 @@ }; return type; } + /* check for reserved anycast addresses */ + + if ((st & __constant_htonl(0xE0000000)) && + ((addr->s6_addr32[2] == __constant_htonl(0xFDFFFFFF) && + (addr->s6_addr32[3] | __constant_htonl(0x7F)) == (u32)~0) || + (addr->s6_addr32[2] == 0 && addr->s6_addr32[3] == 0))) + type = IPV6_ADDR_ANYCAST; + else + type = IPV6_ADDR_UNICAST; + + /* Consider all addresses with the first three bits different of + 000 and 111 as finished. + */ + if ((st & __constant_htonl(0xE0000000)) != __constant_htonl(0x00000000) && + (st & __constant_htonl(0xE0000000)) != __constant_htonl(0xE0000000)) + return type; - if ((st & htonl(0xFFC00000)) == htonl(0xFE800000)) - return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST); + if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFE800000)) + return (IPV6_ADDR_LINKLOCAL | type); - if ((st & htonl(0xFFC00000)) == htonl(0xFEC00000)) - return (IPV6_ADDR_SITELOCAL | IPV6_ADDR_UNICAST); + if ((st & __constant_htonl(0xFFC00000)) == __constant_htonl(0xFEC00000)) + return (IPV6_ADDR_SITELOCAL | type); if ((addr->s6_addr32[0] | addr->s6_addr32[1]) == 0) { if (addr->s6_addr32[2] == 0) { - if (addr->s6_addr32[3] == 0) + if (addr->in6_u.u6_addr32[3] == 0) return IPV6_ADDR_ANY; - if (addr->s6_addr32[3] == htonl(0x00000001)) - return (IPV6_ADDR_LOOPBACK | IPV6_ADDR_UNICAST); + if (addr->s6_addr32[3] == __constant_htonl(0x00000001)) + return (IPV6_ADDR_LOOPBACK | type); - return (IPV6_ADDR_COMPATv4 | IPV6_ADDR_UNICAST); + return (IPV6_ADDR_COMPATv4 | type); } - if (addr->s6_addr32[2] == htonl(0x0000ffff)) + if (addr->s6_addr32[2] == __constant_htonl(0x0000ffff)) return IPV6_ADDR_MAPPED; } - return IPV6_ADDR_RESERVED; + st &= __constant_htonl(0xFF000000); + if (st == 0) + return IPV6_ADDR_RESERVED; + st &= __constant_htonl(0xFE000000); + if (st == __constant_htonl(0x02000000)) + return IPV6_ADDR_RESERVED; /* for NSAP */ + if (st == __constant_htonl(0x04000000)) + return IPV6_ADDR_RESERVED; /* for IPX */ + return type; } static void addrconf_del_timer(struct inet6_ifaddr *ifp) @@ -224,7 +242,6 @@ add_timer(&ifp->timer); } - /* Nobody refers to this device, we may destroy it. */ void in6_dev_finish_destroy(struct inet6_dev *idev) @@ -303,24 +320,91 @@ return idev; } +void ipv6_addr_prefix(struct in6_addr *prefix, + struct in6_addr *addr, int prefix_len) +{ + unsigned long mask; + int ncopy, nbits; + + memset(prefix, 0, sizeof(*prefix)); + + if (prefix_len <= 0) + return; + if (prefix_len > 128) + prefix_len = 128; + + ncopy = prefix_len / 32; + switch (ncopy) { + case 4: prefix->s6_addr32[3] = addr->s6_addr32[3]; + case 3: prefix->s6_addr32[2] = addr->s6_addr32[2]; + case 2: prefix->s6_addr32[1] = addr->s6_addr32[1]; + case 1: prefix->s6_addr32[0] = addr->s6_addr32[0]; + case 0: break; + } + nbits = prefix_len % 32; + if (nbits == 0) + return; + + mask = ~((1 << (32 - nbits)) - 1); + mask = htonl(mask); + + prefix->s6_addr32[ncopy] = addr->s6_addr32[ncopy] & mask; +} + + +static void dev_forward_change(struct inet6_dev *idev) +{ + struct net_device *dev; + struct inet6_ifaddr *ifa; + struct in6_addr addr; + + if (!idev) + return; + dev = idev->dev; + if (dev && (dev->flags & IFF_MULTICAST)) { + ipv6_addr_all_routers(&addr); + + if (idev->cnf.forwarding) + ipv6_dev_mc_inc(dev, &addr); + else + ipv6_dev_mc_dec(dev, &addr); + } + for (ifa=idev->addr_list; ifa; ifa=ifa->if_next) { + ipv6_addr_prefix(&addr, &ifa->addr, ifa->prefix_len); + if (addr.s6_addr32[0] == 0 && addr.s6_addr32[1] == 0 && + addr.s6_addr32[2] == 0 && addr.s6_addr32[3] == 0) + continue; + if (idev->cnf.forwarding) + ipv6_dev_ac_inc(idev->dev, &addr); + else + ipv6_dev_ac_dec(idev->dev, &addr); + } +} + + static void addrconf_forward_change(struct inet6_dev *idev) { struct net_device *dev; - if (idev) + if (idev) { + dev_forward_change(idev); return; + } read_lock(&dev_base_lock); for (dev=dev_base; dev; dev=dev->next) { read_lock(&addrconf_lock); idev = __in6_dev_get(dev); - if (idev) + if (idev) { idev->cnf.forwarding = ipv6_devconf.forwarding; + dev_forward_change(idev); + } read_unlock(&addrconf_lock); } read_unlock(&dev_base_lock); } + /* Nobody refers to this ifaddr, destroy it */ void inet6_ifa_finish_destroy(struct inet6_ifaddr *ifp) @@ -458,29 +542,20 @@ * an address of the attached interface * iii) don't use deprecated addresses */ -int ipv6_get_saddr(struct dst_entry *dst, - struct in6_addr *daddr, struct in6_addr *saddr) +int ipv6_dev_get_saddr(struct net_device *dev, + struct in6_addr *daddr, struct in6_addr *saddr, int onlink) { - int scope; struct inet6_ifaddr *ifp = NULL; struct inet6_ifaddr *match = NULL; - struct net_device *dev = NULL; struct inet6_dev *idev; - struct rt6_info *rt; + int scope; int err; - rt = (struct rt6_info *) dst; - if (rt) - dev = rt->rt6i_dev; - scope = ipv6_addr_scope(daddr); - if (rt && (rt->rt6i_flags & RTF_ALLONLINK)) { - /* - * route for the "all destinations on link" rule - * when no routers are present - */ + if (!onlink) + scope = ipv6_addr_scope(daddr); + else scope = IFA_LINK; - } /* * known dev @@ -568,6 +643,24 @@ return err; } + +int ipv6_get_saddr(struct dst_entry *dst, + struct in6_addr *daddr, struct in6_addr *saddr) +{ + struct rt6_info *rt; + struct net_device *dev = NULL; + int onlink; + + rt = (struct rt6_info *) dst; + if (rt) + dev = rt->rt6i_dev; + + onlink = (rt && (rt->rt6i_flags & RTF_ALLONLINK)); + + return ipv6_dev_get_saddr(dev, daddr, saddr, onlink); +} + + int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr) { struct inet6_dev *idev; @@ -660,7 +753,7 @@ /* Join to solicited addr multicast group. */ -static void addrconf_join_solict(struct net_device *dev, struct in6_addr *addr) +void addrconf_join_solict(struct net_device *dev, struct in6_addr *addr) { struct in6_addr maddr; @@ -671,7 +764,7 @@ ipv6_dev_mc_inc(dev, &maddr); } -static void addrconf_leave_solict(struct net_device *dev, struct in6_addr *addr) +void addrconf_leave_solict(struct net_device *dev, struct in6_addr *addr) { struct in6_addr maddr; @@ -1554,6 +1647,15 @@ addrconf_mod_timer(ifp, AC_RS, ifp->idev->cnf.rtr_solicit_interval); spin_unlock_bh(&ifp->lock); } + + if (ifp->idev->cnf.forwarding) { + struct in6_addr addr; + + ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); + if (addr.s6_addr32[0] || addr.s6_addr32[1] || + addr.s6_addr32[2] || addr.s6_addr32[3]) + ipv6_dev_ac_inc(ifp->idev->dev, &addr); + } } #ifdef CONFIG_PROC_FS @@ -1853,6 +1955,14 @@ break; case RTM_DELADDR: addrconf_leave_solict(ifp->idev->dev, &ifp->addr); + if (ifp->idev->cnf.forwarding) { + struct in6_addr addr; + + ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); + if (addr.s6_addr32[0] || addr.s6_addr32[1] || + addr.s6_addr32[2] || addr.s6_addr32[3]) + ipv6_dev_ac_dec(ifp->idev->dev, &addr); + } if (!ipv6_chk_addr(&ifp->addr, NULL)) ip6_rt_addr_del(&ifp->addr, ifp->idev->dev); break; @@ -1875,11 +1985,7 @@ struct inet6_dev *idev = NULL; if (valp != &ipv6_devconf.forwarding) { - struct net_device *dev = dev_get_by_index(ctl->ctl_name); - if (dev) { - idev = in6_dev_get(dev); - dev_put(dev); - } + idev = (struct inet6_dev *)ctl->extra1; if (idev == NULL) return ret; } else @@ -1889,8 +1995,6 @@ if (*valp) rt6_purge_dflt_routers(0); - if (idev) - in6_dev_put(idev); } return ret; @@ -1967,6 +2071,7 @@ for (i=0; iaddrconf_vars)/sizeof(t->addrconf_vars[0])-1; i++) { t->addrconf_vars[i].data += (char*)p - (char*)&ipv6_devconf; t->addrconf_vars[i].de = NULL; + t->addrconf_vars[i].extra1 = idev; /* embedded; no ref */ } if (dev) { t->addrconf_dev[0].procname = dev->name; diff -ruN linux-2.5.44/net/ipv6/af_inet6.c linux-2.5.44AC/net/ipv6/af_inet6.c --- linux-2.5.44/net/ipv6/af_inet6.c Fri Oct 18 21:01:57 2002 +++ linux-2.5.44AC/net/ipv6/af_inet6.c Mon Oct 28 12:38:09 2002 @@ -76,6 +76,7 @@ /* IPv6 procfs goodies... */ #ifdef CONFIG_PROC_FS +extern int anycast6_get_info(char *, char **, off_t, int); extern int raw6_get_info(char *, char **, off_t, int); extern int tcp6_get_info(char *, char **, off_t, int); extern int udp6_get_info(char *, char **, off_t, int); @@ -380,6 +381,9 @@ /* Free mc lists */ ipv6_sock_mc_close(sk); + /* Free ac lists */ + ipv6_sock_ac_close(sk); + return inet_release(sock); } @@ -694,6 +698,8 @@ goto proc_sockstat6_fail; if (!proc_net_create("snmp6", 0, afinet6_get_snmp)) goto proc_snmp6_fail; + if (!proc_net_create("anycast6", 0, anycast6_get_info)) + goto proc_anycast6_fail; #endif ipv6_netdev_notif_init(); ipv6_packet_init(); @@ -709,6 +715,8 @@ return 0; #ifdef CONFIG_PROC_FS +proc_anycast6_fail: + proc_net_remove("anycast6"); proc_snmp6_fail: proc_net_remove("sockstat6"); proc_sockstat6_fail: @@ -744,6 +752,7 @@ proc_net_remove("udp6"); proc_net_remove("sockstat6"); proc_net_remove("snmp6"); + proc_net_remove("anycast6"); #endif /* Cleanup code parts. */ sit_cleanup(); diff -ruN linux-2.5.44/net/ipv6/anycast.c linux-2.5.44AC/net/ipv6/anycast.c --- linux-2.5.44/net/ipv6/anycast.c Wed Dec 31 16:00:00 1969 +++ linux-2.5.44AC/net/ipv6/anycast.c Mon Oct 28 13:28:07 2002 @@ -0,0 +1,489 @@ +/* + * Anycast support for IPv6 + * Linux INET6 implementation + * + * Authors: + * David L Stevens (dlstevens@us.ibm.com) + * + * based heavily on net/ipv6/mcast.c + * + * 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 +#include +#include +#include +#include + +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +/* Big ac list lock for all the sockets */ +static rwlock_t ipv6_sk_ac_lock = RW_LOCK_UNLOCKED; + +/* XXX ip6_addr_match() and ip6_onlink() really belong in net/core.c */ + +static int +ip6_addr_match(struct in6_addr *addr1, struct in6_addr *addr2, int prefix) +{ + __u32 mask; + int i; + + if (prefix > 128 || prefix < 0) + return 0; + if (prefix == 0) + return 1; + for (i=0; i<4; ++i) { + if (prefix >= 32) + mask = ~0; + else + mask = htonl(~0 << (32 - prefix)); + if ((addr1->s6_addr32[i] ^ addr2->s6_addr32[i]) & mask) + return 0; + prefix -= 32; + if (prefix <= 0) + break; + } + return 1; +} + +static int +ip6_onlink(struct in6_addr *addr, struct net_device *dev) +{ + struct inet6_dev *idev; + struct inet6_ifaddr *ifa; + int onlink; + + onlink = 0; + read_lock(&addrconf_lock); + idev = __in6_dev_get(dev); + if (idev) { + read_lock_bh(&idev->lock); + for (ifa=idev->addr_list; ifa; ifa=ifa->if_next) { + onlink = ip6_addr_match(addr, &ifa->addr, + ifa->prefix_len); + if (onlink) + break; + } + read_unlock_bh(&idev->lock); + } + read_unlock(&addrconf_lock); + return onlink; +} + + +/* + * socket join an anycast group + */ + +int ipv6_sock_ac_join(struct sock *sk, int ifindex, struct in6_addr *addr) +{ + struct ipv6_pinfo *np = inet6_sk(sk); + struct net_device *dev = NULL; + struct inet6_dev *idev; + struct ipv6_ac_socklist *pac; + int ishost = !ipv6_devconf.forwarding; + int err = 0; + + if (ipv6_addr_type(addr) & IPV6_ADDR_MULTICAST) + return -EINVAL; + + pac = sock_kmalloc(sk, sizeof(struct ipv6_ac_socklist), GFP_KERNEL); + if (pac == NULL) + return -ENOMEM; + pac->acl_next = NULL; + ipv6_addr_copy(&pac->acl_addr, addr); + + if (ifindex == 0) { + struct rt6_info *rt; + + rt = rt6_lookup(addr, NULL, 0, 0); + if (rt) { + dev = rt->rt6i_dev; + dev_hold(dev); + dst_release(&rt->u.dst); + } else if (ishost) { + sock_kfree_s(sk, pac, sizeof(*pac)); + return -EADDRNOTAVAIL; + } else { + /* router, no matching interface: just pick one */ + + dev = dev_getany(IFF_UP, IFF_UP|IFF_LOOPBACK); + } + } else + dev = dev_get_by_index(ifindex); + + if (dev == NULL) { + sock_kfree_s(sk, pac, sizeof(*pac)); + return -ENODEV; + } + + idev = in6_dev_get(dev); + if (!idev) { + sock_kfree_s(sk, pac, sizeof(*pac)); + dev_put(dev); + if (ifindex) + return -ENODEV; + else + return -EADDRNOTAVAIL; + } + /* reset ishost, now that we have a specific device */ + ishost = !idev->cnf.forwarding; + in6_dev_put(idev); + + pac->acl_ifindex = dev->ifindex; + + /* XXX + * For hosts, allow link-local or matching prefix anycasts. + * This obviates the need for propagating anycast routes while + * still allowing some non-router anycast participation. + * + * allow anyone to join anycasts that don't require a special route + * and can't be spoofs of unicast addresses (reserved anycast only) + */ + if (!ip6_onlink(addr, dev)) { + if (ishost) + err = -EADDRNOTAVAIL; + else if (!capable(CAP_NET_ADMIN)) + err = -EPERM; + if (err) { + sock_kfree_s(sk, pac, sizeof(*pac)); + dev_put(dev); + return err; + } + } else if (!(ipv6_addr_type(addr) & IPV6_ADDR_ANYCAST) && + !capable(CAP_NET_ADMIN)) + return -EPERM; + + err = ipv6_dev_ac_inc(dev, addr); + if (err) { + sock_kfree_s(sk, pac, sizeof(*pac)); + dev_put(dev); + return err; + } + + write_lock_bh(&ipv6_sk_ac_lock); + pac->acl_next = np->ipv6_ac_list; + np->ipv6_ac_list = pac; + write_unlock_bh(&ipv6_sk_ac_lock); + + dev_put(dev); + + return 0; +} + +/* + * socket leave an anycast group + */ +int ipv6_sock_ac_drop(struct sock *sk, int ifindex, struct in6_addr *addr) +{ + struct ipv6_pinfo *np = inet6_sk(sk); + struct net_device *dev; + struct ipv6_ac_socklist *pac, *prev_pac; + + write_lock_bh(&ipv6_sk_ac_lock); + prev_pac = 0; + for (pac = np->ipv6_ac_list; pac; pac = pac->acl_next) { + if ((ifindex == 0 || pac->acl_ifindex == ifindex) && + ipv6_addr_cmp(&pac->acl_addr, addr) == 0) + break; + prev_pac = pac; + } + if (!pac) { + write_unlock_bh(&ipv6_sk_ac_lock); + return -ENOENT; + } + if (prev_pac) + prev_pac->acl_next = pac->acl_next; + else + np->ipv6_ac_list = pac->acl_next; + + write_unlock_bh(&ipv6_sk_ac_lock); + + dev = dev_get_by_index(pac->acl_ifindex); + if (dev) { + ipv6_dev_ac_dec(dev, &pac->acl_addr); + dev_put(dev); + } + sock_kfree_s(sk, pac, sizeof(*pac)); + return 0; +} + +void ipv6_sock_ac_close(struct sock *sk) +{ + struct ipv6_pinfo *np = inet6_sk(sk); + struct net_device *dev = 0; + struct ipv6_ac_socklist *pac; + int prev_index; + + write_lock_bh(&ipv6_sk_ac_lock); + pac = np->ipv6_ac_list; + np->ipv6_ac_list = 0; + write_unlock_bh(&ipv6_sk_ac_lock); + + prev_index = 0; + while (pac) { + struct ipv6_ac_socklist *next = pac->acl_next; + + if (pac->acl_ifindex != prev_index) { + if (dev) + dev_put(dev); + dev = dev_get_by_index(pac->acl_ifindex); + prev_index = pac->acl_ifindex; + } + if (dev) + ipv6_dev_ac_dec(dev, &pac->acl_addr); + sock_kfree_s(sk, pac, sizeof(*pac)); + pac = next; + } + if (dev) + dev_put(dev); +} + +int inet6_ac_check(struct sock *sk, struct in6_addr *addr, int ifindex) +{ + struct ipv6_ac_socklist *pac; + struct ipv6_pinfo *np = inet6_sk(sk); + int found; + + found = 0; + read_lock(&ipv6_sk_ac_lock); + for (pac=np->ipv6_ac_list; pac; pac=pac->acl_next) { + if (ifindex && pac->acl_ifindex != ifindex) + continue; + found = ipv6_addr_cmp(&pac->acl_addr, addr) == 0; + if (found) + break; + } + read_unlock(&ipv6_sk_ac_lock); + + return found; +} + +static void aca_put(struct ifacaddr6 *ac) +{ + if (atomic_dec_and_test(&ac->aca_refcnt)) { + in6_dev_put(ac->aca_idev); + kfree(ac); + } +} + +/* + * device anycast group inc (add if not found) + */ +int ipv6_dev_ac_inc(struct net_device *dev, struct in6_addr *addr) +{ + struct ifacaddr6 *aca; + struct inet6_dev *idev; + + idev = in6_dev_get(dev); + + if (idev == NULL) + return -EINVAL; + + write_lock_bh(&idev->lock); + if (idev->dead) { + write_unlock_bh(&idev->lock); + in6_dev_put(idev); + return -ENODEV; + } + + for (aca = idev->ac_list; aca; aca = aca->aca_next) { + if (ipv6_addr_cmp(&aca->aca_addr, addr) == 0) { + aca->aca_users++; + write_unlock_bh(&idev->lock); + in6_dev_put(idev); + return 0; + } + } + + /* + * not found: create a new one. + */ + + aca = kmalloc(sizeof(struct ifacaddr6), GFP_ATOMIC); + + if (aca == NULL) { + write_unlock_bh(&idev->lock); + in6_dev_put(idev); + return -ENOMEM; + } + + memset(aca, 0, sizeof(struct ifacaddr6)); + + ipv6_addr_copy(&aca->aca_addr, addr); + aca->aca_idev = idev; + aca->aca_users = 1; + atomic_set(&aca->aca_refcnt, 2); + aca->aca_lock = SPIN_LOCK_UNLOCKED; + + aca->aca_next = idev->ac_list; + idev->ac_list = aca; + write_unlock_bh(&idev->lock); + + ip6_rt_addr_add(&aca->aca_addr, dev); + + addrconf_join_solict(dev, &aca->aca_addr); + + aca_put(aca); + return 0; +} + +/* + * device anycast group decrement + */ +int ipv6_dev_ac_dec(struct net_device *dev, struct in6_addr *addr) +{ + struct inet6_dev *idev; + struct ifacaddr6 *aca, *prev_aca; + + idev = in6_dev_get(dev); + if (idev == NULL) + return -ENODEV; + + write_lock_bh(&idev->lock); + prev_aca = 0; + for (aca = idev->ac_list; aca; aca = aca->aca_next) { + if (ipv6_addr_cmp(&aca->aca_addr, addr) == 0) + break; + prev_aca = aca; + } + if (!aca) { + write_unlock_bh(&idev->lock); + in6_dev_put(idev); + return -ENOENT; + } + if (--aca->aca_users > 0) { + write_unlock_bh(&idev->lock); + in6_dev_put(idev); + return 0; + } + if (prev_aca) + prev_aca->aca_next = aca->aca_next; + else + idev->ac_list = aca->aca_next; + write_unlock_bh(&idev->lock); + addrconf_leave_solict(dev, &aca->aca_addr); + + ip6_rt_addr_del(&aca->aca_addr, dev); + + aca_put(aca); + in6_dev_put(idev); + return 0; +} + +/* + * check if the interface has this anycast address + */ +static int ipv6_chk_acast_dev(struct net_device *dev, struct in6_addr *addr) +{ + struct inet6_dev *idev; + struct ifacaddr6 *aca; + + idev = in6_dev_get(dev); + if (idev) { + read_lock_bh(&idev->lock); + for (aca = idev->ac_list; aca; aca = aca->aca_next) + if (ipv6_addr_cmp(&aca->aca_addr, addr) == 0) + break; + read_unlock_bh(&idev->lock); + in6_dev_put(idev); + return aca != 0; + } + return 0; +} + +/* + * check if given interface (or any, if dev==0) has this anycast address + */ +int ipv6_chk_acast_addr(struct net_device *dev, struct in6_addr *addr) +{ + if (dev) + return ipv6_chk_acast_dev(dev, addr); + read_lock(&dev_base_lock); + for (dev=dev_base; dev; dev=dev->next) + if (ipv6_chk_acast_dev(dev, addr)) + break; + read_unlock(&dev_base_lock); + return dev != 0; +} + + +#ifdef CONFIG_PROC_FS +int anycast6_get_info(char *buffer, char **start, off_t offset, int length) +{ + off_t pos=0, begin=0; + struct ifacaddr6 *im; + int len=0; + struct net_device *dev; + + read_lock(&dev_base_lock); + for (dev = dev_base; dev; dev = dev->next) { + struct inet6_dev *idev; + + if ((idev = in6_dev_get(dev)) == NULL) + continue; + + read_lock_bh(&idev->lock); + for (im = idev->ac_list; im; im = im->aca_next) { + int i; + + len += sprintf(buffer+len,"%-4d %-15s ", dev->ifindex, dev->name); + + for (i=0; i<16; i++) + len += sprintf(buffer+len, "%02x", im->aca_addr.s6_addr[i]); + + len += sprintf(buffer+len, " %5d\n", im->aca_users); + + pos=begin+len; + if (pos < offset) { + len=0; + begin=pos; + } + if (pos > offset+length) { + read_unlock_bh(&idev->lock); + in6_dev_put(idev); + goto done; + } + } + read_unlock_bh(&idev->lock); + in6_dev_put(idev); + } + +done: + read_unlock(&dev_base_lock); + + *start=buffer+(offset-begin); + len-=(offset-begin); + if(len>length) + len=length; + if (len<0) + len=0; + return len; +} + +#endif diff -ruN linux-2.5.44/net/ipv6/icmp.c linux-2.5.44AC/net/ipv6/icmp.c --- linux-2.5.44/net/ipv6/icmp.c Fri Oct 18 21:01:20 2002 +++ linux-2.5.44AC/net/ipv6/icmp.c Mon Oct 28 12:38:09 2002 @@ -388,7 +388,8 @@ saddr = &skb->nh.ipv6h->daddr; - if (ipv6_addr_type(saddr) & IPV6_ADDR_MULTICAST) + if (ipv6_addr_type(saddr) & IPV6_ADDR_MULTICAST || + ipv6_chk_acast_addr(0, saddr)) saddr = NULL; msg.icmph.icmp6_type = ICMPV6_ECHO_REPLY; diff -ruN linux-2.5.44/net/ipv6/ipv6_sockglue.c linux-2.5.44AC/net/ipv6/ipv6_sockglue.c --- linux-2.5.44/net/ipv6/ipv6_sockglue.c Fri Oct 18 21:01:09 2002 +++ linux-2.5.44AC/net/ipv6/ipv6_sockglue.c Mon Oct 28 12:38:09 2002 @@ -351,6 +351,24 @@ retv = ipv6_sock_mc_drop(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_multiaddr); break; } + case IPV6_JOIN_ANYCAST: + case IPV6_LEAVE_ANYCAST: + { + struct ipv6_mreq mreq; + + if (optlen != sizeof(struct ipv6_mreq)) + goto e_inval; + + retv = -EFAULT; + if (copy_from_user(&mreq, optval, sizeof(struct ipv6_mreq))) + break; + + if (optname == IPV6_JOIN_ANYCAST) + retv = ipv6_sock_ac_join(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_acaddr); + else + retv = ipv6_sock_ac_drop(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_acaddr); + break; + } case IPV6_ROUTER_ALERT: retv = ip6_ra_control(sk, val, NULL); break; diff -ruN linux-2.5.44/net/ipv6/ndisc.c linux-2.5.44AC/net/ipv6/ndisc.c --- linux-2.5.44/net/ipv6/ndisc.c Fri Oct 18 21:01:59 2002 +++ linux-2.5.44AC/net/ipv6/ndisc.c Mon Oct 28 13:12:27 2002 @@ -378,7 +378,10 @@ struct in6_addr *daddr, struct in6_addr *solicited_addr, int router, int solicited, int override, int inc_opt) { + static struct in6_addr tmpaddr; + struct inet6_ifaddr *ifp; struct sock *sk = ndisc_socket->sk; + struct in6_addr *src_addr; struct nd_msg *msg; int len; struct sk_buff *skb; @@ -400,13 +403,23 @@ ND_PRINTK1("send_na: alloc skb failed\n"); return; } + /* for anycast or proxy, solicited_addr != src_addr */ + ifp = ipv6_get_ifaddr(solicited_addr, dev); + if (ifp) { + src_addr = solicited_addr; + in6_ifa_put(ifp); + } else { + if (ipv6_dev_get_saddr(dev, daddr, &tmpaddr, 0)) + return; + src_addr = &tmpaddr; + } if (ndisc_build_ll_hdr(skb, dev, daddr, neigh, len) == 0) { kfree_skb(skb); return; } - ip6_nd_hdr(sk, skb, dev, solicited_addr, daddr, IPPROTO_ICMPV6, len); + ip6_nd_hdr(sk, skb, dev, src_addr, daddr, IPPROTO_ICMPV6, len); msg = (struct nd_msg *) skb_put(skb, len); @@ -426,7 +439,7 @@ ndisc_fill_option(msg->opt, ND_OPT_TARGET_LL_ADDR, dev->dev_addr, dev->addr_len); /* checksum */ - msg->icmph.icmp6_cksum = csum_ipv6_magic(solicited_addr, daddr, len, + msg->icmph.icmp6_cksum = csum_ipv6_magic(src_addr, daddr, len, IPPROTO_ICMPV6, csum_partial((__u8 *) msg, len, 0)); @@ -1133,6 +1146,51 @@ } } in6_ifa_put(ifp); + } else if (ipv6_chk_acast_addr(dev, &msg->target)) { + struct inet6_dev *idev = in6_dev_get(dev); + int addr_type = ipv6_addr_type(saddr); + + /* anycast */ + + if (!idev) { + /* XXX: count this drop? */ + return 0; + } + + if (addr_type == IPV6_ADDR_ANY) { + struct in6_addr maddr; + + ipv6_addr_all_nodes(&maddr); + ndisc_send_na(dev, NULL, &maddr, &msg->target, + idev->cnf.forwarding, 0, 0, 1); + in6_dev_put(idev); + return 0; + } + + if (addr_type & IPV6_ADDR_UNICAST) { + int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; + if (inc) + nd_tbl.stats.rcv_probes_mcast++; + else + nd_tbl.stats.rcv_probes_ucast++; + + /* + * update / create cache entry + * for the source adddress + */ + + neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, skb->dev); + + if (neigh || !dev->hard_header) { + ndisc_send_na(dev, neigh, saddr, + &msg->target, + idev->cnf.forwarding, 1, 0, inc); + if (neigh) + neigh_release(neigh); + } + } + in6_dev_put(idev); + } else { struct inet6_dev *in6_dev = in6_dev_get(dev); int addr_type = ipv6_addr_type(saddr); diff -ruN linux-2.5.44/net/netsyms.c linux-2.5.44AC/net/netsyms.c --- linux-2.5.44/net/netsyms.c Fri Oct 18 21:01:49 2002 +++ linux-2.5.44AC/net/netsyms.c Mon Oct 28 12:38:09 2002 @@ -469,6 +469,8 @@ EXPORT_SYMBOL(unregister_netdevice); EXPORT_SYMBOL(netdev_state_change); EXPORT_SYMBOL(dev_new_index); +EXPORT_SYMBOL(dev_getany); +EXPORT_SYMBOL(__dev_getany); EXPORT_SYMBOL(dev_get_by_index); EXPORT_SYMBOL(__dev_get_by_index); EXPORT_SYMBOL(dev_get_by_name); (See attached file: anycast-2.5.44.patch) --0__=07BBE6F3DFE120F28f9e8a93df938690918c07BBE6F3DFE120F2 Content-type: application/octet-stream; name="anycast-2.5.44.patch" Content-Disposition: attachment; filename="anycast-2.5.44.patch" Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNS40NC9pbmNsdWRlL2xpbnV4L2luNi5oIGxp bnV4LTIuNS40NEFDL2luY2x1ZGUvbGludXgvaW42LmgKLS0tIGxpbnV4LTIu NS40NC9pbmNsdWRlL2xpbnV4L2luNi5oCUZyaSBPY3QgMTggMjE6MDE6NTkg MjAwMgorKysgbGludXgtMi41LjQ0QUMvaW5jbHVkZS9saW51eC9pbjYuaAlN b24gT2N0IDI4IDEyOjM4OjA5IDIwMDIKQEAgLTU2LDYgKzU2LDggQEAKIAlp bnQJCWlwdjZtcl9pZmluZGV4OwogfTsKIAorI2RlZmluZSBpcHY2bXJfYWNh ZGRyCWlwdjZtcl9tdWx0aWFkZHIKKwogc3RydWN0IGluNl9mbG93bGFiZWxf cmVxCiB7CiAJc3RydWN0IGluNl9hZGRyCWZscl9kc3Q7CkBAIC0xNTYsNiAr MTU4LDkgQEAKICNkZWZpbmUgSVBWNl9NVFVfRElTQ09WRVIJMjMKICNkZWZp bmUgSVBWNl9NVFUJCTI0CiAjZGVmaW5lIElQVjZfUkVDVkVSUgkJMjUKKy8q IDI2IGlzIElQVjZfVjZPTkxZIGluIFVTQUdJIGNvZGUgKi8KKyNkZWZpbmUg SVBWNl9KT0lOX0FOWUNBU1QJMjcKKyNkZWZpbmUgSVBWNl9MRUFWRV9BTllD QVNUCTI4CiAKIC8qIElQVjZfTVRVX0RJU0NPVkVSIHZhbHVlcyAqLwogI2Rl ZmluZSBJUFY2X1BNVFVESVNDX0RPTlQJCTAKZGlmZiAtcnVOIGxpbnV4LTIu NS40NC9pbmNsdWRlL2xpbnV4L2lwdjYuaCBsaW51eC0yLjUuNDRBQy9pbmNs dWRlL2xpbnV4L2lwdjYuaAotLS0gbGludXgtMi41LjQ0L2luY2x1ZGUvbGlu dXgvaXB2Ni5oCUZyaSBPY3QgMTggMjE6MDI6MjYgMjAwMgorKysgbGludXgt Mi41LjQ0QUMvaW5jbHVkZS9saW51eC9pcHY2LmgJTW9uIE9jdCAyOCAxMjoz ODowOSAyMDAyCkBAIC0xNTUsNiArMTU1LDcgQEAKIAkgICAgICAgICAgICAg ICAgICAgICAgICBwbXR1ZGlzYzoyOwogCiAJc3RydWN0IGlwdjZfbWNfc29j a2xpc3QJKmlwdjZfbWNfbGlzdDsKKwlzdHJ1Y3QgaXB2Nl9hY19zb2NrbGlz dAkqaXB2Nl9hY19saXN0OwogCXN0cnVjdCBpcHY2X2ZsX3NvY2tsaXN0ICpp cHY2X2ZsX2xpc3Q7CiAJX191MzIJCQlkc3RfY29va2llOwogCmRpZmYgLXJ1 TiBsaW51eC0yLjUuNDQvaW5jbHVkZS9saW51eC9uZXRkZXZpY2UuaCBsaW51 eC0yLjUuNDRBQy9pbmNsdWRlL2xpbnV4L25ldGRldmljZS5oCi0tLSBsaW51 eC0yLjUuNDQvaW5jbHVkZS9saW51eC9uZXRkZXZpY2UuaAlGcmkgT2N0IDE4 IDIxOjAyOjMxIDIwMDIKKysrIGxpbnV4LTIuNS40NEFDL2luY2x1ZGUvbGlu dXgvbmV0ZGV2aWNlLmgJTW9uIE9jdCAyOCAxMjozODowOSAyMDAyCkBAIC00 NjQsNiArNDY0LDEwIEBACiBleHRlcm4gdm9pZAkJZGV2X2FkZF9wYWNrKHN0 cnVjdCBwYWNrZXRfdHlwZSAqcHQpOwogZXh0ZXJuIHZvaWQJCWRldl9yZW1v dmVfcGFjayhzdHJ1Y3QgcGFja2V0X3R5cGUgKnB0KTsKIGV4dGVybiBpbnQJ CWRldl9nZXQoY29uc3QgY2hhciAqbmFtZSk7CitleHRlcm4gc3RydWN0IG5l dF9kZXZpY2UJKmRldl9nZXRhbnkodW5zaWduZWQgc2hvcnQgZmxhZ3MsCisJ CQkJCXVuc2lnbmVkIHNob3J0IG1hc2spOworZXh0ZXJuIHN0cnVjdCBuZXRf ZGV2aWNlCSpfX2Rldl9nZXRhbnkodW5zaWduZWQgc2hvcnQgZmxhZ3MsCisJ CQkJCXVuc2lnbmVkIHNob3J0IG1hc2spOwogZXh0ZXJuIHN0cnVjdCBuZXRf ZGV2aWNlCSpkZXZfZ2V0X2J5X25hbWUoY29uc3QgY2hhciAqbmFtZSk7CiBl eHRlcm4gc3RydWN0IG5ldF9kZXZpY2UJKl9fZGV2X2dldF9ieV9uYW1lKGNv bnN0IGNoYXIgKm5hbWUpOwogZXh0ZXJuIHN0cnVjdCBuZXRfZGV2aWNlCSpk ZXZfYWxsb2MoY29uc3QgY2hhciAqbmFtZSwgaW50ICplcnIpOwpkaWZmIC1y dU4gbGludXgtMi41LjQ0L2luY2x1ZGUvbmV0L2FkZHJjb25mLmggbGludXgt Mi41LjQ0QUMvaW5jbHVkZS9uZXQvYWRkcmNvbmYuaAotLS0gbGludXgtMi41 LjQ0L2luY2x1ZGUvbmV0L2FkZHJjb25mLmgJRnJpIE9jdCAxOCAyMTowMTox OCAyMDAyCisrKyBsaW51eC0yLjUuNDRBQy9pbmNsdWRlL25ldC9hZGRyY29u Zi5oCU1vbiBPY3QgMjggMTI6Mzg6MDkgMjAwMgpAQCAtNTgsNyArNTgsMTUg QEAKIGV4dGVybiBpbnQJCQlpcHY2X2dldF9zYWRkcihzdHJ1Y3QgZHN0X2Vu dHJ5ICpkc3QsIAogCQkJCQkgICAgICAgc3RydWN0IGluNl9hZGRyICpkYWRk ciwKIAkJCQkJICAgICAgIHN0cnVjdCBpbjZfYWRkciAqc2FkZHIpOworZXh0 ZXJuIGludAkJCWlwdjZfZGV2X2dldF9zYWRkcihzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCAKKwkJCQkJICAgICAgIHN0cnVjdCBpbjZfYWRkciAqZGFkZHIs CisJCQkJCSAgICAgICBzdHJ1Y3QgaW42X2FkZHIgKnNhZGRyLAorCQkJCQkg ICAgICAgaW50IG9ubGluayk7CiBleHRlcm4gaW50CQkJaXB2Nl9nZXRfbGxh ZGRyKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpbjZfYWRkciAq KTsKK2V4dGVybiB2b2lkCQkJYWRkcmNvbmZfam9pbl9zb2xpY3Qoc3RydWN0 IG5ldF9kZXZpY2UgKmRldiwKKwkJCQkJc3RydWN0IGluNl9hZGRyICphZGRy KTsKK2V4dGVybiB2b2lkCQkJYWRkcmNvbmZfbGVhdmVfc29saWN0KHN0cnVj dCBuZXRfZGV2aWNlICpkZXYsCisJCQkJCXN0cnVjdCBpbjZfYWRkciAqYWRk cik7CiAKIC8qCiAgKgltdWx0aWNhc3QgcHJvdG90eXBlcyAobWNhc3QuYykK QEAgLTg4LDYgKzk2LDI2IEBACiBleHRlcm4gdm9pZAkJCWFkZHJjb25mX3By ZWZpeF9yY3Yoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwKIAkJCQkJCSAgICB1 OCAqb3B0LCBpbnQgbGVuKTsKIAorLyoKKyAqCWFueWNhc3QgcHJvdG90eXBl cyAoYW55Y2FzdC5jKQorICovCitleHRlcm4gaW50CQkJaXB2Nl9zb2NrX2Fj X2pvaW4oc3RydWN0IHNvY2sgKnNrLCAKKwkJCQkJCSAgaW50IGlmaW5kZXgs IAorCQkJCQkJICBzdHJ1Y3QgaW42X2FkZHIgKmFkZHIpOworZXh0ZXJuIGlu dAkJCWlwdjZfc29ja19hY19kcm9wKHN0cnVjdCBzb2NrICpzaywKKwkJCQkJ CSAgaW50IGlmaW5kZXgsIAorCQkJCQkJICBzdHJ1Y3QgaW42X2FkZHIgKmFk ZHIpOworZXh0ZXJuIHZvaWQJCQlpcHY2X3NvY2tfYWNfY2xvc2Uoc3RydWN0 IHNvY2sgKnNrKTsKK2V4dGVybiBpbnQJCQlpbmV0Nl9hY19jaGVjayhzdHJ1 Y3Qgc29jayAqc2ssIHN0cnVjdCBpbjZfYWRkciAqYWRkciwgaW50IGlmaW5k ZXgpOworCitleHRlcm4gaW50CQkJaXB2Nl9kZXZfYWNfaW5jKHN0cnVjdCBu ZXRfZGV2aWNlICpkZXYsCisJCQkJCQlzdHJ1Y3QgaW42X2FkZHIgKmFkZHIp OworZXh0ZXJuIGludAkJCWlwdjZfZGV2X2FjX2RlYyhzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2LAorCQkJCQkJc3RydWN0IGluNl9hZGRyICphZGRyKTsKK2V4 dGVybiBpbnQJCQlpcHY2X2Noa19hY2FzdF9hZGRyKHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYsCisJCQkJCQlzdHJ1Y3QgaW42X2FkZHIgKmFkZHIpOworCisK IC8qIERldmljZSBub3RpZmllciAqLwogZXh0ZXJuIGludCByZWdpc3Rlcl9p bmV0NmFkZHJfbm90aWZpZXIoc3RydWN0IG5vdGlmaWVyX2Jsb2NrICpuYik7 CiBleHRlcm4gaW50IHVucmVnaXN0ZXJfaW5ldDZhZGRyX25vdGlmaWVyKHN0 cnVjdCBub3RpZmllcl9ibG9jayAqbmIpOwpkaWZmIC1ydU4gbGludXgtMi41 LjQ0L2luY2x1ZGUvbmV0L2lmX2luZXQ2LmggbGludXgtMi41LjQ0QUMvaW5j bHVkZS9uZXQvaWZfaW5ldDYuaAotLS0gbGludXgtMi41LjQ0L2luY2x1ZGUv bmV0L2lmX2luZXQ2LmgJRnJpIE9jdCAxOCAyMTowMjozNCAyMDAyCisrKyBs aW51eC0yLjUuNDRBQy9pbmNsdWRlL25ldC9pZl9pbmV0Ni5oCU1vbiBPY3Qg MjggMTI6Mzg6MDkgMjAwMgpAQCAtNjksNiArNjksMjUgQEAKIAlzcGlubG9j a190CQltY2FfbG9jazsKIH07CiAKKy8qIEFueWNhc3Qgc3R1ZmYgKi8KKwor c3RydWN0IGlwdjZfYWNfc29ja2xpc3QKK3sKKwlzdHJ1Y3QgaW42X2FkZHIJ CWFjbF9hZGRyOworCWludAkJCWFjbF9pZmluZGV4OworCXN0cnVjdCBpcHY2 X2FjX3NvY2tsaXN0ICphY2xfbmV4dDsKK307CisKK3N0cnVjdCBpZmFjYWRk cjYKK3sKKwlzdHJ1Y3QgaW42X2FkZHIJCWFjYV9hZGRyOworCXN0cnVjdCBp bmV0Nl9kZXYJKmFjYV9pZGV2OworCXN0cnVjdCBpZmFjYWRkcjYJKmFjYV9u ZXh0OworCWludAkJCWFjYV91c2VyczsKKwlhdG9taWNfdAkJYWNhX3JlZmNu dDsKKwlzcGlubG9ja190CQlhY2FfbG9jazsKK307CisKICNkZWZpbmUJSUZB X0hPU1QJSVBWNl9BRERSX0xPT1BCQUNLCiAjZGVmaW5lCUlGQV9MSU5LCUlQ VjZfQUREUl9MSU5LTE9DQUwKICNkZWZpbmUJSUZBX1NJVEUJSVBWNl9BRERS X1NJVEVMT0NBTApAQCAtOTYsNiArMTE1LDcgQEAKIAogCXN0cnVjdCBpbmV0 Nl9pZmFkZHIJKmFkZHJfbGlzdDsKIAlzdHJ1Y3QgaWZtY2FkZHI2CSptY19s aXN0OworCXN0cnVjdCBpZmFjYWRkcjYJKmFjX2xpc3Q7CiAJcndsb2NrX3QJ CWxvY2s7CiAJYXRvbWljX3QJCXJlZmNudDsKIAlfX3UzMgkJCWlmX2ZsYWdz OwpkaWZmIC1ydU4gbGludXgtMi41LjQ0L25ldC9jb3JlL2Rldi5jIGxpbnV4 LTIuNS40NEFDL25ldC9jb3JlL2Rldi5jCi0tLSBsaW51eC0yLjUuNDQvbmV0 L2NvcmUvZGV2LmMJRnJpIE9jdCAxOCAyMTowMTo1NCAyMDAyCisrKyBsaW51 eC0yLjUuNDRBQy9uZXQvY29yZS9kZXYuYwlNb24gT2N0IDI4IDEyOjM4OjA5 IDIwMDIKQEAgLTU0MSw2ICs1NDEsNTAgQEAKIH0KIAogLyoqCisgKglkZXZf Z2V0YW55IC0gZmluZCBhbnkgZGV2aWNlIHdpdGggZ2l2ZW4gZmxhZ3MKKyAq CUBpZl9mbGFnczogSUZGXyogdmFsdWVzCisgKglAbWFzazogYml0bWFzayBv ZiBiaXRzIGluIGlmX2ZsYWdzIHRvIGNoZWNrCisgKgorICoJU2VhcmNoIGZv ciBhbnkgaW50ZXJmYWNlIHdpdGggdGhlIGdpdmVuIGZsYWdzLiBSZXR1cm5z IE5VTEwgaWYgYSBkZXZpY2UKKyAqCWlzIG5vdCBmb3VuZCBvciBhIHBvaW50 ZXIgdG8gdGhlIGRldmljZS4gVGhlIGRldmljZSByZXR1cm5lZCBoYXMgCisg KgloYWQgYSByZWZlcmVuY2UgYWRkZWQgYW5kIHRoZSBwb2ludGVyIGlzIHNh ZmUgdW50aWwgdGhlIHVzZXIgY2FsbHMKKyAqCWRldl9wdXQgdG8gaW5kaWNh dGUgdGhleSBoYXZlIGZpbmlzaGVkIHdpdGggaXQuCisgKi8KKworc3RydWN0 IG5ldF9kZXZpY2UgKiBkZXZfZ2V0YW55KHVuc2lnbmVkIHNob3J0IGlmX2Zs YWdzLCB1bnNpZ25lZCBzaG9ydCBtYXNrKQoreworCXN0cnVjdCBuZXRfZGV2 aWNlICpkZXY7CisKKwlyZWFkX2xvY2soJmRldl9iYXNlX2xvY2spOworCWRl diA9IF9fZGV2X2dldGFueShpZl9mbGFncywgbWFzayk7CisJaWYgKGRldikK KwkJZGV2X2hvbGQoZGV2KTsKKwlyZWFkX3VubG9jaygmZGV2X2Jhc2VfbG9j ayk7CisJcmV0dXJuIGRldjsKK30KKworLyoqCisgKglfX2Rldl9nZXRhbnkg LSBmaW5kIGFueSBkZXZpY2Ugd2l0aCBnaXZlbiBmbGFncworICoJQGlmX2Zs YWdzOiBJRkZfKiB2YWx1ZXMKKyAqCUBtYXNrOiBiaXRtYXNrIG9mIGJpdHMg aW4gaWZfZmxhZ3MgdG8gY2hlY2sKKyAqCisgKglTZWFyY2ggZm9yIGFueSBp bnRlcmZhY2Ugd2l0aCB0aGUgZ2l2ZW4gZmxhZ3MuIFJldHVybnMgTlVMTCBp ZiBhIGRldmljZQorICoJaXMgbm90IGZvdW5kIG9yIGEgcG9pbnRlciB0byB0 aGUgZGV2aWNlLiBUaGUgY2FsbGVyIG11c3QgaG9sZCBlaXRoZXIKKyAqCXRo ZSBSVE5MIHNlbWFwaG9yZSBvciBAZGV2X2Jhc2VfbG9jay4KKyAqLworCitz dHJ1Y3QgbmV0X2RldmljZSAqX19kZXZfZ2V0YW55KHVuc2lnbmVkIHNob3J0 IGlmX2ZsYWdzLCB1bnNpZ25lZCBzaG9ydCBtYXNrKQoreworCXN0cnVjdCBu ZXRfZGV2aWNlICpkZXY7CisKKwlmb3IgKGRldiA9IGRldl9iYXNlOyBkZXYg IT0gTlVMTDsgZGV2ID0gZGV2LT5uZXh0KSB7CisJCWlmICgoKGRldi0+Zmxh Z3MgXiBpZl9mbGFncykgJiBtYXNrKSA9PSAwKQorCQkJcmV0dXJuIGRldjsK Kwl9CisJcmV0dXJuIE5VTEw7Cit9CisKKy8qKgogICoJZGV2X2FsbG9jX25h bWUgLSBhbGxvY2F0ZSBhIG5hbWUgZm9yIGEgZGV2aWNlCiAgKglAZGV2OiBk ZXZpY2UKICAqCUBuYW1lOiBuYW1lIGZvcm1hdCBzdHJpbmcKZGlmZiAtcnVO IGxpbnV4LTIuNS40NC9uZXQvaXB2Ni9NYWtlZmlsZSBsaW51eC0yLjUuNDRB Qy9uZXQvaXB2Ni9NYWtlZmlsZQotLS0gbGludXgtMi41LjQ0L25ldC9pcHY2 L01ha2VmaWxlCUZyaSBPY3QgMTggMjE6MDI6MjcgMjAwMgorKysgbGludXgt Mi41LjQ0QUMvbmV0L2lwdjYvTWFrZWZpbGUJTW9uIE9jdCAyOCAxMjozODow OSAyMDAyCkBAIC02LDcgKzYsNyBAQAogCiBvYmotJChDT05GSUdfSVBWNikg Kz0gaXB2Ni5vCiAKLWlwdjYtb2JqcyA6PQlhZl9pbmV0Ni5vIGlwNl9vdXRw dXQubyBpcDZfaW5wdXQubyBhZGRyY29uZi5vIHNpdC5vIFwKK2lwdjYtb2Jq cyA6PQlhZl9pbmV0Ni5vIGFueWNhc3QubyBpcDZfb3V0cHV0Lm8gaXA2X2lu cHV0Lm8gYWRkcmNvbmYubyBzaXQubyBcCiAJCXJvdXRlLm8gaXA2X2ZpYi5v IGlwdjZfc29ja2dsdWUubyBuZGlzYy5vIHVkcC5vIHJhdy5vIFwKIAkJcHJv dG9jb2wubyBpY21wLm8gbWNhc3QubyByZWFzc2VtYmx5Lm8gdGNwX2lwdjYu byBcCiAJCWV4dGhkcnMubyBzeXNjdGxfbmV0X2lwdjYubyBkYXRhZ3JhbS5v IHByb2MubyBcCmRpZmYgLXJ1TiBsaW51eC0yLjUuNDQvbmV0L2lwdjYvYWRk cmNvbmYuYyBsaW51eC0yLjUuNDRBQy9uZXQvaXB2Ni9hZGRyY29uZi5jCi0t LSBsaW51eC0yLjUuNDQvbmV0L2lwdjYvYWRkcmNvbmYuYwlGcmkgT2N0IDE4 IDIxOjAyOjMxIDIwMDIKKysrIGxpbnV4LTIuNS40NEFDL25ldC9pcHY2L2Fk ZHJjb25mLmMJTW9uIE9jdCAyOCAxMjo0OTowMyAyMDAyCkBAIC0xMzcsMjEg KzEzNywxNSBAQAogCiBpbnQgaXB2Nl9hZGRyX3R5cGUoc3RydWN0IGluNl9h ZGRyICphZGRyKQogeworCWludCB0eXBlOwogCXUzMiBzdDsKIAogCXN0ID0g YWRkci0+czZfYWRkcjMyWzBdOwogCi0JLyogQ29uc2lkZXIgYWxsIGFkZHJl c3NlcyB3aXRoIHRoZSBmaXJzdCB0aHJlZSBiaXRzIGRpZmZlcmVudCBvZgot CSAgIDAwMCBhbmQgMTExIGFzIHVuaWNhc3RzLgotCSAqLwotCWlmICgoc3Qg JiBodG9ubCgweEUwMDAwMDAwKSkgIT0gaHRvbmwoMHgwMDAwMDAwMCkgJiYK LQkgICAgKHN0ICYgaHRvbmwoMHhFMDAwMDAwMCkpICE9IGh0b25sKDB4RTAw MDAwMDApKQotCQlyZXR1cm4gSVBWNl9BRERSX1VOSUNBU1Q7Ci0KLQlpZiAo KHN0ICYgaHRvbmwoMHhGRjAwMDAwMCkpID09IGh0b25sKDB4RkYwMDAwMDAp KSB7Ci0JCWludCB0eXBlID0gSVBWNl9BRERSX01VTFRJQ0FTVDsKKwlpZiAo KHN0ICYgX19jb25zdGFudF9odG9ubCgweEZGMDAwMDAwKSkgPT0gX19jb25z dGFudF9odG9ubCgweEZGMDAwMDAwKSkgeworCQl0eXBlID0gSVBWNl9BRERS X01VTFRJQ0FTVDsKIAotCQlzd2l0Y2goKHN0ICYgaHRvbmwoMHgwMEZGMDAw MCkpKSB7CisJCXN3aXRjaCgoc3QgJiBfX2NvbnN0YW50X2h0b25sKDB4MDBG RjAwMDApKSkgewogCQkJY2FzZSBfX2NvbnN0YW50X2h0b25sKDB4MDAwMTAw MDApOgogCQkJCXR5cGUgfD0gSVBWNl9BRERSX0xPT1BCQUNLOwogCQkJCWJy ZWFrOwpAQCAtMTY2LDI5ICsxNjAsNTMgQEAKIAkJfTsKIAkJcmV0dXJuIHR5 cGU7CiAJfQorCS8qIGNoZWNrIGZvciByZXNlcnZlZCBhbnljYXN0IGFkZHJl c3NlcyAqLworCQorCWlmICgoc3QgJiBfX2NvbnN0YW50X2h0b25sKDB4RTAw MDAwMDApKSAmJgorCSAgICAoKGFkZHItPnM2X2FkZHIzMlsyXSA9PSBfX2Nv bnN0YW50X2h0b25sKDB4RkRGRkZGRkYpICYmCisJICAgIChhZGRyLT5zNl9h ZGRyMzJbM10gfCBfX2NvbnN0YW50X2h0b25sKDB4N0YpKSA9PSAodTMyKX4w KSB8fAorCSAgICAoYWRkci0+czZfYWRkcjMyWzJdID09IDAgJiYgYWRkci0+ czZfYWRkcjMyWzNdID09IDApKSkKKwkJdHlwZSA9IElQVjZfQUREUl9BTllD QVNUOworCWVsc2UKKwkJdHlwZSA9IElQVjZfQUREUl9VTklDQVNUOworCisJ LyogQ29uc2lkZXIgYWxsIGFkZHJlc3NlcyB3aXRoIHRoZSBmaXJzdCB0aHJl ZSBiaXRzIGRpZmZlcmVudCBvZgorCSAgIDAwMCBhbmQgMTExIGFzIGZpbmlz aGVkLgorCSAqLworCWlmICgoc3QgJiBfX2NvbnN0YW50X2h0b25sKDB4RTAw MDAwMDApKSAhPSBfX2NvbnN0YW50X2h0b25sKDB4MDAwMDAwMDApICYmCisJ ICAgIChzdCAmIF9fY29uc3RhbnRfaHRvbmwoMHhFMDAwMDAwMCkpICE9IF9f Y29uc3RhbnRfaHRvbmwoMHhFMDAwMDAwMCkpCisJCXJldHVybiB0eXBlOwog CQotCWlmICgoc3QgJiBodG9ubCgweEZGQzAwMDAwKSkgPT0gaHRvbmwoMHhG RTgwMDAwMCkpCi0JCXJldHVybiAoSVBWNl9BRERSX0xJTktMT0NBTCB8IElQ VjZfQUREUl9VTklDQVNUKTsKKwlpZiAoKHN0ICYgX19jb25zdGFudF9odG9u bCgweEZGQzAwMDAwKSkgPT0gX19jb25zdGFudF9odG9ubCgweEZFODAwMDAw KSkKKwkJcmV0dXJuIChJUFY2X0FERFJfTElOS0xPQ0FMIHwgdHlwZSk7CiAK LQlpZiAoKHN0ICYgaHRvbmwoMHhGRkMwMDAwMCkpID09IGh0b25sKDB4RkVD MDAwMDApKQotCQlyZXR1cm4gKElQVjZfQUREUl9TSVRFTE9DQUwgfCBJUFY2 X0FERFJfVU5JQ0FTVCk7CisJaWYgKChzdCAmIF9fY29uc3RhbnRfaHRvbmwo MHhGRkMwMDAwMCkpID09IF9fY29uc3RhbnRfaHRvbmwoMHhGRUMwMDAwMCkp CisJCXJldHVybiAoSVBWNl9BRERSX1NJVEVMT0NBTCB8IHR5cGUpOwogCiAJ aWYgKChhZGRyLT5zNl9hZGRyMzJbMF0gfCBhZGRyLT5zNl9hZGRyMzJbMV0p ID09IDApIHsKIAkJaWYgKGFkZHItPnM2X2FkZHIzMlsyXSA9PSAwKSB7Ci0J CQlpZiAoYWRkci0+czZfYWRkcjMyWzNdID09IDApCisJCQlpZiAoYWRkci0+ aW42X3UudTZfYWRkcjMyWzNdID09IDApCiAJCQkJcmV0dXJuIElQVjZfQURE Ul9BTlk7CiAKLQkJCWlmIChhZGRyLT5zNl9hZGRyMzJbM10gPT0gaHRvbmwo MHgwMDAwMDAwMSkpCi0JCQkJcmV0dXJuIChJUFY2X0FERFJfTE9PUEJBQ0sg fCBJUFY2X0FERFJfVU5JQ0FTVCk7CisJCQlpZiAoYWRkci0+czZfYWRkcjMy WzNdID09IF9fY29uc3RhbnRfaHRvbmwoMHgwMDAwMDAwMSkpCisJCQkJcmV0 dXJuIChJUFY2X0FERFJfTE9PUEJBQ0sgfCB0eXBlKTsKIAotCQkJcmV0dXJu IChJUFY2X0FERFJfQ09NUEFUdjQgfCBJUFY2X0FERFJfVU5JQ0FTVCk7CisJ CQlyZXR1cm4gKElQVjZfQUREUl9DT01QQVR2NCB8IHR5cGUpOwogCQl9CiAK LQkJaWYgKGFkZHItPnM2X2FkZHIzMlsyXSA9PSBodG9ubCgweDAwMDBmZmZm KSkKKwkJaWYgKGFkZHItPnM2X2FkZHIzMlsyXSA9PSBfX2NvbnN0YW50X2h0 b25sKDB4MDAwMGZmZmYpKQogCQkJcmV0dXJuIElQVjZfQUREUl9NQVBQRUQ7 CiAJfQogCi0JcmV0dXJuIElQVjZfQUREUl9SRVNFUlZFRDsKKwlzdCAmPSBf X2NvbnN0YW50X2h0b25sKDB4RkYwMDAwMDApOworCWlmIChzdCA9PSAwKQor CQlyZXR1cm4gSVBWNl9BRERSX1JFU0VSVkVEOworCXN0ICY9IF9fY29uc3Rh bnRfaHRvbmwoMHhGRTAwMDAwMCk7CisJaWYgKHN0ID09IF9fY29uc3RhbnRf aHRvbmwoMHgwMjAwMDAwMCkpCisJCXJldHVybiBJUFY2X0FERFJfUkVTRVJW RUQ7CS8qIGZvciBOU0FQICovCisJaWYgKHN0ID09IF9fY29uc3RhbnRfaHRv bmwoMHgwNDAwMDAwMCkpCisJCXJldHVybiBJUFY2X0FERFJfUkVTRVJWRUQ7 CS8qIGZvciBJUFggKi8KKwlyZXR1cm4gdHlwZTsKIH0KIAogc3RhdGljIHZv aWQgYWRkcmNvbmZfZGVsX3RpbWVyKHN0cnVjdCBpbmV0Nl9pZmFkZHIgKmlm cCkKQEAgLTIyNCw3ICsyNDIsNiBAQAogCWFkZF90aW1lcigmaWZwLT50aW1l cik7CiB9CiAKLQogLyogTm9ib2R5IHJlZmVycyB0byB0aGlzIGRldmljZSwg d2UgbWF5IGRlc3Ryb3kgaXQuICovCiAKIHZvaWQgaW42X2Rldl9maW5pc2hf ZGVzdHJveShzdHJ1Y3QgaW5ldDZfZGV2ICppZGV2KQpAQCAtMzAzLDI0ICsz MjAsOTEgQEAKIAlyZXR1cm4gaWRldjsKIH0KIAordm9pZCBpcHY2X2FkZHJf cHJlZml4KHN0cnVjdCBpbjZfYWRkciAqcHJlZml4LAorCXN0cnVjdCBpbjZf YWRkciAqYWRkciwgaW50IHByZWZpeF9sZW4pCit7CisJdW5zaWduZWQgbG9u ZyBtYXNrOworCWludCBuY29weSwgbmJpdHM7CisKKwltZW1zZXQocHJlZml4 LCAwLCBzaXplb2YoKnByZWZpeCkpOworCisJaWYgKHByZWZpeF9sZW4gPD0g MCkKKwkJcmV0dXJuOworCWlmIChwcmVmaXhfbGVuID4gMTI4KQorCQlwcmVm aXhfbGVuID0gMTI4OworCisJbmNvcHkgPSBwcmVmaXhfbGVuIC8gMzI7CisJ c3dpdGNoIChuY29weSkgeworCWNhc2UgNDoJcHJlZml4LT5zNl9hZGRyMzJb M10gPSBhZGRyLT5zNl9hZGRyMzJbM107CisJY2FzZSAzOglwcmVmaXgtPnM2 X2FkZHIzMlsyXSA9IGFkZHItPnM2X2FkZHIzMlsyXTsKKwljYXNlIDI6CXBy ZWZpeC0+czZfYWRkcjMyWzFdID0gYWRkci0+czZfYWRkcjMyWzFdOworCWNh c2UgMToJcHJlZml4LT5zNl9hZGRyMzJbMF0gPSBhZGRyLT5zNl9hZGRyMzJb MF07CisJY2FzZSAwOglicmVhazsKKwl9CisJbmJpdHMgPSBwcmVmaXhfbGVu ICUgMzI7CisJaWYgKG5iaXRzID09IDApCisJCXJldHVybjsKKworCW1hc2sg PSB+KCgxIDw8ICgzMiAtIG5iaXRzKSkgLSAxKTsKKwltYXNrID0gaHRvbmwo bWFzayk7CisKKwlwcmVmaXgtPnM2X2FkZHIzMltuY29weV0gPSBhZGRyLT5z Nl9hZGRyMzJbbmNvcHldICYgbWFzazsKK30KKworCitzdGF0aWMgdm9pZCBk ZXZfZm9yd2FyZF9jaGFuZ2Uoc3RydWN0IGluZXQ2X2RldiAqaWRldikKK3sK KwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2OworCXN0cnVjdCBpbmV0Nl9pZmFk ZHIgKmlmYTsKKwlzdHJ1Y3QgaW42X2FkZHIgYWRkcjsKKworCWlmICghaWRl dikKKwkJcmV0dXJuOworCWRldiA9IGlkZXYtPmRldjsKKwlpZiAoZGV2ICYm IChkZXYtPmZsYWdzICYgSUZGX01VTFRJQ0FTVCkpIHsKKwkJaXB2Nl9hZGRy X2FsbF9yb3V0ZXJzKCZhZGRyKTsKKwkKKwkJaWYgKGlkZXYtPmNuZi5mb3J3 YXJkaW5nKQorCQkJaXB2Nl9kZXZfbWNfaW5jKGRldiwgJmFkZHIpOworCQll bHNlCisJCQlpcHY2X2Rldl9tY19kZWMoZGV2LCAmYWRkcik7CisJfQorCWZv ciAoaWZhPWlkZXYtPmFkZHJfbGlzdDsgaWZhOyBpZmE9aWZhLT5pZl9uZXh0 KSB7CisJCWlwdjZfYWRkcl9wcmVmaXgoJmFkZHIsICZpZmEtPmFkZHIsIGlm YS0+cHJlZml4X2xlbik7CisJCWlmIChhZGRyLnM2X2FkZHIzMlswXSA9PSAw ICYmIGFkZHIuczZfYWRkcjMyWzFdID09IDAgJiYKKwkJICAgIGFkZHIuczZf YWRkcjMyWzJdID09IDAgJiYgYWRkci5zNl9hZGRyMzJbM10gPT0gMCkKKwkJ CWNvbnRpbnVlOworCQlpZiAoaWRldi0+Y25mLmZvcndhcmRpbmcpCisJCQlp cHY2X2Rldl9hY19pbmMoaWRldi0+ZGV2LCAmYWRkcik7CisJCWVsc2UKKwkJ CWlwdjZfZGV2X2FjX2RlYyhpZGV2LT5kZXYsICZhZGRyKTsKKwl9Cit9CisK Kwogc3RhdGljIHZvaWQgYWRkcmNvbmZfZm9yd2FyZF9jaGFuZ2Uoc3RydWN0 IGluZXQ2X2RldiAqaWRldikKIHsKIAlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 OwogCi0JaWYgKGlkZXYpCisJaWYgKGlkZXYpIHsKKwkJZGV2X2ZvcndhcmRf Y2hhbmdlKGlkZXYpOwogCQlyZXR1cm47CisJfQogCiAJcmVhZF9sb2NrKCZk ZXZfYmFzZV9sb2NrKTsKIAlmb3IgKGRldj1kZXZfYmFzZTsgZGV2OyBkZXY9 ZGV2LT5uZXh0KSB7CiAJCXJlYWRfbG9jaygmYWRkcmNvbmZfbG9jayk7CiAJ CWlkZXYgPSBfX2luNl9kZXZfZ2V0KGRldik7Ci0JCWlmIChpZGV2KQorCQlp ZiAoaWRldikgewogCQkJaWRldi0+Y25mLmZvcndhcmRpbmcgPSBpcHY2X2Rl dmNvbmYuZm9yd2FyZGluZzsKKwkJCWRldl9mb3J3YXJkX2NoYW5nZShpZGV2 KTsKKwkJfQogCQlyZWFkX3VubG9jaygmYWRkcmNvbmZfbG9jayk7CiAJfQog CXJlYWRfdW5sb2NrKCZkZXZfYmFzZV9sb2NrKTsKIH0KIAorCiAvKiBOb2Jv ZHkgcmVmZXJzIHRvIHRoaXMgaWZhZGRyLCBkZXN0cm95IGl0ICovCiAKIHZv aWQgaW5ldDZfaWZhX2ZpbmlzaF9kZXN0cm95KHN0cnVjdCBpbmV0Nl9pZmFk ZHIgKmlmcCkKQEAgLTQ1OCwyOSArNTQyLDIwIEBACiAgKgkJYW4gYWRkcmVz cyBvZiB0aGUgYXR0YWNoZWQgaW50ZXJmYWNlIAogICoJaWlpKQlkb24ndCB1 c2UgZGVwcmVjYXRlZCBhZGRyZXNzZXMKICAqLwotaW50IGlwdjZfZ2V0X3Nh ZGRyKHN0cnVjdCBkc3RfZW50cnkgKmRzdCwKLQkJICAgc3RydWN0IGluNl9h ZGRyICpkYWRkciwgc3RydWN0IGluNl9hZGRyICpzYWRkcikKK2ludCBpcHY2 X2Rldl9nZXRfc2FkZHIoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwKKwkJICAg c3RydWN0IGluNl9hZGRyICpkYWRkciwgc3RydWN0IGluNl9hZGRyICpzYWRk ciwgaW50IG9ubGluaykKIHsKLQlpbnQgc2NvcGU7CiAJc3RydWN0IGluZXQ2 X2lmYWRkciAqaWZwID0gTlVMTDsKIAlzdHJ1Y3QgaW5ldDZfaWZhZGRyICpt YXRjaCA9IE5VTEw7Ci0Jc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IE5VTEw7 CiAJc3RydWN0IGluZXQ2X2RldiAqaWRldjsKLQlzdHJ1Y3QgcnQ2X2luZm8g KnJ0OworCWludCBzY29wZTsKIAlpbnQgZXJyOwogCi0JcnQgPSAoc3RydWN0 IHJ0Nl9pbmZvICopIGRzdDsKLQlpZiAocnQpCi0JCWRldiA9IHJ0LT5ydDZp X2RldjsKIAotCXNjb3BlID0gaXB2Nl9hZGRyX3Njb3BlKGRhZGRyKTsKLQlp ZiAocnQgJiYgKHJ0LT5ydDZpX2ZsYWdzICYgUlRGX0FMTE9OTElOSykpIHsK LQkJLyoKLQkJICoJcm91dGUgZm9yIHRoZSAiYWxsIGRlc3RpbmF0aW9ucyBv biBsaW5rIiBydWxlCi0JCSAqCXdoZW4gbm8gcm91dGVycyBhcmUgcHJlc2Vu dAotCQkgKi8KKwlpZiAoIW9ubGluaykKKwkJc2NvcGUgPSBpcHY2X2FkZHJf c2NvcGUoZGFkZHIpOworCWVsc2UKIAkJc2NvcGUgPSBJRkFfTElOSzsKLQl9 CiAKIAkvKgogCSAqCWtub3duIGRldgpAQCAtNTY4LDYgKzY0MywyNCBAQAog CXJldHVybiBlcnI7CiB9CiAKKworaW50IGlwdjZfZ2V0X3NhZGRyKHN0cnVj dCBkc3RfZW50cnkgKmRzdCwKKwkJICAgc3RydWN0IGluNl9hZGRyICpkYWRk ciwgc3RydWN0IGluNl9hZGRyICpzYWRkcikKK3sKKwlzdHJ1Y3QgcnQ2X2lu Zm8gKnJ0OworCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSBOVUxMOworCWlu dCBvbmxpbms7CisKKwlydCA9IChzdHJ1Y3QgcnQ2X2luZm8gKikgZHN0Owor CWlmIChydCkKKwkJZGV2ID0gcnQtPnJ0NmlfZGV2OworCisJb25saW5rID0g KHJ0ICYmIChydC0+cnQ2aV9mbGFncyAmIFJURl9BTExPTkxJTkspKTsKKwor CXJldHVybiBpcHY2X2Rldl9nZXRfc2FkZHIoZGV2LCBkYWRkciwgc2FkZHIs IG9ubGluayk7Cit9CisKKwogaW50IGlwdjZfZ2V0X2xsYWRkcihzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaW42X2FkZHIgKmFkZHIpCiB7CiAJ c3RydWN0IGluZXQ2X2RldiAqaWRldjsKQEAgLTY2MCw3ICs3NTMsNyBAQAog CiAvKiBKb2luIHRvIHNvbGljaXRlZCBhZGRyIG11bHRpY2FzdCBncm91cC4g Ki8KIAotc3RhdGljIHZvaWQgYWRkcmNvbmZfam9pbl9zb2xpY3Qoc3RydWN0 IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGluNl9hZGRyICphZGRyKQordm9p ZCBhZGRyY29uZl9qb2luX3NvbGljdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 LCBzdHJ1Y3QgaW42X2FkZHIgKmFkZHIpCiB7CiAJc3RydWN0IGluNl9hZGRy IG1hZGRyOwogCkBAIC02NzEsNyArNzY0LDcgQEAKIAlpcHY2X2Rldl9tY19p bmMoZGV2LCAmbWFkZHIpOwogfQogCi1zdGF0aWMgdm9pZCBhZGRyY29uZl9s ZWF2ZV9zb2xpY3Qoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlu Nl9hZGRyICphZGRyKQordm9pZCBhZGRyY29uZl9sZWF2ZV9zb2xpY3Qoc3Ry dWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGluNl9hZGRyICphZGRyKQog ewogCXN0cnVjdCBpbjZfYWRkciBtYWRkcjsKIApAQCAtMTU1NCw2ICsxNjQ3 LDE1IEBACiAJCWFkZHJjb25mX21vZF90aW1lcihpZnAsIEFDX1JTLCBpZnAt PmlkZXYtPmNuZi5ydHJfc29saWNpdF9pbnRlcnZhbCk7CiAJCXNwaW5fdW5s b2NrX2JoKCZpZnAtPmxvY2spOwogCX0KKworCWlmIChpZnAtPmlkZXYtPmNu Zi5mb3J3YXJkaW5nKSB7CisJCXN0cnVjdCBpbjZfYWRkciBhZGRyOworCisJ CWlwdjZfYWRkcl9wcmVmaXgoJmFkZHIsICZpZnAtPmFkZHIsIGlmcC0+cHJl Zml4X2xlbik7CisJCWlmIChhZGRyLnM2X2FkZHIzMlswXSB8fCBhZGRyLnM2 X2FkZHIzMlsxXSB8fAorCQkgICAgYWRkci5zNl9hZGRyMzJbMl0gfHwgYWRk ci5zNl9hZGRyMzJbM10pCisJCQlpcHY2X2Rldl9hY19pbmMoaWZwLT5pZGV2 LT5kZXYsICZhZGRyKTsKKwl9CiB9CiAKICNpZmRlZiBDT05GSUdfUFJPQ19G UwpAQCAtMTg1Myw2ICsxOTU1LDE0IEBACiAJCWJyZWFrOwogCWNhc2UgUlRN X0RFTEFERFI6CiAJCWFkZHJjb25mX2xlYXZlX3NvbGljdChpZnAtPmlkZXYt PmRldiwgJmlmcC0+YWRkcik7CisJCWlmIChpZnAtPmlkZXYtPmNuZi5mb3J3 YXJkaW5nKSB7CisJCQlzdHJ1Y3QgaW42X2FkZHIgYWRkcjsKKworCQkJaXB2 Nl9hZGRyX3ByZWZpeCgmYWRkciwgJmlmcC0+YWRkciwgaWZwLT5wcmVmaXhf bGVuKTsKKwkJCWlmIChhZGRyLnM2X2FkZHIzMlswXSB8fCBhZGRyLnM2X2Fk ZHIzMlsxXSB8fAorCQkJICAgIGFkZHIuczZfYWRkcjMyWzJdIHx8IGFkZHIu czZfYWRkcjMyWzNdKQorCQkJCWlwdjZfZGV2X2FjX2RlYyhpZnAtPmlkZXYt PmRldiwgJmFkZHIpOworCQl9CiAJCWlmICghaXB2Nl9jaGtfYWRkcigmaWZw LT5hZGRyLCBOVUxMKSkKIAkJCWlwNl9ydF9hZGRyX2RlbCgmaWZwLT5hZGRy LCBpZnAtPmlkZXYtPmRldik7CiAJCWJyZWFrOwpAQCAtMTg3NSwxMSArMTk4 NSw3IEBACiAJCXN0cnVjdCBpbmV0Nl9kZXYgKmlkZXYgPSBOVUxMOwogCiAJ CWlmICh2YWxwICE9ICZpcHY2X2RldmNvbmYuZm9yd2FyZGluZykgewotCQkJ c3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IGRldl9nZXRfYnlfaW5kZXgoY3Rs LT5jdGxfbmFtZSk7Ci0JCQlpZiAoZGV2KSB7Ci0JCQkJaWRldiA9IGluNl9k ZXZfZ2V0KGRldik7Ci0JCQkJZGV2X3B1dChkZXYpOwotCQkJfQorCQkJaWRl diA9IChzdHJ1Y3QgaW5ldDZfZGV2ICopY3RsLT5leHRyYTE7CiAJCQlpZiAo aWRldiA9PSBOVUxMKQogCQkJCXJldHVybiByZXQ7CiAJCX0gZWxzZQpAQCAt MTg4OSw4ICsxOTk1LDYgQEAKIAogCQlpZiAoKnZhbHApCiAJCQlydDZfcHVy Z2VfZGZsdF9yb3V0ZXJzKDApOwotCQlpZiAoaWRldikKLQkJCWluNl9kZXZf cHV0KGlkZXYpOwogCX0KIAogICAgICAgICByZXR1cm4gcmV0OwpAQCAtMTk2 Nyw2ICsyMDcxLDcgQEAKIAlmb3IgKGk9MDsgaTxzaXplb2YodC0+YWRkcmNv bmZfdmFycykvc2l6ZW9mKHQtPmFkZHJjb25mX3ZhcnNbMF0pLTE7IGkrKykg ewogCQl0LT5hZGRyY29uZl92YXJzW2ldLmRhdGEgKz0gKGNoYXIqKXAgLSAo Y2hhciopJmlwdjZfZGV2Y29uZjsKIAkJdC0+YWRkcmNvbmZfdmFyc1tpXS5k ZSA9IE5VTEw7CisJCXQtPmFkZHJjb25mX3ZhcnNbaV0uZXh0cmExID0gaWRl djsgLyogZW1iZWRkZWQ7IG5vIHJlZiAqLwogCX0KIAlpZiAoZGV2KSB7CiAJ CXQtPmFkZHJjb25mX2RldlswXS5wcm9jbmFtZSA9IGRldi0+bmFtZTsKZGlm ZiAtcnVOIGxpbnV4LTIuNS40NC9uZXQvaXB2Ni9hZl9pbmV0Ni5jIGxpbnV4 LTIuNS40NEFDL25ldC9pcHY2L2FmX2luZXQ2LmMKLS0tIGxpbnV4LTIuNS40 NC9uZXQvaXB2Ni9hZl9pbmV0Ni5jCUZyaSBPY3QgMTggMjE6MDE6NTcgMjAw MgorKysgbGludXgtMi41LjQ0QUMvbmV0L2lwdjYvYWZfaW5ldDYuYwlNb24g T2N0IDI4IDEyOjM4OjA5IDIwMDIKQEAgLTc2LDYgKzc2LDcgQEAKIC8qIElQ djYgcHJvY2ZzIGdvb2RpZXMuLi4gKi8KIAogI2lmZGVmIENPTkZJR19QUk9D X0ZTCitleHRlcm4gaW50IGFueWNhc3Q2X2dldF9pbmZvKGNoYXIgKiwgY2hh ciAqKiwgb2ZmX3QsIGludCk7CiBleHRlcm4gaW50IHJhdzZfZ2V0X2luZm8o Y2hhciAqLCBjaGFyICoqLCBvZmZfdCwgaW50KTsKIGV4dGVybiBpbnQgdGNw Nl9nZXRfaW5mbyhjaGFyICosIGNoYXIgKiosIG9mZl90LCBpbnQpOwogZXh0 ZXJuIGludCB1ZHA2X2dldF9pbmZvKGNoYXIgKiwgY2hhciAqKiwgb2ZmX3Qs IGludCk7CkBAIC0zODAsNiArMzgxLDkgQEAKIAkvKiBGcmVlIG1jIGxpc3Rz ICovCiAJaXB2Nl9zb2NrX21jX2Nsb3NlKHNrKTsKIAorCS8qIEZyZWUgYWMg bGlzdHMgKi8KKwlpcHY2X3NvY2tfYWNfY2xvc2Uoc2spOworCiAJcmV0dXJu IGluZXRfcmVsZWFzZShzb2NrKTsKIH0KIApAQCAtNjk0LDYgKzY5OCw4IEBA CiAJCWdvdG8gcHJvY19zb2Nrc3RhdDZfZmFpbDsKIAlpZiAoIXByb2NfbmV0 X2NyZWF0ZSgic25tcDYiLCAwLCBhZmluZXQ2X2dldF9zbm1wKSkKIAkJZ290 byBwcm9jX3NubXA2X2ZhaWw7CisJaWYgKCFwcm9jX25ldF9jcmVhdGUoImFu eWNhc3Q2IiwgMCwgYW55Y2FzdDZfZ2V0X2luZm8pKQorCQlnb3RvIHByb2Nf YW55Y2FzdDZfZmFpbDsKICNlbmRpZgogCWlwdjZfbmV0ZGV2X25vdGlmX2lu aXQoKTsKIAlpcHY2X3BhY2tldF9pbml0KCk7CkBAIC03MDksNiArNzE1LDgg QEAKIAlyZXR1cm4gMDsKIAogI2lmZGVmIENPTkZJR19QUk9DX0ZTCitwcm9j X2FueWNhc3Q2X2ZhaWw6CisJcHJvY19uZXRfcmVtb3ZlKCJhbnljYXN0NiIp OwogcHJvY19zbm1wNl9mYWlsOgogCXByb2NfbmV0X3JlbW92ZSgic29ja3N0 YXQ2Iik7CiBwcm9jX3NvY2tzdGF0Nl9mYWlsOgpAQCAtNzQ0LDYgKzc1Miw3 IEBACiAJcHJvY19uZXRfcmVtb3ZlKCJ1ZHA2Iik7CiAJcHJvY19uZXRfcmVt b3ZlKCJzb2Nrc3RhdDYiKTsKIAlwcm9jX25ldF9yZW1vdmUoInNubXA2Iik7 CisJcHJvY19uZXRfcmVtb3ZlKCJhbnljYXN0NiIpOwogI2VuZGlmCiAJLyog Q2xlYW51cCBjb2RlIHBhcnRzLiAqLwogCXNpdF9jbGVhbnVwKCk7CmRpZmYg LXJ1TiBsaW51eC0yLjUuNDQvbmV0L2lwdjYvYW55Y2FzdC5jIGxpbnV4LTIu NS40NEFDL25ldC9pcHY2L2FueWNhc3QuYwotLS0gbGludXgtMi41LjQ0L25l dC9pcHY2L2FueWNhc3QuYwlXZWQgRGVjIDMxIDE2OjAwOjAwIDE5NjkKKysr IGxpbnV4LTIuNS40NEFDL25ldC9pcHY2L2FueWNhc3QuYwlNb24gT2N0IDI4 IDEzOjI4OjA3IDIwMDIKQEAgLTAsMCArMSw0ODkgQEAKKy8qCisgKglBbnlj YXN0IHN1cHBvcnQgZm9yIElQdjYKKyAqCUxpbnV4IElORVQ2IGltcGxlbWVu dGF0aW9uIAorICoKKyAqCUF1dGhvcnM6CisgKglEYXZpZCBMIFN0ZXZlbnMg KGRsc3RldmVuc0B1cy5pYm0uY29tKQorICoKKyAqCWJhc2VkIGhlYXZpbHkg b24gbmV0L2lwdjYvbWNhc3QuYworICoKKyAqCVRoaXMgcHJvZ3JhbSBpcyBm cmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IK KyAqICAgICAgbW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05V IEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqICAgICAgYXMgcHVibGlzaGVk IGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJz aW9uCisgKiAgICAgIDIgb2YgdGhlIExpY2Vuc2UsIG9yIChhdCB5b3VyIG9w dGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKi8KKworI2luY2x1ZGUgPGxp bnV4L2NvbmZpZy5oPgorI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgorI2lu Y2x1ZGUgPGxpbnV4L2Vycm5vLmg+CisjaW5jbHVkZSA8bGludXgvdHlwZXMu aD4KKyNpbmNsdWRlIDxsaW51eC9yYW5kb20uaD4KKyNpbmNsdWRlIDxsaW51 eC9zdHJpbmcuaD4KKyNpbmNsdWRlIDxsaW51eC9zb2NrZXQuaD4KKyNpbmNs dWRlIDxsaW51eC9zb2NraW9zLmg+CisjaW5jbHVkZSA8bGludXgvc2NoZWQu aD4KKyNpbmNsdWRlIDxsaW51eC9uZXQuaD4KKyNpbmNsdWRlIDxsaW51eC9p bjYuaD4KKyNpbmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4KKyNpbmNsdWRl IDxsaW51eC9pZl9hcnAuaD4KKyNpbmNsdWRlIDxsaW51eC9yb3V0ZS5oPgor I2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KKyNpbmNsdWRlIDxsaW51eC9wcm9j X2ZzLmg+CisKKyNpbmNsdWRlIDxuZXQvc29jay5oPgorI2luY2x1ZGUgPG5l dC9zbm1wLmg+CisKKyNpbmNsdWRlIDxuZXQvaXB2Ni5oPgorI2luY2x1ZGUg PG5ldC9wcm90b2NvbC5oPgorI2luY2x1ZGUgPG5ldC9pZl9pbmV0Ni5oPgor I2luY2x1ZGUgPG5ldC9uZGlzYy5oPgorI2luY2x1ZGUgPG5ldC9hZGRyY29u Zi5oPgorI2luY2x1ZGUgPG5ldC9pcDZfcm91dGUuaD4KKworI2luY2x1ZGUg PG5ldC9jaGVja3N1bS5oPgorCisvKiBCaWcgYWMgbGlzdCBsb2NrIGZvciBh bGwgdGhlIHNvY2tldHMgKi8KK3N0YXRpYyByd2xvY2tfdCBpcHY2X3NrX2Fj X2xvY2sgPSBSV19MT0NLX1VOTE9DS0VEOworCisvKiBYWFggaXA2X2FkZHJf bWF0Y2goKSBhbmQgaXA2X29ubGluaygpIHJlYWxseSBiZWxvbmcgaW4gbmV0 L2NvcmUuYyAqLworCitzdGF0aWMgaW50CitpcDZfYWRkcl9tYXRjaChzdHJ1 Y3QgaW42X2FkZHIgKmFkZHIxLCBzdHJ1Y3QgaW42X2FkZHIgKmFkZHIyLCBp bnQgcHJlZml4KQoreworCV9fdTMyCW1hc2s7CisJaW50CWk7CisKKwlpZiAo cHJlZml4ID4gMTI4IHx8IHByZWZpeCA8IDApCisJCXJldHVybiAwOworCWlm IChwcmVmaXggPT0gMCkKKwkJcmV0dXJuIDE7CisJZm9yIChpPTA7IGk8NDsg KytpKSB7CisJCWlmIChwcmVmaXggPj0gMzIpCisJCQltYXNrID0gfjA7CisJ CWVsc2UKKwkJCW1hc2sgPSBodG9ubCh+MCA8PCAoMzIgLSBwcmVmaXgpKTsK KwkJaWYgKChhZGRyMS0+czZfYWRkcjMyW2ldIF4gYWRkcjItPnM2X2FkZHIz MltpXSkgJiBtYXNrKQorCQkJcmV0dXJuIDA7CisJCXByZWZpeCAtPSAzMjsK KwkJaWYgKHByZWZpeCA8PSAwKQorCQkJYnJlYWs7CisJfQorCXJldHVybiAx OworfQorCitzdGF0aWMgaW50CitpcDZfb25saW5rKHN0cnVjdCBpbjZfYWRk ciAqYWRkciwgc3RydWN0IG5ldF9kZXZpY2UgKmRldikKK3sKKwlzdHJ1Y3Qg aW5ldDZfZGV2CSppZGV2OworCXN0cnVjdCBpbmV0Nl9pZmFkZHIJKmlmYTsK KwlpbnQJb25saW5rOworCisJb25saW5rID0gMDsKKwlyZWFkX2xvY2soJmFk ZHJjb25mX2xvY2spOworCWlkZXYgPSBfX2luNl9kZXZfZ2V0KGRldik7CisJ aWYgKGlkZXYpIHsKKwkJcmVhZF9sb2NrX2JoKCZpZGV2LT5sb2NrKTsKKwkJ Zm9yIChpZmE9aWRldi0+YWRkcl9saXN0OyBpZmE7IGlmYT1pZmEtPmlmX25l eHQpIHsKKwkJCW9ubGluayA9IGlwNl9hZGRyX21hdGNoKGFkZHIsICZpZmEt PmFkZHIsCisJCQkJCWlmYS0+cHJlZml4X2xlbik7CisJCQlpZiAob25saW5r KQorCQkJCWJyZWFrOworCQl9CisJCXJlYWRfdW5sb2NrX2JoKCZpZGV2LT5s b2NrKTsKKwl9CisJcmVhZF91bmxvY2soJmFkZHJjb25mX2xvY2spOworCXJl dHVybiBvbmxpbms7Cit9CisKKworLyoKKyAqCXNvY2tldCBqb2luIGFuIGFu eWNhc3QgZ3JvdXAKKyAqLworCitpbnQgaXB2Nl9zb2NrX2FjX2pvaW4oc3Ry dWN0IHNvY2sgKnNrLCBpbnQgaWZpbmRleCwgc3RydWN0IGluNl9hZGRyICph ZGRyKQoreworCXN0cnVjdCBpcHY2X3BpbmZvICpucCA9IGluZXQ2X3NrKHNr KTsKKwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gTlVMTDsKKwlzdHJ1Y3Qg aW5ldDZfZGV2ICppZGV2OworCXN0cnVjdCBpcHY2X2FjX3NvY2tsaXN0ICpw YWM7CisJaW50CWlzaG9zdCA9ICFpcHY2X2RldmNvbmYuZm9yd2FyZGluZzsK KwlpbnQJZXJyID0gMDsKKworCWlmIChpcHY2X2FkZHJfdHlwZShhZGRyKSAm IElQVjZfQUREUl9NVUxUSUNBU1QpCisJCXJldHVybiAtRUlOVkFMOworCisJ cGFjID0gc29ja19rbWFsbG9jKHNrLCBzaXplb2Yoc3RydWN0IGlwdjZfYWNf c29ja2xpc3QpLCBHRlBfS0VSTkVMKTsKKwlpZiAocGFjID09IE5VTEwpCisJ CXJldHVybiAtRU5PTUVNOworCXBhYy0+YWNsX25leHQgPSBOVUxMOworCWlw djZfYWRkcl9jb3B5KCZwYWMtPmFjbF9hZGRyLCBhZGRyKTsKKworCWlmIChp ZmluZGV4ID09IDApIHsKKwkJc3RydWN0IHJ0Nl9pbmZvICpydDsKKworCQly dCA9IHJ0Nl9sb29rdXAoYWRkciwgTlVMTCwgMCwgMCk7CisJCWlmIChydCkg eworCQkJZGV2ID0gcnQtPnJ0NmlfZGV2OworCQkJZGV2X2hvbGQoZGV2KTsK KwkJCWRzdF9yZWxlYXNlKCZydC0+dS5kc3QpOworCQl9IGVsc2UgaWYgKGlz aG9zdCkgeworCQkJc29ja19rZnJlZV9zKHNrLCBwYWMsIHNpemVvZigqcGFj KSk7CisJCQlyZXR1cm4gLUVBRERSTk9UQVZBSUw7CisJCX0gZWxzZSB7CisJ CQkvKiByb3V0ZXIsIG5vIG1hdGNoaW5nIGludGVyZmFjZToganVzdCBwaWNr IG9uZSAqLworCisJCQlkZXYgPSBkZXZfZ2V0YW55KElGRl9VUCwgSUZGX1VQ fElGRl9MT09QQkFDSyk7CisJCX0KKwl9IGVsc2UKKwkJZGV2ID0gZGV2X2dl dF9ieV9pbmRleChpZmluZGV4KTsKKworCWlmIChkZXYgPT0gTlVMTCkgewor CQlzb2NrX2tmcmVlX3Moc2ssIHBhYywgc2l6ZW9mKCpwYWMpKTsKKwkJcmV0 dXJuIC1FTk9ERVY7CisJfQorCisJaWRldiA9IGluNl9kZXZfZ2V0KGRldik7 CisJaWYgKCFpZGV2KSB7CisJCXNvY2tfa2ZyZWVfcyhzaywgcGFjLCBzaXpl b2YoKnBhYykpOworCQlkZXZfcHV0KGRldik7CisJCWlmIChpZmluZGV4KQor CQkJcmV0dXJuIC1FTk9ERVY7CisJCWVsc2UKKwkJCXJldHVybiAtRUFERFJO T1RBVkFJTDsKKwl9CisJLyogcmVzZXQgaXNob3N0LCBub3cgdGhhdCB3ZSBo YXZlIGEgc3BlY2lmaWMgZGV2aWNlICovCisJaXNob3N0ID0gIWlkZXYtPmNu Zi5mb3J3YXJkaW5nOworCWluNl9kZXZfcHV0KGlkZXYpOworCisJcGFjLT5h Y2xfaWZpbmRleCA9IGRldi0+aWZpbmRleDsKKworCS8qIFhYWAorCSAqIEZv ciBob3N0cywgYWxsb3cgbGluay1sb2NhbCBvciBtYXRjaGluZyBwcmVmaXgg YW55Y2FzdHMuCisJICogVGhpcyBvYnZpYXRlcyB0aGUgbmVlZCBmb3IgcHJv cGFnYXRpbmcgYW55Y2FzdCByb3V0ZXMgd2hpbGUKKwkgKiBzdGlsbCBhbGxv d2luZyBzb21lIG5vbi1yb3V0ZXIgYW55Y2FzdCBwYXJ0aWNpcGF0aW9uLgor CSAqCisJICogYWxsb3cgYW55b25lIHRvIGpvaW4gYW55Y2FzdHMgdGhhdCBk b24ndCByZXF1aXJlIGEgc3BlY2lhbCByb3V0ZQorCSAqIGFuZCBjYW4ndCBi ZSBzcG9vZnMgb2YgdW5pY2FzdCBhZGRyZXNzZXMgKHJlc2VydmVkIGFueWNh c3Qgb25seSkKKwkgKi8KKwlpZiAoIWlwNl9vbmxpbmsoYWRkciwgZGV2KSkg eworCQlpZiAoaXNob3N0KQorCQkJZXJyID0gLUVBRERSTk9UQVZBSUw7CisJ CWVsc2UgaWYgKCFjYXBhYmxlKENBUF9ORVRfQURNSU4pKQorCQkJZXJyID0g LUVQRVJNOworCQlpZiAoZXJyKSB7CisJCQlzb2NrX2tmcmVlX3Moc2ssIHBh Yywgc2l6ZW9mKCpwYWMpKTsKKwkJCWRldl9wdXQoZGV2KTsKKwkJCXJldHVy biBlcnI7CisJCX0KKwl9IGVsc2UgaWYgKCEoaXB2Nl9hZGRyX3R5cGUoYWRk cikgJiBJUFY2X0FERFJfQU5ZQ0FTVCkgJiYKKwkJICAgIWNhcGFibGUoQ0FQ X05FVF9BRE1JTikpCisJCXJldHVybiAtRVBFUk07CisKKwllcnIgPSBpcHY2 X2Rldl9hY19pbmMoZGV2LCBhZGRyKTsKKwlpZiAoZXJyKSB7CisJCXNvY2tf a2ZyZWVfcyhzaywgcGFjLCBzaXplb2YoKnBhYykpOworCQlkZXZfcHV0KGRl dik7CisJCXJldHVybiBlcnI7CisJfQorCisJd3JpdGVfbG9ja19iaCgmaXB2 Nl9za19hY19sb2NrKTsKKwlwYWMtPmFjbF9uZXh0ID0gbnAtPmlwdjZfYWNf bGlzdDsKKwlucC0+aXB2Nl9hY19saXN0ID0gcGFjOworCXdyaXRlX3VubG9j a19iaCgmaXB2Nl9za19hY19sb2NrKTsKKworCWRldl9wdXQoZGV2KTsKKwor CXJldHVybiAwOworfQorCisvKgorICoJc29ja2V0IGxlYXZlIGFuIGFueWNh c3QgZ3JvdXAKKyAqLworaW50IGlwdjZfc29ja19hY19kcm9wKHN0cnVjdCBz b2NrICpzaywgaW50IGlmaW5kZXgsIHN0cnVjdCBpbjZfYWRkciAqYWRkcikK K3sKKwlzdHJ1Y3QgaXB2Nl9waW5mbyAqbnAgPSBpbmV0Nl9zayhzayk7CisJ c3RydWN0IG5ldF9kZXZpY2UgKmRldjsKKwlzdHJ1Y3QgaXB2Nl9hY19zb2Nr bGlzdCAqcGFjLCAqcHJldl9wYWM7CisKKwl3cml0ZV9sb2NrX2JoKCZpcHY2 X3NrX2FjX2xvY2spOworCXByZXZfcGFjID0gMDsKKwlmb3IgKHBhYyA9IG5w LT5pcHY2X2FjX2xpc3Q7IHBhYzsgcGFjID0gcGFjLT5hY2xfbmV4dCkgewor CQlpZiAoKGlmaW5kZXggPT0gMCB8fCBwYWMtPmFjbF9pZmluZGV4ID09IGlm aW5kZXgpICYmCisJCSAgICAgaXB2Nl9hZGRyX2NtcCgmcGFjLT5hY2xfYWRk ciwgYWRkcikgPT0gMCkKKwkJCWJyZWFrOworCQlwcmV2X3BhYyA9IHBhYzsK Kwl9CisJaWYgKCFwYWMpIHsKKwkJd3JpdGVfdW5sb2NrX2JoKCZpcHY2X3Nr X2FjX2xvY2spOworCQlyZXR1cm4gLUVOT0VOVDsKKwl9CisJaWYgKHByZXZf cGFjKQorCQlwcmV2X3BhYy0+YWNsX25leHQgPSBwYWMtPmFjbF9uZXh0Owor CWVsc2UKKwkJbnAtPmlwdjZfYWNfbGlzdCA9IHBhYy0+YWNsX25leHQ7CisK Kwl3cml0ZV91bmxvY2tfYmgoJmlwdjZfc2tfYWNfbG9jayk7CisKKwlkZXYg PSBkZXZfZ2V0X2J5X2luZGV4KHBhYy0+YWNsX2lmaW5kZXgpOworCWlmIChk ZXYpIHsKKwkJaXB2Nl9kZXZfYWNfZGVjKGRldiwgJnBhYy0+YWNsX2FkZHIp OworCQlkZXZfcHV0KGRldik7CisJfQorCXNvY2tfa2ZyZWVfcyhzaywgcGFj LCBzaXplb2YoKnBhYykpOworCXJldHVybiAwOworfQorCit2b2lkIGlwdjZf c29ja19hY19jbG9zZShzdHJ1Y3Qgc29jayAqc2spCit7CisJc3RydWN0IGlw djZfcGluZm8gKm5wID0gaW5ldDZfc2soc2spOworCXN0cnVjdCBuZXRfZGV2 aWNlICpkZXYgPSAwOworCXN0cnVjdCBpcHY2X2FjX3NvY2tsaXN0ICpwYWM7 CisJaW50CXByZXZfaW5kZXg7CisKKwl3cml0ZV9sb2NrX2JoKCZpcHY2X3Nr X2FjX2xvY2spOworCXBhYyA9IG5wLT5pcHY2X2FjX2xpc3Q7CisJbnAtPmlw djZfYWNfbGlzdCA9IDA7CisJd3JpdGVfdW5sb2NrX2JoKCZpcHY2X3NrX2Fj X2xvY2spOworCisJcHJldl9pbmRleCA9IDA7CisJd2hpbGUgKHBhYykgewor CQlzdHJ1Y3QgaXB2Nl9hY19zb2NrbGlzdCAqbmV4dCA9IHBhYy0+YWNsX25l eHQ7CisKKwkJaWYgKHBhYy0+YWNsX2lmaW5kZXggIT0gcHJldl9pbmRleCkg eworCQkJaWYgKGRldikKKwkJCQlkZXZfcHV0KGRldik7CisJCQlkZXYgPSBk ZXZfZ2V0X2J5X2luZGV4KHBhYy0+YWNsX2lmaW5kZXgpOworCQkJcHJldl9p bmRleCA9IHBhYy0+YWNsX2lmaW5kZXg7CisJCX0KKwkJaWYgKGRldikKKwkJ CWlwdjZfZGV2X2FjX2RlYyhkZXYsICZwYWMtPmFjbF9hZGRyKTsKKwkJc29j a19rZnJlZV9zKHNrLCBwYWMsIHNpemVvZigqcGFjKSk7CisJCXBhYyA9IG5l eHQ7CisJfQorCWlmIChkZXYpCisJCWRldl9wdXQoZGV2KTsKK30KKworaW50 IGluZXQ2X2FjX2NoZWNrKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IGluNl9h ZGRyICphZGRyLCBpbnQgaWZpbmRleCkKK3sKKwlzdHJ1Y3QgaXB2Nl9hY19z b2NrbGlzdCAqcGFjOworCXN0cnVjdCBpcHY2X3BpbmZvICpucCA9IGluZXQ2 X3NrKHNrKTsKKwlpbnQJZm91bmQ7CisKKwlmb3VuZCA9IDA7CisJcmVhZF9s b2NrKCZpcHY2X3NrX2FjX2xvY2spOworCWZvciAocGFjPW5wLT5pcHY2X2Fj X2xpc3Q7IHBhYzsgcGFjPXBhYy0+YWNsX25leHQpIHsKKwkJaWYgKGlmaW5k ZXggJiYgcGFjLT5hY2xfaWZpbmRleCAhPSBpZmluZGV4KQorCQkJY29udGlu dWU7CisJCWZvdW5kID0gaXB2Nl9hZGRyX2NtcCgmcGFjLT5hY2xfYWRkciwg YWRkcikgPT0gMDsKKwkJaWYgKGZvdW5kKQorCQkJYnJlYWs7CisJfQorCXJl YWRfdW5sb2NrKCZpcHY2X3NrX2FjX2xvY2spOworCisJcmV0dXJuIGZvdW5k OworfQorCitzdGF0aWMgdm9pZCBhY2FfcHV0KHN0cnVjdCBpZmFjYWRkcjYg KmFjKQoreworCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZhYy0+YWNhX3Jl ZmNudCkpIHsKKwkJaW42X2Rldl9wdXQoYWMtPmFjYV9pZGV2KTsKKwkJa2Zy ZWUoYWMpOworCX0KK30KKworLyoKKyAqCWRldmljZSBhbnljYXN0IGdyb3Vw IGluYyAoYWRkIGlmIG5vdCBmb3VuZCkKKyAqLworaW50IGlwdjZfZGV2X2Fj X2luYyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaW42X2FkZHIg KmFkZHIpCit7CisJc3RydWN0IGlmYWNhZGRyNiAqYWNhOworCXN0cnVjdCBp bmV0Nl9kZXYgKmlkZXY7CisKKwlpZGV2ID0gaW42X2Rldl9nZXQoZGV2KTsK KworCWlmIChpZGV2ID09IE5VTEwpCisJCXJldHVybiAtRUlOVkFMOworCisJ d3JpdGVfbG9ja19iaCgmaWRldi0+bG9jayk7CisJaWYgKGlkZXYtPmRlYWQp IHsKKwkJd3JpdGVfdW5sb2NrX2JoKCZpZGV2LT5sb2NrKTsKKwkJaW42X2Rl dl9wdXQoaWRldik7CisJCXJldHVybiAtRU5PREVWOworCX0KKworCWZvciAo YWNhID0gaWRldi0+YWNfbGlzdDsgYWNhOyBhY2EgPSBhY2EtPmFjYV9uZXh0 KSB7CisJCWlmIChpcHY2X2FkZHJfY21wKCZhY2EtPmFjYV9hZGRyLCBhZGRy KSA9PSAwKSB7CisJCQlhY2EtPmFjYV91c2VycysrOworCQkJd3JpdGVfdW5s b2NrX2JoKCZpZGV2LT5sb2NrKTsKKwkJCWluNl9kZXZfcHV0KGlkZXYpOwor CQkJcmV0dXJuIDA7CisJCX0KKwl9CisKKwkvKgorCSAqCW5vdCBmb3VuZDog Y3JlYXRlIGEgbmV3IG9uZS4KKwkgKi8KKworCWFjYSA9IGttYWxsb2Moc2l6 ZW9mKHN0cnVjdCBpZmFjYWRkcjYpLCBHRlBfQVRPTUlDKTsKKworCWlmIChh Y2EgPT0gTlVMTCkgeworCQl3cml0ZV91bmxvY2tfYmgoJmlkZXYtPmxvY2sp OworCQlpbjZfZGV2X3B1dChpZGV2KTsKKwkJcmV0dXJuIC1FTk9NRU07CisJ fQorCisJbWVtc2V0KGFjYSwgMCwgc2l6ZW9mKHN0cnVjdCBpZmFjYWRkcjYp KTsKKworCWlwdjZfYWRkcl9jb3B5KCZhY2EtPmFjYV9hZGRyLCBhZGRyKTsK KwlhY2EtPmFjYV9pZGV2ID0gaWRldjsKKwlhY2EtPmFjYV91c2VycyA9IDE7 CisJYXRvbWljX3NldCgmYWNhLT5hY2FfcmVmY250LCAyKTsKKwlhY2EtPmFj YV9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VEOworCisJYWNhLT5hY2FfbmV4 dCA9IGlkZXYtPmFjX2xpc3Q7CisJaWRldi0+YWNfbGlzdCA9IGFjYTsKKwl3 cml0ZV91bmxvY2tfYmgoJmlkZXYtPmxvY2spOworCisJaXA2X3J0X2FkZHJf YWRkKCZhY2EtPmFjYV9hZGRyLCBkZXYpOworCisJYWRkcmNvbmZfam9pbl9z b2xpY3QoZGV2LCAmYWNhLT5hY2FfYWRkcik7CisKKwlhY2FfcHV0KGFjYSk7 CisJcmV0dXJuIDA7Cit9CisKKy8qCisgKglkZXZpY2UgYW55Y2FzdCBncm91 cCBkZWNyZW1lbnQKKyAqLworaW50IGlwdjZfZGV2X2FjX2RlYyhzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaW42X2FkZHIgKmFkZHIpCit7CisJ c3RydWN0IGluZXQ2X2RldiAqaWRldjsKKwlzdHJ1Y3QgaWZhY2FkZHI2ICph Y2EsICpwcmV2X2FjYTsKKworCWlkZXYgPSBpbjZfZGV2X2dldChkZXYpOwor CWlmIChpZGV2ID09IE5VTEwpCisJCXJldHVybiAtRU5PREVWOworCisJd3Jp dGVfbG9ja19iaCgmaWRldi0+bG9jayk7CisJcHJldl9hY2EgPSAwOworCWZv ciAoYWNhID0gaWRldi0+YWNfbGlzdDsgYWNhOyBhY2EgPSBhY2EtPmFjYV9u ZXh0KSB7CisJCWlmIChpcHY2X2FkZHJfY21wKCZhY2EtPmFjYV9hZGRyLCBh ZGRyKSA9PSAwKQorCQkJYnJlYWs7CisJCXByZXZfYWNhID0gYWNhOworCX0K KwlpZiAoIWFjYSkgeworCQl3cml0ZV91bmxvY2tfYmgoJmlkZXYtPmxvY2sp OworCQlpbjZfZGV2X3B1dChpZGV2KTsKKwkJcmV0dXJuIC1FTk9FTlQ7CisJ fQorCWlmICgtLWFjYS0+YWNhX3VzZXJzID4gMCkgeworCQl3cml0ZV91bmxv Y2tfYmgoJmlkZXYtPmxvY2spOworCQlpbjZfZGV2X3B1dChpZGV2KTsKKwkJ cmV0dXJuIDA7CisJfQorCWlmIChwcmV2X2FjYSkKKwkJcHJldl9hY2EtPmFj YV9uZXh0ID0gYWNhLT5hY2FfbmV4dDsKKwllbHNlCisJCWlkZXYtPmFjX2xp c3QgPSBhY2EtPmFjYV9uZXh0OworCXdyaXRlX3VubG9ja19iaCgmaWRldi0+ bG9jayk7CisJYWRkcmNvbmZfbGVhdmVfc29saWN0KGRldiwgJmFjYS0+YWNh X2FkZHIpOworCisJaXA2X3J0X2FkZHJfZGVsKCZhY2EtPmFjYV9hZGRyLCBk ZXYpOworCisJYWNhX3B1dChhY2EpOworCWluNl9kZXZfcHV0KGlkZXYpOwor CXJldHVybiAwOworfQorCisvKgorICoJY2hlY2sgaWYgdGhlIGludGVyZmFj ZSBoYXMgdGhpcyBhbnljYXN0IGFkZHJlc3MKKyAqLworc3RhdGljIGludCBp cHY2X2Noa19hY2FzdF9kZXYoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3Ry dWN0IGluNl9hZGRyICphZGRyKQoreworCXN0cnVjdCBpbmV0Nl9kZXYgKmlk ZXY7CisJc3RydWN0IGlmYWNhZGRyNiAqYWNhOworCisJaWRldiA9IGluNl9k ZXZfZ2V0KGRldik7CisJaWYgKGlkZXYpIHsKKwkJcmVhZF9sb2NrX2JoKCZp ZGV2LT5sb2NrKTsKKwkJZm9yIChhY2EgPSBpZGV2LT5hY19saXN0OyBhY2E7 IGFjYSA9IGFjYS0+YWNhX25leHQpCisJCQlpZiAoaXB2Nl9hZGRyX2NtcCgm YWNhLT5hY2FfYWRkciwgYWRkcikgPT0gMCkKKwkJCQlicmVhazsKKwkJcmVh ZF91bmxvY2tfYmgoJmlkZXYtPmxvY2spOworCQlpbjZfZGV2X3B1dChpZGV2 KTsKKwkJcmV0dXJuIGFjYSAhPSAwOworCX0KKwlyZXR1cm4gMDsKK30KKwor LyoKKyAqCWNoZWNrIGlmIGdpdmVuIGludGVyZmFjZSAob3IgYW55LCBpZiBk ZXY9PTApIGhhcyB0aGlzIGFueWNhc3QgYWRkcmVzcworICovCitpbnQgaXB2 Nl9jaGtfYWNhc3RfYWRkcihzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1 Y3QgaW42X2FkZHIgKmFkZHIpCit7CisJaWYgKGRldikKKwkJcmV0dXJuIGlw djZfY2hrX2FjYXN0X2RldihkZXYsIGFkZHIpOworCXJlYWRfbG9jaygmZGV2 X2Jhc2VfbG9jayk7CisJZm9yIChkZXY9ZGV2X2Jhc2U7IGRldjsgZGV2PWRl di0+bmV4dCkKKwkJaWYgKGlwdjZfY2hrX2FjYXN0X2RldihkZXYsIGFkZHIp KQorCQkJYnJlYWs7CisJcmVhZF91bmxvY2soJmRldl9iYXNlX2xvY2spOwor CXJldHVybiBkZXYgIT0gMDsKK30KKworCisjaWZkZWYgQ09ORklHX1BST0Nf RlMKK2ludCBhbnljYXN0Nl9nZXRfaW5mbyhjaGFyICpidWZmZXIsIGNoYXIg KipzdGFydCwgb2ZmX3Qgb2Zmc2V0LCBpbnQgbGVuZ3RoKQoreworCW9mZl90 IHBvcz0wLCBiZWdpbj0wOworCXN0cnVjdCBpZmFjYWRkcjYgKmltOworCWlu dCBsZW49MDsKKwlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2OworCQorCXJlYWRf bG9jaygmZGV2X2Jhc2VfbG9jayk7CisJZm9yIChkZXYgPSBkZXZfYmFzZTsg ZGV2OyBkZXYgPSBkZXYtPm5leHQpIHsKKwkJc3RydWN0IGluZXQ2X2RldiAq aWRldjsKKworCQlpZiAoKGlkZXYgPSBpbjZfZGV2X2dldChkZXYpKSA9PSBO VUxMKQorCQkJY29udGludWU7CisKKwkJcmVhZF9sb2NrX2JoKCZpZGV2LT5s b2NrKTsKKwkJZm9yIChpbSA9IGlkZXYtPmFjX2xpc3Q7IGltOyBpbSA9IGlt LT5hY2FfbmV4dCkgeworCQkJaW50IGk7CisKKwkJCWxlbiArPSBzcHJpbnRm KGJ1ZmZlcitsZW4sIiUtNGQgJS0xNXMgIiwgZGV2LT5pZmluZGV4LCBkZXYt Pm5hbWUpOworCisJCQlmb3IgKGk9MDsgaTwxNjsgaSsrKQorCQkJCWxlbiAr PSBzcHJpbnRmKGJ1ZmZlcitsZW4sICIlMDJ4IiwgaW0tPmFjYV9hZGRyLnM2 X2FkZHJbaV0pOworCisJCQlsZW4gKz0gc3ByaW50ZihidWZmZXIrbGVuLCAi ICU1ZFxuIiwgaW0tPmFjYV91c2Vycyk7CisKKwkJCXBvcz1iZWdpbitsZW47 CisJCQlpZiAocG9zIDwgb2Zmc2V0KSB7CisJCQkJbGVuPTA7CisJCQkJYmVn aW49cG9zOworCQkJfQorCQkJaWYgKHBvcyA+IG9mZnNldCtsZW5ndGgpIHsK KwkJCQlyZWFkX3VubG9ja19iaCgmaWRldi0+bG9jayk7CisJCQkJaW42X2Rl dl9wdXQoaWRldik7CisJCQkJZ290byBkb25lOworCQkJfQorCQl9CisJCXJl YWRfdW5sb2NrX2JoKCZpZGV2LT5sb2NrKTsKKwkJaW42X2Rldl9wdXQoaWRl dik7CisJfQorCitkb25lOgorCXJlYWRfdW5sb2NrKCZkZXZfYmFzZV9sb2Nr KTsKKworCSpzdGFydD1idWZmZXIrKG9mZnNldC1iZWdpbik7CisJbGVuLT0o b2Zmc2V0LWJlZ2luKTsKKwlpZihsZW4+bGVuZ3RoKQorCQlsZW49bGVuZ3Ro OworCWlmIChsZW48MCkKKwkJbGVuPTA7CisJcmV0dXJuIGxlbjsKK30KKwor I2VuZGlmCmRpZmYgLXJ1TiBsaW51eC0yLjUuNDQvbmV0L2lwdjYvaWNtcC5j IGxpbnV4LTIuNS40NEFDL25ldC9pcHY2L2ljbXAuYwotLS0gbGludXgtMi41 LjQ0L25ldC9pcHY2L2ljbXAuYwlGcmkgT2N0IDE4IDIxOjAxOjIwIDIwMDIK KysrIGxpbnV4LTIuNS40NEFDL25ldC9pcHY2L2ljbXAuYwlNb24gT2N0IDI4 IDEyOjM4OjA5IDIwMDIKQEAgLTM4OCw3ICszODgsOCBAQAogCiAJc2FkZHIg PSAmc2tiLT5uaC5pcHY2aC0+ZGFkZHI7CiAKLQlpZiAoaXB2Nl9hZGRyX3R5 cGUoc2FkZHIpICYgSVBWNl9BRERSX01VTFRJQ0FTVCkKKwlpZiAoaXB2Nl9h ZGRyX3R5cGUoc2FkZHIpICYgSVBWNl9BRERSX01VTFRJQ0FTVCB8fAorCSAg ICBpcHY2X2Noa19hY2FzdF9hZGRyKDAsIHNhZGRyKSkgCiAJCXNhZGRyID0g TlVMTDsKIAogCW1zZy5pY21waC5pY21wNl90eXBlID0gSUNNUFY2X0VDSE9f UkVQTFk7CmRpZmYgLXJ1TiBsaW51eC0yLjUuNDQvbmV0L2lwdjYvaXB2Nl9z b2NrZ2x1ZS5jIGxpbnV4LTIuNS40NEFDL25ldC9pcHY2L2lwdjZfc29ja2ds dWUuYwotLS0gbGludXgtMi41LjQ0L25ldC9pcHY2L2lwdjZfc29ja2dsdWUu YwlGcmkgT2N0IDE4IDIxOjAxOjA5IDIwMDIKKysrIGxpbnV4LTIuNS40NEFD L25ldC9pcHY2L2lwdjZfc29ja2dsdWUuYwlNb24gT2N0IDI4IDEyOjM4OjA5 IDIwMDIKQEAgLTM1MSw2ICszNTEsMjQgQEAKIAkJCXJldHYgPSBpcHY2X3Nv Y2tfbWNfZHJvcChzaywgbXJlcS5pcHY2bXJfaWZpbmRleCwgJm1yZXEuaXB2 Nm1yX211bHRpYWRkcik7CiAJCWJyZWFrOwogCX0KKwljYXNlIElQVjZfSk9J Tl9BTllDQVNUOgorCWNhc2UgSVBWNl9MRUFWRV9BTllDQVNUOgorCXsKKwkJ c3RydWN0IGlwdjZfbXJlcSBtcmVxOworCisJCWlmIChvcHRsZW4gIT0gc2l6 ZW9mKHN0cnVjdCBpcHY2X21yZXEpKQorCQkJZ290byBlX2ludmFsOworCisJ CXJldHYgPSAtRUZBVUxUOworCQlpZiAoY29weV9mcm9tX3VzZXIoJm1yZXEs IG9wdHZhbCwgc2l6ZW9mKHN0cnVjdCBpcHY2X21yZXEpKSkKKwkJCWJyZWFr OworCisJCWlmIChvcHRuYW1lID09IElQVjZfSk9JTl9BTllDQVNUKQorCQkJ cmV0diA9IGlwdjZfc29ja19hY19qb2luKHNrLCBtcmVxLmlwdjZtcl9pZmlu ZGV4LCAmbXJlcS5pcHY2bXJfYWNhZGRyKTsKKwkJZWxzZQorCQkJcmV0diA9 IGlwdjZfc29ja19hY19kcm9wKHNrLCBtcmVxLmlwdjZtcl9pZmluZGV4LCAm bXJlcS5pcHY2bXJfYWNhZGRyKTsKKwkJYnJlYWs7CisJfQogCWNhc2UgSVBW Nl9ST1VURVJfQUxFUlQ6CiAJCXJldHYgPSBpcDZfcmFfY29udHJvbChzaywg dmFsLCBOVUxMKTsKIAkJYnJlYWs7CmRpZmYgLXJ1TiBsaW51eC0yLjUuNDQv bmV0L2lwdjYvbmRpc2MuYyBsaW51eC0yLjUuNDRBQy9uZXQvaXB2Ni9uZGlz Yy5jCi0tLSBsaW51eC0yLjUuNDQvbmV0L2lwdjYvbmRpc2MuYwlGcmkgT2N0 IDE4IDIxOjAxOjU5IDIwMDIKKysrIGxpbnV4LTIuNS40NEFDL25ldC9pcHY2 L25kaXNjLmMJTW9uIE9jdCAyOCAxMzoxMjoyNyAyMDAyCkBAIC0zNzgsNyAr Mzc4LDEwIEBACiAJCSAgIHN0cnVjdCBpbjZfYWRkciAqZGFkZHIsIHN0cnVj dCBpbjZfYWRkciAqc29saWNpdGVkX2FkZHIsCiAJCSAgIGludCByb3V0ZXIs IGludCBzb2xpY2l0ZWQsIGludCBvdmVycmlkZSwgaW50IGluY19vcHQpIAog eworCXN0YXRpYyBzdHJ1Y3QgaW42X2FkZHIgdG1wYWRkcjsKKwlzdHJ1Y3Qg aW5ldDZfaWZhZGRyICppZnA7CiAgICAgICAgIHN0cnVjdCBzb2NrICpzayA9 IG5kaXNjX3NvY2tldC0+c2s7CisJc3RydWN0IGluNl9hZGRyICpzcmNfYWRk cjsKICAgICAgICAgc3RydWN0IG5kX21zZyAqbXNnOwogICAgICAgICBpbnQg bGVuOwogICAgICAgICBzdHJ1Y3Qgc2tfYnVmZiAqc2tiOwpAQCAtNDAwLDEz ICs0MDMsMjMgQEAKIAkJTkRfUFJJTlRLMSgic2VuZF9uYTogYWxsb2Mgc2ti IGZhaWxlZFxuIik7CiAJCXJldHVybjsKIAl9CisJLyogZm9yIGFueWNhc3Qg b3IgcHJveHksIHNvbGljaXRlZF9hZGRyICE9IHNyY19hZGRyICovCisJaWZw ID0gaXB2Nl9nZXRfaWZhZGRyKHNvbGljaXRlZF9hZGRyLCBkZXYpOworCWlm IChpZnApIHsKKwkJc3JjX2FkZHIgPSBzb2xpY2l0ZWRfYWRkcjsKKwkJaW42 X2lmYV9wdXQoaWZwKTsKKwl9IGVsc2UgeworCQlpZiAoaXB2Nl9kZXZfZ2V0 X3NhZGRyKGRldiwgZGFkZHIsICZ0bXBhZGRyLCAwKSkKKwkJCXJldHVybjsK KwkJc3JjX2FkZHIgPSAmdG1wYWRkcjsKKwl9CiAKIAlpZiAobmRpc2NfYnVp bGRfbGxfaGRyKHNrYiwgZGV2LCBkYWRkciwgbmVpZ2gsIGxlbikgPT0gMCkg ewogCQlrZnJlZV9za2Ioc2tiKTsKIAkJcmV0dXJuOwogCX0KIAotCWlwNl9u ZF9oZHIoc2ssIHNrYiwgZGV2LCBzb2xpY2l0ZWRfYWRkciwgZGFkZHIsIElQ UFJPVE9fSUNNUFY2LCBsZW4pOworCWlwNl9uZF9oZHIoc2ssIHNrYiwgZGV2 LCBzcmNfYWRkciwgZGFkZHIsIElQUFJPVE9fSUNNUFY2LCBsZW4pOwogCiAJ bXNnID0gKHN0cnVjdCBuZF9tc2cgKikgc2tiX3B1dChza2IsIGxlbik7CiAK QEAgLTQyNiw3ICs0MzksNyBAQAogCQluZGlzY19maWxsX29wdGlvbihtc2ct Pm9wdCwgTkRfT1BUX1RBUkdFVF9MTF9BRERSLCBkZXYtPmRldl9hZGRyLCBk ZXYtPmFkZHJfbGVuKTsKIAogCS8qIGNoZWNrc3VtICovCi0JbXNnLT5pY21w aC5pY21wNl9ja3N1bSA9IGNzdW1faXB2Nl9tYWdpYyhzb2xpY2l0ZWRfYWRk ciwgZGFkZHIsIGxlbiwgCisJbXNnLT5pY21waC5pY21wNl9ja3N1bSA9IGNz dW1faXB2Nl9tYWdpYyhzcmNfYWRkciwgZGFkZHIsIGxlbiwgCiAJCQkJCQkg SVBQUk9UT19JQ01QVjYsCiAJCQkJCQkgY3N1bV9wYXJ0aWFsKChfX3U4ICop IG1zZywgCiAJCQkJCQkJICAgICAgbGVuLCAwKSk7CkBAIC0xMTMzLDYgKzEx NDYsNTEgQEAKIAkJCQl9CiAJCQl9CiAJCQlpbjZfaWZhX3B1dChpZnApOwor CQl9IGVsc2UgaWYgKGlwdjZfY2hrX2FjYXN0X2FkZHIoZGV2LCAmbXNnLT50 YXJnZXQpKSB7CisJCQlzdHJ1Y3QgaW5ldDZfZGV2ICppZGV2ID0gaW42X2Rl dl9nZXQoZGV2KTsKKwkJCWludCBhZGRyX3R5cGUgPSBpcHY2X2FkZHJfdHlw ZShzYWRkcik7CisJCisJCQkvKiBhbnljYXN0ICovCisJCisJCQlpZiAoIWlk ZXYpIHsKKwkJCQkvKiBYWFg6IGNvdW50IHRoaXMgZHJvcD8gKi8KKwkJCQly ZXR1cm4gMDsKKwkJCX0KKwkKKwkJCWlmIChhZGRyX3R5cGUgPT0gSVBWNl9B RERSX0FOWSkgeworCQkJCXN0cnVjdCBpbjZfYWRkciBtYWRkcjsKKwkKKwkJ CQlpcHY2X2FkZHJfYWxsX25vZGVzKCZtYWRkcik7CisJCQkJbmRpc2Nfc2Vu ZF9uYShkZXYsIE5VTEwsICZtYWRkciwgJm1zZy0+dGFyZ2V0LAorCQkJCQkg ICAgICBpZGV2LT5jbmYuZm9yd2FyZGluZywgMCwgMCwgMSk7CisJCQkJaW42 X2Rldl9wdXQoaWRldik7CisJCQkJcmV0dXJuIDA7CisJCQl9CisJCisJCQlp ZiAoYWRkcl90eXBlICYgSVBWNl9BRERSX1VOSUNBU1QpIHsKKwkJCQlpbnQg aW5jID0gaXB2Nl9hZGRyX3R5cGUoZGFkZHIpJklQVjZfQUREUl9NVUxUSUNB U1Q7CisJCQkJaWYgKGluYykgIAorCQkJCQluZF90Ymwuc3RhdHMucmN2X3By b2Jlc19tY2FzdCsrOworCSAJCQllbHNlCisJCQkJCW5kX3RibC5zdGF0cy5y Y3ZfcHJvYmVzX3VjYXN0Kys7CisJCisJCQkJLyoKKwkJCQkgKiAgIHVwZGF0 ZSAvIGNyZWF0ZSBjYWNoZSBlbnRyeQorCQkJCSAqICAgZm9yIHRoZSBzb3Vy Y2UgYWRkZHJlc3MKKwkJCQkgKi8KKworCQkJCW5laWdoID0gbmVpZ2hfZXZl bnRfbnMoJm5kX3RibCwgbGxhZGRyLCBzYWRkciwgc2tiLT5kZXYpOworCisJ CQkJaWYgKG5laWdoIHx8ICFkZXYtPmhhcmRfaGVhZGVyKSB7CisJCQkJCW5k aXNjX3NlbmRfbmEoZGV2LCBuZWlnaCwgc2FkZHIsCisJCQkJCQkmbXNnLT50 YXJnZXQsIAorCQkJCQkgICAgICAgIGlkZXYtPmNuZi5mb3J3YXJkaW5nLCAx LCAwLCBpbmMpOworCQkJCQlpZiAobmVpZ2gpCisJCQkJCQluZWlnaF9yZWxl YXNlKG5laWdoKTsKKwkJCQl9CisJCQl9CisJCQlpbjZfZGV2X3B1dChpZGV2 KTsKKwogCQl9IGVsc2UgewogCQkJc3RydWN0IGluZXQ2X2RldiAqaW42X2Rl diA9IGluNl9kZXZfZ2V0KGRldik7CiAJCQlpbnQgYWRkcl90eXBlID0gaXB2 Nl9hZGRyX3R5cGUoc2FkZHIpOwpkaWZmIC1ydU4gbGludXgtMi41LjQ0L25l dC9uZXRzeW1zLmMgbGludXgtMi41LjQ0QUMvbmV0L25ldHN5bXMuYwotLS0g bGludXgtMi41LjQ0L25ldC9uZXRzeW1zLmMJRnJpIE9jdCAxOCAyMTowMTo0 OSAyMDAyCisrKyBsaW51eC0yLjUuNDRBQy9uZXQvbmV0c3ltcy5jCU1vbiBP Y3QgMjggMTI6Mzg6MDkgMjAwMgpAQCAtNDY5LDYgKzQ2OSw4IEBACiBFWFBP UlRfU1lNQk9MKHVucmVnaXN0ZXJfbmV0ZGV2aWNlKTsKIEVYUE9SVF9TWU1C T0wobmV0ZGV2X3N0YXRlX2NoYW5nZSk7CiBFWFBPUlRfU1lNQk9MKGRldl9u ZXdfaW5kZXgpOworRVhQT1JUX1NZTUJPTChkZXZfZ2V0YW55KTsKK0VYUE9S VF9TWU1CT0woX19kZXZfZ2V0YW55KTsKIEVYUE9SVF9TWU1CT0woZGV2X2dl dF9ieV9pbmRleCk7CiBFWFBPUlRfU1lNQk9MKF9fZGV2X2dldF9ieV9pbmRl eCk7CiBFWFBPUlRfU1lNQk9MKGRldl9nZXRfYnlfbmFtZSk7Cg== --0__=07BBE6F3DFE120F28f9e8a93df938690918c07BBE6F3DFE120F2-- From Larry.Sendlosky@storigen.com Mon Oct 28 13:19:55 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 13:19:59 -0800 (PST) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SLJsuR030669 for ; Mon, 28 Oct 2002 13:19:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: via-rhine "reset did not complete" errors MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 16:20:19 -0500 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A03C07B@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: via-rhine "reset did not complete" errors Thread-Index: AcJ+uZPu+xV8gPSeT3yf3Ory50izAQACltggAADO3sA= From: "Larry Sendlosky" To: "Larry Sendlosky" , "Donald Becker" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SLJsuR030669 X-archive-position: 988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev Oop, litte red-faced here....basically, I can't count. When the 'stop' routine does issue a stop cmd, the "bad" status of CR0 is 0xc (not 0xE as my mind read it). The "start" bit is not on after the "stop". Just the recvr and stop bits. A subsequent reset issued by the 'start' routine will not complete when in this state. sorry for the mind fart... larry -----Original Message----- From: Larry Sendlosky Sent: Monday, October 28, 2002 4:03 PM To: Donald Becker Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; rl@hellgate.ch Subject: RE: via-rhine "reset did not complete" errors Hi Donald, Thanks for the reply. The "reset timeout" happens on the initial reset in the 'open' routine. The reset bit (bit 7 of CR1) is not clearing after being written. This usually happens after the 'close' routine (on a previous 'ifconfig eth0 down') writes the stop cmd to CR0 and the "start" bit is still on after writing the stop cmd to CR0. What is the proper way to "stop" this little beast? thanks again, larry -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Monday, October 28, 2002 2:38 PM To: Larry Sendlosky Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; rl@hellgate.ch Subject: Re: via-rhine "reset did not complete" errors On Mon, 28 Oct 2002, Larry Sendlosky wrote: > We're using VIA EPIA mini-ITX with 800Mhz C3 and the > VT6103 PHY. (via-rhine driver says VT6102). We have made sure > power supply is "big enough". Our kernel is 2.4.18 with > via-rhine.c patches to fix TX timeout. Those are evil patches... > Our TX timeout issues seem to have gone away with the recent > patches. However we are still plagued with the "reset did not > complete in 10ms" errors. A driver _really_, _really_ shouldn't be busy-waiting for link negotiation to complete. That happened a lot with MS-DOS drivers, but it wasn't even reasonable there. Yet it's far easier for someone to get a horribly flawed patch like that accepted, while my patches went completely ignored. > Once it this state, a warm restart of > the system is necessary (and we have seen this problem at > boot time, which is more confusing). Look at the what the code is doing. It is easier to write drivers when you make the rest of the kernel single threaded on your code... -- 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 Larry.Sendlosky@storigen.com Mon Oct 28 14:38:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 14:38:13 -0800 (PST) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SMc8uR002237 for ; Mon, 28 Oct 2002 14:38:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: via-rhine "reset did not complete" errors MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Oct 2002 17:38:34 -0500 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A03C07C@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: via-rhine "reset did not complete" errors Thread-Index: AcJ+uZPu+xV8gPSeT3yf3Ory50izAQACltggAADO3sAAArmyIA== From: "Larry Sendlosky" To: "Larry Sendlosky" , "Donald Becker" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g9SMc8uR002237 X-archive-position: 989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev More info/possible solution: I remembered the Via linuxfet driver and dug it up. The linuxfet close routine does acknowledge some problems and does some special casing and action when the recvr does not turn off in a certain amount of time. I put that code in the our via-rhine driver and my 'ifconfig eth0 down; ifconfig eth0 up; ping -c2 xxxx; sleep 2;' loop has been running for about 20 minutes. Without changes it usually took less than a minute for "fail". larry -----Original Message----- From: Larry Sendlosky Sent: Monday, October 28, 2002 4:20 PM To: Larry Sendlosky; Donald Becker Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; rl@hellgate.ch Subject: RE: via-rhine "reset did not complete" errors Oop, litte red-faced here....basically, I can't count. When the 'stop' routine does issue a stop cmd, the "bad" status of CR0 is 0xc (not 0xE as my mind read it). The "start" bit is not on after the "stop". Just the recvr and stop bits. A subsequent reset issued by the 'start' routine will not complete when in this state. sorry for the mind fart... larry -----Original Message----- From: Larry Sendlosky Sent: Monday, October 28, 2002 4:03 PM To: Donald Becker Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; rl@hellgate.ch Subject: RE: via-rhine "reset did not complete" errors Hi Donald, Thanks for the reply. The "reset timeout" happens on the initial reset in the 'open' routine. The reset bit (bit 7 of CR1) is not clearing after being written. This usually happens after the 'close' routine (on a previous 'ifconfig eth0 down') writes the stop cmd to CR0 and the "start" bit is still on after writing the stop cmd to CR0. What is the proper way to "stop" this little beast? thanks again, larry -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Monday, October 28, 2002 2:38 PM To: Larry Sendlosky Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; rl@hellgate.ch Subject: Re: via-rhine "reset did not complete" errors On Mon, 28 Oct 2002, Larry Sendlosky wrote: > We're using VIA EPIA mini-ITX with 800Mhz C3 and the > VT6103 PHY. (via-rhine driver says VT6102). We have made sure > power supply is "big enough". Our kernel is 2.4.18 with > via-rhine.c patches to fix TX timeout. Those are evil patches... > Our TX timeout issues seem to have gone away with the recent > patches. However we are still plagued with the "reset did not > complete in 10ms" errors. A driver _really_, _really_ shouldn't be busy-waiting for link negotiation to complete. That happened a lot with MS-DOS drivers, but it wasn't even reasonable there. Yet it's far easier for someone to get a horribly flawed patch like that accepted, while my patches went completely ignored. > Once it this state, a warm restart of > the system is necessary (and we have seen this problem at > boot time, which is more confusing). Look at the what the code is doing. It is easier to write drivers when you make the rest of the kernel single threaded on your code... -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From ja@ssi.bg Mon Oct 28 14:55:11 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 14:55:12 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SMt1uR002664 for ; Mon, 28 Oct 2002 14:55:07 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id g9SMsiY01591; Mon, 28 Oct 2002 22:54:44 GMT Date: Mon, 28 Oct 2002 22:54:44 +0000 (GMT) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Rik van Riel cc: netdev , Arnaldo Carvalho de Melo Subject: Re: multipath routing doesn't work with netlink In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Mon, 28 Oct 2002, Rik van Riel wrote: > Am I doing something wrong or is there a kernel bug that > prevents multipath routing from working with NETLINK ? Not bug but a hidden feature :) You can define alternative default routes with "ip route append". > # ip route add default via 10.0.16.1 > # ip route add default via 10.0.17.2 > RTNETLINK answers: File exists And this is "ip route prepend" (NLM_F_REQUEST|NLM_F_CREATE without NLM_F_APPEND): > # route add default gw 10.0.17.2 > # > Is there a fundamental reason that iproute2 (using NETLINK) should > fail here, or is this a bug for which patches will be accepted ? You can reach exactly the text explaining these features by searching for "prepend" in ip-cref.tex. Note that the paragraph recommends to avoid them, may be something that Alexey will change one day :) > regards, > > Rik Regards -- Julian Anastasov From riel@conectiva.com.br Mon Oct 28 15:04:01 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 15:04:05 -0800 (PST) Received: from 3-090.ctame701-1.telepar.net.br (root@3-090.ctame701-1.telepar.net.br [200.193.161.90]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SN3xuR003608 for ; Mon, 28 Oct 2002 15:04:00 -0800 Received: from localhost ([IPv6:::ffff:127.0.0.1]:59370 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Mon, 28 Oct 2002 21:04:18 -0200 Date: Mon, 28 Oct 2002 21:04:17 -0200 (BRST) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Julian Anastasov cc: netdev , Arnaldo Carvalho de Melo Subject: Re: multipath routing doesn't work with netlink In-Reply-To: Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: riel@conectiva.com.br Precedence: bulk X-list: netdev On Mon, 28 Oct 2002, Julian Anastasov wrote: > On Mon, 28 Oct 2002, Rik van Riel wrote: > > # ip route add default via 10.0.16.1 > > # ip route add default via 10.0.17.2 > > RTNETLINK answers: File exists > > And this is "ip route prepend" (NLM_F_REQUEST|NLM_F_CREATE > without NLM_F_APPEND): "ip route prepend" doesn't work here, but "ip route append" does exactly what is wanted. Thank you, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: october@surriel.com From ja@ssi.bg Mon Oct 28 15:31:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 15:31:46 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [212.95.166.194]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9SNVUuR013430 for ; Mon, 28 Oct 2002 15:31:40 -0800 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id g9SNVMY01715; Mon, 28 Oct 2002 23:31:22 GMT Date: Tue, 29 Oct 2002 01:31:22 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Rik van Riel cc: netdev , Arnaldo Carvalho de Melo Subject: Re: multipath routing doesn't work with netlink In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev On Mon, 28 Oct 2002, Rik van Riel wrote: > "ip route prepend" doesn't work here, but "ip route append" does > exactly what is wanted. Try harder, it should work. Of course, append/prepend fail too if the same route exists, they simply use different keys for route uniqueness. Regards -- Julian Anastasov From niv@us.ibm.com Mon Oct 28 15:53:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 15:53:08 -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 g9SNr3uR014136 for ; Mon, 28 Oct 2002 15:53:04 -0800 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9SNrTaZ270276; Mon, 28 Oct 2002 18:53:29 -0500 Received: from smtp.linux.ibm.com (ltc-eth1000.torolab.ibm.com [9.26.4.197]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9SNrQAb062900; Mon, 28 Oct 2002 18:53:27 -0500 Received: from imap.linux.ibm.com (imap.linux.ibm.com [9.27.103.44]) by smtp.linux.ibm.com (Postfix) with ESMTP id B832B3FE06; Mon, 28 Oct 2002 18:53:28 -0500 (EST) Received: from w-nivedita.beaverton.ibm.com (unknown [9.47.18.15]) by imap.linux.ibm.com (Postfix) with ESMTP id F3F447C017; Mon, 28 Oct 2002 18:53:27 -0500 (EST) Date: Mon, 28 Oct 2002 15:51:14 -0800 (PST) From: Nivedita Singhvi X-X-Sender: nivedita@w-nivedita.beaverton.ibm.com To: netdev@oss.sgi.com, Subject: sctp snmp mib stats in /proc/net/snmp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 993 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 Hi, I'm attaching a bitkeeper patch below that adds support for the display of sctp snmp mib stats in /proc/net/snmp. It is dependent on several patches already submitted/accepted into the SCTP tree. This patch is also slated for inclusion in the sourceforge linux kernel sctp project tree, given no objections here. I'm posting this to netdev and linux-net in case anyone has any issues with the /proc/net/snmp display altering (post feature freeze and all that) even though I dont think that really applies here (or for any additional such changes in the near future).. thanks, Nivedita This BitKeeper patch contains the following changesets: 1.814 # This is a BitKeeper patch. What follows are the unified diffs for the # set of deltas contained in the patch. The rest of the patch, the part # that BitKeeper cares about, is below these diffs. # User: nivedita # Host: w-nivedita.beaverton.ibm.com # Root: /home/nivedita/sctp/sc3/lksctp-2.5 # #--- 1.4/net/ipv4/proc.c Sun Sep 29 17:56:38 2002 #+++ 1.5/net/ipv4/proc.c Mon Oct 28 12:41:20 2002 #@@ -49,6 +49,8 @@ # #include # #include # #include #+#include /* for sctp_statistics */ #+ # # static int fold_prot_inuse(struct proto *proto) # { #@@ -143,8 +145,13 @@ # for (i=0; i= len) # { # *start = buffer; # # Diff checksum=febe7f08 # Patch vers: 1.3 # Patch type: REGULAR == ChangeSet == torvalds@athlon.transmeta.com|ChangeSet|20020205173056|16047|c1d11a41ed024864 jgrimm@touki.austin.ibm.com|ChangeSet|20021028142304|29005 D 1.814 02/10/28 12:42:00-08:00 nivedita@w-nivedita.beaverton.ibm.com +1 -0 B torvalds@athlon.transmeta.com|ChangeSet|20020205173056|16047|c1d11a41ed024864 C c SCTP: Added SCTP SNMP stats display in /proc/net/snmp K 30551 P ChangeSet ------------------------------------------------ 0a0 > torvalds@athlon.transmeta.com|net/ipv4/proc.c|20020205173958|34679|e9623c7f3908083b nivedita@w-nivedita.beaverton.ibm.com|net/ipv4/proc.c|20021028204120|53456 == net/ipv4/proc.c == torvalds@athlon.transmeta.com|net/ipv4/proc.c|20020205173958|34679|e9623c7f3908083b schoenfr@gaaertner.de|net/ipv4/proc.c|20020930005638|00910 D 1.5 02/10/28 12:41:20-08:00 nivedita@w-nivedita.beaverton.ibm.com +8 -1 B torvalds@athlon.transmeta.com|ChangeSet|20020205173056|16047|c1d11a41ed024864 C c Added SCTP SNMP stats display support K 53456 O -rw-rw-r-- P net/ipv4/proc.c ------------------------------------------------ I51 2 #include /* for sctp_statistics */ \ D146 1 I146 5 len += sprintf (buffer +len, "\nSctp: CurrEstab ActiveEstabs PassiveEstabs Aborteds Shutdowns OutOfBlues ChecksumErrors OutCtrlChunks OutOrderChunks OutUnorderChunks InCtrlChunks InOrderChunks InUnorderChunks FragUsrMsgs ReasmUsrMsgs OutSCTPPacks InSCTPPacks RtoAlgorithm RtoMin RtoMax RtoInitial ValCookieLife MaxInitRetr\n" "Sctp:"); for (i=0; i; Mon, 28 Oct 2002 17:19:55 -0800 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9T1KLHO018498; Mon, 28 Oct 2002 20:20:21 -0500 Received: from smtp.linux.ibm.com (ltc-eth1000.torolab.ibm.com [9.26.4.197]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9T1KIAb123352; Mon, 28 Oct 2002 20:20:18 -0500 Received: from imap.linux.ibm.com (imap.linux.ibm.com [9.27.103.44]) by smtp.linux.ibm.com (Postfix) with ESMTP id 5A8663FE06; Mon, 28 Oct 2002 20:20:20 -0500 (EST) Received: from w-nivedita.beaverton.ibm.com (unknown [9.47.18.15]) by imap.linux.ibm.com (Postfix) with ESMTP id 96CB67C017; Mon, 28 Oct 2002 20:20:19 -0500 (EST) Date: Mon, 28 Oct 2002 17:18:04 -0800 (PST) From: Nivedita Singhvi X-X-Sender: nivedita@w-nivedita.beaverton.ibm.com To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [patch 2.5.44+] IpInUnknownProtos support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 994 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 This adds the update for the SNMP MIB counter IpInUnknownProtos (to catch all those unrecognized sctp packets ;)) for ipv4. thanks, Nivedita diff -urN linux-2.5.44s1/net/ipv4/ip_input.c linux-2.5.44s2/net/ipv4/ip_input.c --- linux-2.5.44s1/net/ipv4/ip_input.c Mon Oct 28 17:05:40 2002 +++ linux-2.5.44s2/net/ipv4/ip_input.c Mon Oct 28 17:00:58 2002 @@ -240,6 +240,7 @@ IP_INC_STATS_BH(IpInDelivers); } else { if (!raw_sk) { + IP_INC_STATS_BH(IpInUnknownProtos); icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); } else From jgarzik@pobox.com Mon Oct 28 18:51:44 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 18:51:49 -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 g9T2pguR005983 for ; Mon, 28 Oct 2002 18:51:43 -0800 Received: from rdu74-163-114.nc.rr.com ([24.74.163.114] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 186MUH-0000iu-00; Tue, 29 Oct 2002 02:52:13 +0000 Message-ID: <3DBDF7C4.4050408@pobox.com> Date: Mon, 28 Oct 2002 21:51:48 -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: Marcelo Tosatti CC: Alan Cox , netdev@oss.sgi.com, LKML Subject: [BK/GNU] net driver series 13 Content-Type: multipart/mixed; boundary="------------090203010605090204080202" X-archive-position: 995 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. --------------090203010605090204080202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------090203010605090204080202 Content-Type: text/plain; name="net-drivers-2.4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="net-drivers-2.4.txt" Marcelo, please do a bk pull http://gkernel.bkbits.net/net-drivers-2.4 This will update the following files: drivers/net/pcmcia/fmvj18x_cs.c | 5 ++--- drivers/net/tulip/tulip_core.c | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) through these ChangeSets: (02/10/28 1.770) del_timer_sync fixes for fmvj18x_cs net driver (02/10/28 1.769) Add PCI id to tulip net driver --------------090203010605090204080202 Content-Type: application/x-bzip2; name="netdrvr-13.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="netdrvr-13.tar.bz2" QlpoOTFBWSZTWYfquIkAA3D/hOiwAgBZf//7f6/fZP//3/oABBAIUAOZ5jao dtAUGRKaE2po2ozU0wJiZMJ6m0TamjEyaAyNMmmTTDKpo0PSNAAAAAAGgAAA AABJEBE9QU9TanhRpoaNAANM1GmgADQDagcZMmjQGjTEZGhiGBNGmIMRoMIA DBJFCaaYJqnk9GiMak2poxNA0BhGg09QZpGmJ7lPazZnNMl/hCnRIEatVIQK MKLs9oSFIWNAwkmTrQ7Z3Pjb0hl3JJmCbBs6G6buzNDoyDrtAcbOdIx4sENx twnlaogILStRAsolrZ1OmSWPDWES4T7HQHHvb+zSHBYoyorEohjAJmYNF4aQ MIR5dMcxqW1sjrCDM5pAVgJtypmtEkTaKJxMH4yjr744w8IhSooYGl47A5j7 +pnXVdv9QrAbggCh4TAHXeRp8bF5UEXL95XEiYuCMqaoG25BpAIGHuJ6CYCX sggVy+0TDJfhM8FVrLKrSdrLUCYYMKNKZUBjembTphmZu92+dTzd3XiKja1j DDImA4rp5gOEI6ip0HFAJSwQnW6B2QXIIhs5JE/mTVAqScs54QgbZNN79u1L hKkOzncvlY2k0RnolIML42iaVM59KLzxnYgYIYgn3ByGQOHB2IBEtkIBDDvj q6CrV1CL3gZngRg9GzhFXTnKI8zQpK6+Kx8FTJ8rjEXikNMGqVtKiinkMtQt 8pBirA9TLbO0pQJILYLV+lNMMqOoXheGteXW64jQZw9QnXgUzAWx8X6EqeNu kfaEHEmREYEl6vNvkOYUAohGN9UDQM1GwSVBMwJEnAEOK6qOhFYN0clIYxLq MpMlfIkgwah/BJAGqU3p5IjTpdr0IlO8S/E/yJSIcAbgHD5/RBjlWNSwhyhP eOqufLkeS6uQ7TnFqkVtRGShzGMCg/kR0hGEWdIzBd9TGxPpgMVDTePzkhEc wESyjHscsHTODeRxwaNMtRhjYcDNCYgWRgeMwBmKHGKA1FWeSIuPJzistsxR U5y8RuD5pmaom7hZcStsSnGQTuIrxoL67Fg2BNeJxPS74VR0G2QK7x2axjVI gycnSbISJ8KBg7a78i/ZmC0CbvfrmlodKRjGFFNHV7QzxRB5d22O8gpFMaDK Vqp7UygCAKzPi7jSbdwtIBE2GUD0kVYUM3cGDSAxEIlVY5uIjMGBTqhhwYeF UlF8MADR0zk9uvgyWNtIN+UyQfFu9bVJiESoKVYcXwQv0ga5t1TZCQV9aAGS qEl/xdyRThQkIfquIkA= --------------090203010605090204080202-- From netdev-bounce@oss.sgi.com Mon Oct 28 19:35:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 19:35:33 -0800 (PST) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T3ZRuR007236 for ; Mon, 28 Oct 2002 19:35:28 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8O7GA2XO8ZFVE7@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 14:35:23 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DE3512C595; Tue, 29 Oct 2002 14:13:23 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 01A8912C8D5; Tue, 29 Oct 2002 13:42:09 +1100 (EST) Date: Tue, 29 Oct 2002 13:42:10 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029024210.01A8912C8D5@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 996 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev In article (at Wed, 23 Oct 2002 10:36:19 +0300 (EEST)), Pekka Savola says: > Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is > also enabled, from IPv4 addresses using TCP without > 'match-mapped-addresses yes', or is that a separate problem? Bind9 trys to bind :: and all ipv4 addresses on the node. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From netdev-bounce@oss.sgi.com Mon Oct 28 20:58:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 20:59:02 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T4wtuR009069 for ; Mon, 28 Oct 2002 20:58:56 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8QH085YY9065D1@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 15:40:11 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D8D912CBD0; Tue, 29 Oct 2002 15:16:44 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id B76CD12CE75; Tue, 29 Oct 2002 14:39:59 +1100 (EST) Date: Tue, 29 Oct 2002 14:39:59 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029033959.B76CD12CE75@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 997 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev > The e1000 can very well do hardware checksumming on transmit. > > The missing piece of the puzzle is that his application is not > using sendfile(), without which no transmit checksum offload > can take place. As far as I've understood, sendfile() won't do much good with large files. Is this right? We're talking of 3-6GB files here ... roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From netdev-bounce@oss.sgi.com Mon Oct 28 21:30:08 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 21:30:16 -0800 (PST) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T5U7uR009881 for ; Mon, 28 Oct 2002 21:30:08 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8S5A705E95MWV8@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 16:27:59 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5BED712C4B1; Tue, 29 Oct 2002 16:02:14 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id A18D012C5A5; Tue, 29 Oct 2002 15:45:07 +1100 (EST) Date: Tue, 29 Oct 2002 15:45:07 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029044507.A18D012C5A5@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 998 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev > '50 clients *each* streaming at ~4.4MBps', better make that clear, > otherwise something is *very* broken. Also mention that you have an e1000 > card which does not do outgoing checksumming. just to clearify s/MBps/Mbps/ s/bps/bits per second/ > You'd think that a kernel would be able to do 250megabits of TCP checksums > though. > > > ...adding the whole profile output - sorted by the first column this > > time... > > > > 905182 total 0.4741 > > 121426 csum_partial_copy_generic 474.3203 > > 93633 default_idle 1800.6346 > > 74665 do_wp_page 111.1086 > > Perhaps the 'copy' also entails grabbing the page from disk, leading to > inflated csum_partial_copy_generic stats? I really don't know. Just to clearify a little more - the server app uses O_DIRECT to read the data before tossing it to the socket. > Where are you serving from? What do you mean? roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From netdev-bounce@oss.sgi.com Mon Oct 28 21:46:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 21:46:26 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T5kNuR010534 for ; Mon, 28 Oct 2002 21:46:23 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8RBX7W0094ET5M@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 16:05:02 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5526512C776 for ; Tue, 29 Oct 2002 15:29:57 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id A394712D5B4 for ; Tue, 29 Oct 2002 15:17:55 +1100 (EST) Date: Tue, 29 Oct 2002 15:17:55 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029041755.A394712D5B4@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 999 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev =B9=D9=B7=B9=B9=CC=BC=D2 =09 =09=09 =09 =09 =09=09 =09 =09 =09=09 =09 =09 =09=09 =09=09 =09 =09 =09=09 =09 =09 =09=09 =09
3D""
3D"" 3D""
3D"" 3D""
3D"" 3D""
3D"" 3D""
3D""
=BB=E7=BE=F7=C0=E5=C1=D6=BC=D2 : =BC=AD= =BF=EF=BD=C3 =B0=AD=B3=B2=B1=B8 =BF=AA=BB=EF=B5=BF 820-10 =B1=DB=B6= =F3=BD=BA=C5=B8=BF=F6=BA=F4=B5=F9 4=C3=FE
=B4=EB=C7=A5=C0=FC=C8=AD : 02 - 3452 -7347 / =BC=D2=BA=F1= =C0=DA=BB=F3=B4=E3=BD=C7 : 031-703 - 5670 / H.P 018 - 310 - 5670
=BB=E7=BE=F7=C0=DA =B5=EE=B7=CF=B9=F8=C8=A3 : 129-20-18866 / = =C5=EB=BD=C5=C6=C7=B8=C5=BE=F7=BD=C5=B0=ED =C1=A63849=C8=A3 / =B4= =EB=C7=A5 : =B9=AE=C0=E7=C3=B6
=20
=20
=BA=BB =B8=DE=C0=CF=C0=BA =C1=A4=BA=B8= =C5=EB=BD=C5=BA=CE =B1=C7=B0=ED =BB=E7=C7=D7=BF=A1 =C0=C7=B0=C5 =C1= =A6=B8=F1=BF=A1 [=B1=A4=B0=ED]=B6=F3 =C7=A5=BD=C3=B5=C8 =B8=DE=C0= =CF=C0=D4=B4=CF=B4=D9.
=B1=CD=C7=CF=C0=C7 =B8=DE=C0=CF=C0=BA =C0=A5=BB=F3=BF=A1=BC= =AD =C3=EB=B5=E6=C7=CF=BF=B4=C0=B8=B8=E7 =C1=D6=BC=D2=BF=DC=BF=A1 = =BE=EE=B6=B0=C7=D1 =C1=A4=BA=B8=B5=B5 =BA=B8=C0=AF=C7=CF=B0=ED =C0= =D6=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9. =BF=F8=C4=A1=BE=CA=B4=C2 =B8=DE= =C0=CF=C0=CC=BE=FA=B4=D9=B8=E9
=BE=C6=B7=A1=C0=C7 [=BC=F6=BD=C5=B0=C5=BA=CE]=B8=A6 =B4=AD= =B7=AF =B1=CD=C7=CF=C0=C7 =B8=DE=C0=CF=C1=D6=BC=D2=B8=A6 =C7=D1 =B9= =F8=B8=B8 =B9=DD=BC=DB=C7=D8 =C1=D6=BD=CA=BD=C3=BF=C0. =BA=D2=C6=ED= =C0=BB =B5=E5=B7=C1 =C1=CB=BC=DB=C7=D5=B4=CF=B4=D9.
(Please click here to remove your address from our mailing li= st. Sorry=20 for the trouble.)

           =            &nb= sp;           =            &nb= sp;           =            &nb= sp;           =            &nb= sp;

From netdev-bounce@oss.sgi.com Mon Oct 28 22:43:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 22:43:58 -0800 (PST) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T6houR011747 for ; Mon, 28 Oct 2002 22:43:51 -0800 Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8ULLTC4095MWXD@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 17:38:21 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F139E1300C7; Tue, 29 Oct 2002 17:38:18 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by splat.its.monash.edu.au (Postfix) with ESMTP id 0B22B1300D2; Tue, 29 Oct 2002 17:37:33 +1100 (EST) Date: Tue, 29 Oct 2002 17:37:33 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029063733.0B22B1300D2@splat.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1000 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, bert hubert wrote: > On Wed, Oct 23, 2002 at 03:42:48PM +0200, Roy Sigurd Karlsbakk wrote: > > > The e1000 can very well do hardware checksumming on transmit. > > > > > > The missing piece of the puzzle is that his application is not > > > using sendfile(), without which no transmit checksum offload > > > can take place. > > > > As far as I've understood, sendfile() won't do much good with large files. Is > > this right? > > I still refuse to believe that a 1.8GHz Pentium4 can only checksum > 250megabits/second. MD Raid5 does better and they probably don't use a > checksum as braindead as that used by TCP. > > If the checksumming is not the problem, the copying is, which would be a > weakness of your hardware. The function profiled does both the copying and > the checksumming. > > But 250megabits/second also seems low. > > Dave? > Ordinary DUAL Pentium 400 MHz machine does this... Calculating CPU speed...done Testing checksum speed...done Testing RAM copy...done Testing I/O port speed...done CPU Clock = 400 MHz checksum speed = 685 Mb/s RAM copy = 1549 Mb/s I/O port speed = 654 kb/s This is 685 megaBYTES per second. checksum speed = 685 Mb/s Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Bush : The Fourth Reich of America From netdev-bounce@oss.sgi.com Mon Oct 28 22:47:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 22:47:11 -0800 (PST) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T6l7uR012132 for ; Mon, 28 Oct 2002 22:47:08 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8UU2VXCE95MWXL@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 17:45:23 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2B79C12C122; Tue, 29 Oct 2002 17:10:16 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id ACCDA12CEA6; Tue, 29 Oct 2002 17:10:12 +1100 (EST) Date: Tue, 29 Oct 2002 17:10:12 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029061012.ACCDA12CEA6@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1001 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, Nivedita Singhvi wrote: > "Richard B. Johnson" wrote: > > > No. It's done over each word (short int) and the actual summation > > takes place during the address calculation of the next word. This > > gets you a checksum that is practically free. > > Yep, sorry, word, not byte. My bad. The cost is in the fact > that this whole process involves loading each word of the data > stream into a register. Which is why I also used to consider > the checksum cost as negligible. > > > A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second. > > It will copy at 1,549 megabytes per second. Those are megaBYTES! > > But then why the difference in the checksum/copy and copy? > Are you saying the checksum is not costing you 864 megabytes > a second?? Costing you 864 megabytes per second? Lets say the checksum was free. You are then able to INF bytes/per/sec. So it's costing you INF bytes/per/sec? No, it's costing you nothing. If we were not dealing with INF, then 'Cost' is approximately 1/N, not N. Cost is work_done_without_checksum - work_done_with_checksum. Because of the low-pass filter pole, these numbers are practically the same. But, you can get a measurable difference between any two large numbers. This makes the 'cost' seem high. You need to make it relative to make any sense, so a 'goodness' can be expressed as a ratio of the cost and the work having been done. Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Bush : The Fourth Reich of America From netdev-bounce@oss.sgi.com Mon Oct 28 23:16:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 23:16:11 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T7G2uR012836 for ; Mon, 28 Oct 2002 23:16:03 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8VS51XKQ906ICB@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 18:12:37 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4C5F412C890; Tue, 29 Oct 2002 17:52:52 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 4E2B912C7A9; Tue, 29 Oct 2002 17:52:41 +1100 (EST) Date: Tue, 29 Oct 2002 17:52:41 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029065241.4E2B912C7A9@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1002 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, Kyle C Quest wrote: > I'm just curious... what happened to the generic option, SO_ONEFAMILY, that > would replace > the need for IPV6_V6ONLY? This kind of thing is only applicable to IPv4 and IPv6 (and badly even there), there is no use trying to generalize it -- the idea was discarded. > > In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002 > 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > > > Actually, it would be great if you said what is wrong in that my patch? > > > It looks so simple that I am not ready to agree that real one should be > > > so complicated. :-) > > > > Well, I've refered alexey's patch and simplified many if-clauses. > > Here's the new patch and test results. seems ok. > > > > -------------------- > > Linux IPv6 stack provides the ability for IPv6 applications to > > interoperate with IPv4 applications. Port space for TCP (or UDP) is > > shared by IPv6 and IPv4. This conforms to RFC2553. > > However, some kind of applications may want to restrict their use of > > an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is > > defined for such applications in RFC2553bis, which is successor of > RFC2553. > > This patch allows to bind both IPv6 and IPv4 sockets with the single > > port number at the same time if IPV6_V6ONLY socket options is set to > > the IPv6 socket. > > > > Packet delivery strategy is similar to one before, but we prefer > > IPv4 a bit. > > > > Test results and patch against 2.4.20-pre11 follows. > > > > *** Test for bind(2) *** > > > > [SOCK_DGRAM w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x x x x > > :: x x x x > > 127.1 x x x o > > ::1 x x o x > > > > ==> OK > > > > [SOCK_DGRAM w/ IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x o x o > > :: o x o x > > 127.1 x o x o > > ::1 o x o x > > > > ==> OK > > > > [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > [SOCK_STREAM w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x x x x > > :: x x x x > > 127.1 x x x o > > ::1 x x o x > > > > ==> OK > > > > [SOCK_STREAM w/ IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 x o x o > > :: o x o x > > 127.1 x o x o > > ::1 o x o x > > > > ==> OK > > > > [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY] > > 0 :: 127.1 ::1 > > 0 o o o o > > :: o o o o > > 127.1 o o o o > > ::1 o o o o > > > > ==> OK > > > > *** Test for Receiver *** > > > > [IPv6] > > 1a. :: <- ::1 > > received from ::1 > > > > 1b. :: w/IPV6_V6ONLY <- ::1 > > received from ::1 > > > > 2a. :: <- 127.0.0.1 > > received from ::1 > > > > 2b. :: w/IPV6_V6ONLY <- 127.0.0.1 > > none received > > > > 3a. :: <- ff02::1 > > received from fe80::EUI64 > > > > 3b. :: w/IPV6_V6ONLY <- ff02::1 > > received from fe80::EUI64 > > > > 4a. :: <- 224.0.0.1 > > received from ::ffff:ipv4addr > > > > 4b. :: w/IPV6_V6ONLY <- 224.0.0.1 > > none received > > > > ==> OK > > > > [IPv4] > > 1. 0.0.0.0 <- ::1 > > none received > > > > 2. 0.0.0.0 <- 127.0.0.1 > > received from 127.0.0.1 > > > > 3. 0.0.0.0 <- ff02::1 > > none received > > > > 4. 0.0.0.0 <- 224.0.0.1 > > received from ipv4addr > > > > ==> OK > > > > [IPv6 vs IPv4] > > 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1 > > ipv6 received from ::1 > > > > 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1 > > ipv4 received from 127.0.0.1 > > > > 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1 > > ipv6 received from fe80::EUI64 > > > > 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1 > > ipv4 received from ipv4addra > > > > ==> OK > > > > ------------------------------------------------------------------- > > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number > (IPV6_V6ONLY Support) - Rev.2 > > Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023 > > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > > Credit: YOSHIFUJI Hideaki / USAGI Project > > Reference: RFC2553bis > > ------------------------------------------------------------------- > > Index: Documentation/networking/ip-sysctl.txt > > =================================================================== > > RCS file: > /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt > ,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.42.1 > > diff -u -r1.1.1.1 -r1.1.1.1.42.1 > > --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 > 1.1.1.1 > > +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 > 1.1.1.1.42.1 > > @@ -462,6 +462,15 @@ > > IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ > also > > apply to IPv6 [XXX?]. > > > > +bindv6only - BOOLEAN > > + Default value for IPV6_V6ONLY socket option, > > + which restricts use of the IPv6 socket to IPv6 communication > > + only. > > + TRUE: disable IPv4-mapped address feature > > + FALSE: enable IPv4-mapped address feature > > + > > + Default: FALSE (as specified in RFC2553bis) > > + > > conf/default/*: > > Change the interface-specific default settings. > > > > Index: include/linux/in6.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1 > > +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -156,6 +156,7 @@ > > #define IPV6_MTU_DISCOVER 23 > > #define IPV6_MTU 24 > > #define IPV6_RECVERR 25 > > +#define IPV6_V6ONLY 26 > > > > /* IPV6_MTU_DISCOVER values */ > > #define IPV6_PMTUDISC_DONT 0 > > Index: include/linux/sysctl.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.1 > > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > > --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 > > +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > > @@ -345,7 +345,8 @@ > > enum { > > NET_IPV6_CONF=16, > > NET_IPV6_NEIGH=17, > > - NET_IPV6_ROUTE=18 > > + NET_IPV6_ROUTE=18, > > + NET_IPV6_BINDV6ONLY=20, > > }; > > > > enum { > > Index: include/net/ipv6.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.38.1 > > diff -u -r1.1.1.1 -r1.1.1.1.38.1 > > --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > > +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1 > > @@ -88,6 +88,9 @@ > > > > #include > > > > +/* sysctls */ > > +extern int sysctl_ipv6_bindv6only; > > + > > extern struct ipv6_mib ipv6_statistics[NR_CPUS*2]; > > #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field) > > #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field) > > Index: include/net/sock.h > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > > +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -171,7 +171,8 @@ > > __u8 mc_loop:1, > > recverr:1, > > sndflow:1, > > - pmtudisc:2; > > + pmtudisc:2, > > + ipv6only:1; > > > > struct ipv6_mc_socklist *ipv6_mc_list; > > struct ipv6_fl_socklist *ipv6_fl_list; > > @@ -188,6 +189,12 @@ > > struct icmp6_filter filter; > > }; > > > > +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only) > > +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \ > > + (sk)->net_pinfo.af_inet6.ipv6only) > > +#else > > +#define __ipv6_only_sock(sk) 0 > > +#define ipv6_only_sock(sk) 0 > > #endif /* IPV6 */ > > > > #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE) > > Index: net/ipv4/tcp_ipv4.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.2 > > diff -u -r1.1.1.2 -r1.1.1.2.16.2 > > --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2 > > +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 > > @@ -45,9 +45,13 @@ > > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > > * Andi Kleen : Fix new listen. > > * Andi Kleen : Fix accept error reporting. > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > */ > > > > #include > > + > > #include > > #include > > #include > > @@ -182,6 +186,7 @@ > > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > > if (sk != sk2 && > > sk2->reuse <= 1 && > > + !ipv6_only_sock(sk2) && > > sk->bound_dev_if == sk2->bound_dev_if) { > > if (!sk_reuse || > > !sk2->reuse || > > @@ -418,23 +423,27 @@ > > struct sock *result = NULL; > > int score, hiscore; > > > > - hiscore=0; > > + hiscore=-1; > > for(; sk; sk = sk->next) { > > - if(sk->num == hnum) { > > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > > __u32 rcv_saddr = sk->rcv_saddr; > > > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > > + score = sk->family == PF_INET ? 1 : 0; > > +#else > > score = 1; > > +#endif > > if(rcv_saddr) { > > if (rcv_saddr != daddr) > > continue; > > - score++; > > + score+=2; > > } > > if (sk->bound_dev_if) { > > if (sk->bound_dev_if != dif) > > continue; > > - score++; > > + score+=2; > > } > > - if (score == 3) > > + if (score == 5) > > return sk; > > if (score > hiscore) { > > hiscore = score; > > @@ -456,6 +465,7 @@ > > if (sk->num == hnum && > > sk->next == NULL && > > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > > + (sk->family == PF_INET || !ipv6_only_sock(sk)) && > > !sk->bound_dev_if) > > goto sherry_cache; > > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > > Index: net/ipv4/udp.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -61,6 +61,9 @@ > > * return ENOTCONN for unconnected sockets (POSIX) > > * Janos Farkas : don't deliver multi/broadcasts to a different > > * bound-to-device socket > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > * > > * > > * This program is free software; you can redistribute it and/or > > @@ -85,6 +88,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -159,6 +163,7 @@ > > sk2 = sk2->next) { > > if (sk2->num == snum && > > sk2 != sk && > > + !ipv6_only_sock(sk2) && > > sk2->bound_dev_if == sk->bound_dev_if && > > (!sk2->rcv_saddr || > > !sk->rcv_saddr || > > @@ -215,29 +220,34 @@ > > int badness = -1; > > > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = > sk->next) { > > - if(sk->num == hnum) { > > - int score = 0; > > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > > + int score; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > > + score = sk->family == PF_INET ? 1 : 0; > > +#else > > + score = 1; > > +#endif > > if(sk->rcv_saddr) { > > if(sk->rcv_saddr != daddr) > > continue; > > - score++; > > + score+=2; > > } > > if(sk->daddr) { > > if(sk->daddr != saddr) > > continue; > > - score++; > > + score+=2; > > } > > if(sk->dport) { > > if(sk->dport != sport) > > continue; > > - score++; > > + score+=2; > > } > > if(sk->bound_dev_if) { > > if(sk->bound_dev_if != dif) > > continue; > > - score++; > > + score+=2; > > } > > - if(score == 4) { > > + if(score == 9) { > > result = sk; > > break; > > } else if(score > badness) { > > @@ -273,6 +283,7 @@ > > (s->daddr && s->daddr!=rmt_addr) || > > (s->dport != rmt_port && s->dport != 0) || > > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > > + ipv6_only_sock(s) || > > (s->bound_dev_if && s->bound_dev_if != dif)) > > continue; > > break; > > Index: net/ipv6/af_inet6.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.36.1 > > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > > --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > > @@ -88,6 +88,8 @@ > > extern void ipv6_sysctl_unregister(void); > > #endif > > > > +int sysctl_ipv6_bindv6only; > > + > > #ifdef INET_REFCNT_DEBUG > > atomic_t inet6_sock_nr; > > #endif > > @@ -173,6 +175,8 @@ > > sk->net_pinfo.af_inet6.mc_loop = 1; > > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > > > + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only; > > + > > /* Init the ipv4 part of the socket since we can have sockets > > * using v6 API for ipv4. > > */ > > Index: net/ipv6/ipv6_sockglue.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.36.1 > > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > > --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > > @@ -157,7 +157,8 @@ > > break; > > } > > > > - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > > + if (ipv6_only_sock(sk) || > > + !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > > retv = -EADDRNOTAVAIL; > > break; > > } > > @@ -203,6 +204,13 @@ > > } > > goto e_inval; > > > > + case IPV6_V6ONLY: > > + if (sk->num) > > + goto e_inval; > > + np->ipv6only = valbool; > > + retv = 0; > > + break; > > + > > case IPV6_PKTINFO: > > np->rxopt.bits.rxinfo = valbool; > > retv = 0; > > @@ -465,6 +473,10 @@ > > return -ENOTCONN; > > break; > > } > > + > > + case IPV6_V6ONLY: > > + val = np->ipv6only; > > + break; > > > > case IPV6_PKTINFO: > > val = np->rxopt.bits.rxinfo; > > Index: net/ipv6/sysctl_net_ipv6.c > > =================================================================== > > RCS file: > /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v > > retrieving revision 1.1.1.1 > > retrieving revision 1.1.1.1.40.1 > > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > > --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > > +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > > @@ -17,6 +17,8 @@ > > > > ctl_table ipv6_table[] = { > > {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, > > + {NET_IPV6_BINDV6ONLY, "bindv6only", > > + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, > > {0} > > }; > > > > Index: net/ipv6/tcp_ipv6.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.1 > > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > > --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > > +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > > @@ -14,6 +14,9 @@ > > * > > * Fixes: > > * Hideaki YOSHIFUJI : sin6_scope_id support > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > * > > * This program is free software; you can redistribute it and/or > > * modify it under the terms of the GNU General Public License > > @@ -148,14 +151,23 @@ > > !sk2->reuse || > > sk2->state == TCP_LISTEN) { > > /* NOTE: IPv6 tw bucket have different format */ > > - if (!sk2->rcv_saddr || > > - addr_type == IPV6_ADDR_ANY || > > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > - sk2->state != TCP_TIME_WAIT ? > > - &sk2->net_pinfo.af_inet6.rcv_saddr : > > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > > - sk->rcv_saddr==sk2->rcv_saddr)) > > + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > > + (sk2->family == AF_INET6 && > > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > > + (addr_type == IPV6_ADDR_ANY && > > + (!ipv6_only_sock(sk) || > > + !(sk2->family == AF_INET6 ? > ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED : > 1))) || > > + (sk2->family == AF_INET6 && > > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > + sk2->state != TCP_TIME_WAIT ? > > + &sk2->net_pinfo.af_inet6.rcv_saddr : > > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) || > > + (addr_type == IPV6_ADDR_MAPPED && > > + !ipv6_only_sock(sk2) && > > + (!sk2->rcv_saddr || > > + !sk->rcv_saddr || > > + sk->rcv_saddr == sk2->rcv_saddr))) > > break; > > } > > } > > @@ -601,6 +613,9 @@ > > struct sockaddr_in sin; > > > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > > + > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > > > sin.sin_family = AF_INET; > > sin.sin_port = usin->sin6_port; > > Index: net/ipv6/udp.c > > =================================================================== > > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > > retrieving revision 1.1.1.2 > > retrieving revision 1.1.1.2.16.1 > > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > > --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > > +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > > @@ -11,6 +11,9 @@ > > * > > * Fixes: > > * Hideaki YOSHIFUJI : sin6_scope_id support > > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > > + * allow both IPv4 and IPv6 sockets to bind > > + * a single port at the same time. > > * > > * This program is free software; you can redistribute it and/or > > * modify it under the terms of the GNU General Public License > > @@ -106,13 +109,21 @@ > > if (sk2->num == snum && > > sk2 != sk && > > sk2->bound_dev_if == sk->bound_dev_if && > > - (!sk2->rcv_saddr || > > - addr_type == IPV6_ADDR_ANY || > > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > > + ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > > + (sk2->family == AF_INET6 && > > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > > + (addr_type == IPV6_ADDR_ANY && > > + (!ipv6_only_sock(sk) || > > + !(sk2->family == AF_INET6 ? > (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) : > 1))) || > > + (sk2->family == AF_INET6 && > > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > > + &sk2->net_pinfo.af_inet6.rcv_saddr)) || > > (addr_type == IPV6_ADDR_MAPPED && > > - sk2->family == AF_INET && > > - sk->rcv_saddr == sk2->rcv_saddr)) && > > + !ipv6_only_sock(sk2) && > > + (!sk2->rcv_saddr || > > + !sk->rcv_saddr || > > + sk->rcv_saddr == sk2->rcv_saddr))) && > > (!sk2->reuse || !sk->reuse)) > > goto fail; > > } > > @@ -221,6 +232,8 @@ > > int err; > > > > if (usin->sin6_family == AF_INET) { > > + if (__ipv6_only_sock(sk)) > > + return -EAFNOSUPPORT; > > err = udp_connect(sk, uaddr, addr_len); > > goto ipv4_connected; > > } > > @@ -256,6 +269,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > > struct sockaddr_in sin; > > > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > + > > sin.sin_family = AF_INET; > > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > sin.sin_port = usin->sin6_port; > > @@ -783,8 +799,11 @@ > > fl.oif = 0; > > > > if (sin6) { > > - if (sin6->sin6_family == AF_INET) > > + if (sin6->sin6_family == AF_INET) { > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > return udp_sendmsg(sk, msg, ulen); > > + } > > > > if (addr_len < SIN6_LEN_RFC2133) > > return -EINVAL; > > @@ -830,6 +849,9 @@ > > > > if (addr_type == IPV6_ADDR_MAPPED) { > > struct sockaddr_in sin; > > + > > + if (__ipv6_only_sock(sk)) > > + return -ENETUNREACH; > > > > sin.sin_family = AF_INET; > > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From netdev-bounce@oss.sgi.com Mon Oct 28 23:24:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 23:24:41 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T7OcuR013603 for ; Mon, 28 Oct 2002 23:24:39 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8VIZMMLS906ICB@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 18:05:20 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1437212C847; Tue, 29 Oct 2002 17:35:38 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 2888C12C7AE; Tue, 29 Oct 2002 17:35:27 +1100 (EST) Date: Tue, 29 Oct 2002 17:35:27 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029063527.2888C12C7AE@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1003 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev All, Just tried 2.4.20-pre11 and all NIC issues seem to be resolved. Both eepro100 and e100 drivers work correctly. Paul -----Original Message----- From: Donald Becker [mailto:becker@scyld.com] Sent: Tuesday, October 22, 2002 7:21 PM To: Felipe W Damasio Cc: Paul Hernandez; Jeff Garzik; Linux-net; netdev@oss.sgi.com Subject: RE: NIC on 2.4.19 SMP (mii-diag output) On 22 Oct 2002, Felipe W Damasio wrote: > On Mon, 2002-10-21 at 15:16, Paul Hernandez wrote: > > I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD > > 10baseT > > Advertising no additional info pages. > > IEEE 802.3 CSMA/CD protocol. > > Link partner capability is 0000:. > > Negotiation did not complete. > > The link partner is not advertising it's capabilities. No! There is not link partner. 0000 is the default value for the register when there is no negotiation going on. If you have link beat _and_ the register is 0000, then no autonegotiation took place. If the link partner advertised "not capable of anything", the register will report 0001. -- 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 netdev-bounce@oss.sgi.com Mon Oct 28 23:30:04 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 23:30:06 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T7U3uR014112 for ; Mon, 28 Oct 2002 23:30:04 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8WC7AGVU94E44Z@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 18:28:00 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9A33112C129; Tue, 29 Oct 2002 18:16:05 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 44DE912C1C6; Tue, 29 Oct 2002 18:16:01 +1100 (EST) Date: Tue, 29 Oct 2002 18:16:01 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029071601.44DE912C1C6@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1004 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002 michael@albog.dk wrote: > - What kernel version have most IPv6 features build-in ?? (Maybe a feature is > missing in 2.4.19. I have read an article about patching the kernel: > http://project6.ferrara.linux.it/papers/best_ipv6_support_4_linux/best_ipv6_supp > ort_4_linux.html, it is necessary?). micheal, that article is a bit obsolete. i will update it as soon as possible, but until next week there is no chance i can do it (friday i will get my MS degree in electronic engineering and i am __very__ busy now). however, the choice of the kernel to use is quite simple: if you need the advanced features in usagi kernel (e.g. ISATAP, drop packets with fake ipv4-mapped address, RFC 3041 support, anycast support, allow default route when forwarding is enabled, Node Information Queries, IPSEC, MIPv6, IPv6-in-IPv6 tunneling) you should install the usagi kit. if not, use the standard vanilla kernel. p.s. i wouldn't spend too much time working on ripng. if you wish to analyze routing protocols, perhaps OSPF and BGP4+ would be better choices. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it mauro.tortonesi@ing.unife.it Ferrara Linux Users Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it From netdev-bounce@oss.sgi.com Mon Oct 28 23:38:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Mon, 28 Oct 2002 23:38:26 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T7cKuR015005 for ; Mon, 28 Oct 2002 23:38:21 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8WO01L2A906OBV@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 18:37:31 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D30B012C192; Tue, 29 Oct 2002 18:33:26 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id AD63512C198; Tue, 29 Oct 2002 18:33:26 +1100 (EST) Date: Tue, 29 Oct 2002 18:33:26 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029073326.AD63512C198@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1005 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev I'm just curious... what happened to the generic option, SO_ONEFAMILY, that would replace the need for IPV6_V6ONLY? > In article <200210031552.TAA29921@sex.inr.ac.ru> (at Thu, 3 Oct 2002 19:52:40 +0400 (MSD)), kuznet@ms2.inr.ac.ru says: > > > Actually, it would be great if you said what is wrong in that my patch? > > It looks so simple that I am not ready to agree that real one should be > > so complicated. :-) > > Well, I've refered alexey's patch and simplified many if-clauses. > Here's the new patch and test results. seems ok. > > -------------------- > Linux IPv6 stack provides the ability for IPv6 applications to > interoperate with IPv4 applications. Port space for TCP (or UDP) is > shared by IPv6 and IPv4. This conforms to RFC2553. > However, some kind of applications may want to restrict their use of > an IPv6 socket to IPv6 communication only. IPV6_V6ONLY socket option is > defined for such applications in RFC2553bis, which is successor of RFC2553. > This patch allows to bind both IPv6 and IPv4 sockets with the single > port number at the same time if IPV6_V6ONLY socket options is set to > the IPv6 socket. > > Packet delivery strategy is similar to one before, but we prefer > IPv4 a bit. > > Test results and patch against 2.4.20-pre11 follows. > > *** Test for bind(2) *** > > [SOCK_DGRAM w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x x x x > :: x x x x > 127.1 x x x o > ::1 x x o x > > ==> OK > > [SOCK_DGRAM w/ IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x o x o > :: o x o x > 127.1 x o x o > ::1 o x o x > > ==> OK > > [SOCK_DGRAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_DGRAM w/ SO_REUSEADDR w IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_STREAM w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x x x x > :: x x x x > 127.1 x x x o > ::1 x x o x > > ==> OK > > [SOCK_STREAM w/ IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 x o x o > :: o x o x > 127.1 x o x o > ::1 o x o x > > ==> OK > > [SOCK_STREAM w/ SO_REUSEADDR w/o IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > [SOCK_STREAM w/ SO_REUSEADDR w IPV6_V6ONLY] > 0 :: 127.1 ::1 > 0 o o o o > :: o o o o > 127.1 o o o o > ::1 o o o o > > ==> OK > > *** Test for Receiver *** > > [IPv6] > 1a. :: <- ::1 > received from ::1 > > 1b. :: w/IPV6_V6ONLY <- ::1 > received from ::1 > > 2a. :: <- 127.0.0.1 > received from ::1 > > 2b. :: w/IPV6_V6ONLY <- 127.0.0.1 > none received > > 3a. :: <- ff02::1 > received from fe80::EUI64 > > 3b. :: w/IPV6_V6ONLY <- ff02::1 > received from fe80::EUI64 > > 4a. :: <- 224.0.0.1 > received from ::ffff:ipv4addr > > 4b. :: w/IPV6_V6ONLY <- 224.0.0.1 > none received > > ==> OK > > [IPv4] > 1. 0.0.0.0 <- ::1 > none received > > 2. 0.0.0.0 <- 127.0.0.1 > received from 127.0.0.1 > > 3. 0.0.0.0 <- ff02::1 > none received > > 4. 0.0.0.0 <- 224.0.0.1 > received from ipv4addr > > ==> OK > > [IPv6 vs IPv4] > 5. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ::1 > ipv6 received from ::1 > > 6. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 127.0.0.1 > ipv4 received from 127.0.0.1 > > 7. :: w/IPV6_V6ONLY vs 0.0.0.0 <- ff02::1 > ipv6 received from fe80::EUI64 > > 8. :: w/IPV6_V6ONLY vs 0.0.0.0 <- 224.0.0.1 > ipv4 received from ipv4addra > > ==> OK > > ------------------------------------------------------------------- > Patch-Name: Allow Both IPv6 and IPv4 Sockets on the Same Port Number (IPV6_V6ONLY Support) - Rev.2 > Patch-Id: FIX_2_4_20_pre11_DOUBLEBIND-20021023 > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > Credit: YOSHIFUJI Hideaki / USAGI Project > Reference: RFC2553bis > ------------------------------------------------------------------- > Index: Documentation/networking/ip-sysctl.txt > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/Documentation/networking/ip-sysctl.txt ,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.42.1 > diff -u -r1.1.1.1 -r1.1.1.1.42.1 > --- Documentation/networking/ip-sysctl.txt 20 Aug 2002 09:48:10 -0000 1.1.1.1 > +++ Documentation/networking/ip-sysctl.txt 22 Oct 2002 19:19:48 -0000 1.1.1.1.42.1 > @@ -462,6 +462,15 @@ > IPv6 has no global variables such as tcp_*. tcp_* settings under ipv4/ also > apply to IPv6 [XXX?]. > > +bindv6only - BOOLEAN > + Default value for IPV6_V6ONLY socket option, > + which restricts use of the IPv6 socket to IPv6 communication > + only. > + TRUE: disable IPv4-mapped address feature > + FALSE: enable IPv4-mapped address feature > + > + Default: FALSE (as specified in RFC2553bis) > + > conf/default/*: > Change the interface-specific default settings. > > Index: include/linux/in6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/in6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- include/linux/in6.h 20 Aug 2002 09:46:34 -0000 1.1.1.1 > +++ include/linux/in6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -156,6 +156,7 @@ > #define IPV6_MTU_DISCOVER 23 > #define IPV6_MTU 24 > #define IPV6_RECVERR 25 > +#define IPV6_V6ONLY 26 > > /* IPV6_MTU_DISCOVER values */ > #define IPV6_PMTUDISC_DONT 0 > Index: include/linux/sysctl.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/linux/sysctl.h,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- include/linux/sysctl.h 9 Oct 2002 01:35:37 -0000 1.1.1.2 > +++ include/linux/sysctl.h 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -345,7 +345,8 @@ > enum { > NET_IPV6_CONF=16, > NET_IPV6_NEIGH=17, > - NET_IPV6_ROUTE=18 > + NET_IPV6_ROUTE=18, > + NET_IPV6_BINDV6ONLY=20, > }; > > enum { > Index: include/net/ipv6.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/ipv6.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.38.1 > diff -u -r1.1.1.1 -r1.1.1.1.38.1 > --- include/net/ipv6.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > +++ include/net/ipv6.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.38.1 > @@ -88,6 +88,9 @@ > > #include > > +/* sysctls */ > +extern int sysctl_ipv6_bindv6only; > + > extern struct ipv6_mib ipv6_statistics[NR_CPUS*2]; > #define IP6_INC_STATS(field) SNMP_INC_STATS(ipv6_statistics, field) > #define IP6_INC_STATS_BH(field) SNMP_INC_STATS_BH(ipv6_statistics, field) > Index: include/net/sock.h > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/include/net/sock.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- include/net/sock.h 20 Aug 2002 09:46:45 -0000 1.1.1.1 > +++ include/net/sock.h 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -171,7 +171,8 @@ > __u8 mc_loop:1, > recverr:1, > sndflow:1, > - pmtudisc:2; > + pmtudisc:2, > + ipv6only:1; > > struct ipv6_mc_socklist *ipv6_mc_list; > struct ipv6_fl_socklist *ipv6_fl_list; > @@ -188,6 +189,12 @@ > struct icmp6_filter filter; > }; > > +#define __ipv6_only_sock(sk) ((sk)->net_pinfo.af_inet6.ipv6only) > +#define ipv6_only_sock(sk) ((sk)->family == PF_INET6 && \ > + (sk)->net_pinfo.af_inet6.ipv6only) > +#else > +#define __ipv6_only_sock(sk) 0 > +#define ipv6_only_sock(sk) 0 > #endif /* IPV6 */ > > #if defined(CONFIG_INET) || defined(CONFIG_INET_MODULE) > Index: net/ipv4/tcp_ipv4.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/tcp_ipv4.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.2 > diff -u -r1.1.1.2 -r1.1.1.2.16.2 > --- net/ipv4/tcp_ipv4.c 9 Oct 2002 01:35:52 -0000 1.1.1.2 > +++ net/ipv4/tcp_ipv4.c 22 Oct 2002 19:40:48 -0000 1.1.1.2.16.2 > @@ -45,9 +45,13 @@ > * Vitaly E. Lavrov : Transparent proxy revived after year coma. > * Andi Kleen : Fix new listen. > * Andi Kleen : Fix accept error reporting. > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > */ > > #include > + > #include > #include > #include > @@ -182,6 +186,7 @@ > for( ; sk2 != NULL; sk2 = sk2->bind_next) { > if (sk != sk2 && > sk2->reuse <= 1 && > + !ipv6_only_sock(sk2) && > sk->bound_dev_if == sk2->bound_dev_if) { > if (!sk_reuse || > !sk2->reuse || > @@ -418,23 +423,27 @@ > struct sock *result = NULL; > int score, hiscore; > > - hiscore=0; > + hiscore=-1; > for(; sk; sk = sk->next) { > - if(sk->num == hnum) { > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > __u32 rcv_saddr = sk->rcv_saddr; > > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = sk->family == PF_INET ? 1 : 0; > +#else > score = 1; > +#endif > if(rcv_saddr) { > if (rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if (sk->bound_dev_if) { > if (sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if (score == 3) > + if (score == 5) > return sk; > if (score > hiscore) { > hiscore = score; > @@ -456,6 +465,7 @@ > if (sk->num == hnum && > sk->next == NULL && > (!sk->rcv_saddr || sk->rcv_saddr == daddr) && > + (sk->family == PF_INET || !ipv6_only_sock(sk)) && > !sk->bound_dev_if) > goto sherry_cache; > sk = __tcp_v4_lookup_listener(sk, daddr, hnum, dif); > Index: net/ipv4/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv4/udp.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- net/ipv4/udp.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv4/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -61,6 +61,9 @@ > * return ENOTCONN for unconnected sockets (POSIX) > * Janos Farkas : don't deliver multi/broadcasts to a different > * bound-to-device socket > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * > * This program is free software; you can redistribute it and/or > @@ -85,6 +88,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -159,6 +163,7 @@ > sk2 = sk2->next) { > if (sk2->num == snum && > sk2 != sk && > + !ipv6_only_sock(sk2) && > sk2->bound_dev_if == sk->bound_dev_if && > (!sk2->rcv_saddr || > !sk->rcv_saddr || > @@ -215,29 +220,34 @@ > int badness = -1; > > for(sk = udp_hash[hnum & (UDP_HTABLE_SIZE - 1)]; sk != NULL; sk = sk->next) { > - if(sk->num == hnum) { > - int score = 0; > + if(sk->num == hnum && !ipv6_only_sock(sk)) { > + int score; > +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) > + score = sk->family == PF_INET ? 1 : 0; > +#else > + score = 1; > +#endif > if(sk->rcv_saddr) { > if(sk->rcv_saddr != daddr) > continue; > - score++; > + score+=2; > } > if(sk->daddr) { > if(sk->daddr != saddr) > continue; > - score++; > + score+=2; > } > if(sk->dport) { > if(sk->dport != sport) > continue; > - score++; > + score+=2; > } > if(sk->bound_dev_if) { > if(sk->bound_dev_if != dif) > continue; > - score++; > + score+=2; > } > - if(score == 4) { > + if(score == 9) { > result = sk; > break; > } else if(score > badness) { > @@ -273,6 +283,7 @@ > (s->daddr && s->daddr!=rmt_addr) || > (s->dport != rmt_port && s->dport != 0) || > (s->rcv_saddr && s->rcv_saddr != loc_addr) || > + ipv6_only_sock(s) || > (s->bound_dev_if && s->bound_dev_if != dif)) > continue; > break; > Index: net/ipv6/af_inet6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/af_inet6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.36.1 > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > --- net/ipv6/af_inet6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/af_inet6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > @@ -88,6 +88,8 @@ > extern void ipv6_sysctl_unregister(void); > #endif > > +int sysctl_ipv6_bindv6only; > + > #ifdef INET_REFCNT_DEBUG > atomic_t inet6_sock_nr; > #endif > @@ -173,6 +175,8 @@ > sk->net_pinfo.af_inet6.mc_loop = 1; > sk->net_pinfo.af_inet6.pmtudisc = IPV6_PMTUDISC_WANT; > > + sk->net_pinfo.af_inet6.ipv6only = sysctl_ipv6_bindv6only; > + > /* Init the ipv4 part of the socket since we can have sockets > * using v6 API for ipv4. > */ > Index: net/ipv6/ipv6_sockglue.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/ipv6_sockglue.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.36.1 > diff -u -r1.1.1.1 -r1.1.1.1.36.1 > --- net/ipv6/ipv6_sockglue.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/ipv6_sockglue.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.36.1 > @@ -157,7 +157,8 @@ > break; > } > > - if (!(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > + if (ipv6_only_sock(sk) || > + !(ipv6_addr_type(&np->daddr) & IPV6_ADDR_MAPPED)) { > retv = -EADDRNOTAVAIL; > break; > } > @@ -203,6 +204,13 @@ > } > goto e_inval; > > + case IPV6_V6ONLY: > + if (sk->num) > + goto e_inval; > + np->ipv6only = valbool; > + retv = 0; > + break; > + > case IPV6_PKTINFO: > np->rxopt.bits.rxinfo = valbool; > retv = 0; > @@ -465,6 +473,10 @@ > return -ENOTCONN; > break; > } > + > + case IPV6_V6ONLY: > + val = np->ipv6only; > + break; > > case IPV6_PKTINFO: > val = np->rxopt.bits.rxinfo; > Index: net/ipv6/sysctl_net_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/sysctl_net_ipv6.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.1.1.1.40.1 > diff -u -r1.1.1.1 -r1.1.1.1.40.1 > --- net/ipv6/sysctl_net_ipv6.c 20 Aug 2002 09:47:02 -0000 1.1.1.1 > +++ net/ipv6/sysctl_net_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.1.40.1 > @@ -17,6 +17,8 @@ > > ctl_table ipv6_table[] = { > {NET_IPV6_ROUTE, "route", NULL, 0, 0555, ipv6_route_table}, > + {NET_IPV6_BINDV6ONLY, "bindv6only", > + &sysctl_ipv6_bindv6only, sizeof(int), 0644, NULL, &proc_dointvec}, > {0} > }; > > Index: net/ipv6/tcp_ipv6.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/tcp_ipv6.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- net/ipv6/tcp_ipv6.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > +++ net/ipv6/tcp_ipv6.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -14,6 +14,9 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -148,14 +151,23 @@ > !sk2->reuse || > sk2->state == TCP_LISTEN) { > /* NOTE: IPv6 tw bucket have different format */ > - if (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - sk2->state != TCP_TIME_WAIT ? > - &sk2->net_pinfo.af_inet6.rcv_saddr : > - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || > - (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && > - sk->rcv_saddr==sk2->rcv_saddr)) > + if ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > + (sk2->family == AF_INET6 && > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > + (addr_type == IPV6_ADDR_ANY && > + (!ipv6_only_sock(sk) || > + !(sk2->family == AF_INET6 ? ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED : 1))) || > + (sk2->family == AF_INET6 && > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > + sk2->state != TCP_TIME_WAIT ? > + &sk2->net_pinfo.af_inet6.rcv_saddr : > + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) || > + (addr_type == IPV6_ADDR_MAPPED && > + !ipv6_only_sock(sk2) && > + (!sk2->rcv_saddr || > + !sk->rcv_saddr || > + sk->rcv_saddr == sk2->rcv_saddr))) > break; > } > } > @@ -601,6 +613,9 @@ > struct sockaddr_in sin; > > SOCK_DEBUG(sk, "connect: ipv4 mapped\n"); > + > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_port = usin->sin6_port; > Index: net/ipv6/udp.c > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/udp.c,v > retrieving revision 1.1.1.2 > retrieving revision 1.1.1.2.16.1 > diff -u -r1.1.1.2 -r1.1.1.2.16.1 > --- net/ipv6/udp.c 9 Oct 2002 01:35:53 -0000 1.1.1.2 > +++ net/ipv6/udp.c 22 Oct 2002 19:19:48 -0000 1.1.1.2.16.1 > @@ -11,6 +11,9 @@ > * > * Fixes: > * Hideaki YOSHIFUJI : sin6_scope_id support > + * YOSHIFUJI Hideaki @USAGI: Support IPV6_V6ONLY socket option, which > + * allow both IPv4 and IPv6 sockets to bind > + * a single port at the same time. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -106,13 +109,21 @@ > if (sk2->num == snum && > sk2 != sk && > sk2->bound_dev_if == sk->bound_dev_if && > - (!sk2->rcv_saddr || > - addr_type == IPV6_ADDR_ANY || > - !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > - &sk2->net_pinfo.af_inet6.rcv_saddr) || > + ((!sk2->rcv_saddr && !ipv6_only_sock(sk)) || > + (sk2->family == AF_INET6 && > + ipv6_addr_any(&sk2->net_pinfo.af_inet6.rcv_saddr) && > + !(ipv6_only_sock(sk2) && addr_type == IPV6_ADDR_MAPPED)) || > + (addr_type == IPV6_ADDR_ANY && > + (!ipv6_only_sock(sk) || > + !(sk2->family == AF_INET6 ? (ipv6_addr_type(&sk2->net_pinfo.af_inet6.rcv_saddr) == IPV6_ADDR_MAPPED) : 1))) || > + (sk2->family == AF_INET6 && > + !ipv6_addr_cmp(&sk->net_pinfo.af_inet6.rcv_saddr, > + &sk2->net_pinfo.af_inet6.rcv_saddr)) || > (addr_type == IPV6_ADDR_MAPPED && > - sk2->family == AF_INET && > - sk->rcv_saddr == sk2->rcv_saddr)) && > + !ipv6_only_sock(sk2) && > + (!sk2->rcv_saddr || > + !sk->rcv_saddr || > + sk->rcv_saddr == sk2->rcv_saddr))) && > (!sk2->reuse || !sk->reuse)) > goto fail; > } > @@ -221,6 +232,8 @@ > int err; > > if (usin->sin6_family == AF_INET) { > + if (__ipv6_only_sock(sk)) > + return -EAFNOSUPPORT; > err = udp_connect(sk, uaddr, addr_len); > goto ipv4_connected; > } > @@ -256,6 +269,9 @@ > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > + > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > sin.sin_port = usin->sin6_port; > @@ -783,8 +799,11 @@ > fl.oif = 0; > > if (sin6) { > - if (sin6->sin6_family == AF_INET) > + if (sin6->sin6_family == AF_INET) { > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > return udp_sendmsg(sk, msg, ulen); > + } > > if (addr_len < SIN6_LEN_RFC2133) > return -EINVAL; > @@ -830,6 +849,9 @@ > > if (addr_type == IPV6_ADDR_MAPPED) { > struct sockaddr_in sin; > + > + if (__ipv6_only_sock(sk)) > + return -ENETUNREACH; > > sin.sin_family = AF_INET; > sin.sin_addr.s_addr = daddr->s6_addr32[3]; > > From netdev-bounce@oss.sgi.com Tue Oct 29 01:31:59 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 01:32:03 -0800 (PST) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T9VwuR016334 for ; Tue, 29 Oct 2002 01:31:59 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8W2VSIC08ZFVZK@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 18:20:30 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 755C312C7A0 for ; Tue, 29 Oct 2002 18:05:32 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 4636112C7B2 for ; Tue, 29 Oct 2002 18:05:32 +1100 (EST) Date: Tue, 29 Oct 2002 18:05:32 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029070532.4636112C7B2@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1006 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev Hi all, First of all, I hope this is no inconvenience to anyone, but I thought it may be of interest to some people on the netdev mailinglist as well. Just to inform people who may be interested, the ipsysctl tutorial has been released in a new version at http://ipsysctl-tutorial.frozentux.net. There are a lot of bugfixes in the new version, but no big additions at this time. I hope to spend more time the upcoming weeks with adding explanations about the route/ and neigh/ part of the sysctl's though. Comments are welcome, as always. Before anyone asks this time, no I will not add explanations of the IPv6 sysctl's at this time since I want to finish up what I have begun before I even think about that;). However, if anyone wants to, they are more than welcome to write those sections up themselves and send to me for inclusion. Sorry for taking your time, I hope this will be of some help. ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net From kherry1@caramail.com Tue Oct 29 01:38:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 01:38:07 -0800 (PST) Received: from mail2.caramail.com (mail2.caramail.com [213.193.13.93]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9T9bquR016711; Tue, 29 Oct 2002 01:37:53 -0800 Received: from caramail.com (www31.caramail.com [213.193.13.41]) by mail2.caramail.com (Postfix) with SMTP id 1AFC4C8D4; Tue, 29 Oct 2002 10:12:32 +0100 (MET) From: "herry kamara.j" To: kherry1@caramail.com Message-ID: <1035882750026922@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [64.110.146.1] Mime-Version: 1.0 Subject: urgent assistance Date: Tue, 29 Oct 2002 10:12:30 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0269221035882750_ID" X-archive-position: 1007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kherry1@caramail.com Precedence: bulk X-list: netdev This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0269221035882750_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear, Permit me to, inform you about my desire to go into business relationship with you after my prayer I have the revelation that you will successfully assist me . However, I have already send you this same letter by post one week ago but I am not sure if you did receive it since I have not heard from you hence my resending it again through mail. I am herry kamara Guei the survived and only son of General Robert Guei who was killed on 19th Sept 2002 along with my mother and the rest of the family in a fell coup attempt suspected to be planned my father. General Robert Guei My father being the first General and Military head of states of Cote d'Ivoire in the year 2000 . When my father and mother was alive , My Father Gen Guei called the family and told us about the sum of US$12 million dollars he Lodged in a suspense account in a bank here in Abidjan Cote D'Ivoire My father told the family that he used my name herry kamara Guei as the next beneficiary in deposit of the money . As a Military If their is any problem, we should seek for a reliable foreign partner in a country of our choice to assist us transfer the money to an oversea account where it will be save for the family and be used for a proper future investment purpose in any lucrative business . As the only survive Son of Gen Guei , I am honourably soliciting for your kind assistance immediately to provide your bank account details, informations, including your Tel and Fax number and address of the bank . As soon as I received your banking information, I will send to you all the neccessary documents of this deposit for you to contact the bank for immediately transfer of this money to your nominated account . I am promise to offer you 10% of the total sum of $12 million dollars for your effort in assisting me to transferring the money to your account. and also you will serve as the Guidian of this money and also arrange for my coming over to your country . I expect your urgent attention , as I will want this transaction to be concluded quik. Thanks and God bless you as you do care for me . Amen Best Regard herry kamara Guei _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35=80 Hors co=FBt du SMS) --=_NextPart_Caramail_0269221035882750_ID-- From netdev-bounce@oss.sgi.com Tue Oct 29 03:36:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 03:36:21 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TBaGuR019233 for ; Tue, 29 Oct 2002 03:36:17 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8UZJEIB2906MG4@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 17:49:37 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B4A9A12CBDB; Tue, 29 Oct 2002 17:15:05 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 5183C12C989; Tue, 29 Oct 2002 17:14:53 +1100 (EST) Date: Tue, 29 Oct 2002 17:14:53 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029061453.5183C12C989@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1008 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev "Richard B. Johnson" wrote: > No. It's done over each word (short int) and the actual summation > takes place during the address calculation of the next word. This > gets you a checksum that is practically free. Yep, sorry, word, not byte. My bad. The cost is in the fact that this whole process involves loading each word of the data stream into a register. Which is why I also used to consider the checksum cost as negligible. > A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second. > It will copy at 1,549 megabytes per second. Those are megaBYTES! But then why the difference in the checksum/copy and copy? Are you saying the checksum is not costing you 864 megabytes a second?? thanks, Nivedita From netdev-bounce@oss.sgi.com Tue Oct 29 05:20:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 05:20:38 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TDKZuR021860 for ; Tue, 29 Oct 2002 05:20:35 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8OWODAWY905X5M@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 14:55:33 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 71F3E12CE53; Tue, 29 Oct 2002 14:25:41 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 437EE12D03E; Tue, 29 Oct 2002 14:04:41 +1100 (EST) Date: Tue, 29 Oct 2002 14:04:42 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029030442.437EE12D03E@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1009 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev > > > > 905182 total 0.4741 > > 121426 csum_partial_copy_generic 474.3203 > > Well, maybe take a look at this func and try to optimize it? I don't know assembly that good - sorry. > > 93633 default_idle 1800.6346 > > 74665 do_wp_page 111.1086 > > What's this? do_wp_page is Defined as a function in: mm/memory.c comments from the file: /* * This routine handles present pages, when users try to write * to a shared page. It is done by copying the page to a new address * and decrementing the shared-page counter for the old page. * * Goto-purists beware: the only reason for goto's here is that it results * in better assembly code.. The "default" path will see no jumps at all. * * Note that this routine assumes that the protection checks have been * done by the caller (the low-level page fault routine in most cases). * Thus we can safely just mark it writable once we've done any necessary * COW. * * We also mark the page dirty at this point even though the page will * change only once the write actually happens. This avoids a few races, * and potentially makes it more efficient. * * We hold the mm semaphore and the page_table_lock on entry and exit * with the page_table_lock released. */ > > > 65857 ide_intr 184.9916 > > You have 1 ide_intr per 2 csum_partial_copy_generic... hmmm... > how large is your readahead? I assume you'd like to fetch > more sectors from ide per interrupt. (I hope you do DMA ;) doing DMA - RAID-0 with 1MB chunk size on 4 disks. > > 53636 handle_IRQ_event 432.5484 > > 21973 do_softirq 107.7108 > > 20498 e1000_intr 244.0238 > > I know zero about networking, but why 120 000 csum_partial_copy_generic > and inly 20 000 nic interrupts? That may be abnormal. sorry I don't know -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From davem@redhat.com Tue Oct 29 05:59:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 05:59:37 -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 g9TDxZuR023064 for ; Tue, 29 Oct 2002 05:59:35 -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 FAA01478; Tue, 29 Oct 2002 05:49:43 -0800 Date: Tue, 29 Oct 2002 05:49:42 -0800 (PST) Message-Id: <20021029.054942.106663164.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: sctp snmp mib stats in /proc/net/snmp 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: 1010 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: Mon, 28 Oct 2002 15:51:14 -0800 (PST) I'm posting this to netdev and linux-net in case anyone has any issues with the /proc/net/snmp display altering (post feature freeze and all that) even though I dont think that really applies here (or for any additional such changes in the near future).. I can barely parse this, please output bitkeeper patches in gnupatch format (pass "-tu" to bk export) when you wish humans to read it. :-) From netdev-bounce@oss.sgi.com Tue Oct 29 07:17:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 07:17:53 -0800 (PST) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TFHkuR007317 for ; Tue, 29 Oct 2002 07:17:47 -0800 Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8J8PDTFK95MWKJ@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 12:13:21 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3108C1300C1; Tue, 29 Oct 2002 12:12:13 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by splat.its.monash.edu.au (Postfix) with ESMTP id CB709130104; Tue, 29 Oct 2002 12:12:09 +1100 (EST) Date: Tue, 29 Oct 2002 12:12:09 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029011209.CB709130104@splat.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1011 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev hi I've got this video server serving video for VoD. problem is the P4 1.8 seems to be maxed out by a few system calls. The below output is for ~50 clients streaming at ~4.5Mbps. if trying to increase this to ~70, the CPU maxes out. Does anyone have an idea? bash-2.05# readprofile | sort -rn +2 | head -30 154203 default_idle 2409.4219 212723 csum_partial_copy_generic 916.9095 100164 handle_IRQ_event 695.5833 24979 system_call 390.2969 37300 e1000_intr 388.5417 119699 ide_intr 340.0540 30598 skb_release_data 273.1964 40740 do_softirq 195.8654 131818 do_wp_page 164.7725 9935 fget 155.2344 24747 kfree 154.6687 10911 del_timer 113.6562 11683 ip_conntrack_find_get 91.2734 4120 sock_poll 85.8333 9357 ip_ct_find_proto 83.5446 5194 sock_wfree 81.1562 4929 add_wait_queue 77.0156 8361 flush_tlb_page 74.6518 4571 remove_wait_queue 71.4219 2191 __brelse 68.4688 29477 skb_clone 68.2338 8562 do_gettimeofday 59.4583 5673 process_timeout 59.0938 11097 tcp_v4_send_check 57.7969 6124 kfree_skbmem 54.6786 17115 tcp_poll 53.4844 21130 nf_hook_slow 52.8250 8299 ip_ct_refresh 51.8687 15429 __kfree_skb 50.7533 1059 lru_cache_del 46.0435 roy -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From netdev-bounce@oss.sgi.com Tue Oct 29 07:35:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 07:35:32 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TFZQuR007754 for ; Tue, 29 Oct 2002 07:35:27 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8ULA435494ETE3@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 17:38:05 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8FC0D12CD57; Tue, 29 Oct 2002 17:01:52 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id AABB012C935; Tue, 29 Oct 2002 17:01:28 +1100 (EST) Date: Tue, 29 Oct 2002 17:01:28 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029060128.AABB012C935@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1012 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, Nivedita Singhvi wrote: > bert hubert wrote: > > > I still refuse to believe that a 1.8GHz Pentium4 can only checksum > > 250megabits/second. MD Raid5 does better and they probably don't use a > > checksum as braindead as that used by TCP. > > > > If the checksumming is not the problem, the copying is, which would be a > > weakness of your hardware. The function profiled does both the copying and > > the checksumming. > > Yep, its not so much the checksumming as the fact that this is > done over each byte of data and copied. > > thanks, > Nivedita No. It's done over each word (short int) and the actual summation takes place during the address calculation of the next word. This gets you a checksum that is practically free. A 400 MHz ix86 CPU will checksum/copy at 685 megabytes per second. It will copy at 1,549 megabytes per second. Those are megaBYTES! If you have slow network performance it has nothing to do with either copy or checksum. Data transmission acts like a low-pass filter. The dominant pole of that transfer function determines the speed, that's why it's called dominant. If you measure a data-rate of 10 megabytes/second. Nothing you do with copy or checksum will affect it to any significant extent. If you have a data-rate of 100 megabytes per second, then any tinkering with copy will have an effective improvement ratio of 100/1,559 ~= 0.064. If you have a data rate of 100 megabytes per second and you tinker with checksum, you get an improvement ratio of 100/685 ~=0.14. These are just not the things that are affecting your performance. If you were to double the checksumming speed, you increase the throughput by 2 * 0.14 = 0.28 with the parameters shown. The TCP/IP checksum is quite nice. It may have been discovered by accident, but it's still nice. It works regardless of whether you have a little endian or big endian machine. It also doesn't wrap so you don't (usually) show a good checksum when the data is bad. It does have the characteristic that if all the bits are inverted, it will checksum good. However, there are not too many real-world scenarios that would result in this inversion. So it's not "brain-dead" as you state. A hardware checksum is really quick because it's really easy. Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Bush : The Fourth Reich of America From rl@hellgate.ch Tue Oct 29 08:34:25 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 08:34:31 -0800 (PST) Received: from k3.hellgate.ch (147.224.186.195.dial.bluewin.ch [195.186.224.147]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TGYOuR009466 for ; Tue, 29 Oct 2002 08:34:24 -0800 Received: by k3.hellgate.ch (MTA, from userid 500) id 9C61C2BFA2; Tue, 29 Oct 2002 17:35:16 +0100 (CET) Date: Tue, 29 Oct 2002 17:35:16 +0100 From: Roger Luethi To: Donald Becker Cc: Larry Sendlosky , linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: via-rhine "reset did not complete" errors Message-ID: <20021029163516.GC3714@k3.hellgate.ch> References: <7BFCE5F1EF28D64198522688F5449D5A03C079@xchangeserver2.storigen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: Linux 2.5.44 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net X-archive-position: 1013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev On Mon, 28 Oct 2002 14:38:18 -0500, Donald Becker wrote: > On Mon, 28 Oct 2002, Larry Sendlosky wrote: > > > We're using VIA EPIA mini-ITX with 800Mhz C3 and the > > VT6103 PHY. (via-rhine driver says VT6102). We have made sure > > power supply is "big enough". Our kernel is 2.4.18 with > > via-rhine.c patches to fix TX timeout. > > Those are evil patches... Care to elaborate? Since I wrote the patch to fix the Tx timeout issue, I'd be very interested to learn how exactly it is evil. Roger From niv@us.ibm.com Tue Oct 29 09:23:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 09:23:33 -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 g9THNVuR010777 for ; Tue, 29 Oct 2002 09:23:31 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9THO41E038770; Tue, 29 Oct 2002 12:24:04 -0500 Received: from smtp.linux.ibm.com (ltc-eth1000.torolab.ibm.com [9.26.4.197]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9THO47r214388; Tue, 29 Oct 2002 10:24:04 -0700 Received: from imap.linux.ibm.com (imap.linux.ibm.com [9.27.103.44]) by smtp.linux.ibm.com (Postfix) with ESMTP id C6C2B3FE07; Tue, 29 Oct 2002 12:24:03 -0500 (EST) Received: from w-nivedita.beaverton.ibm.com (unknown [9.47.18.15]) by imap.linux.ibm.com (Postfix) with ESMTP id E3E737C017; Tue, 29 Oct 2002 12:24:02 -0500 (EST) Date: Tue, 29 Oct 2002 09:21:40 -0800 (PST) From: Nivedita Singhvi X-X-Sender: nivedita@w-nivedita.beaverton.ibm.com To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: Re: sctp snmp mib stats in /proc/net/snmp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1014 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 "David S. Miller" wrote: > I can barely parse this, please output bitkeeper patches > in gnupatch format (pass "-tu" to bk export) when you wish > humans to read it. :-) > Ah, sorry about that, and thanks for the tip :). Will do next time..For now, here is the plain diff. thanks, Nivedita diff -urN linux-2.5.44/net/ipv4/proc.c linux-2.5.44sc6/net/ipv4/proc.c --- linux-2.5.44/net/ipv4/proc.c Fri Oct 18 21:01:08 2002 +++ linux-2.5.44sc6/net/ipv4/proc.c Fri Oct 25 15:38:35 2002 @@ -49,6 +49,8 @@ #include #include #include +#include /* for sctp_statistics */ + static int fold_prot_inuse(struct proto *proto) { @@ -143,8 +145,13 @@ for (i=0; i= len) { *start = buffer; From davem@redhat.com Tue Oct 29 09:28:12 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 09:28:13 -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 g9THSBuR011148 for ; Tue, 29 Oct 2002 09:28: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 JAA02095; Tue, 29 Oct 2002 09:18:24 -0800 Date: Tue, 29 Oct 2002 09:18:23 -0800 (PST) Message-Id: <20021029.091823.121274899.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: sctp snmp mib stats in /proc/net/snmp 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: 1015 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, 29 Oct 2002 09:21:40 -0800 (PST) Ah, sorry about that, and thanks for the tip :). Will do next time..For now, here is the plain diff. 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 From niv@us.ibm.com Tue Oct 29 09:36:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 09:36:30 -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 g9THaSuR011587 for ; Tue, 29 Oct 2002 09:36:28 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9THauGV022714; Tue, 29 Oct 2002 12:36:56 -0500 Received: from us.ibm.com (sig-9-65-43-104.mts.ibm.com [9.65.43.104]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9THar7r186424; Tue, 29 Oct 2002 10:36:54 -0700 Message-ID: <3DBEC628.75396DA@us.ibm.com> Date: Tue, 29 Oct 2002 09:32:24 -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 Subject: Re: sctp snmp mib stats in /proc/net/snmp References: <20021029.091823.121274899.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1016 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 "David S. Miller" wrote: > > From: Nivedita Singhvi > Date: Tue, 29 Oct 2002 09:21:40 -0800 (PST) > > Ah, sorry about that, and thanks for the > tip :). Will do next time..For now, here is > the plain diff. > > 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! thanks, Nivedita From davem@redhat.com Tue Oct 29 09:41:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 09:41:07 -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 g9THf5uR011992 for ; Tue, 29 Oct 2002 09:41:05 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id JAA02173; Tue, 29 Oct 2002 09:32:19 -0800 Date: Tue, 29 Oct 2002 09:32:18 -0800 (PST) Message-Id: <20021029.093218.64662498.davem@redhat.com> To: niv@us.ibm.com Cc: netdev@oss.sgi.com Subject: Re: [patch 2.5.44+] IpInUnknownProtos support From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1017 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: Mon, 28 Oct 2002 17:18:04 -0800 (PST) This adds the update for the SNMP MIB counter IpInUnknownProtos (to catch all those unrecognized sctp packets ;)) for ipv4. I've applied this patch, thanks. From netdev-bounce@oss.sgi.com Tue Oct 29 11:20:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 11:20:37 -0800 (PST) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TJKZuR019063 for ; Tue, 29 Oct 2002 11:20:35 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8PHXV71W8ZFSHA@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 15:12:44 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4502B12CEE2; Tue, 29 Oct 2002 14:31:32 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 6F43212C73F; Tue, 29 Oct 2002 14:19:40 +1100 (EST) Date: Tue, 29 Oct 2002 14:19:40 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029031940.6F43212C73F@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1018 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev bert hubert wrote: > > ...adding the whole profile output - sorted by the first column this time... > > > > 905182 total 0.4741 > > 121426 csum_partial_copy_generic 474.3203 > > 93633 default_idle 1800.6346 > > 74665 do_wp_page 111.1086 > > Perhaps the 'copy' also entails grabbing the page from disk, leading to > inflated csum_partial_copy_generic stats? I think this is strictly a copy from user space->kernel and vice versa. This shouldnt include the disk access etc. thanks, Nivedita From netdev-bounce@oss.sgi.com Tue Oct 29 11:20:37 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 11:20:39 -0800 (PST) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TJKZuT019063 for ; Tue, 29 Oct 2002 11:20:37 -0800 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8KZM2ZXK8ZFR6O@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 13:03:18 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id ECB1B12C032; Tue, 29 Oct 2002 13:03:15 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by blammo.its.monash.edu.au (Postfix) with ESMTP id E5A9C12C046; Tue, 29 Oct 2002 13:03:08 +1100 (EST) Date: Tue, 29 Oct 2002 13:03:08 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029020308.E5A9C12C046@blammo.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1019 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Tue, 22 Oct 2002, Ben Greear wrote: > No reason not to provide both! The IOCTL can take care of any drivers > that don't take module parameters for it, and can do it in a generic > way. sure maybe via the ethertool or whatever tool that is being used would be a good start. The default should still be weight_p. > > The tulip driver I am poking at hard-coded it to 16. 64 seems to work > just as good. > > Any idea (other than trial and error) for how to determine a good value > for this? Maybe should take the number of active devices into account > and wiggle things dynamically from user-space? > What i recall is 64 was a good number and thats why we had it as default. I cant remember who changed the value to 16(Robert?), but it does seem to be a good value as well. If that was the only driver and it had a lot of packets, it would still get to use all the 300 packets in the budget; it will just have to do it in 300/16 times .. cheers, jamal From netdev-bounce@oss.sgi.com Tue Oct 29 11:36:56 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 11:36:57 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9TJatuR020300 for ; Tue, 29 Oct 2002 11:36:56 -0800 Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KO8O1RRGXU94ET2X@vaxh.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 14:30:32 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DCDFD13007E; Tue, 29 Oct 2002 14:30:31 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by splat.its.monash.edu.au (Postfix) with ESMTP id 1B454130071; Tue, 29 Oct 2002 14:30:22 +1100 (EST) Date: Tue, 29 Oct 2002 14:30:22 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029033022.1B454130071@splat.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1020 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wednesday 23 October 2002 16:59, Nivedita Singhvi wrote: > bert hubert wrote: > > > ...adding the whole profile output - sorted by the first column this > > > time... > > > > > > 905182 total 0.4741 > > > 121426 csum_partial_copy_generic 474.3203 > > > 93633 default_idle 1800.6346 > > > 74665 do_wp_page 111.1086 > > > > Perhaps the 'copy' also entails grabbing the page from disk, leading to > > inflated csum_partial_copy_generic stats? > > I think this is strictly a copy from user space->kernel and vice versa. > This shouldnt include the disk access etc. hm I'm doing O_DIRECT read (from disk), so it needs to be user -> kernel, then. any chance of using O_DIRECT to the socket? -- Roy Sigurd Karlsbakk, Datavaktmester ProntoTV AS - http://www.pronto.tv/ Tel: +47 9801 3356 Computers are like air conditioners. They stop working when you open Windows. From netdev-bounce@oss.sgi.com Tue Oct 29 17:19:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 17:20:00 -0800 (PST) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U1JuuR030840 for ; Tue, 29 Oct 2002 17:19:57 -0800 Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KO8MTYT8GS95MR6E@vaxc.cc.monash.edu.au> for netdev@oss.sgi.com; Tue, 29 Oct 2002 13:56:13 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CC6B51300AE; Tue, 29 Oct 2002 13:55:57 +1100 (EST) Received: from localhost.localdomain (enigma.its.monash.edu.au [130.194.3.233]) by splat.its.monash.edu.au (Postfix) with ESMTP id 61F2313007C; Tue, 29 Oct 2002 13:55:53 +1100 (EST) Date: Tue, 29 Oct 2002 13:55:53 +1100 (EST) From: netdev-bounce@oss.sgi.com To: undisclosed-recipients: ; Message-id: <20021029025553.61F2313007C@splat.its.monash.edu.au> Content-transfer-encoding: 7BIT X-archive-position: 1021 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: netdev-bounce@oss.sgi.com Precedence: bulk X-list: netdev On Wed, 23 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Wed, 23 Oct 2002 10:36:19 +0300 (EEST)), Pekka Savola says: > > > Does Bind 9.2.1 work this so that it can receive packets, when IPv6 is > > also enabled, from IPv4 addresses using TCP without > > 'match-mapped-addresses yes', or is that a separate problem? > > Bind9 trys to bind :: and all ipv4 addresses on the node. Yes, but binding those IPv4 addresses _for TCP_ failed after binding to ::, at least previously. That worked e.g. on BSD. Does that work now, too? I.e. I have two boxes, both running Bind 9.2.1. Linux gives: $ netstat -an | grep :53 tcp 0 0 :::53 :::* LISTEN udp 0 0 193.94.160.1:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 :::53 :::* and BSD gives: # netstat -an | grep .53 tcp6 0 0 ::1.953 *.* LISTEN tcp4 0 0 127.0.0.1.953 *.* LISTEN tcp4 0 0 127.0.0.1.53 *.* LISTEN tcp4 0 0 193.166.4.206.53 *.* LISTEN tcp4 0 0 193.166.187.10.53 *.* LISTEN tcp6 0 0 *.53 *.* LISTEN udp4 0 0 127.0.0.1.53 *.* udp4 0 0 193.166.4.206.53 *.* udp4 0 0 193.166.187.10.53 *.* udp6 0 0 *.53 *.* Will this work 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 borisp@mc.com Tue Oct 29 17:40:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 17:40:40 -0800 (PST) Received: from mc.com (iris.mc.com [192.233.16.119]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U1eZuR031525 for ; Tue, 29 Oct 2002 17:40:36 -0800 Received: from mc.com by mc.com (8.8.8+Sun/SMI-SVR4) id UAA00051; Tue, 29 Oct 2002 20:40:18 -0500 (EST) Message-ID: <3DBF3881.6070208@mc.com> Date: Tue, 29 Oct 2002 20:40:17 -0500 From: Boris Protopopov Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: Cheng Jin , netdev@oss.sgi.com Subject: Re: Linux SMP on 2.4.18-3 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: borisp@mc.com Precedence: bulk X-list: netdev Jamal, could you give some pointers as to how "NAPIfy" a 2.4.18-3/e1000-4.3.15 setup ? Boris. jamal 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. > In non-NAPI based NICs such as yours, you could have reordering within > the system (this is described in the NAPI paper). Either get it NAPIfied > or get yourself a NAPI capable NIC such as tg3 based, e1000, Dlink gige > etc. > > cheers, > jamal > > On Sun, 27 Oct 2002, Cheng Jin wrote: > > >>Hi, >> >>Please excuse me for asking questions on a rather old kernel. We decided >>to do kernel modificatios against 2.4.18-3 so we can't back it out now. >> >>On the SMP test machine we have at the lab (Dual 2.4 Ghz Xeons with one >>SysKonnect Gigabit Ethernet card, SuperMicro P4DP6 MB), I observed TCP >>functions being called simultaneously by both processors. What I did was >>to simply increment a counter (init to zero) and check whether it is one >>in the functions under suspicion. Sure enough, I see a lot of messages >>printed out saying it is two. Admittedly, my counter var is not protected >>either, but seeing it becoming 2 is proof enough that the functions are >>entered simultaneously (yes I decrement the counter before functions >>return). >> >>I looked at the code fairly extensively, and I didn't see any lock for >>these functions, tcp_send_skb, tcp_push_one, update_send_head, where >>packets_out gets incremented. The problem I was having was that >>tp->packets_out got out of sync with the number of unacked packets on the >>sk->write_queue. >> >>I would like to confirm with people that are involved with kernel >>developement that what I observed was indeed correct. >> >>Thanks, >> >>Cheng >> >>Lab # 626 395 8820 >> >> > > > > > From apache@intranet.ru Tue Oct 29 17:41:41 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 17:41:44 -0800 (PST) Received: from intranet.ru (host161-151.pool80105.interbusiness.it [80.105.151.161]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9U1fbuR031873 for ; Tue, 29 Oct 2002 17:41:39 -0800 Received: (from apache@localhost) by intranet.ru (8.11.2/8.11.2) id g9U3eWF11659; Wed, 30 Oct 2002 04:40:32 +0100 Date: Wed, 30 Oct 2002 04:40:32 +0100 Message-Id: <200210300340.g9U3eWF11659@intranet.ru> From: Maurizio Burgassi To: netdev@oss.sgi.com Subject: perfumes and flavours in web MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 68 X-archive-position: 1023 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maurizioburgassi@virgilio.it Precedence: bulk X-list: netdev perfumes and flavours in web [[HTML alternate version deleted]] From jgarzik@pobox.com Tue Oct 29 17:54:32 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 17:54:33 -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 g9U1sVuR032308 for ; Tue, 29 Oct 2002 17:54:31 -0800 Received: from rdu74-163-114.nc.rr.com ([24.74.163.114] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 186i4W-0006bv-00; Wed, 30 Oct 2002 01:55:04 +0000 Message-ID: <3DBF3BDC.8030902@pobox.com> Date: Tue, 29 Oct 2002 20:54:36 -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: Boris Protopopov CC: jamal , Cheng Jin , netdev@oss.sgi.com Subject: Re: Linux SMP on 2.4.18-3 References: <3DBF3881.6070208@mc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1024 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 Boris Protopopov wrote: > Jamal, could you give some pointers as to how "NAPIfy" a > 2.4.18-3/e1000-4.3.15 setup ? Boris. In general, read Documentation/networking/NAPI_HOWTO.txt. For e1000 specifically, copy drivers/net/e1000/*.[ch] to 2.4.x. Jeff From ak@suse.de Tue Oct 29 22:36:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Tue, 29 Oct 2002 22:36:54 -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 g9U6apuR021384 for ; Tue, 29 Oct 2002 22:36:52 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 6809D14302; Wed, 30 Oct 2002 07:37:23 +0100 (MET) Date: Wed, 30 Oct 2002 07:37:23 +0100 From: Andi Kleen To: Rik van Riel Cc: netdev , Arnaldo Carvalho de Melo Subject: Re: multipath routing doesn't work with netlink Message-ID: <20021030073722.A30664@oldwotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from riel@conectiva.com.br on Mon, Oct 28, 2002 at 02:10:24PM -0200 X-archive-position: 1025 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 There are two kinds of multipath routing in the kernel (which are differently implemented in the kernel and do different things): - default route failover. You configured it. It doesn't do any load balancing, but when your default route stops working it'll eventually try the other one. You configured that. - 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) -Andi From info@ecomputersupport.com Wed Oct 30 08:42:00 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 08:42:04 -0800 (PST) Received: from mail.imaginethatgraphic.com (IDENT:MGUj46G8xowztRQoIx6XsvJIpBFZayto@12-225-48-222.client.attbi.com [12.225.48.222]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9UGfxuR015196 for ; Wed, 30 Oct 2002 08:42:00 -0800 Received: (qmail 14098 invoked from network); 27 Aug 2002 04:18:31 -0000 Received: from unknown (HELO bup) (209.210.10.127) by 12-225-48-222.client.attbi.com with SMTP; 27 Aug 2002 04:18:31 -0000 Message-ID: <000301c2802f$95b0b7c0$6c0a0a0a@pacstar> From: "E-Computer Support" To: Subject: "Free Setup" Now Available Date: Tue, 29 Oct 2002 16:57:07 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C27FEA.400772E0" 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: 1026 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_0004_01C27FEA.400772E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C27FEA.40754FE0" ------=_NextPart_001_0005_01C27FEA.40754FE0 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.. All packages include e-mail support*=20 c.. 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_0005_01C27FEA.40754FE0 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""
3D""
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""
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
  • All packages include e-mail support*=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_0005_01C27FEA.40754FE0-- ------=_NextPart_000_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0 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_0004_01C27FEA.400772E0-- From pekkas@netcore.fi Wed Oct 30 09:16:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 09:16:26 -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 g9UHGJuR016396 for ; Wed, 30 Oct 2002 09:16:19 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UHGo312762; Wed, 30 Oct 2002 19:16:50 +0200 Date: Wed, 30 Oct 2002 19:16:50 +0200 (EET) From: Pekka Savola To: Andi Kleen cc: netdev@oss.sgi.com Subject: Re: Ambiguities in TCP/IP - firewall bypassing (fwd) In-Reply-To: <20021020063535.A6016@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1027 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 Thanks. Needless to say I belive this is a big problem. That's because about all firewalls/packet filters except Linux (possibly due to the fact that there is no "established" except in full stateful matching) -- checked Cisco, Juniper, BSD ipfw -- seem to treat "established" as "ack|rst", and SYN+RST passes through them like a hot knife in the butter. On Sun, 20 Oct 2002, Andi Kleen wrote: > On Sat, Oct 19, 2002 at 02:38:56PM +0300, Pekka Savola wrote: > > See the thread on bugtraq. > > > > Linux 2.4.19 initiates TCP handshake with SYN and RST bits set. SYN with > > _RST_ seems like a total nonsense (SYN with FIN might even be useful for > > stuff like T/TCP) but I guess the spec didn't take any stance on that.. > > Here is a patch to fix it for 2.4.19. > > > --- linux/net/ipv4/tcp_input.c-o 2002-10-15 17:24:53.000000000 +0200 > +++ linux/net/ipv4/tcp_input.c 2002-10-20 06:34:05.000000000 +0200 > @@ -3664,6 +3664,9 @@ > goto discard; > > case TCP_LISTEN: > + if(th->rst) > + goto discard; > + > if(th->ack) > return 1; > > > > -Andi > > -- 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 Robert.Olsson@data.slu.se Wed Oct 30 10:54:58 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 10:54:59 -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 g9UIsuuR024798 for ; Wed, 30 Oct 2002 10:54:57 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3/8.9.3) id UAA18500; Wed, 30 Oct 2002 20:03:29 +0100 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15808.11521.25342.659187@robur.slu.se> Date: Wed, 30 Oct 2002 20:03:29 +0100 To: Cheng Jin Cc: jamal , "netdev@oss.sgi.com" Subject: Re: Linux SMP on 2.4.18-3 In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 X-archive-position: 1028 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 Cheng Jin writes: > Out of curiosity, what is the maximum send rate (pps) under Linux > 2.4.18-3? I read in the paper that sending across two Intel Gbe with one > CPU gets up to 36o Kpps. Yes forwarding performance... A good chip/driver can itself do a lot more. I have seen very decent numbers with e1000, tg3 and dl2k. For FE tulip has been a top performer for long time but I also now see 144 kpps from my laptop w. 3c59x driver. Cheers. --ro From werner@almesberger.net Wed Oct 30 19:02:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 19:02:20 -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 g9V32HuR011393 for ; Wed, 30 Oct 2002 19:02:17 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id TAA04602 for ; Wed, 30 Oct 2002 19:02:57 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id g9V32ns26284 for netdev@oss.sgi.com; Thu, 31 Oct 2002 00:02:49 -0300 Date: Thu, 31 Oct 2002 00:02:49 -0300 From: Werner Almesberger To: netdev@oss.sgi.com Subject: TCP connection passing Message-ID: <20021031000249.A20233@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1029 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 Here's something creepy for Halloween: a dirty little hack that allows you to pass TCP endpoints across hosts, across reboots, etc. http://www.almesberger.net/tcpcp/tcpcp-0.tar.gz (Includes a patch for 2.5.45, a bit of user space, and plenty of documentation of its shortcomings. The patch is a bit deceptive: in order to make timestamps work properly, more invasive changes are needed.) I got the idea for this hack while listening to Fabio Olive Leite's talk about load-balancing at Linux-Kongress, but besides that, he's not to blame for it. The implementation is a proof of concept, which is quite sloppy with timestamps, MSS, window, etc., and don't even look at what it does to congestion control ... Anyway, it seems to work, and it's fun to play with. - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From yoshfuji@linux-ipv6.org Wed Oct 30 19:44:23 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 19:44:26 -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 g9V3iKuR013168 for ; Wed, 30 Oct 2002 19:44: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 g9V3j7GR012902; Thu, 31 Oct 2002 12:45:07 +0900 Date: Thu, 31 Oct 2002 12:44:59 +0900 (JST) Message-Id: <20021031.124459.66300488.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com CC: davem@redhat.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Subject: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 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: ,!^C1nUj;HDn\o}#MDnZW<|oj*]iIB/>/Rj|xZ=D=hBIY#)lQ,$n#kJvDg7at|p;w0^8&4_ OS17ezZP7m/LlFJYPF}FdcGx!,qBM:w{Ub2#M8_@n^nYT%?u+bwTsqni(z5 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: 1030 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! Nodes use IPv6 stateless address autoconfiguration to generate addresses. They are formed by combining network prefixes with an interface identifier. On interfaces such as ethernet, interface identifier is derived from static embedded IEEE Identifies. and eavesdroppers and other information collectors may identify the address is actually correspond to the same node. Privacy Extensions (RFC3041) is designed to make it difficult for eavesdroppers and other information collectors to identify actually correspond to the same node by changing the interface identifier periodically. This patch is against linux-2.5.44+bk2 snapshot. Thanks in advance. ------------------------------------------------------------------- Patch-Name: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Patch-Id: FIX_2_5_44+bk2_ADDRCONF_PRIVACY-20021031 Patch-Author: YOSHIFUJI Hideaki / USAGI Project Credit: YOSHIFUJI Hideaki / USAGI Project ------------------------------------------------------------------- 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.6.1 diff -u -r1.1.1.3 -r1.1.1.3.6.1 --- Documentation/networking/ip-sysctl.txt 30 Oct 2002 09:43:01 -0000 1.1.1.3 +++ Documentation/networking/ip-sysctl.txt 30 Oct 2002 18:15:04 -0000 1.1.1.3.6.1 @@ -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: 1 (for most devices) + 0 (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.6.1 diff -u -r1.1.1.2 -r1.1.1.2.6.1 --- include/linux/rtnetlink.h 30 Oct 2002 09:43:04 -0000 1.1.1.2 +++ include/linux/rtnetlink.h 30 Oct 2002 18:15:04 -0000 1.1.1.2.6.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.6.1 diff -u -r1.1.1.3 -r1.1.1.3.6.1 --- include/linux/sysctl.h 30 Oct 2002 09:43:03 -0000 1.1.1.3 +++ include/linux/sysctl.h 30 Oct 2002 18:15:04 -0000 1.1.1.3.6.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.8.1 diff -u -r1.1.1.2 -r1.1.1.2.8.1 --- include/net/addrconf.h 19 Oct 2002 05:51:09 -0000 1.1.1.2 +++ include/net/addrconf.h 30 Oct 2002 18:15:04 -0000 1.1.1.2.8.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.16.1 diff -u -r1.1.1.1 -r1.1.1.1.16.1 --- include/net/if_inet6.h 7 Oct 2002 10:22:46 -0000 1.1.1.1 +++ include/net/if_inet6.h 30 Oct 2002 18:15:04 -0000 1.1.1.1.16.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/Config.help =================================================================== RCS file: net/ipv6/Config.help diff -N net/ipv6/Config.help --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ net/ipv6/Config.help 30 Oct 2002 18:15:04 -0000 1.1.12.1 @@ -0,0 +1,12 @@ +IPv6: Privacy Extensions (RFC 3041) support +CONFIG_IPV6_PRIVACY + 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 generates temporary addresses but it won't use + them unless application explicitly bind them. To prefer temporary + address, do + + echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr Index: net/ipv6/Config.in =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/Config.in,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 --- net/ipv6/Config.in 16 Oct 2002 04:23:08 -0000 1.1.1.2 +++ net/ipv6/Config.in 30 Oct 2002 18:15:04 -0000 1.1.1.2.10.1 @@ -2,6 +2,8 @@ # IPv6 configuration # +bool ' IPv6: Privacy Extentions (RFC 3041) support' CONFIG_IPV6_PRIVACY + if [ "$CONFIG_NETFILTER" != "n" ]; then source net/ipv6/netfilter/Config.in fi 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.6.1 diff -u -r1.1.1.4 -r1.1.1.4.6.1 --- net/ipv6/addrconf.c 30 Oct 2002 09:43:18 -0000 1.1.1.4 +++ net/ipv6/addrconf.c 30 Oct 2002 18:15:04 -0000 1.1.1.4.6.1 @@ -62,6 +62,12 @@ #include #include +#ifdef CONFIG_IPV6_PRIVACY +#include +#include +#include +#endif + #include #define IPV6_MAX_ADDRESSES 16 @@ -83,6 +89,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 +135,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 = 1, + .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 +156,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 = 1, + .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 +302,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 +444,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 +477,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 +499,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 +537,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 +635,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 +661,7 @@ struct inet6_dev *idev; struct rt6_info *rt; int err; + int hiscore = -1, score; rt = (struct rt6_info *) dst; if (rt) @@ -497,17 +691,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 +734,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 +765,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 +860,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 +940,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 +1213,7 @@ struct inet6_ifaddr * ifp; struct in6_addr addr; int plen; + int create = 0; plen = pinfo->prefix_len >> 3; @@ -924,6 +1249,7 @@ return; } + create = 1; addrconf_dad_start(ifp); } @@ -934,6 +1260,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 +1275,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 +2275,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 +2322,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 +2362,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; } From yoshfuji@linux-ipv6.org Wed Oct 30 19:54:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 19:54:35 -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 g9V3sWuR013716 for ; Wed, 30 Oct 2002 19:54:33 -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 g9V3tFGR012991; Thu, 31 Oct 2002 12:55:16 +0900 Date: Thu, 31 Oct 2002 12:55:15 +0900 (JST) Message-Id: <20021031.125515.108721967.yoshfuji@linux-ipv6.org> To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021031.124459.66300488.yoshfuji@linux-ipv6.org> References: <20021031.124459.66300488.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: ,!^C1nUj;HDn\o}#MDnZW<|oj*]iIB/>/Rj|xZ=D=hBIY#)lQ,$n#kJvDg7at|p;w0^8&4_ OS17ezZP7m/LlFJYPF}FdcGx!,qBM:w{Ub2#M8_@n^nYT%?u+bwTsqni(z5 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: 1031 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 <20021031.124459.66300488.yoshfuji@linux-ipv6.org> (at Thu, 31 Oct 2002 12:44:59 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 says: > Credit: YOSHIFUJI Hideaki / USAGI Project Oops, I've forgot to credit myself in the source. Please apply on top of the patch. Index: net/ipv6/addrconf.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/addrconf.c,v retrieving revision 1.1.1.4.6.1 retrieving revision 1.1.1.4.6.2 diff -u -r1.1.1.4.6.1 -r1.1.1.4.6.2 --- net/ipv6/addrconf.c 30 Oct 2002 18:15:04 -0000 1.1.1.4.6.1 +++ net/ipv6/addrconf.c 31 Oct 2002 03:50:36 -0000 1.1.1.4.6.2 @@ -28,6 +28,8 @@ * packets. * YOSHIFUJI Hideaki @USAGI : improved accuracy of * address validation timer. + * YOSHIFUJI Hideaki @USAGI : Privacy Extensions (RFC3041) + * support. */ #include -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pekkas@netcore.fi Wed Oct 30 23:24:40 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 23:24:46 -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 g9V7ObuR023253 for ; Wed, 30 Oct 2002 23:24:38 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9V7P1e19528; Thu, 31 Oct 2002 09:25:02 +0200 Date: Thu, 31 Oct 2002 09:25:01 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: linux-kernel@vger.kernel.org, , , , Subject: Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 In-Reply-To: <20021031.124459.66300488.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 1032 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 belive privacy extensions can be harmful for especially long-lived applications and lead to a false sense of security: they should not be enabled (by any definition of enabled) by default. http://www.ietf.org/internet-drafts/draft-dupont-ipv6-rfc3041harmful-01.txt give some reasoning not to depend on them for privacy. On Thu, 31 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > Hello! > > Nodes use IPv6 stateless address autoconfiguration to generate addresses. > They are formed by combining network prefixes with an interface identifier. > On interfaces such as ethernet, interface identifier is derived from > static embedded IEEE Identifies. and eavesdroppers and other information > collectors may identify the address is actually correspond to the same > node. > Privacy Extensions (RFC3041) is designed to make it difficult for > eavesdroppers and other information collectors to identify actually > correspond to the same node by changing the interface identifier > periodically. > > This patch is against linux-2.5.44+bk2 snapshot. > > Thanks in advance. > > ------------------------------------------------------------------- > Patch-Name: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 > Patch-Id: FIX_2_5_44+bk2_ADDRCONF_PRIVACY-20021031 > Patch-Author: YOSHIFUJI Hideaki / USAGI Project > Credit: YOSHIFUJI Hideaki / USAGI Project > ------------------------------------------------------------------- > 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.6.1 > diff -u -r1.1.1.3 -r1.1.1.3.6.1 > --- Documentation/networking/ip-sysctl.txt 30 Oct 2002 09:43:01 -0000 1.1.1.3 > +++ Documentation/networking/ip-sysctl.txt 30 Oct 2002 18:15:04 -0000 1.1.1.3.6.1 > @@ -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: 1 (for most devices) > + 0 (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.6.1 > diff -u -r1.1.1.2 -r1.1.1.2.6.1 > --- include/linux/rtnetlink.h 30 Oct 2002 09:43:04 -0000 1.1.1.2 > +++ include/linux/rtnetlink.h 30 Oct 2002 18:15:04 -0000 1.1.1.2.6.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.6.1 > diff -u -r1.1.1.3 -r1.1.1.3.6.1 > --- include/linux/sysctl.h 30 Oct 2002 09:43:03 -0000 1.1.1.3 > +++ include/linux/sysctl.h 30 Oct 2002 18:15:04 -0000 1.1.1.3.6.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.8.1 > diff -u -r1.1.1.2 -r1.1.1.2.8.1 > --- include/net/addrconf.h 19 Oct 2002 05:51:09 -0000 1.1.1.2 > +++ include/net/addrconf.h 30 Oct 2002 18:15:04 -0000 1.1.1.2.8.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.16.1 > diff -u -r1.1.1.1 -r1.1.1.1.16.1 > --- include/net/if_inet6.h 7 Oct 2002 10:22:46 -0000 1.1.1.1 > +++ include/net/if_inet6.h 30 Oct 2002 18:15:04 -0000 1.1.1.1.16.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/Config.help > =================================================================== > RCS file: net/ipv6/Config.help > diff -N net/ipv6/Config.help > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ net/ipv6/Config.help 30 Oct 2002 18:15:04 -0000 1.1.12.1 > @@ -0,0 +1,12 @@ > +IPv6: Privacy Extensions (RFC 3041) support > +CONFIG_IPV6_PRIVACY > + 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 generates temporary addresses but it won't use > + them unless application explicitly bind them. To prefer temporary > + address, do > + > + echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr > Index: net/ipv6/Config.in > =================================================================== > RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/Config.in,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 > --- net/ipv6/Config.in 16 Oct 2002 04:23:08 -0000 1.1.1.2 > +++ net/ipv6/Config.in 30 Oct 2002 18:15:04 -0000 1.1.1.2.10.1 > @@ -2,6 +2,8 @@ > # IPv6 configuration > # > > +bool ' IPv6: Privacy Extentions (RFC 3041) support' CONFIG_IPV6_PRIVACY > + > if [ "$CONFIG_NETFILTER" != "n" ]; then > source net/ipv6/netfilter/Config.in > fi > 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.6.1 > diff -u -r1.1.1.4 -r1.1.1.4.6.1 > --- net/ipv6/addrconf.c 30 Oct 2002 09:43:18 -0000 1.1.1.4 > +++ net/ipv6/addrconf.c 30 Oct 2002 18:15:04 -0000 1.1.1.4.6.1 > @@ -62,6 +62,12 @@ > #include > #include > > +#ifdef CONFIG_IPV6_PRIVACY > +#include > +#include > +#include > +#endif > + > #include > > #define IPV6_MAX_ADDRESSES 16 > @@ -83,6 +89,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 +135,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 = 1, > + .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 +156,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 = 1, > + .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 +302,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 +444,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 +477,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 +499,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 +537,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 +635,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 +661,7 @@ > struct inet6_dev *idev; > struct rt6_info *rt; > int err; > + int hiscore = -1, score; > > rt = (struct rt6_info *) dst; > if (rt) > @@ -497,17 +691,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 +734,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 +765,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 +860,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 +940,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 +1213,7 @@ > struct inet6_ifaddr * ifp; > struct in6_addr addr; > int plen; > + int create = 0; > > plen = pinfo->prefix_len >> 3; > > @@ -924,6 +1249,7 @@ > return; > } > > + create = 1; > addrconf_dad_start(ifp); > } > > @@ -934,6 +1260,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 +1275,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 +2275,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 +2322,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 +2362,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; > } > > -- 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 yoshfuji@linux-ipv6.org Wed Oct 30 23:31:36 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 23:31:40 -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 g9V7VZuR023646 for ; Wed, 30 Oct 2002 23:31:36 -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 g9V7W9GR014842; Thu, 31 Oct 2002 16:32:09 +0900 Date: Thu, 31 Oct 2002 16:32:09 +0900 (JST) Message-Id: <20021031.163209.595697847.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, 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.124459.66300488.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: ,!^C1nUj;HDn\o}#MDnZW<|oj*]iIB/>/Rj|xZ=D=hBIY#)lQ,$n#kJvDg7at|p;w0^8&4_ OS17ezZP7m/LlFJYPF}FdcGx!,qBM:w{Ub2#M8_@n^nYT%?u+bwTsqni(z5 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: 1033 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 09:25:01 +0200 (EET)), Pekka Savola says: > I belive privacy extensions can be harmful for especially long-lived > applications and lead to a false sense of security: they should not be > enabled (by any definition of enabled) by default. Temporary addresses are generated (on most links) but not used by default (latter is done by source address selection) by my patch. Set sysctl net.ipv6.conf.ethXX.use_tempaddr > 1 to use it by default. (I have per-application setsockopt interface but it is not included because patch for source address selection is not accepted at this moment.) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pekkas@netcore.fi Wed Oct 30 23:43:17 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 23:43:21 -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 g9V7hGuR024091 for ; Wed, 30 Oct 2002 23:43:17 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9V7heO19666; Thu, 31 Oct 2002 09:43:40 +0200 Date: Thu, 31 Oct 2002 09:43:40 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: linux-kernel@vger.kernel.org, , , , Subject: Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 In-Reply-To: <20021031.163209.595697847.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 1034 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, 31 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Thu, 31 Oct 2002 09:25:01 +0200 (EET)), Pekka Savola says: > > > I belive privacy extensions can be harmful for especially long-lived > > applications and lead to a false sense of security: they should not be > > enabled (by any definition of enabled) by default. > > Temporary addresses are generated (on most links) but not used by default > (latter is done by source address selection) by my patch. > Set sysctl net.ipv6.conf.ethXX.use_tempaddr > 1 to use it by default. > > (I have per-application setsockopt interface but it is not included > because patch for source address selection is not accepted at this moment.) Generating and re-generating new temporary addresses seems to be a useless work and just new addresses unless they're being used at least by some applications. -- 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 hari@cosystech.com Wed Oct 30 23:45:28 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 23:45:30 -0800 (PST) Received: from thewall.cosystech.com (lan-202-144-95-57.maa.sify.net [202.144.95.57] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V7jOuR024507 for ; Wed, 30 Oct 2002 23:45:26 -0800 Received: from lynx.cosystech.com (lynx.cosystech.com [192.9.200.45]) by thewall.cosystech.com (8.11.2/8.11.6) with SMTP id g9V7Vc610453 for ; Thu, 31 Oct 2002 13:01:43 +0530 Received: from harish ([192.9.200.229]) by lynx.cosystech.com (5.x/SMI-SVR4) id AA03311; Thu, 31 Oct 2002 13:17:29 +0530 From: "Harish Kulkarni" To: Subject: Network Device-Driver/Layer Implementation: Help required Date: Thu, 31 Oct 2002 13:25:18 +0530 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15808.11521.25342.659187@robur.slu.se> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 X-archive-position: 1035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hari@cosystech.com Precedence: bulk X-list: netdev Hello all, I have a T1/E1 device driver: ( completed till PCI initialization and other device-internals initialization,including interrupts handling procedures), now i am not understanding how to provide the interface to upper layers?. I have walked through the lapb-module.txt and some code of IPX, but still the things are not clear. Can any one help/guide me? -Thanks Hari > -----Original Message----- > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com]On > Behalf Of Robert Olsson > Sent: Thursday, October 31, 2002 12:33 AM > To: Cheng Jin > Cc: jamal; netdev@oss.sgi.com > Subject: Re: Linux SMP on 2.4.18-3 > > > > Cheng Jin writes: > > > Out of curiosity, what is the maximum send rate (pps) under Linux > > 2.4.18-3? I read in the paper that sending across two Intel > Gbe with one > > CPU gets up to 36o Kpps. > > Yes forwarding performance... > > A good chip/driver can itself do a lot more. I have seen very > decent numbers > with e1000, tg3 and dl2k. For FE tulip has been a top performer for long > time but I also now see 144 kpps from my laptop w. 3c59x driver. > > Cheers. > --ro > > > From yoshfuji@linux-ipv6.org Wed Oct 30 23:49:03 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 23:49:04 -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 g9V7n2uR024901 for ; Wed, 30 Oct 2002 23:49:02 -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 g9V7nfGR014961; Thu, 31 Oct 2002 16:49:41 +0900 Date: Thu, 31 Oct 2002 16:49:40 +0900 (JST) Message-Id: <20021031.164940.672083668.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, 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.163209.595697847.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: ,!^C1nUj;HDn\o}#MDnZW<|oj*]iIB/>/Rj|xZ=D=hBIY#)lQ,$n#kJvDg7at|p;w0^8&4_ OS17ezZP7m/LlFJYPF}FdcGx!,qBM:w{Ub2#M8_@n^nYT%?u+bwTsqni(z5 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: 1036 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 09:43:40 +0200 (EET)), Pekka Savola says: > Generating and re-generating new temporary addresses seems to be a useless > work and just new addresses unless they're being used at least by some > applications. set default to 0 (don't use it) for now is ok? --yoshfuji From werner@almesberger.net Wed Oct 30 23:58:33 2002 Received: with ECARTIS (v1.0.0; list netdev); Wed, 30 Oct 2002 23:58:35 -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 g9V7wXuR025424 for ; Wed, 30 Oct 2002 23:58:33 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id XAA05338 for ; Wed, 30 Oct 2002 23:59:16 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id g9V7x9E15760 for netdev@oss.sgi.com; Thu, 31 Oct 2002 04:59:09 -0300 Date: Thu, 31 Oct 2002 04:59:09 -0300 From: Werner Almesberger To: netdev@oss.sgi.com Subject: TCP connection passing, version 1 Message-ID: <20021031045909.A15756@almesberger.net> References: <20021031000249.A20233@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031000249.A20233@almesberger.net>; from wa@almesberger.net on Thu, Oct 31, 2002 at 12:02:49AM -0300 X-archive-position: 1037 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 little update: http://www.almesberger.net/tcpcp/tcpcp-1.tar.gz This one gets timestamps right, but needs to change a few things in the rest of TCP. I've also added a Web server demo application. - Werner ----------------------------------- CHANGES ----------------------------------- Version 1 (31-OCT-2002) ----------------------- - tcpcp_hooks now try to load the tcpcp module - added ts_offset to struct tcp_opt and related structures, so that tcpcp can adjust local timestamps on a per-socket basis - added app/sendcp, a simple Web server with connection passing - /proc/sys/net/ipv4/sysctl_privileged was not created when using tcpcp as a module -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From pb@bieringer.de Thu Oct 31 00:19:20 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 00:19:26 -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 g9V8J9uR026170 for ; Thu, 31 Oct 2002 00:19:10 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 7092413859; Thu, 31 Oct 2002 08:50:53 +0100 (CET) X-AV-Checked: Thu Oct 31 08:50:53 2002 smtp2.aerasec.de Received: from pD9E4E1D7.dip.t-dialin.net (pD9E4E1D7.dip.t-dialin.net [::ffff:217.228.225.215]) (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 5225913857; Thu, 31 Oct 2002 08:50:46 +0100 (CET) Date: Thu, 31 Oct 2002 08:50:43 +0100 From: Peter Bieringer To: "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" , netdev@oss.sgi.com Cc: usagi@linux-ipv6.org Subject: Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Message-ID: <13640000.1036050643@localhost> In-Reply-To: <20021031.124459.66300488.yoshfuji@linux-ipv6.org> References: <20021031.124459.66300488.yoshfuji@linux-ipv6.org> 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="==========1729506916==========" X-archive-position: 1038 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 --==========1729506916========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, btw: many credits for your hard work to split the big USAGI extension into by kernel developers acceptable parts! How many percent are already proceeded? --On Thursday, October 31, 2002 12:44:59 PM +0900 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" wrote: > This patch is against linux-2.5.44+bk2 snapshot. Do you plan also to release a patch for 2.4.20+? Thank you very much, 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 --==========1729506916========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9wODVe1eqe5WPQi0RAjaHAJ9MEjxkggU+T0Nm304Fd1N8BgjxzwCg6NvN PEhqzoLLinEs1sh3Haxu68c= =2V3j -----END PGP SIGNATURE----- --==========1729506916==========-- From pekkas@netcore.fi Thu Oct 31 00:23:46 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 00:23:49 -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 g9V8NjuR026783 for ; Thu, 31 Oct 2002 00:23:46 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9V8OBe20022; Thu, 31 Oct 2002 10:24:11 +0200 Date: Thu, 31 Oct 2002 10:24:11 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: linux-kernel@vger.kernel.org, , , , Subject: Re: [PATCH] IPv6: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 In-Reply-To: <20021031.164940.672083668.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 1039 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, 31 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Thu, 31 Oct 2002 09:43:40 +0200 (EET)), Pekka Savola says: > > > Generating and re-generating new temporary addresses seems to be a useless > > work and just new addresses unless they're being used at least by some > > applications. > > 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). (This is why I never perceived privacy addresses as a critical work item at the moment -- e.g. multicast routing might be more interesting.) I don't know how Dave and Alexey feel, of course. -- 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 takamiya@po.ntts.co.jp Thu Oct 31 00:45:35 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 00:45:41 -0800 (PST) Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V8jYuR027734 for ; Thu, 31 Oct 2002 00:45:34 -0800 Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id RAA08345 for ; Thu, 31 Oct 2002 17:46:15 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: from daemon.inl.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id g9V8kEX05364 for ; Thu, 31 Oct 2002 17:46:14 +0900 (JST) (envelope-from takamiya@po.ntts.co.jp) Received: (qmail 99309 invoked by alias); 31 Oct 2002 17:46:13 +0900 Received: (qmail 99254 invoked from network); 31 Oct 2002 17:46:12 +0900 Received: from localhost by localhost with SMTP; 31 Oct 2002 17:46:12 +0900 Date: Thu, 31 Oct 2002 17:44:42 +0900 (JST) Message-Id: <20021031.174442.846937513.takamiya@po.ntts.co.jp> To: ajtuomin@morphine.tml.hut.fi Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@wide.ad.jp, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 From: Noriaki Takamiya In-Reply-To: <20021017162624.GC16370@morphine.tml.hut.fi> References: <20021017162624.GC16370@morphine.tml.hut.fi> X-Mailer: Mew version 3.0.55 on XEmacs 21.4.8 (Honest Recruiter) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1040 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: takamiya@po.ntts.co.jp Precedence: bulk X-list: netdev Hi, This is Takamiya, a member of USAGI Project. Your work is very cool. However, we believe there are several issues on direction / design and behavior in your implementation. Please note that we're preparing for checking to what extent this patch is compliant to the Internet draft of MIPv6. So we may comment other things later. (1) About MIPV6CALLFUNC and MIPV6CALLPROC It is reasonable to use these macros for modularized functions. But the current your implementation needs to select HA or MN when compiling the kernel. So, it doesn't seems to be needed this macros, and the real function may be called directly. How about this? Rather, how about using sysctl and so on to switch the functionality? (2) Avoiding Netfilter Hooks In your imprementation HA uses netfilter to intercept packets sent to MN. We think it is costy so we have a suggestion to use FIB structure to forward packets to MN. Bacause we think forwarding packets from HA to MN is FORWARDING, not FILTERING. We think the kernel maintainers may prefer such a manner using FIB structure for forwarding. (3) Binding Cache We think it is reasonable way to use FIB structure to holding Binding Cache Entries if you us FIB structure for forwarding packets from HA to MN as we suggested (4). (4) Processing Mobility Header How about using ip6_txoptions and hdrproc_lst? Because Mobility header is an extension header, we think it is reasonable way to handle it in ipv6_parse_exthdrs(). (5) How about using CryptoAPI? CryptoAPI is merged to mainline. We believe we can use the CryptoAPI for caluculating cookies of RR. How do you think about this? (6) Order of HAO and Routing header When MN acts also as CN, the order doesn't seems to be compliant to ID-18 in the implementation. The order will be the following: [IPv6][HAO][RT2] I-D says: [IPv6][RT2][HAO] (7) Source Address Selection of MN When host acts as MN, your implementation always select HoA as the source address. The source address should be a CoA. Regards, -- Noriaki Takamiya From pekkas@netcore.fi Thu Oct 31 01:00:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 01:00:10 -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 g9V907uR028200 for ; Thu, 31 Oct 2002 01:00:08 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9V8tum20299; Thu, 31 Oct 2002 10:55:56 +0200 Date: Thu, 31 Oct 2002 10:55:56 +0200 (EET) From: Pekka Savola To: Noriaki Takamiya cc: ajtuomin@morphine.tml.hut.fi, , , , , , , Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: <20021031.174442.846937513.takamiya@po.ntts.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1041 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, 31 Oct 2002, Noriaki Takamiya wrote: > (2) Avoiding Netfilter Hooks > In your imprementation HA uses netfilter to intercept packets > sent to MN. We think it is costy so we have a suggestion to > use FIB structure to forward packets to MN. Bacause we think > forwarding packets from HA to MN is FORWARDING, not FILTERING. > We think the kernel maintainers may prefer such a manner using > FIB structure for forwarding. Sounds sensible. > (7) Source Address Selection of MN > When host acts as MN, your implementation always select HoA as the > source address. The source address should be a CoA. No, draft-ietf-ipv6-default-addr-select-09.txt Rule 4 says home addresses should be preferred, except via a possible API interaction. -- 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 yoshfuji@linux-ipv6.org Thu Oct 31 01:08:47 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 01:08:49 -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 g9V98kuR028660 for ; Thu, 31 Oct 2002 01:08:47 -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 g9V98xGR015543; Thu, 31 Oct 2002 18:08:59 +0900 Date: Thu, 31 Oct 2002 18:08:53 +0900 (JST) Message-Id: <20021031.180853.380251036.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: takamiya@po.ntts.co.jp, ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com, jagana@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021031.174442.846937513.takamiya@po.ntts.co.jp> 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: ,!^C1nUj;HDn\o}#MDnZW<|oj*]iIB/>/Rj|xZ=D=hBIY#)lQ,$n#kJvDg7at|p;w0^8&4_ OS17ezZP7m/LlFJYPF}FdcGx!,qBM:w{Ub2#M8_@n^nYT%?u+bwTsqni(z5 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: 1042 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:55:56 +0200 (EET)), Pekka Savola says: > > (7) Source Address Selection of MN > > When host acts as MN, your implementation always select HoA as the > > source address. The source address should be a CoA. > > No, draft-ietf-ipv6-default-addr-select-09.txt Rule 4 says home addresses > should be preferred, except via a possible API interaction. Yes, we know. What we meant was there are some cases that we need to use actual address on the device, not HoA. ---yoshfuji From yoshfuji@linux-ipv6.org Thu Oct 31 01:17:22 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 01:17:23 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9V9HLuR029084 for ; Thu, 31 Oct 2002 01:17: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 g9V9HtGR015600; Thu, 31 Oct 2002 18:18:01 +0900 Date: Thu, 31 Oct 2002 18:17:55 +0900 (JST) Message-Id: <20021031.181755.739870345.yoshfuji@linux-ipv6.org> To: pb@bieringer.de Cc: netdev@oss.sgi.com, 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: <13640000.1036050643@localhost> References: <20021031.124459.66300488.yoshfuji@linux-ipv6.org> <13640000.1036050643@localhost> 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: ,!^C1nUj;HDn\o}#MDnZW<|oj*]iIB/>/Rj|xZ=D=hBIY#)lQ,$n#kJvDg7at|p;w0^8&4_ OS17ezZP7m/LlFJYPF}FdcGx!,qBM:w{Ub2#M8_@n^nYT%?u+bwTsqni(z5 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: 1043 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 <13640000.1036050643@localhost> (at Thu, 31 Oct 2002 08:50:43 +0100), Peter Bieringer says: > > This patch is against linux-2.5.44+bk2 snapshot. > > Do you plan also to release a patch for 2.4.20+? You need to apply the following patch too. Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ajtuomin@tml.hut.fi Thu Oct 31 02:44:30 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 02:44:32 -0800 (PST) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VAiNuR001562 for ; Thu, 31 Oct 2002 02:44:28 -0800 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id MAA29987 for ; Thu, 31 Oct 2002 12:45:04 +0200 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma029978; Thu, 31 Oct 02 12:44:58 +0200 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9VAh0Ml001595; Thu, 31 Oct 2002 12:43:00 +0200 (EET) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9VAguF5019202; Thu, 31 Oct 2002 12:42:56 +0200 (EET) Received: (from ajtuomin@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) id g9VAflLV019200; Thu, 31 Oct 2002 12:41:47 +0200 (EET) Date: Thu, 31 Oct 2002 12:41:46 +0200 From: Antti Tuominen To: Noriaki Takamiya Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@wide.ad.jp, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 Message-ID: <20021031104146.GA18786@morphine.tml.hut.fi> References: <20021017162624.GC16370@morphine.tml.hut.fi> <20021031.174442.846937513.takamiya@po.ntts.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031.174442.846937513.takamiya@po.ntts.co.jp> User-Agent: Mutt/1.4i X-archive-position: 1044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ajtuomin@morphine.tml.hut.fi Precedence: bulk X-list: netdev On Thu, Oct 31, 2002 at 05:44:42PM +0900, Noriaki Takamiya wrote: > Hi, Hello Takamiya, > Please note that we're preparing for checking to what extent this > patch is compliant to the Internet draft of MIPv6. May I ask with what? We ran all the TAHI tests last month at ETSI IPv6 Plugtest, and know pretty much were we stand. And with all due respect to TAHI, who checks that the test suites conform to the spec? > (1) About MIPV6CALLFUNC and MIPV6CALLPROC > It is reasonable to use these macros for modularized > functions. But the current your implementation needs to select > HA or MN when compiling the kernel. So, it doesn't seems to be > needed this macros, and the real function may be called > directly. How about this? If MIPv6 is compiled as module, and is not loaded, those macros protect against calling non-existant code. HA and MN do not need to be compiled statically, if that is what you are implying. You must first select CN support, which decides module or static. > Rather, how about using sysctl and so on to switch the > functionality? No. Users want to be able to have only one of the capabilities loaded at one time (i.e. CN, CN+MN or CN+HA). When you compile e.g. CN, there is no HA or MN support compiled in, so the sysctl makes no sense. > (4) Processing Mobility Header > How about using ip6_txoptions and hdrproc_lst? > Because Mobility header is an extension header, we think it is > reasonable way to handle it in ipv6_parse_exthdrs(). No. We did this back in Draft 15, when all the mobility stuff was destination options. Mobility Header is not an extension header, but rather a final protocol. Only Home Address Option is an extension header and is handled in ipv6/exthdrs.c. What is the problem with this? > (5) How about using CryptoAPI? > CryptoAPI is merged to mainline. > We believe we can use the CryptoAPI for caluculating cookies > of RR. How do you think about this? Yes, this will be done. But that was merged yesterday, and we are only humans :) > (6) Order of HAO and Routing header > When MN acts also as CN, the order doesn't seems to be > compliant to ID-18 in the implementation. The order will be > the following: > > [IPv6][HAO][RT2] > > I-D says: > > [IPv6][RT2][HAO] Right. We haven't changed the IPv6 code to support the third destination option header placement (after RH, before frag/AH/ESP), and since it introduces no compatibility problems with any other implementation we've tested with, it has not been a priority. Regards, Antti -- Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland. Research assistant, Institute of Digital Communications at HUT work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi From lpetande@morphine.tml.hut.fi Thu Oct 31 02:47:57 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 02:47:59 -0800 (PST) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VAluuR001948 for ; Thu, 31 Oct 2002 02:47:57 -0800 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id MAA30140 for ; Thu, 31 Oct 2002 12:48:37 +0200 X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma030071; Thu, 31 Oct 02 12:46:52 +0200 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9VAivMl001608; Thu, 31 Oct 2002 12:44:57 +0200 (EET) Received: from tml.hut.fi (localhost [127.0.0.1]) by morphine.tml.hut.fi (8.12.2+Sun/8.12.2) with ESMTP id g9VAiuF5019208; Thu, 31 Oct 2002 12:44:56 +0200 (EET) Received: from localhost (lpetande@localhost) by tml.hut.fi (8.12.2+Sun/8.12.2/Submit) with ESMTP id g9VAi0I5019205; Thu, 31 Oct 2002 12:44:00 +0200 (EET) Date: Thu, 31 Oct 2002 12:44:00 +0200 (EET) From: Henrik Petander To: Noriaki Takamiya cc: ajtuomin@morphine.tml.hut.fi, , , , , , , , Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 In-Reply-To: <20021031.174442.846937513.takamiya@po.ntts.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1045 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lpetande@morphine.tml.hut.fi Precedence: bulk X-list: netdev Hi Noriaki, On Thu, 31 Oct 2002, Noriaki Takamiya wrote: > Hi, > > This is Takamiya, a member of USAGI Project. > Your work is very cool. Thanks. > > Please note that we're preparing for checking to what extent this > patch is compliant to the Internet draft of MIPv6. We are interested in seeing the results, especially if the tests are based on the draft19, which ought to be published soon based on the discussions in the mobile-ip mailing list. > > (2) Avoiding Netfilter Hooks > In your imprementation HA uses netfilter to intercept packets > sent to MN. We think it is costy so we have a suggestion to > use FIB structure to forward packets to MN. Bacause we think > forwarding packets from HA to MN is FORWARDING, not FILTERING. > We think the kernel maintainers may prefer such a manner using > FIB structure for forwarding. We are using standard routing in HA to route packets intercepted by HA to MN through a tunnel device. However, HA needs to also act as a neighbor discovery proxy for MN and not tunnel any ND packets destined to MN, but reply to them on the bahalf of MN. We use the netfilter hook to check for ND packets with global addresses that would be otherwise tunneled and feed them directly to the local processing code. Thanks, Henrik Petander ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- From s9905155@sms.ed.ac.uk Thu Oct 31 04:12:26 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 04:12:31 -0800 (PST) Received: from grassmarket.ucs.ed.ac.uk (grassmarket.ucs.ed.ac.uk [129.215.166.64]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VCCPuR004515 for ; Thu, 31 Oct 2002 04:12:26 -0800 Received: (from nobody@localhost) by grassmarket.ucs.ed.ac.uk (8.11.6/8.11.6) id g9VCD5k08313 for netdev@oss.sgi.com; Thu, 31 Oct 2002 12:13:05 GMT From: BJ Cran X-Authentication-Warning: grassmarket.ucs.ed.ac.uk: nobody set sender to s9905155@sms.ed.ac.uk using -f To: netdev@oss.sgi.com Subject: ipv4 /proc/net/route bug in 2.4 and 2.5 kernels Message-ID: <1036066385.3dc11e51d11ab@sms.ed.ac.uk> Date: Thu, 31 Oct 2002 12:13:05 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Originating-IP: 129.215.124.238 X-archive-position: 1046 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: s9905155@sms.ed.ac.uk Precedence: bulk X-list: netdev Hi, I've discovered a bug in the 2.4 and 2.5 kernels relating to the information in /proc. The values reported in /proc/net/route are wrong - the main error is the MTU field which should be MSS, and should be the MTU-40. The route command has the header fixed, but still gets the value from /proc, and so reports the wrong value of 40. I'm currently using 2.5.43, and have tracked it down to line 1031 in net/ipv4/fib_semantics.c in function fib_node_seq_show. It appears that fi->fib_advmss is 0, because when I change the '+40' to '+45' that is the value which appears in the MTU field in /proc/net/route, and in the MSS field when running '/sbin/route -e'. Also, on line 191 of net/ipv4/ip_proc.c (in function fib_seq_show), I think the 'MTU' should be 'MSS' according to the comments in route.c, and to make the output of the route command and the proc entry consistent. I've also posted this bug report to the lkml, but haven't had any reply. I realise that it isn't a priority with more serious bugs in 2.5 needing fixed, but it would be nice to get the information correct, especially since this bug has been around since the 2.4-pre kernels. Thanks. -- Bruce Cran From jleu@nero.doit.wisc.edu Thu Oct 31 07:34:48 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 07:34:52 -0800 (PST) Received: from nero.doit.wisc.edu (IDENT:root@nero.doit.wisc.edu [128.104.17.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g9VFYluR014239 for ; Thu, 31 Oct 2002 07:34:48 -0800 Received: (from jleu@localhost) by nero.doit.wisc.edu (8.11.6/8.11.6) id g9VGZom06938; Thu, 31 Oct 2002 10:35:50 -0600 Date: Thu, 31 Oct 2002 10:35:49 -0600 From: "James R. Leu" To: Harish Kulkarni Cc: netdev@oss.sgi.com Subject: Re: Network Device-Driver/Layer Implementation: Help required Message-ID: <20021031103549.A6846@nero.doit.wisc.edu> Reply-To: jleu@mindspring.com References: <15808.11521.25342.659187@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from hari@cosystech.com on Thu, Oct 31, 2002 at 01:25:18PM +0530 Organization: none X-archive-position: 1047 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jleu@mindspring.com Precedence: bulk X-list: netdev What L2 protocols will it support? This will determin how you present it to the network stack. At a minimum it will have to create a net_device which has all sorts of function pointers in it that you will have to implement. On Thu, Oct 31, 2002 at 01:25:18PM +0530, Harish Kulkarni wrote: > Hello all, > I have a T1/E1 device driver: ( completed till PCI initialization and other > device-internals initialization,including interrupts handling procedures), > now i am not understanding how to provide the interface to upper layers?. I > have walked through the lapb-module.txt and some code of IPX, but still the > things are not clear. Can any one help/guide me? > -Thanks > Hari > > > > -----Original Message----- > > From: netdev-bounce@oss.sgi.com [mailto:netdev-bounce@oss.sgi.com]On > > Behalf Of Robert Olsson > > Sent: Thursday, October 31, 2002 12:33 AM > > To: Cheng Jin > > Cc: jamal; netdev@oss.sgi.com > > Subject: Re: Linux SMP on 2.4.18-3 > > > > > > > > Cheng Jin writes: > > > > > Out of curiosity, what is the maximum send rate (pps) under Linux > > > 2.4.18-3? I read in the paper that sending across two Intel > > Gbe with one > > > CPU gets up to 36o Kpps. > > > > Yes forwarding performance... > > > > A good chip/driver can itself do a lot more. I have seen very > > decent numbers > > with e1000, tg3 and dl2k. For FE tulip has been a top performer for long > > time but I also now see 144 kpps from my laptop w. 3c59x driver. > > > > Cheers. > > --ro > > > > > > > -- James R. Leu From willy@www.linux.org.uk Thu Oct 31 11:01:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 11:01:27 -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 g9VJ1NuR024898 for ; Thu, 31 Oct 2002 11:01:24 -0800 Received: from willy by www.linux.org.uk with local (Exim 3.33 #5) id 187KZx-0001Pu-00; Thu, 31 Oct 2002 19:02:05 +0000 Date: Thu, 31 Oct 2002 19:02:05 +0000 From: Matthew Wilcox To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] update packet & wanpipe ioctl routines Message-ID: <20021031190205.M27461@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 1048 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev Convert af_packet.c and af_wanpipe.c to call dev_ioctl by default. I'm less than convinced these protocols should be calling inet_ioctl, but I'm not going to change that behaviour. diff -urpNX dontdiff linux-2.5.45/net/packet/af_packet.c linux-2.5.45-willy/net/packet/af_packet.c --- linux-2.5.45/net/packet/af_packet.c 2002-10-31 10:28:10.000000000 -0500 +++ linux-2.5.45-willy/net/packet/af_packet.c 2002-10-29 17:25:30.000000000 -0500 @@ -1432,8 +1432,7 @@ static int packet_ioctl(struct socket *s { struct sock *sk = sock->sk; - switch(cmd) - { + switch(cmd) { case SIOCOUTQ: { int amount = atomic_read(&sk->wmem_alloc); @@ -1452,35 +1451,12 @@ static int packet_ioctl(struct socket *s return put_user(amount, (int *)arg); } case SIOCGSTAMP: - if(sk->stamp.tv_sec==0) + if (sk->stamp.tv_sec==0) return -ENOENT; if (copy_to_user((void *)arg, &sk->stamp, sizeof(struct timeval))) return -EFAULT; break; - case SIOCGIFFLAGS: -#ifndef CONFIG_INET - case SIOCSIFFLAGS: -#endif - case SIOCGIFCONF: - case SIOCGIFMETRIC: - case SIOCSIFMETRIC: - case SIOCGIFMEM: - case SIOCSIFMEM: - case SIOCGIFMTU: - case SIOCSIFMTU: - case SIOCSIFLINK: - case SIOCGIFHWADDR: - case SIOCSIFHWADDR: - case SIOCSIFMAP: - case SIOCGIFMAP: - case SIOCSIFSLAVE: - case SIOCGIFSLAVE: - case SIOCGIFINDEX: - case SIOCGIFNAME: - case SIOCGIFCOUNT: - case SIOCSIFHWBROADCAST: - return(dev_ioctl(cmd,(void *) arg)); #ifdef CONFIG_INET case SIOCADDRT: @@ -1501,7 +1477,7 @@ static int packet_ioctl(struct socket *s #endif default: - return -EOPNOTSUPP; + return dev_ioctl(cmd, (void *)arg); } return 0; } diff -urpNX dontdiff linux-2.5.45/net/wanrouter/af_wanpipe.c linux-2.5.45-willy/net/wanrouter/af_wanpipe.c --- linux-2.5.45/net/wanrouter/af_wanpipe.c 2002-10-31 10:28:10.000000000 -0500 +++ linux-2.5.45-willy/net/wanrouter/af_wanpipe.c 2002-10-29 16:34:36.000000000 -0500 @@ -1922,30 +1922,6 @@ static int wanpipe_ioctl(struct socket * sock->file->f_flags |= O_NONBLOCK; return 0; - case SIOCGIFFLAGS: -#ifndef CONFIG_INET - case SIOCSIFFLAGS: -#endif - case SIOCGIFCONF: - case SIOCGIFMETRIC: - case SIOCSIFMETRIC: - case SIOCGIFMEM: - case SIOCSIFMEM: - case SIOCGIFMTU: - case SIOCSIFMTU: - case SIOCSIFLINK: - case SIOCGIFHWADDR: - case SIOCSIFHWADDR: - case SIOCSIFMAP: - case SIOCGIFMAP: - case SIOCSIFSLAVE: - case SIOCGIFSLAVE: - case SIOCGIFINDEX: - case SIOCGIFNAME: - case SIOCGIFCOUNT: - case SIOCSIFHWBROADCAST: - return(dev_ioctl(cmd,(void *) arg)); - #ifdef CONFIG_INET case SIOCADDRT: case SIOCDELRT: @@ -1968,7 +1944,7 @@ static int wanpipe_ioctl(struct socket * #endif default: - return -EOPNOTSUPP; + return dev_ioctl(cmd,(void *) arg); } /*NOTREACHED*/ } -- Revolutions do not require corporate support. From ahu@outpost.ds9a.nl Thu Oct 31 14:19:39 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 14:19: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 g9VMJcuR009825 for ; Thu, 31 Oct 2002 14:19:39 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B07894634; Thu, 31 Oct 2002 23:20:21 +0100 (CET) Date: Thu, 31 Oct 2002 23:20:21 +0100 From: bert hubert To: netdev@oss.sgi.com Subject: ipsec state? Message-ID: <20021031222021.GA19261@outpost.ds9a.nl> Mail-Followup-To: bert hubert , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1049 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 Where is ipsec right now? I see fascinating code in the kernel that is mostly disabled. I heard an earlier statement that this code would be using the freeswan pluto userspace stuff, is that still true? any estimate on when this code can be tried by the brave? I'm just itching to document this stuff on lartc.org. Thanks - this is a big thing, lots and lots of people are suddenly all excited over 2.5/2.6. I bet we're going to see a swift adoption of it, far swifter than 2.4. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From werner@almesberger.net Thu Oct 31 14:59:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 14:59:45 -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 g9VMxguR011530 for ; Thu, 31 Oct 2002 14:59:42 -0800 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.9.3/8.9.3) with ESMTP id PAA08177 for ; Thu, 31 Oct 2002 15:00:23 -0800 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id g9VN0HC21557 for netdev@oss.sgi.com; Thu, 31 Oct 2002 20:00:17 -0300 Date: Thu, 31 Oct 2002 20:00:17 -0300 From: Werner Almesberger To: netdev@oss.sgi.com Subject: TCP connection passing, version 2 Message-ID: <20021031200017.A21544@almesberger.net> References: <20021031000249.A20233@almesberger.net> <20021031045909.A15756@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021031045909.A15756@almesberger.net>; from wa@almesberger.net on Thu, Oct 31, 2002 at 04:59:09AM -0300 X-archive-position: 1050 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wa@almesberger.net Precedence: bulk X-list: netdev Another update: http://www.almesberger.net/tcpcp/tcpcp-2.tar.gz This one fixes window, MSS, and buffer space handling. I've also added a bit of documentation describing how to use it properly. - Werner ----------------------------------- CHANGES ----------------------------------- Version 2 (31-OCT-2002) ----------------------- - removed 1000 "voodoo slack" term in __tcpcp_maxicisize's size estimate - tcpcp.c:tcpcp_init now correctly identifies the version as the one of the ICI format, not as the one of tcpcp itself - tcpcp.c:tcpcp_buffers checks send sequence numbers - tcpcp.c:tcpcp_fixup adjusts receive buffer to advertized window - tcpcp.c:tcpcp_fixup sets MSS clamp to value from ICI - documented request_module race in tcpcp_hooks.c - README and tcpcp.c: added discussion of usefulness of tcpcp_start - added description of handover procedure in doc/README.HANDOVER - minor cleanups here and there -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From krkumar@us.ibm.com Thu Oct 31 18:18:52 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 18:18:55 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA12IpuR019688 for ; Thu, 31 Oct 2002 18:18:52 -0800 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA12JUgI059200; Thu, 31 Oct 2002 21:19:30 -0500 Received: from gateway.beaverton.ibm.com (gateway.beaverton.ibm.com [138.95.180.1]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA12JNM4122546; Thu, 31 Oct 2002 21:19:23 -0500 Received: from eng2.beaverton.ibm.com (eng2.beaverton.ibm.com [9.47.57.17]) by gateway.beaverton.ibm.com (8.10.0.Beta10/8.11.6) with ESMTP id gA12JNb04619; Thu, 31 Oct 2002 18:19:23 -0800 (PST) Received: (from kkumar@localhost) by eng2.beaverton.ibm.com (8.10.0.Beta10/8.8.5/token.aware-1.2) id gA12JMn11699; Thu, 31 Oct 2002 18:19:22 -0800 (PST) From: Krishna Kumar Message-Id: <200211010219.gA12JMn11699@eng2.beaverton.ibm.com> Subject: [PATCHSET] Mobile IPv6 for 2.5.45 To: kuznet@ms2.inr.ac.ru, davem@redhat.com Date: Thu, 31 Oct 2002 18:19:21 -0800 (PST) Cc: ajtuomin@tml.hut.fi (Antti Tuominen), lpetande@tml.hut.fi (Petander Henrik), jagana@us.ibm.com, krkumar@us.ibm.com (Krishna Kumar), netdev@oss.sgi.com, linux-kernel@vger.kernel.org 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: 1051 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, We have been working with MIPL to further split the patch as you had suggested. The patch I am sending breaks this into Correspondent Node, Mobile Node and Home Agent functionalities. This patch is against 2.5.45. As part of integrating with 2.5.45 as well as due to the splitting done, there is one outstanding issue with the patch : at module unload time, some memory allocated during module_init is not freed up. However this is a small issue and we are confident of submitting a patch in a couple of days to fix this. The code base is the same that was submitted a few days ago, so the only new thing is the further splitting work and integrating with 2.5.45. The patch is in two parts, you need to first install the following patch : http://traci.mipl.mediapoli.com/patches/mipl-2.5.45.patch After that, please apply the patch at the end of this mail (created as part of 2.5.45 cleanup) to create the final tree. Once the two patches are applied, you will see separate files for the client and the agent parts. Please let us know if you need any clarification on this patch. Thanks, - KK ---------------------------- Patch 2 ------------------------------------------ diff -ruN linux-2.5.45.org/net/ipv6/ipv6_syms.c linux-2.5.45/net/ipv6/ipv6_syms.c --- linux-2.5.45.org/net/ipv6/ipv6_syms.c Thu Oct 31 18:00:41 2002 +++ linux-2.5.45/net/ipv6/ipv6_syms.c Thu Oct 31 15:07:47 2002 @@ -54,6 +54,7 @@ EXPORT_SYMBOL(ip6_rt_addr_del); EXPORT_SYMBOL(ip6_routing_table); EXPORT_SYMBOL(ip6_route_add); +EXPORT_SYMBOL(ip6_route_del); EXPORT_SYMBOL(ip6_del_rt); EXPORT_SYMBOL(fib6_clean_tree); EXPORT_SYMBOL(rt6_lock); diff -ruN linux-2.5.45.org/net/ipv6/route.c linux-2.5.45/net/ipv6/route.c --- linux-2.5.45.org/net/ipv6/route.c Thu Oct 31 17:52:04 2002 +++ linux-2.5.45/net/ipv6/route.c Thu Oct 31 13:07:03 2002 @@ -788,7 +788,7 @@ return err; } -static int ip6_route_del(struct in6_rtmsg *rtmsg) +int ip6_route_del(struct in6_rtmsg *rtmsg) { struct fib6_node *fn; struct rt6_info *rt; diff -ruN linux-2.5.45.org/net/ipv6/ipv6_tunnel.c linux-2.5.45/net/ipv6/ipv6_tunnel.c --- linux-2.5.45.org/net/ipv6/ipv6_tunnel.c Thu Oct 31 18:00:41 2002 +++ linux-2.5.45/net/ipv6/ipv6_tunnel.c Thu Oct 31 12:53:23 2002 @@ -1202,16 +1202,16 @@ t->parms.name); goto tx_err_dst_release; } - mtu = dst->pmtu - sizeof (*ipv6h); + mtu = dst->metrics[RTAX_MTU-1] - sizeof (*ipv6h); if (opt) { mtu -= (opt->opt_nflen + opt->opt_flen); } if (mtu < IPV6_MIN_MTU) mtu = IPV6_MIN_MTU; - if (skb->dst && mtu < skb->dst->pmtu) { + if (skb->dst && mtu < skb->dst->metrics[RTAX_MTU-1]) { struct rt6_info *rt6 = (struct rt6_info *) skb->dst; rt6->rt6i_flags |= RTF_MODIFIED; - rt6->u.dst.pmtu = mtu; + rt6->u.dst.metrics[RTAX_MTU-1] = mtu; } if (skb->len > mtu) { icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, dev); diff -ruN linux-2.5.45.org/net/ipv6/exthdrs.c linux-2.5.45/net/ipv6/exthdrs.c --- linux-2.5.45.org/net/ipv6/exthdrs.c Thu Oct 31 18:00:41 2002 +++ linux-2.5.45/net/ipv6/exthdrs.c Thu Oct 31 12:44:06 2002 @@ -80,7 +80,7 @@ /* An unknown option is detected, decide what to do */ -static int ip6_tlvopt_unknown(struct sk_buff *skb, int optoff) +int ip6_tlvopt_unknown(struct sk_buff *skb, int optoff) { switch ((skb->nh.raw[optoff] & 0xC0) >> 6) { case 0: /* ignore */ diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/ha.h linux-2.5.45/net/ipv6/mobile_ip6/ha.h --- linux-2.5.45.org/net/ipv6/mobile_ip6/ha.h Thu Oct 31 18:00:42 2002 +++ linux-2.5.45/net/ipv6/mobile_ip6/ha.h Thu Oct 31 15:43:25 2002 @@ -258,6 +258,13 @@ if (*lifetime > MAX_RR_BINDING_LIFE) *lifetime = MAX_RR_BINDING_LIFE; } + +static __inline__ int mipv6_del_tnl_to_mn(struct in6_addr *coa, + struct in6_addr *ha_addr, struct in6_addr *home_addr) +{ + return 0; +} + #endif /* CONFIG_IPV6_MOBILITY_HA */ #endif diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/hashlist.c linux-2.5.45/net/ipv6/mobile_ip6/hashlist.c --- linux-2.5.45.org/net/ipv6/mobile_ip6/hashlist.c Thu Oct 31 18:00:42 2002 +++ linux-2.5.45/net/ipv6/mobile_ip6/hashlist.c Thu Oct 31 16:21:08 2002 @@ -115,7 +115,9 @@ } if (hashlist->kmem) { +#if 0 kmem_cache_destroy(hashlist->kmem); +#endif hashlist->kmem = NULL; } diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/bcache.c linux-2.5.45/net/ipv6/mobile_ip6/bcache.c --- linux-2.5.45.org/net/ipv6/mobile_ip6/bcache.c Thu Oct 31 18:00:42 2002 +++ linux-2.5.45/net/ipv6/mobile_ip6/bcache.c Thu Oct 31 16:31:47 2002 @@ -905,7 +905,7 @@ del_timer(&bcache->callback_timer); while ((entry = (struct mipv6_bcache_entry *) - hashlist_get_first(bcache->entries)) != NULL) { + hashlist_get_first(bcache->entries)) != NULL) { hashkey.a1 = &entry->home_addr; hashkey.a2 = &entry->our_addr; diff -ruN linux-2.5.45.org/net/ipv6/mobile_ip6/halist.c linux-2.5.45/net/ipv6/mobile_ip6/halist.c --- linux-2.5.45.org/net/ipv6/mobile_ip6/halist.c Thu Oct 31 18:00:42 2002 +++ linux-2.5.45/net/ipv6/mobile_ip6/halist.c Thu Oct 31 16:59:17 2002 @@ -472,7 +472,9 @@ DEBUG(DBG_INFO, "Stopping the timer"); del_timer(&home_agents->expire_timer); +#if 0 mipv6_halist_gc(1); +#endif hashlist_destroy(home_agents->entries); proc_net_remove("mip6_home_agents"); diff -ruN linux-2.5.45.org/include/net/ip6_route.h linux-2.5.45/include/net/ip6_route.h --- linux-2.5.45.org/include/net/ip6_route.h Thu Oct 31 18:00:41 2002 +++ linux-2.5.45/include/net/ip6_route.h Thu Oct 31 15:09:50 2002 @@ -37,6 +37,7 @@ extern int ipv6_route_ioctl(unsigned int cmd, void *arg); extern int ip6_route_add(struct in6_rtmsg *rtmsg); +extern int ip6_route_del(struct in6_rtmsg *rtmsg); extern int ip6_del_rt(struct rt6_info *); extern int ip6_rt_addr_add(struct in6_addr *addr, diff -ruN linux-2.5.45.org/include/linux/sysctl.h linux-2.5.45/include/linux/sysctl.h --- linux-2.5.45.org/include/linux/sysctl.h Thu Oct 31 18:00:41 2002 +++ linux-2.5.45/include/linux/sysctl.h Thu Oct 31 12:32:08 2002 @@ -359,7 +359,7 @@ NET_IPV6_NEIGH=17, NET_IPV6_ROUTE=18, NET_IPV6_ICMP=19, - NET_IPV6_BINDV6ONLY=20 + NET_IPV6_BINDV6ONLY=20, NET_IPV6_MOBILITY=21 }; ---------------------------- End of Patch ------------------------------------- From davem@redhat.com Thu Oct 31 18:26:43 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 18:26:45 -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 gA12QhuR020071 for ; Thu, 31 Oct 2002 18:26:43 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id SAA20908; Thu, 31 Oct 2002 18:17:09 -0800 Date: Thu, 31 Oct 2002 18:17:08 -0800 (PST) Message-Id: <20021031.181708.102783497.davem@redhat.com> To: krkumar@us.ibm.com Cc: kuznet@ms2.inr.ac.ru, ajtuomin@tml.hut.fi, lpetande@tml.hut.fi, jagana@us.ibm.com, 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: <200211010219.gA12JMn11699@eng2.beaverton.ibm.com> References: <200211010219.gA12JMn11699@eng2.beaverton.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: 1052 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 Why isn't the home agent code being done in userspace? That is where it belongs. It's huge. From yoshfuji@wide.ad.jp Thu Oct 31 18:35:31 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 18:35:34 -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 gA12ZTuR020485 for ; Thu, 31 Oct 2002 18:35:30 -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 gA12aCGR022228; Fri, 1 Nov 2002 11:36:13 +0900 Date: Fri, 01 Nov 2002 11:36:12 +0900 (JST) Message-Id: <20021101.113612.10745857.yoshfuji@wide.ad.jp> To: davem@redhat.com Cc: krkumar@us.ibm.com, kuznet@ms2.inr.ac.ru, ajtuomin@tml.hut.fi, lpetande@tml.hut.fi, jagana@us.ibm.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021031.181708.102783497.davem@redhat.com> References: <200211010219.gA12JMn11699@eng2.beaverton.ibm.com> <20021031.181708.102783497.davem@redhat.com> 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-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: 1053 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev In article <20021031.181708.102783497.davem@redhat.com> (at Thu, 31 Oct 2002 18:17:08 -0800 (PST)), "David S. Miller" says: > > Why isn't the home agent code being done in userspace? That is > where it belongs. It's huge. I think core part of HA belongs to kernel (forwarding etc.) Registration process should live in user space. --yoshfuji From mis_fotos_privadas_mirror@yahoo.com.ar Thu Oct 31 19:56:24 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 19:56:28 -0800 (PST) Received: from localhost.localdomain (host124.200-43-224.telecom.net.ar [200.43.224.124] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA13thuR021484 for ; Thu, 31 Oct 2002 19:56:23 -0800 Received: from localhost.localdomain (vaio [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gA13u0Qp007115 for ; Fri, 1 Nov 2002 00:56:01 -0300 Received: (from mailman@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gA13twO8007108; Fri, 1 Nov 2002 00:55:58 -0300 Date: Fri, 1 Nov 2002 00:55:58 -0300 Message-Id: <200211010355.gA13twO8007108@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: mailman set sender to mis_fotos_privadas_mirror@yahoo.com.ar using -f From: Reply-To: Subject: Fw: Mis Fotos (solo adultos) To: netdev@oss.sgi.com X-archive-position: 1056 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mis_fotos_privadas_mirror@yahoo.com.ar Precedence: bulk X-list: netdev que buena que esta... > >Hola, mis fotos ya estan online, espero que las disfrutes... > >http://ar.geocities.com/mis_fotos_privadas_mirror/ > >Solo para adultos! > > > > From yoshfuji@linux-ipv6.org Thu Oct 31 19:23:09 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 19:25:21 -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 gA13MouR021101 for ; Thu, 31 Oct 2002 19:23:08 -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 gA13MIGR022630; Fri, 1 Nov 2002 12:22:18 +0900 Date: Fri, 01 Nov 2002 12:22:12 +0900 (JST) Message-Id: <20021101.122212.601751630.yoshfuji@linux-ipv6.org> To: lpetande@morphine.tml.hut.fi Cc: takamiya@po.ntts.co.jp, ajtuomin@morphine.tml.hut.fi, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021031.174442.846937513.takamiya@po.ntts.co.jp> 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: 1054 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 12:44:00 +0200 (EET)), Henrik Petander says: > > (2) Avoiding Netfilter Hooks > > In your imprementation HA uses netfilter to intercept packets > > sent to MN. We think it is costy so we have a suggestion to > > use FIB structure to forward packets to MN. Bacause we think > > forwarding packets from HA to MN is FORWARDING, not FILTERING. > > We think the kernel maintainers may prefer such a manner using > > FIB structure for forwarding. > > We are using standard routing in HA to route packets intercepted by HA to > MN through a tunnel device. However, HA needs to also act as a neighbor > discovery proxy for MN and not tunnel any ND packets destined to MN, but > reply to them on the bahalf of MN. We use the netfilter hook to check for > ND packets with global addresses that would be otherwise tunneled and feed > them directly to the local processing code. I believe that netfilter is not appropriate here. If it is protocol requirement, do it in the stack itself. Well, HA is router. Sending side: Make mip6_forward(). When new MN is being registered, setup proxy ndisc and make routes to MN via mip device (which is mip tunnel), which actually calls mip6_foward(). When packet arrives, it checks MNs and forward it to it. Receiving side: mipl tunnel receives packets from MN. check source address according to the list of MNs, then forward it. Also, I believe that the binding information should be hold as FIB entry. --yoshfuji From yoshfuji@linux-ipv6.org Thu Oct 31 19:29:06 2002 Received: with ECARTIS (v1.0.0; list netdev); Thu, 31 Oct 2002 19:31:17 -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 gA13S6uR021175 for ; Thu, 31 Oct 2002 19:29:06 -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 gA13S4GR022664; Fri, 1 Nov 2002 12:28:04 +0900 Date: Fri, 01 Nov 2002 12:27:58 +0900 (JST) Message-Id: <20021101.122758.809131116.yoshfuji@linux-ipv6.org> To: ajtuomin@morphine.tml.hut.fi Cc: takamiya@po.ntts.co.jp, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, pekkas@netcore.fi, torvalds@transmeta.com, jagana@us.ibm.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021031104146.GA18786@morphine.tml.hut.fi> References: <20021017162624.GC16370@morphine.tml.hut.fi> <20021031.174442.846937513.takamiya@po.ntts.co.jp> <20021031104146.GA18786@morphine.tml.hut.fi> 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: 1055 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 <20021031104146.GA18786@morphine.tml.hut.fi> (at Thu, 31 Oct 2002 12:41:46 +0200), Antti Tuominen says: > > (4) Processing Mobility Header > > How about using ip6_txoptions and hdrproc_lst? > > Because Mobility header is an extension header, we think it is > > reasonable way to handle it in ipv6_parse_exthdrs(). > > No. We did this back in Draft 15, when all the mobility stuff was > destination options. Mobility Header is not an extension header, but > rather a final protocol. Only Home Address Option is an extension > header and is handled in ipv6/exthdrs.c. What is the problem with > this? This is not so strong request here at this moment. --yoshfuji