From owner-netdev@oss.sgi.com Sun Jan 2 01:16:30 2000 Received: by oss.sgi.com id ; Sun, 2 Jan 2000 01:16:20 -0800 Received: from pizda.ninka.net ([216.101.162.242]:54400 "EHLO pizda.ninka.net") by oss.sgi.com with ESMTP id ; Sun, 2 Jan 2000 01:16:03 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA10012; Sun, 2 Jan 2000 01:14:37 -0800 Date: Sun, 2 Jan 2000 01:14:37 -0800 Message-Id: <200001020914.BAA10012@pizda.ninka.net> X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: rusty@linuxcare.com.au CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com In-reply-to: (message from Rusty Russell on Fri, 31 Dec 1999 15:04:46 +1100) Subject: Re: BUG: 2.3.35 SMP tcpdump crash References: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing From: Rusty Russell Date: Fri, 31 Dec 1999 15:04:46 +1100 In message <199912301714.UAA10334@ms2.inr.ac.ru> you write: > Look at new skb_expand etc., backing out this fixes the problem. Thanks. Looks like someone is doing what I never expected: calling skb_realloc_headroom() to get *less* headroom (from 32 down to 16). This fixes it; now I'm looking to see who's doing that. It doesn't matter at all who is doing it, because the old interface allowed it therefore we should continue to allow it. Sorry for the delay: urgent coffee machine repairs got priority. Patch applied, thanks. Alexey, please remove the backout of this from future softnet patchlets, thanks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Mon Jan 3 05:03:09 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 05:02:48 -0800 Received: from [202.96.44.48] ([202.96.44.48]:61082 "HELO mta3.263.net") by oss.sgi.com with SMTP id ; Mon, 3 Jan 2000 05:02:26 -0800 Received: by mta3.263.net (Postfix, from userid 60001) id 2BA7E1C5A3493; Mon, 3 Jan 2000 21:06:03 +0800 (CST) MIME-Version: 1.0 Message-Id: <38709EBB.10768@mta6> Date: Mon, 3 Jan 2000 21:06:03 +0800 (CST) From: zam_ustc@263.net To: linux-kernel@vger.rutgers.edu Cc: netdev@oss.sgi.com, netdev@roxanne.nuclecu.unam.mx, netdev@nuclecu.unam.mx Subject: Help on Kernel-Application Programme Communication X-Priority: 3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi,everyone! I am writing a IPv6 packet scheduling algorithm for the Linux kernel.I want to schedule the packets according to the priority assigned to them by a Priority Server. My thoughts goes as follows: The kernel maitains a priority table for each packet-flow(the packets who share the same src and dst addr, and the same ports,and so on.) Before the output of a IPv6 packet, the kernel searches its priority table,if it finds a priority for the packet,it then queues the packet in the according queue; otherwise, it sends part of the packet to a daemon programme running at the application layer. The daemon programme then transfers the packet to the Priority Server(usually not the same machine with the daemon programme) for priority. The Server respones with the priority assigned to the packet-flow. Then the daemon programme update the kernel's priority table by some mechanism(how?). The difficulty comes when I want the kernel wants to communicate with the daemon. I don't know how to implement this. Maybe it is a bad idea.But how can I? I'd really appreciate any assistance--I have been thinking on it for such a long time. Thanks a lot. Mikel _____________________________________________ Ê׶¼ÔÚÏß--ÏȽøÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net Ãâ·ÑÓÊÏä ÓʼþÔÓÖ¾ Ç©ÃûÓʼþ Óʼþ¼ÓÃÜ Óʼþ×·Éíºô ËÑË÷ÒýÇæ ¸öÈËÕ¾µã ÔÚÏßÓÎÏ· ÍøÉÏÁÄÌì ÍøÉϹҺŠ½ðÈÚÍõ¹ú ÔÚÏßɱ¶¾ ÌøÔéÊг¡ Èí¼þÏÂÔØ ÐÝÏÐÓéÀÖ Åµ·½°²È«£¬ÖúÄúe·ƽ°² From owner-netdev@oss.sgi.com Mon Jan 3 07:20:44 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 07:20:23 -0800 Received: from pizda.ninka.net ([216.101.162.242]:61057 "EHLO pizda.ninka.net") by oss.sgi.com with ESMTP id ; Mon, 3 Jan 2000 07:20:00 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id HAA10552; Mon, 3 Jan 2000 07:18:24 -0800 Date: Mon, 3 Jan 2000 07:18:24 -0800 Message-Id: <200001031518.HAA10552@pizda.ninka.net> X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: sekiya@ISI.EDU CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, venaas@nvg.ntnu.no In-reply-to: (message from Yuji Sekiya on Thu, 30 Dec 1999 22:18:56 +0900) Subject: Re: two ipv6 oops on 2.3.31 References: <199912150024.QAA06037@ns1.filetron.com> <199912151501.SAA02381@ms2.inr.ac.ru> <19991229182935.J10337@wiget> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Date: Thu, 30 Dec 1999 22:18:56 +0900 From: Yuji Sekiya > Alexey, Why this patch don't go to main kernel source ? > I check 2.3.35 and this problem is not fixed. > With this patch IPv6 work fine. And how about this patch, Alexey ? This patch made by solves ICMPV6_PKT_TOOBIG problem. I've put both of these ipv6 fixes into my tree and will send them off to Linus right now. Thanks for reminding me about it. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Mon Jan 3 07:52:03 2000 Received: by oss.sgi.com id ; Mon, 3 Jan 2000 07:51:54 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:50181 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Mon, 3 Jan 2000 07:51:30 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA22407; Mon, 3 Jan 2000 18:51:46 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200001031551.SAA22407@ms2.inr.ac.ru> Subject: Re: BUG: 2.3.35 SMP tcpdump crash To: davem@redhat.com (David S. Miller) Date: Mon, 3 Jan 2000 18:51:45 +0300 (MSK) Cc: rusty@linuxcare.com.au, netdev@oss.sgi.com In-Reply-To: <200001020914.BAA10012@pizda.ninka.net> from "David S. Miller" at Jan 2, 0 01:14:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 1303 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Alexey, please remove the backout of this from future softnet > patchlets, thanks. In progress. BTW I see real logical problem here, which I've already tried to explain earlier advocating separate functions for reallocating head room and head/tail room. Function skb_realloc_headroom() (and skb_cow()) copies only data, because it was used only in places, when we were about to modify this header and preserving it was useless. Essentially, "cow" here apply only to packet header. skb_copy() copied _all_ because it was called from obscure contexts, when we wanted to make full exact mirror of skb. Mostly it was useless work, certainly. But net/* still gets MAC header stripped, and we want to preserve it sometimes. Paul tried to generalize it. I guess to have MAC header for checking and printing in netfilter, does not it? 8) skb_realloc_tailroom() is different. Essentially, it is fully orthogonal to skb_realloc_headroom(), because it prepares skb to modify data part. One day (really soon, I hope) we will hold data separately (f.e. in page cache), so that the difference will be really drastic. Well, all this is blather, for now the only practical question is to audit code and check that skb_copy() is not used before all the information from MAC header is extracted. Alexey From owner-netdev@oss.sgi.com Tue Jan 4 13:50:01 2000 Received: by oss.sgi.com id ; Tue, 4 Jan 2000 13:49:50 -0800 Received: from [130.131.166.29] ([130.131.166.29]:18411 "EHLO canospam.agcs.com") by oss.sgi.com with ESMTP id ; Tue, 4 Jan 2000 13:49:39 -0800 Received: from frontier. (marshal.agcs.com [130.131.60.2]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id OAA02427 for ; Tue, 4 Jan 2000 14:50:15 -0700 (MST) Received: from bootstrap.agcs.com ([130.131.48.11]) by frontier.agcs.com; Tue, 04 Jan 2000 14:50:02 +0000 (MST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (8.9.3/8.9.1) with ESMTP id OAA21932 for ; Tue, 4 Jan 2000 14:49:29 -0700 (MST) Posted-Date: Tue, 4 Jan 2000 14:49:29 -0700 (MST) Received: from agcs.com ([130.131.166.110]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA1F5 for ; Tue, 4 Jan 2000 14:50:02 -0700 Message-ID: <38726B0B.118E885F@agcs.com> Date: Tue, 04 Jan 2000 14:50:03 -0700 From: Ben Greear Reply-To: greearb@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: netdev Subject: Question on ARP proxy code. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I have an application in mind that will stretch the current ARP code farther than it will go (I think.) Basically, I want to have many (100+) interfaces, each with 1-4 IP addresses hanging off of them. I don't want the box to use an IP address out of the 'real' address space for each interface, and I don't want to use subnets. Currently, I have a prototype with only 3-4 interfaces doing this with ARP-proxy and host routes. The problem is that, as far as I can tell, for every new interface I add (and it's associated IP(s)), I will have to add proxy-arp statements to every other interface for these IP(s). This obviously doesn't scale well to 100+ interfaces. So, I was thinking of implementing some sort of arp-proxy scheme where you could have two chains of rules, accept and deny. Each entry would have an IP/MASK associated with it. Basically, if you passed the accept, and you did not fail the deny rules, then the box will proxy for that IP. The rules should be ordered so that the more specific rules out-weigh the more generic (ie less significant MASK bits) rules. That should allow me to do something like: for each interface accept all ARP proxy deny ARP proxy for all IPs assigned to that interface add host route for each IP assigned to that interface done So, can this be done with current code? If not, can anyone suggest a good place to hack this into the kernel (user space daemon?) I looked at ipv4/arp.c and core/neighbour.c, but I haven't found where the decision is made whether or not to proxy for an IP. Thanks, Ben -- Ben Greear greearb@agcs.com Pager: 202-2717 (623) 581 4980 "More weight!" -- _The Crucible._ http://hydrogen:8080/home/greearb/public_html/index.html From owner-netdev@oss.sgi.com Tue Jan 4 19:19:31 2000 Received: by oss.sgi.com id ; Tue, 4 Jan 2000 19:19:22 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:38407 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Tue, 4 Jan 2000 19:19:09 -0800 Received: from gargle.linuxcare.com.au (penicillin.linuxcare.com.au [10.61.2.27]) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA12014; Wed, 5 Jan 2000 14:19:27 +1100 Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Wed, 5 Jan 2000 14:19:27 +1100 (EST) Message-Id: From: Rusty Russell To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com (David S. Miller), netdev@oss.sgi.com Subject: Re: BUG: 2.3.35 SMP tcpdump crash In-reply-to: Your message of "Mon, 03 Jan 2000 18:51:45 +0300." <200001031551.SAA22407@ms2.inr.ac.ru> Date: Wed, 05 Jan 2000 14:19:27 +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In message <200001031551.SAA22407@ms2.inr.ac.ru> you write: > skb_copy() copied _all_ because it was called from obscure contexts, > when we wanted to make full exact mirror of skb. Mostly it was useless > work, certainly. But net/* still gets MAC header stripped, and we > want to preserve it sometimes. I must be very stupid today. skb_copy() still copies MAC header: /* Copy the bytes */ memcpy(n->head,skb->head,skb->end-skb->head); Did you mean skb_cow()? > Well, all this is blather, for now the only practical question > is to audit code and check that skb_copy() is not used before all > the information from MAC header is extracted. If you mean skb_cow: why not revert my recent `fix'. Something like this, and be happy 8-). --- linux-2.3-official/net/core/skbuff.c Wed Jan 5 14:13:36 2000 +++ linux-2.3-official/net/core/skbuff.c.~2~ Wed Jan 5 14:10:55 2000 @@ -345,6 +345,9 @@ { struct sk_buff *n; + if (newheadroom < skb_headroom(skb)) + newheadroom = skb_headroom(skb); + /* * Allocate the copy buffer */ @@ -358,9 +361,8 @@ /* Set the tail pointer and length */ skb_put(n,skb->len); - - /* Copy the data only. */ - memcpy(n->data, skb->data, skb->len); + /* Copy the bytes: data pointers must point to same data. */ + memcpy(n->data - skb_headroom(skb), skb->head, skb->end-skb->head); copy_skb_header(n, skb); return n; -- Hacking time. From owner-netdev@oss.sgi.com Wed Jan 5 08:56:17 2000 Received: by oss.sgi.com id ; Wed, 5 Jan 2000 08:56:07 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:5125 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 5 Jan 2000 08:55:50 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA00702; Wed, 5 Jan 2000 19:55:16 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200001051655.TAA00702@ms2.inr.ac.ru> Subject: Re: BUG: 2.3.35 SMP tcpdump crash To: rusty@linuxcare.com.au (Rusty Russell) Date: Wed, 5 Jan 2000 19:55:16 +0300 (MSK) Cc: davem@redhat.com, netdev@oss.sgi.com In-Reply-To: from "Rusty Russell" at Jan 5, 0 02:19:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 507 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > I must be very stupid today. skb_copy() still copies MAC header: > > /* Copy the bytes */ > memcpy(n->head,skb->head,skb->end-skb->head); Superb! > If you mean skb_cow: why not revert my recent `fix'. Something like > this, and be happy 8-). Well, actually I did _not_ want to copy it in skb_cow(). When head is reallocated, copying old head is useless work. The thing, which I said about, is that potential users of skb_expand _probably_ really want this, when they expand tail. Alexey From owner-netdev@oss.sgi.com Wed Jan 5 10:02:06 2000 Received: by oss.sgi.com id ; Wed, 5 Jan 2000 10:01:57 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:19206 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 5 Jan 2000 10:01:41 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA01338; Wed, 5 Jan 2000 21:02:10 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200001051802.VAA01338@ms2.inr.ac.ru> Subject: Re: Question on ARP proxy code. To: greearb@agcs.COM Date: Wed, 5 Jan 2000 21:02:10 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <38726B0B.118E885F@agcs.com> from "Ben Greear" at Jan 5, 0 01:13:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 441 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > So, I was thinking of implementing some sort of arp-proxy scheme where you could > have two chains of rules, accept and deny. Each entry would have an IP/MASK associated > with it. Add netfilter hooks to arp.c better. It is really useful, not depending on any particular applications. > So, can this be done with current code? Your problem is solved simply by: echo 1 > /proc/sys/net/ipv4/conf/all/proxy-arp Alexey Kuznetsov From owner-netdev@oss.sgi.com Thu Jan 6 05:34:10 2000 Received: by oss.sgi.com id ; Thu, 6 Jan 2000 05:34:01 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:38828 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Thu, 6 Jan 2000 05:33:42 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA25338; Thu, 6 Jan 2000 08:34:02 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id IAA09109; Thu, 6 Jan 2000 08:34:02 -0500 (EST) Date: Thu, 6 Jan 2000 08:34:02 -0500 (EST) From: jamal To: netdev@oss.sgi.com, linux-kernel@vger.rutgers.edu cc: kuznet@ms2.inr.ac.ru Subject: [ANNOUNCE] SOFTNETing Network Drivers HOWTO Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-947133931=:8719" Content-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1804928587-947133931=:8719 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I have taken that distateful task avoided by most hackers -- something commonly reffered to in some circles as "documentation". Attached is a HOWTO describing the changes required to softnet network device drivers. I apologize for its size. ANK has disinfected the document -- so you can bet that the accuracy of its contents are not just based on Yoda's famous last advice to you all, they constitute words from the horse's mouth as well;-> I'll maintain the document until Softnet becomes mainstream. What is needed currently is a volunteer to put up this document on a fast web site somewhere and provide a CGI interface where people can submit the drivers they have tested. Some form of dbase to store the details of the tested drivers is needed. Please send me email. This is the first version; send me patches with corrections only -- flames to my email address but mostly if they are not personal post on l-k and/or netdev. cheers, jamal ---559023410-1804928587-947133931=:8719 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="softnet.drivers.HOWTO" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="softnet.drivers.HOWTO" DQpUaGlzIGRvY3VtZW50ICBpcyBpbnRlbmRlZCB0byBoZWxwIHRoZSBwb3J0 aW5nIG9mICJsZWdhY3kiIG5ldHdvcmsgDQpkcml2ZXJzIHRvIHRoZSBuZXcg aW50ZXJmYWNlIHByb3ZpZGVkIGJ5IHRoZSBuZXcgc29mdG5ldCBhcmNoaXRl Y3R1cmUuDQpJdCBkb2VzIG5vdCBkZWx2ZSBpbnRvIHRoZSBkZXRhaWxzIG9m IHNvZnRuZXQgKHRoYXQgd291bGQgYmUgYW5vdGhlcg0KYXJ0aWNsZSkuDQoN ClRocm91Z2hvdXQgdGhlIGRvY3VtZW50ICJUb3BsZXZlbCIgYW5kICJjb3Jl IiBhcmUgaW50ZXJjaGFuZ2UtYWJseQ0KdXNlZCB0byByZWZlciB0byB0aGUg bmV0d29yayBjb2RlIGFib3ZlIHRoZSBkcml2ZXIuDQoNCg0KRkxBRyBPQlNP TEVUSU9ODQotLS0tLS0tLS0tLS0tLS0NClNldmVyYWwgZGV2aWNlIGZsYWdz IGFyZSBvYnNvbGV0ZWQ7IHRoZWlyIGZ1bmN0aW9uYWxpdHkgaXMgZW1iZWRk ZWQgaW4NCmEgZGlmZmVyZW50IHJlLWluY2FybmF0aW9uIGFzIHdpbGwgYmUg ZXhwbGFpbmVkLg0KDQoqKiBUaGUgb2Jzb2xldGVkIGRldmljZSBmbGFncyBh cmU6DQoNCmRldi0+dGJ1c3kgDQpkZXYtPnN0YXJ0DQpkZXYtPmludGVycnVw dA0KDQpUaGUgY3VycmVudCByZXBsYWNlbWVudHMvbmV3IGZsYWdzIGFyZSBz dG9yZWQgaW4gdGhlDQpiaXRtYXAgZGV2LT5zdGF0ZQ0KDQpDdXJyZW50bHkg ZGVmaW5lZCBzdGF0ZSBiaXRzL2ZsYWdzIGFyZToNCg0KYml0IDA6IAkgICAg ICBMSU5LX1NUQVRFX1hPRkYNCmJpdCAxOiAgICAgICAgTElOS19TVEFURV9E T1dODQpiaXQgMzogICAgICAgIExJTktfU1RBVEVfU1RBUlQNCmJpdCA0OiAg ICAgICAgTElOS19TVEFURV9SWFNFTQ0KYml0IDU6ICAgICAgICBMSU5LX1NU QVRFX1RYU0VNDQpiaXQgNjogICAgICAgIExJTktfU1RBVEVfU0NIRUQNCg0K TElOS19TVEFURV9YT0ZGIGlzIHRoZSByZXBsYWNlbWVudCBmb3IgZGV2LT50 YnVzeQ0KDQpMSU5LX1NUQVRFX0RPV04gaXMgdGhlIHJlcGxhY2VtZW50IGZv ciB0aGUgIUlGRl9SVU5OSU5HIGNoZWNrDQoNCkxJTktfU1RBVEVfU1RBUlQg aXMgdGhlIHJlcGxhY2VtZW50IGZvciBkZXYtPnN0YXJ0DQoNCkxJTktfU1RB VEVfUlhTRU0gaXMgdGhlIHJlcGxhY2VtZW50IGZvciBkZXYtPmludGVycnVw dA0KDQpMSU5LX1NUQVRFX1RYU0VNIGlzIGEgZmxhZyB1c2VkIG9ubHkgYnkg ZmFzdHJvdXRpbmcgZHJpdmVycw0KVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBn byBpbnRvIHRoZSBkZXRhaWxzIG9mIGZhc3Ryb3V0aW5nIG90aGVyDQp0aGFu IHRvIHNheSBpdCBpcyBhIG1lY2hhbmlzbSBmb3IgZGlyZWN0IE5JQy10by1O SUMgcm91dGluZy4gDQpJZiB5b3VyIGRyaXZlciB3YXMgZmFzcm91dGUgZW5h YmxlZCBpbiAyLjIgKGFuZCBpIG9ubHkga25vdyBvZiB0d28gDQpzdWNoIGRy aXZlcnMgOy0+KSB0aGVuIHRoaXMgaXMgZXF1aXZhbGVudCB0byBkZXYtPnR4 X3NlbWFwaG9yZS4NCkVzc2VudGlhbGx5LCBpZiB5b3VyIGRldmljZSBkb2Vz IG5vdCBrbm93IGFib3V0IGZhc3Qgcm91dGluZw0KdGhlbiB5b3UgbmVlZCBu b3QgdG8gd29ycnkgYWJvdXQgdGhpcy4NCg0KTElOS19TVEFURV9TQ0hFRCBp cyBhbiBpbnRlcm5hbCBmbGFnIHRvIHRoZSBUb3AgTGV2ZWwgKGxheWVyDQph Ym92ZSB0aGUgZHJpdmVyKS4NClRoZSBkcml2ZXIgd3JpdGVyIG5lZWQgbm90 IGJlIGNvbmNlcm5lZCBhYm91dCBMSU5LX1NUQVRFX1NDSEVEIA0KYnV0IG5l ZWRzIHRvIHVuZGVyc3RhbmQgdGhlIGltcGxpY2F0aW9ucyBhcyB3aWxsIGhv cGVmdWxseQ0KYmUgY29udmV5ZWQgYnkgdGhpcyBkb2N1bWVudC4NCg0KQ2F1 dGlvbiBuZWVkcyB0byBiZSBleGVyY2lzZWQgYXMgdGhlIHJlcGxhY2VtZW50 IGlzIG5vdCBhIA0KZGlyZWN0IG9uZSB0byBvbmUgbWFwcGluZywgZ2l2ZW4g dGhlIG5ldyBtZWNoYW5pc20gYmVpbmcgDQppbnRyb2R1Y2VkIGJ5IHNvZnRu ZXQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgU01QLCB0aGVyZSBhcmUNCmludHJp Y2FjaWVzIGludm9sdmVkLiBIb3BlZnVsbHkgYWZ0ZXIgcmVhZGluZyB0aGlz IHR3byB0aW1lcywNCml0IHNob3VsZCBiZWNvbWUgY2xlYXI7LT4gKE9LLCBv bmNlIGZvciB0aGUgZXhwZXJpZW5jZWQpLg0KDQpOTyBNT1JFIFBPTExJTkcg ZGV2LT50YnVzeQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKiog R29uZSBpcyB0aGUgInBvbGxpbmciIG1lY2hhbmlzbSB0aGF0IGludm9sdmVk IGNoZWNraW5nDQpieSB0aGUgY29yZSBsYXllciAoYWJvdmUgdGhlIGRyaXZl cikgZm9yIHRoZSBkZXYtPnRidXN5IHNldHRpbmc7DQpObyBtb3JlIGJhYnkt c2l0dGluZzsgdGhlIGRyaXZlciBpcyBub3cgaW4gY2hhcmdlIG9mIGl0cyBv d24gZmF0ZSA7LT4gDQooZXZlbiBpZiBvbmUgY2FuIHN0aWxsIGRlZmluZSB3 aGF0IGhhcHBlbnMgYXMgcG9sbGluZykuDQoNClNvbWUgYmFja2dyb3VuZCBl eHBsYW5hdGlvbiBpcyBuZWNlc3NhcnkgdG8gdW5kZXJzdGFuZCB0aGUgY2hh bmdlIA0KaW4gdGhlIGNvcmU6DQpGb3IgaGlzdG9yaWNhbCByZWFzb25zIGl0 IGlzIHdvcnRoIG5vdGluZyB0aGF0IGluIDIuMCANCmRldl9xdWV1ZV94bWl0 KCkgaWdub3JlZCBkZXYtPnRidXN5IGFuZCBhIGZ1bmN0aW9uYWxpdHkgc2lt aWxhciB0byB0aGF0DQpvZiBhIHdhdGNoZG9nIHdhcyBwbGF5ZWQgYnkgX25l d18gcGFja2V0cyBwdXNoaW5nIHRvIHRoZSBkcml2ZXIgZm9yDQp0cmFuc21p c3Npb24uIFRoaXMgd2F5IHRoZSBkcml2ZXIgY291bGQgcmVjb3ZlciBmcm9t IHRyYW5zbWlzc2lvbiBsb2NrdXBzDQpldGMuIEFsbCB0aGUgZGV2aWNlcywg aW5jbHVkaW5nIERPV05lZCBvbmVzIHdlcmUgc3RvcmVkDQppbiBhIHJ1bnF1 ZXVlIGFuZCBzY2FubmVkIHR3aWNlIG9uIGVhY2ggbmV0X2JoIGV2ZW50Lg0K DQpJbiAyLjIgb25seSB0aGUgZGV2aWNlcyB3aGljaCBoYXZlIHNvbWUgcGFj a2V0cyBpbiB0aGUgcXVldWUNCm9yIHJlY2VudGx5IGhhZCBzb21ldGhpbmcg YXJlIGFkZGVkIHRvIHRoZSBydW5xdWV1ZSwgd2hpY2ggaXMgc3RpbGwgDQpz Y2FubmVkIG9uIGVhY2ggbmV0X2JoIGV2ZW50IHR3aWNlLiBJZiBkZXYtPnRi dXN5IGlzIHNldCwgdGhlDQpwYWNrZXQgaXMgX25vdF8gaGFuZGVkIHRvIHRo ZSBkcml2ZXIgZm9yIHRyYW5zbWlzc2lvbi4gQXMgYSBiYWNrdXAsDQphIHdh dGNoZG9nIHRpbWVyIG1vbml0b3JzIGRldi0+dGJ1c3kgYW5kIGlmIGl0IGlz IHN0dWNrIGZvciANCnRvbyBsb25nIGEgdGltZSwgdGhlbiBhIGRldi0+aGFy ZF9zdGFydF94bWl0KCkgaXMgZm9yY2VkLiANCg0KVGhlIDIuMiBiZWhhdmlv ciBpcyBtYWludGFpbmVkIGluIHRoZSBjdXJyZW50IDIuMy4NCg0KV2l0aCBz b2Z0bmV0LCBkZXYtPmhhcmRfc3RhcnRfeG1pdCgpIGlzIG5vIGxvbmdlciBp bnZva2VkIGJ5DQp0aGUgd2F0Y2hkb2cgdGltZXIuIEluc3RlYWQgYSBuZXcg aW50ZXJmYWNlIGRldi0+dHhfdGltZW91dCgpIGlzIA0KaW52b2tlZC4gDQoN ClRoZSByZXBsYWNlbWVudCB0aW1lciByb3V0aW5lIGlzIHJlZ2lzdGVyZWQg aW50byB0aGUgZGV2IHN0cnVjdHVyZSANCmJ5IHRoZSBkcml2ZXIuIE1vc3Qg ZHJpdmVycyBhbHJlYWR5IGhhZCBhIHRpbWVyIHJvdXRpbmUgdXNlZCB0byBy ZWNvdmVyIA0KZnJvbSB0cmFuc21pc3Npb24gbG9ja3Vwcy4gQSBzaW1wbGUg cmUtdXNlIG9mIHN1Y2ggYSByb3V0aW5lIHdpdGggcHJvcGVyIA0KcmVwbGFj ZW1lbnRzIG9mIHRoZSBvbGQgZmxhZyB0cmFuc2l0aW9ucyB3b3VsZCBzdWZm aWNlIGluIG1vc3QgY2FzZXMuDQoNCkFzIGEgcmVzdWx0IG9mIHRoZSByZXF1 aXJlbWVudCwgdGhlcmUgYXJlIHR3byBuZXcgZW50cmllcyBpbiB0aGUgbmV0 X2Rldg0Kc3RydWN0dXJlOiBkZXYtPnR4X3RpbWVvdXQgd2hpY2ggaXMgdGhl IGZ1bmN0aW9uIHBvaW50ZXIgdG8gdGhlIGRyaXZlcg0KdGltZW91dCByb3V0 aW5lIGFuZCBkZXYtPndhdGNoZG9nX3RpbWVvIHdoaWNoIGlzIHRoZSB2YWx1 ZSB0aGF0IGlzIHVzZWQgDQpmb3IgdGhlIHRpbWVvdXQuDQpUaGUgYXR0YWNo bWVudCB0byB0aGUgZGV2aWNlIHN0cnVjdHVyZSBmb3IgdGhlc2UgZW50cmll cyBpcyBkb25lIGFyb3VuZCANCnRoZSBzYW1lIHRpbWUgdGhhdCB0aGluZ3Mg bGlrZSBkZXYtPmhhcmRfc3RhcnRfeG1pdCBhcmUgYXR0YWNoZWQgdG8gdGhl IA0KbmV0X2RldiBzdHJ1Y3R1cmUgYnkgdGhlIGRyaXZlciBpLmUgbm9ybWFs bHkgaW4gdGhlIGRldl9wcm9iZSgpIHJvdXRpbmUNClRoZSB0aW1lciwgaG93 ZXZlciwgaXMgZmlyZWQgb25jZSB0aGUgZGV2aWNlIGlzIGlmdXAnZWQgYnkg dGhlIGNvcmUNCihpLmUgaXQgaXMgbm90IHRoZSByZXNwb25zaWJpbGl0eSBv ZiB0aGUgZHJpdmVyIGF1dGhvciB0byBhZGQgaXQgdG8NCnRoZSB0aW1lciBs aXN0KS4NCg0KDQpBcyBhIHF1aWNrIGd1aWRlbGluZToNCmNvZGUgd2hpY2gg dXNlZCB0byBkbyAoaW4gdGhlIG15ZGV2X2h3X3N0YXJ0X3htaXQoKSByb3V0 aW5lKQ0Kc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KLS0tDQogICAgICAgIGlm ICh0ZXN0X2FuZF9zZXRfYml0KDAsICh2b2lkKikmZGV2LT50YnVzeSkgIT0g MCkgew0KICAgICAgICAgICAgICAgIGlmIChqaWZmaWVzIC0gZGV2LT50cmFu c19zdGFydCA+PSBUWF9USU1FT1VUKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgZGV2X3R4X3RpbWVvdXQoZGV2KTsNCiAgICAgICAgICAgICAgICByZXR1 cm4gMTsNCiAgICAgICAgfQ0KLS0tLQ0KDQoNCnNob3VsZCBub3cgYmUgcmlw cGVkIG9mZiBhbmQgYmUgcmVwbGFjZWQgYnkgKGluIHRoZSBwcm9iZSgpIHJv dXRpbmUpDQoNCg0KLS0tDQogICAgICAgIGRldi0+dHhfdGltZW91dCA9ICZt eV90eF90aW1lb3V0X2Z1bmM7DQogICAgICAgIGRldi0+d2F0Y2hkb2dfdGlt ZW8gPSBNWV9ERVZfVFhfVElNRU9VVDsNCi0tLQ0KDQoNCioqKiBBbHNvIGEg bmV3IGltcG9ydGFudCBjaGFuZ2U6DQpJdCBpcyB1cCB0byB0aGUgZGV2aWNl IHRvIGFkZCBpdHNlbGYgdG8gdGhlIHJ1bnF1ZXVlIA0KaS5lIGl0IGlzIG5v IGxvbmdlciB0aGUgY29yZSdzIHJlc3BvbnNpYmlsdHkuIFRoaXMgaXMgZG9u ZSB2aWEgdGhlIA0KbmV0aWZfd2FrZV9xdWV1ZSgpIGNhbGwgYnkgdGhlIGRy aXZlci4gDQpNb3JlIG9uIHRoaXMgYmVsb3cgaW4gdGhlICJHRU5FUkFMIEdV SURFTElORVMiIHNlY3Rpb24uDQoNCltPYnZpb3VzbHkgdGhpcyBjaGFuZ2Ug aW4gc29mdG5ldCBub3Qgb25seSByZWR1Y2VzIENQVSB1dGlsaXphdGlvbiwN CmJ1dCBtb3JlIGltcG9ydGFudGx5IHJlZHVjZXMgdGhlIGNvZGUgY29tcGxl eGl0eV0NCg0KR0VORVJBTCBHVUlERUxJTkVTDQotLS0tLS0tLS0tLS0tLS0t LS0NCg0KVGhpcyBpcyBhIGdlbmVyYWwgZ3VpZGVsaW5lIG9uIGhvdyB5b3Ug cmVwbGFjZSB0aGUgZmxhZ3MuDQpUaGUgdGltZXIgc2hvdWxkIGJlIGFkZGVk IGFzIGluZGljYXRlZCBhYm92ZS4NCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoxKSBP UEVOSU5HIHRoZSBkZXZpY2U6DQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCiANCmN1cnJl bnQ6DQotLS0tLS0tLQ0KVGhpcyBpbnZvbHZlcyBzZXR0aW5nIHRoZSBkZXYt PnN0YXJ0IGZsYWcgYW5kIA0KY2xlYXJpbmcgdGhlIGRldi0+dGJ1c3kgYW5k IGRldi0+aW50ZXJydXB0DQoNCg0KTmV3IHdheToNCi0tLS0tLS0NCg0KaW52 b2tlIG5ldGlmX3N0YXJ0X3F1ZXVlKGRldikuIEF0IHRoZSBtb21lbnQsDQp0 aGlzIGNsZWFycyB0aGUgTElOS19TVEFURV9YT0ZGIHN0YXRlIGJpdC4NCk9u IHJldHVybiBmcm9tIHRoZSBvcGVuKCkgdGhlIGNvcmUvVG9wbGV2ZWwgY29k ZQ0Kc2V0cyB0aGUgTElOS19TVEFURV9TVEFSVCBiaXQuDQoNCkl0IGlzIG5v dCBhZHZpc2FibGUgZm9yIHlvdSB0byBjbHIvc2V0X2JpdCgpIG9uIGFueSBv ZiB0aGUNCmFib3ZlLiBMZXQgdGhlIG5ldGlmX3N0YXJ0X3F1ZXVlKCkgYW5k IHRoZSBnZW5lcmFsIFRvcGxldmVsDQpjb2RlIHRha2UgY2FyZSBvZiB0aGlu Z3M7DQppdCBpcyBtb3JlIHBvcnRhYmxlIHRoaXMgd2F5LCBpbiBjYXNlIGlu IHRoZSBmdXR1cmUgc29tZSBuZXcNCmZ1bmN0aW9uYWxpdHkgZ2V0cyBhZGRl ZCB0byBuZXRpZl9zdGFydF9xdWV1ZSgpIGV0Yy4NCg0KDQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoy KSB0aGUgZGV2LT50YnVzeSBEVVJJTkcgREVWSUNFIE9QRVJBVElPTlMNCmku ZSB3aGVuIHRoZSBkZXZpY2UgaXMgc2VuZGluZyBhbmQgcmVjZWl2aW5nIHBh Y2tldHMNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCg0KQSkgQ2xlYXJpbmcgaXQ6DQoNCmN1cnJlbnQ6 DQo9PT09PT09DQoNCmNvZGUgc25pcHBldHMgZnJvbSBkaWZmZXJlbnQgZHJp dmVyczogDQoNCi0tDQpjbGVhcl9iaXQoMCwodm9pZCAqKSZkZXYtPnRidXN5 KQ0KLS0NCg0Kb3IgaW4gc29tZSBkcml2ZXJzDQoNCi0tLQ0KaWYgKHRlc3Rf YW5kX3NldF9iaXQoMCwgKHZvaWQqKSZkZXYtPnRidXN5KSAhPSAwKQ0KICAg ICAgICAgICAgICAgIGRldi0+dGJ1c3kgPSAwOw0KLS0tDQoNCmV0Yw0KDQpu ZXcgd2F5OiANCj09PT09PT0NCg0KaW52b2tlIG5ldGlmX3dha2VfcXVldWUo ZGV2KQ0KDQp0aGlzIHRha2VzIHRoZSB0aGUgZGV2aWNlIG91dCBvZiB0aGUg TElOS19TVEFURV9YT0ZGIHN0YXRlDQoobWVhbmluZyBpdCBpcyByZWFkeSB0 byByZWNlaXZlIHBhY2tldHMgZnJvbSB0aGUgdXBwZXIgbGF5ZXJzKQ0KTm90 ZSB0aGF0IGl0IGlzIGV4dHJlbWVseSBkYW5nZXJvdXMgZm9yIHlvdSB0byBj bHJfYml0KCkNCmRpcmVjdGx5IG9uIHRoZSBMSU5LX1NUQVRFX1hPRkYuIG5l dGlmX3dha2VfcXVldWUoKSBkb2VzIGEgbG90DQptb3JlIHRoYW4ganVzdCBy ZXNldCB0aGlzIGJpdC4gSXQgc2NoZWR1bGVzIHRoZSBkZXZpY2UgdG8gYmUg c2VydmljZWQNClNjaGVkdWxpbmcgaGVyZSBhbHNvIGluY2x1ZGVzIGV4cGxp Y2l0bHkgZG9pbmcgc29tZXRoaW5nIGVxdWl2YWxlbnQNCnRvIHRoZSBtYXJr X2JoKE5FVF9CSCkgd2hpY2ggd2FzIGRvbmUgYnkgc29tZSBkcml2ZXJzIA0K dG8gaGVscCBraWNrIHNvbWUgb2YgdGhlIHJlY2VpdmUgcGFja2V0IGlucHV0 IHByb2Nlc3NpbmcNCmFzIHdlbGwgYXMgZ2V0dGluZyBhZGRlZCB0byB0aGUg ZGV2aWNlIHJ1bnF1ZXVlLg0KDQpCKSBzZXR0aW5nIGl0IA0KDQpjdXJyZW50 Og0KPT09PT09PT0NCg0KLS0NCnRlc3RfYW5kX3NldF9iaXQoMCwodm9pZCAq KSZkZXYtPnRidXN5KQ0KLS0tDQoNCmV0Yw0KDQpuZXcgd2F5Og0KPT09PT09 PT0NCmNhbGw6DQpuZXRpZl9zdG9wX3F1ZXVlKGRldikNCg0KdGhpcyB0YWtl cyB0aGUgdGhlIGRldmljZSBpbnRvIHRoZSBMSU5LX1NUQVRFX1hPRkYgc3Rh dGUNCih3aGljaCBtZWFucyBpdCBjYW50IHJlY2VpdmUgcGFja2V0cyBhbnlt b3JlIGZyb20gdXBwZXIgbGF5ZXJzLikNCkl0IGlzIHlvdXIgcmVzcG9uc2li aWxpdHkgdG8gZW5zdXJlIHRoYXQgeW91IGdvIGJhY2sgdG8gdGhlDQpub24t WE9GRiBzdGF0ZSBhdCBzb21lIHBvaW50IGxhdGVyIG9uOyBzb21laG93IHNv bWV3aGVyZSB5b3UgbmVlZCANCnRvIGd1YXJhbnRlZSB0aGF0IHRoZSBuZXRp Zl93YWtlX3F1ZXVlKCkgaXMgaW52b2tlZC4gDQpZb3VyIGRldl90eF90aW1l b3V0KCkgbXVzdCBlaXRoZXIgY2FsbCBuZXRpZl93YWtlX3F1ZXVlKCkgb3Ig DQpyZXN0YXJ0IGl0cyB0cmFuc21pdHRlciwgc28gdGhhdCBuZXRpZl93YWtl X3F1ZXVlKCkgaXMgY2FsbGVkIA0KbGF0ZXIgZnJvbSBpbnRlcnVwdCBjb2Rl Lg0KDQpHZW5lcmFsIHJ1bGVzIG9mIHRodW1iOg0KMS4gSWYgdGhlIGRldmlj ZSBzZXRzIFhPRkYgKGR1ZSB0byBhIGNhbGwgdG8gbmV0aWZfc3RvcF9xdWV1 ZSgpKSwgaXQgTVVTVCANCiAgIGNhbGwgbmV0aWZfd2FrZV9xdWV1ZSgpIGF0 IHNvbWUgcG9pbnQgbGF0ZXIuDQoyLiBUb3AgbGV2ZWwgKGNvcmUgYWJvdmUg dGhlIGRyaXZlcikgV0lMTCBOT1QgY2FsbCBoYXJkX3N0YXJ0X3htaXQoKSwg DQogICBpZiBYT0ZGIGlzIHNldC4gDQozLiBUb3AgbGV2ZWwgZm9yZ2V0cyBh Ym91dCB0aGUgZGV2aWNlIGlmIFhPRkYgaXMgc2V0IGFuZCBpdCBpcyB0aGUN CiAgIGRldmljZSdzIHJlc3BvbnNpYmlsaXR5IHRvIHJlLWxpbmsgaXRzZWxm IHRvIHRoZSBydW5xdWV1ZSB3aXRoIA0KICAgbmV0aWZfd2FrZV9xdWV1ZSgp IHNvIGl0IGNhbiBiZSBzZXJ2aWNlZCBhZ2Fpbi4NCjQuIFRoZSBkZXZpY2Ug TVVTVCBub3Qgc2V0IFhPRkYgZnJvbSBhIGNvbnRleHQgbm90IHByb3RlY3Rl ZCBieSANCiAgIGEgcHJpdmF0ZSB4bWl0X2xvY2ssIHJlYWxseS4gU3VjaCBh IGxvY2sgY291bGQgYmUgc3RvcmVkIGluIHRoZSBkZXZpY2Uncw0KICAgcHJp dmF0ZSBzdHJ1Y3R1cmUuDQogICBJZiBpdCBkb2VzLCBpdCBjYW5ub3QgZ3Vh cmFudGVlIHRoYXQgaGFyZF9zdGFydF94bWl0KCkgaXMgY2FsbGVkDQogICB3 aXRoIGEgY2xlYW4gWE9GRi4gVGhlIGludGVycnVwdCBoYW5kbGVyIGNvdWxk IGZvciBleGFtcGxlDQogICBjYWxsIG5ldGlmX3dha2VfcXVldWUoKSBhbmQg YSByYWNlIGNvbmRpdGlvbiBjb3VsZCByZXN1bHQuDQogICBPbmUgd2F5IHRv IHJlZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgYSByYWNlIGNvbmRpdGlvbiBo YXBwZW5pbmcgaXMNCiAgIG5vdCB0byBzdG9wIHRoZSBpbnRlcmZhY2UgKGNh bGxpbmcgdG8gbmV0aWZfc3RvcF9xdWV1ZSgpKSByaWdodCBhdCANCiAgIHRo ZSBlbnRyeSB0byBoYXJkX3N0YXJ0X3htaXQoKSwgYnV0IHJhdGhlciBzdG9w IGl0IG9ubHkgd2hlbiANCiAgIGhhcmRfc3RhcnRfeG1pdCgpIGZpbmRzIHRo YXQgdGhlIGRldmljZSB3aWxsIG5vdCBhYmxlIHRvIGFjY2VwdCANCiAgIG1v cmUgcGFja2V0cyAoZWcgd2hlbiBpdHMgdHhtaXQgcmluZyBpcyBmdWxsKS4N Cg0KICAgVGhlIGdlbmVyYWwgcHJpbmNpcGxlcyBvZiB0aGlzIGFyZSBhcyBm b2xsb3dzOg0KDQogIC0tLS0tLS1PTEQtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tfC0tLS0tLS0tTkVXLS0tLS0tLS0tLS0tLS0tDQogIGlmICh0 ZXN0X2FuZF9zZXRfYml0KDAsICZkZXYtPnRidXN5KSkgeyAgfCAgICAgICBu ZXRpZl9zdG9wX3F1ZXVlKGRldikNCiAgICAgICAgcmV0dXJuIDE7ICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQogICB9IGVsc2UgeyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICBpZiAoMSkgew0KICAgICAg ICAgcmVhbCB3b3JrICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgcmVhbCB3b3JrDQogICAgICAgICBpZiAoaXRfaXNfbm90X2Z1bGwo KSkgICAgICAgICAgICAgfCAgICAgICAgICAgICBpZiAoaXRfaXNfbm90X2Z1 bGwoKSkNCiAgICAgICAgICAgICAgICAgZGV2LT50YnVzeSA9IDA7ICAgICAg ICAgICB8ICAgICAgICAgICAgICAgIG5ldGlmX3dha2VfcXVldWUoKQ0KICAg ICAgICAgcmV0dXJuIDA7ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgcmV0dXJuIDA7DQogICB9ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICB9DQogIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCiAgIExvb2sgYXQgdGhlIHNvZnRuZXR0ZWQtM2M1MDku YyBmb3IgYW4gZXhhbXBsZSBvZiBzdWNoIGEgdHJpY2suDQogICANCiAgIFN1 Y2ggY29kZSBzaG91bGQgYmUgdXNlZCByZWFsbHkgYXMgYW4gaW50ZXJtaWRp YXRlIHNvbHV0aW9uIG9ubHkgDQogICBiZWNhdXNlIGl0IGRvZXMgbm90IGd1 YXJhbnRlZSB5b3Ugc2FmZXR5LiBUaGUgc2FmZSB3YXkgdG8gZG8gaXQsIHdp dGhvdXQNCiAgIGEgZG91YnQsIGlzIHRvIGFkZCBhIHNwaW5sb2NrIGluIHlv dXIgZGV2aWNlX3ByaXZhdGVfc3RydWN0dXJlIGFuZCB1c2UNCiAgIGl0IHRv IGxvY2sgY3JpdGljYWwgc2VjdGlvbnMgc3VjaCBhcyB0aG9zZSBjbGVhcmlu ZyBYT0ZGLg0KICAgVGhpcyBpcyBhIHRyaXZpYWwgdGFzayBmb3IgY2FyZHMg d2hpY2ggYWxyZWFkeSBoYXZlIHRoaXMgbG9jaw0KICAgKGVnIGVlcHJvMTAw LCA4MzkwIGV0Yy4pLCBidXQgaXMgZGlmZmljdWx0IGZvciB0aG9zZSB0aGF0 IGxhY2sNCiAgIGl0IChlZyAgdHVsaXApLiBUaGUgc29mdG5ldGVkIGVlcHJv MTAwLmMgaXMgYSByZWFsbHkNCiAgIGdvb2QgZXhhbXBsZSBvZiBzb21ldGhp bmcgdGhhdCBjb25mb3JtcyB3ZWxsLiANCiAgIFtUT0RPOiBVcGRhdGUgdGhp cyB3aXRoIGFuIGV4YW1wbGUgZnJvbSB0aGUgZWVwcm9dDQoNCg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KMykgVGhlIGRldi0+aW50ZXJydXB0IERVUklORyBERVZJQ0UgT1BFUkFU SU9OUw0KaS5lIHdoZW4gdGhlIGRldmljZSBpcyBzZW5kaW5nIGFuZCByZWNl aXZpbmcgcGFja2V0cw0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkEpIHNldHRpbmcg aXQ6DQoNCmN1cnJlbnQ6DQo9PT09PT09PQ0KDQpkZXYtPmludGVycnVwdD0x Ow0KDQpuZXcgd2F5DQo9PT09PT09DQoNCmJpdF9zZXQoTElOS19TVEFURV9S WFNFTSwgJmRldi0+c3RhdGUpDQoNClRoaXMgdGFrZXMgdGhlIGRldmljZSBp bnRvIHRoZSAiaW5wdXQgaW50ZXJydXB0IHByb2Nlc3NpbmciIHN0YXRlDQoN CkIpIGNsZWFyaW5nIGl0DQoNCmN1cnJlbnQ6DQo9PT09PT09PQ0KDQpkZXYt PmludGVycnVwdD0wOw0KDQpjbGVhcl9iaXQoTElOS19TVEFURV9SWFNFTSwg JmRldi0+c3RhdGUpDQoNClRoaXMgdGFrZXMgdGhlIGRldmljZSBvdXQgb2Yg dGhlICJpbnB1dCBpbnRlcnJ1cHQgcHJvY2Vzc2luZyIgc3RhdGUNCg0KUmVh bGx5LCB0aGUgZGV2LT5pbnRlcnJ1cHQgd2FzIG9ic29sZXRlZCBldmVuIGlu IDIuMiBidXQNCndhcyBzdGlsbCBiZWluZyB1c2VkIGJ5IHNvbWUgZHJpdmVy cy4NCmRldi0+aW50ZXJydXB0IGlzIG5vb3AgaW4gMi4yIGtlcm5lbHMgYW5k IGEgU01QIGJ1ZyB3b3JrYXJvdW5kIGluIDIuMC4gDQoNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo0KSBtYXJrX2JoKE5FVF9CSCkNCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K R29uZS4NCmludm9rZSBpbnN0ZWFkOiBuZXRpZl93YWtlX3F1ZXVlKGRldik7 DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KNSkgTWlzY2VsbGVuaWE6DQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCg0KY2hlY2tpbmcgZm9yIHNldCBiaXRzIGV0Yw0KDQp1c2Ug dGhlIHNldF9iaXQoKSBjYWxscw0KDQplZzoNCnRvIGNoZWNrIGlmIHdlIGFy ZSBpbiB0aGUgTElOS19TVEFURV9TVEFSVCBzdGF0ZQ0KZG86DQogICAgICAg IGlmICh0ZXN0X2JpdChMSU5LX1NUQVRFX1NUQVJULCAmZGV2LT5zdGF0ZSkp DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQo2KSBUT0RPDQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCi0gZWVwcm8gZXhhbXBsZQ0KLSBza2VsZXRvbi5jIGV4YW1wbGUNCg0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo3KSBDcmVkaXRzDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cg0KMTk5OTEyMjcNCi0gSmFtYWwgSGFkaSBTYWxpbSA8aGFkaUBjeWJlcnVz LmNhPg0KLSBBbGV4ZXkgS3V6bmV0c292IDxrdXpuZXRAbXMyLmluci5hYy5y dT4NCg0KDQo= ---559023410-1804928587-947133931=:8719-- From owner-netdev@oss.sgi.com Thu Jan 6 13:48:49 2000 Received: by oss.sgi.com id ; Thu, 6 Jan 2000 13:48:40 -0800 Received: from w200.z208176006.sjc-ca.dsl.cnc.net ([208.176.6.200]:35602 "EHLO ffnet.com") by oss.sgi.com with ESMTP id ; Thu, 6 Jan 2000 13:48:24 -0800 Received: from zeno.ffnet.com (zeno.ffnet.com [172.16.248.95]) by ffnet.com (8.8.8/8.8.8) with ESMTP id NAA07296 for ; Thu, 6 Jan 2000 13:49:06 -0800 (PST) (envelope-from neal@ffnet.com) Received: from localhost (neal@localhost) by zeno.ffnet.com (8.9.3/8.8.8) with ESMTP id NAA93028 for ; Thu, 6 Jan 2000 13:49:05 -0800 (PST) (envelope-from neal@ffnet.com) X-Authentication-Warning: zeno.ffnet.com: neal owned process doing -bs Date: Thu, 6 Jan 2000 13:49:05 -0800 (PST) From: Neal Cardwell To: netdev@oss.sgi.com Subject: external static routes to local interfaces Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing If i have a Linux 2.2.x machine with a loopback interface bound to address , is it possible (for testing purposes) get the machine to send packets bound for over eth0 to a gateway with address ? Under FreeBSD you can do this with: route add But under Linux 2.2.12 when I tried: route add gw dev eth0 this gives a routing table that seems reasonable: Kernel IP routing table Dest Gateway Genmask Flags Metric Ref Use Iface 255.255.255.255 UGH 0 0 0 eth0 But despite this routing table, packets bound for do *not* go to the gateway, but rather through the loopback interface. Is this a bug or a feature? How do i do this in Linux? thanks, neal From owner-netdev@oss.sgi.com Thu Jan 6 15:31:40 2000 Received: by oss.sgi.com id ; Thu, 6 Jan 2000 15:31:30 -0800 Received: from w200.z208176006.sjc-ca.dsl.cnc.net ([208.176.6.200]:54022 "EHLO ffnet.com") by oss.sgi.com with ESMTP id ; Thu, 6 Jan 2000 15:31:08 -0800 Received: from zeno.ffnet.com (zeno.ffnet.com [172.16.248.95]) by ffnet.com (8.8.8/8.8.8) with ESMTP id PAA15422 for ; Thu, 6 Jan 2000 15:31:55 -0800 (PST) (envelope-from neal@ffnet.com) Received: from localhost (neal@localhost) by zeno.ffnet.com (8.9.3/8.8.8) with ESMTP id PAA96151 for ; Thu, 6 Jan 2000 15:31:54 -0800 (PST) (envelope-from neal@ffnet.com) X-Authentication-Warning: zeno.ffnet.com: neal owned process doing -bs Date: Thu, 6 Jan 2000 15:31:54 -0800 (PST) From: Neal Cardwell To: netdev@oss.sgi.com Subject: ip_statistics bug in Linux 2.0/2.2/2.3 TCP? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing tcp_v4_do_rcv() seems to be missing a counter bump like: ip_statistics.IpInDelivers++; The analogous counter increment is in tcp_v6_do_rcv(), which is one reason i suspect this is a bug. Another reason is the very large discrepancy between IpInReceives and IpInDelivers when there is a lot of inbound TCP traffic; this seems counterintuitive, at the very least. Is this a bug, or am i missing something? thanks, neal From owner-netdev@oss.sgi.com Sat Jan 8 04:58:54 2000 Received: by oss.sgi.com id ; Sat, 8 Jan 2000 04:58:44 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:1552 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Sat, 8 Jan 2000 04:58:31 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id PAA09896; Sat, 8 Jan 2000 15:58:41 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200001081258.PAA09896@ms2.inr.ac.ru> Subject: Re: external static routes to local interfaces To: neal@ffnet.COM (Neal Cardwell) Date: Sat, 8 Jan 2000 15:58:41 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: from "Neal Cardwell" at Jan 7, 0 01:13:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 559 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > But despite this routing table, packets bound for do *not* go to the > gateway, but rather through the loopback interface. > > Is this a bug or a feature? How do i do this in Linux? It is overriden by route, which is invisible with "route". You may delete it with "ip route" but you will not achieve desired result in any case. To summarize, it is impossible. System has single route for each destination, so that deleting loopback route will route packets to the place, which you ordered, but packets will _not_ be accepted locally. Alexey From owner-netdev@oss.sgi.com Mon Jan 10 02:48:09 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 02:47:49 -0800 Received: from jazz.prihateam.fi ([193.94.170.3]:41328 "EHLO jazz.prihateam.fi") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 02:47:27 -0800 Received: from fuuga.helsinki.prihateam.fi (rock.prihateam.fi [10.11.11.6]) by jazz.prihateam.fi with ESMTP id MAA16917 for ; Mon, 10 Jan 2000 12:48:37 +0200 Received: from ronsu (ronsu.haaga.prihateam.fi [10.10.12.8]) by fuuga.helsinki.prihateam.fi with ESMTP id MAA11804 for ; Mon, 10 Jan 2000 12:48:15 +0200 (EET) Message-Id: <4.2.0.58.20000110123511.00a38eb0@mail.helsinki.prihateam.fi> X-Sender: petri@mail.helsinki.prihateam.fi X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Jan 2000 12:48:14 +0200 To: netdev@oss.sgi.com From: Petri Mattila Subject: ARP request with incorrect (?) source IP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello, I have a little problem here with linux-2.2.12 router, it generates weird ARP requests, with the following config: Linux-2.2.12 server - two ethernet segments: 192.168.12.1/24 and 192.168.13.1/24 - route 10.10.0.0/16 to 192.168.13.2 - DNS-server bind-8.2.2-P5 listening both addresses Tigris access-router, 192.168.13.2 - default-GW 192.168.13.1 - dialups using 10.10.0.0/16 addresses. When the dialup-host 10.10.10.65 makes a DNS lookup to 192.168.12.1, on segment 192.168.13.1/24 we see this: 12:15:50.685128 8:0:3:6:12:49 0:c0:95:e0:27:e3 0800 79: 10.10.10.65.1027 > 192.168.12.1.53: 1+ (37) 12:15:50.685583 0:c0:95:e0:27:e3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.13.2 tell 192.168.12.1 the linux server makes ARP request with 192.168.12.1 as source address, which seems a little weird to me... Is this correct? At least the tigris access router do not answer... Any ideas? -- Petri From owner-netdev@oss.sgi.com Mon Jan 10 11:32:02 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 11:31:52 -0800 Received: from [155.33.144.250] ([155.33.144.250]:16460 "EHLO nofear.sweet.com") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 11:31:30 -0800 Received: from localhost (gws@localhost) by nofear.sweet.com (8.9.2/8.9.2) with SMTP id OAA01478 for ; Mon, 10 Jan 2000 14:32:37 -0500 (EST) Date: Mon, 10 Jan 2000 14:32:36 -0500 (EST) From: Greg Simpson To: netdev@oss.sgi.com Subject: current IPSEC/SKIP implementations? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Do you guys know the status of IPSEC within the linux kernel? I haven't been able to find any good, recently updated resources on this topic, and ppp over ssh isn't perfect - or compatible with routers :) TIA, -g From owner-netdev@oss.sgi.com Mon Jan 10 11:59:42 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 11:59:32 -0800 Received: from alcove.wittsend.com ([130.205.0.20]:13843 "EHLO alcove.wittsend.com") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 11:59:19 -0800 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id PAA18987; Mon, 10 Jan 2000 15:00:10 -0500 Date: Mon, 10 Jan 2000 15:00:09 -0500 From: "Michael H. Warfield" To: Greg Simpson Cc: netdev@oss.sgi.com Subject: Re: current IPSEC/SKIP implementations? Message-ID: <20000110150009.A17303@alcove.wittsend.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from gws@sweet.com on Mon, Jan 10, 2000 at 02:32:36PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, Jan 10, 2000 at 02:32:36PM -0500, Greg Simpson wrote: > Do you guys know the status of IPSEC within the linux kernel? > I haven't been able to find any good, recently updated resources on this > topic, and ppp over ssh isn't perfect - or compatible with routers :) http://www.freeswan.org Currently in release version 1.2. Daily snapshots are required if you are working with the 2.3.x kernels or want the latest toots and whistles. Version 1.2 will patch the 2.2.x kernels. Pluto (IKE) supports automatic keying. Some patches exist for PKI and certificates. Mailing list: linux-ipsec@clinet.fi FTP Site: ftp://ftp.xs4all.nl/pub/crypto/freeswan > TIA, > -g Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-netdev@oss.sgi.com Mon Jan 10 15:29:52 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 15:29:32 -0800 Received: from tnt.isi.edu ([128.9.128.128]:59815 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 15:29:09 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA12682; Mon, 10 Jan 2000 15:30:12 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id PAA00751; Mon, 10 Jan 2000 15:30:11 -0800 (PST) Date: Mon, 10 Jan 2000 15:30:11 -0800 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: kusune@sfc.wide.ad.jp, netdev@oss.sgi.com Subject: Re: source address selection In-Reply-To: In your message of "Thu, 30 Dec 1999 18:40:51 +0300 (MSK)" <199912301540.SAA06756@ms2.inr.ac.ru> References: <199912301540.SAA06756@ms2.inr.ac.ru> User-Agent: Wanderlust/2.2.12 (Joyride) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Thu, 30 Dec 1999 18:40:51 +0300 (MSK), kuznet@ms2.inr.ac.ru wrote: Hello Alexey, > > > > If you have no plan to implement source address selection > > > > into IPv4 protocol stack, > > Please, explain. What is "source address selection"? > I have no idea what can be added to IPv4 in this area. > All that could be done, were done to 2.2. Sorry for my late response. Hmm... I apologize that you confused the issue due to my poor English :-p In brief, we want the mechanism of source address selection into IPv6 stack. If we have one Ethernet interface with some prefixes as the following, eth0 Link encap:Ethernet HWaddr 00:60:52:04:BC:B7 inet addr:XXX.XXX.XXX.XXX Bcast:XXX.XXX.XXX.XXX Mask:255.255.255.224 inet6 addr: 3ffe:505:d::abcd/64 Scope:Global inet6 addr: 3ffe:801:a::beef/64 Scope:Global inet6 addr: 2001:200:c::1234/64 Scope:Global inet6 addr: fe80::260:52ff:fe04:bcb7/10 Scope:Link how can we select source address to communicate other IPv6 hosts ? a) Every application have to implement the mechanism to select the best source address by itself, b) We have to specify a source address by any command-line option whenever we use IPv6 application, or c) Linux kernel might select the appropriate source address. What option do you think the best ? We(Linux IPv6 Users JP) think c is reasonable. So we have made a patch for source address selection. I'm really interested in your opinion for the improvement of Linux IPv6 stack. Regards. -- Yuji Sekiya USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Mon Jan 10 15:55:13 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 15:55:03 -0800 Received: from tnt.isi.edu ([128.9.128.128]:53165 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 15:54:34 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA14730; Mon, 10 Jan 2000 15:55:02 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id PAA00783; Mon, 10 Jan 2000 15:55:01 -0800 (PST) Date: Mon, 10 Jan 2000 15:55:01 -0800 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, users@ipv6.org, yoshfuji@ecei.tohoku.ac.jp Subject: Re: sin6_scope_id In-Reply-To: In your message of "Wed, 29 Dec 1999 19:07:59 +0300 (MSK)" <199912291607.TAA04827@ms2.inr.ac.ru> References: <199912291607.TAA04827@ms2.inr.ac.ru> User-Agent: Wanderlust/2.2.12 (Joyride) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Wed, 29 Dec 1999 19:07:59 +0300 (MSK), kuznet@ms2.inr.ac.ru wrote: Hello Alexey ! > > RFC2553 says in section 2.4 that follow > > Linux does not follow this RFC. It complies to previous RFC. Hmm... OK. I understand YOUR opnion. YOU don't like the idea of scope_id. But I DON'T AGREE... I think many plathomes such as Solaris, FreeBSD, NetBSD, OpenBSD, WinNT and other commercial operating systems may support RFC2553. Even in such situatuon, aren't you willing to support it ? If Linux kernel don't support it, I think that Linux will become a peculiar IPv6 implementation... > IPv4 has the same problems as IPv6 does. Yes, That's why I think we should improve this problem in IPv6. > After thinking a bit, you will understand that IPv4 has both link local > and site local and all the kinds of addresses. The only difference of IPv6 > is returning to brain-dead "classful" addressing, which was rejected > in IPv4 years ago. No. In case of IPv6, all interfaces have link-local address(es). In case of IPv4, if some interfaces have a link-local address (as you say), each addresses has different network address respectively. (e.g. eth0 belongs to 192.168.1.0/24 and eth0 belongs to 192.168.2.0/24) However in IPv6, all interfaces belong to the same network address (fe80::). So, we must specify an outgoing interface because kernel can't select outgoing interface automatically when destination address is link-local. we will try to make patch for sin6_socpe_id... -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Mon Jan 10 16:55:43 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 16:55:34 -0800 Received: from zmamail01.zma.compaq.com ([161.114.64.101]:33809 "HELO zmamail01.zma.compaq.com") by oss.sgi.com with SMTP id ; Mon, 10 Jan 2000 16:55:10 -0800 Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 8214C273; Mon, 10 Jan 2000 19:56:16 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 57A8D330; Mon, 10 Jan 2000 19:56:16 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id TAA0000006214; Mon, 10 Jan 2000 19:56:16 -0500 (EST) From: Jim Bound Message-Id: <200001110056.TAA0000006214@quarry.zk3.dec.com> To: Yuji Sekiya Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, users@ipv6.org, yoshfuji@ecei.tohoku.ac.jp Subject: Re: sin6_scope_id In-reply-to: Your message of "Mon, 10 Jan 2000 15:55:01 PST." Date: Mon, 10 Jan 2000 19:56:15 -0500 X-Mts: smtp Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing folks, Everyone has to support sin6_scope_id. This all has been discussed on ipng list. There will be an update to rfc2553 soon in the space of sin6_scope_id. It will not affect kernel implementations of scopes or rfc2553 implementations of that API. It will be an enhancement to the API. /jim From owner-netdev@oss.sgi.com Mon Jan 10 21:45:25 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 21:45:06 -0800 Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:13047 "EHLO grendel.conscoop.ottawa.on.ca") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 21:44:48 -0800 Received: (from rgb@localhost) by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id AAA01326; Tue, 11 Jan 2000 00:46:21 -0500 Date: Tue, 11 Jan 2000 00:46:19 -0500 From: Richard Guy Briggs To: "Michael H. Warfield" Cc: Greg Simpson , netdev@oss.sgi.com Subject: Re: current IPSEC/SKIP implementations? Message-ID: <20000111004619.H2961@grendel.conscoop.ottawa.on.ca> References: <20000110150009.A17303@alcove.wittsend.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=DOr+hlVy7JMLa9bO; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.7i In-Reply-To: <20000110150009.A17303@alcove.wittsend.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing --DOr+hlVy7JMLa9bO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Mon, Jan 10, 2000 at 03:00:09PM -0500, Michael H. Warfield wrote: > On Mon, Jan 10, 2000 at 02:32:36PM -0500, Greg Simpson wrote: >=20 > > Do you guys know the status of IPSEC within the linux kernel? For the foreseeable future, IPSEC CANNOT be included in the kernel because it is export restricted and it is being maintained and distributed primarily from the USA. It CAN be added afterwards by anyone (except where local law prohibits its use, ie. USSR, Cuba, etc...) This situation could change if the US government gives up its pointless export restrictions on purely defensive technology, OR, the main maintenance/distribution of the kernel leaves the US (Hey Linus, going back to Finland anytime soon?) > > I haven't been able to find any good, recently updated resources on this > > topic, and ppp over ssh isn't perfect - or compatible with routers :) >=20 > http://www.freeswan.org >=20 > Currently in release version 1.2. Daily snapshots are required > if you are working with the 2.3.x kernels or want the latest toots and > whistles. Version 1.2 will patch the 2.2.x kernels. Pluto (IKE) supports > automatic keying. Some patches exist for PKI and certificates. The version 1.2 patches are fairly important, or get a new snapshot. Another release is due around the end of January. "Release Early, Release Often" > Mailing list: linux-ipsec@clinet.fi >=20 > FTP Site: ftp://ftp.xs4all.nl/pub/crypto/freeswan >=20 > > TIA, >=20 > > -g >=20 > Mike Thanks Mike! > --=20 > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com > (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mh= w/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! slainte mhath, RGB --=20 Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: --DOr+hlVy7JMLa9bO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBOHrDqd+sBuIhFagtAQG+VgP/Uwx18tdUiUkyQqoDw+Hk1NEpUgjFf6eR DaYCTSemGnxpC93zYMp7oxKneA+idkRb2r+a83zmp+1DLdh3aqoIHZG18Nx8wdpl xOvJnR6OKFO68PQIuUJsRrANAv5BctwlK0X98IZxQQ+hyYIKBfcOhzivK2koAv5+ G+z5sbMz/dQ= =C3I9 -----END PGP SIGNATURE----- --DOr+hlVy7JMLa9bO-- From owner-netdev@oss.sgi.com Mon Jan 10 22:11:46 2000 Received: by oss.sgi.com id ; Mon, 10 Jan 2000 22:11:36 -0800 Received: from [155.33.144.250] ([155.33.144.250]:20568 "EHLO nofear.sweet.com") by oss.sgi.com with ESMTP id ; Mon, 10 Jan 2000 22:11:13 -0800 Received: from localhost (gws@localhost) by nofear.sweet.com (8.9.2/8.9.2) with SMTP id BAA02485; Tue, 11 Jan 2000 01:12:18 -0500 (EST) Date: Tue, 11 Jan 2000 01:12:17 -0500 (EST) From: Greg Simpson To: Richard Guy Briggs cc: "Michael H. Warfield" , netdev@oss.sgi.com Subject: Re: current IPSEC/SKIP implementations? In-Reply-To: <20000111004619.H2961@grendel.conscoop.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > > > TIA, > > > > > -g > > > > Mike > > Thanks Mike! Yes, thanks, Mike :) And you too, Richard. Frees/wan looks very neat. A little bit off topic for the list, but are there any free ipsec clients for windows available? Or any commercial ones that you'd recommend? Is it safe to assume they can all talk to each other, or are there some proprietary schemes to avoid? Curious. -g > > > -- > > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com > > (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ > > NIC whois: MHW9 | An optimist believes we live in the best of all > > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! > > slainte mhath, RGB > -- > Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada > > Prevent Internet Wiretapping! -- FreeS/WAN: > Thanks for voting Green! -- Marillion: > From owner-netdev@oss.sgi.com Tue Jan 11 00:14:22 2000 Received: by oss.sgi.com id ; Tue, 11 Jan 2000 00:14:02 -0800 Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:48123 "EHLO grendel.conscoop.ottawa.on.ca") by oss.sgi.com with ESMTP id ; Tue, 11 Jan 2000 00:13:42 -0800 Received: (from rgb@localhost) by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id DAA03179; Tue, 11 Jan 2000 03:15:16 -0500 Date: Tue, 11 Jan 2000 03:15:15 -0500 From: Richard Guy Briggs To: Greg Simpson Cc: Richard Guy Briggs , "Michael H. Warfield" , netdev@oss.sgi.com Subject: Re: current IPSEC/SKIP implementations? Message-ID: <20000111031515.J2961@grendel.conscoop.ottawa.on.ca> References: <20000111004619.H2961@grendel.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=G1IH56i3DES2a+WZ; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.7i In-Reply-To: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing --G1IH56i3DES2a+WZ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2000 at 01:12:17AM -0500, Greg Simpson wrote: > Frees/wan looks very neat. >=20 > A little bit off topic for the list, but are there any free ipsec clients > for windows available? Or any commercial ones that you'd recommend? > Is it safe to assume they can all talk to each other, or are there some > proprietary schemes to avoid? IPSEC is a set of open proposed standards, RFC2401, etc., so they *should* all talk to each other, but YMMV until this stuff gets ironed out. They are not simple protocols. I don't know the M$ offerings at all. There is an interoperability workshop on as we speak in California. > -g >=20 > > > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com > >=20 > > slainte mhath, RGB slainte mhath, RGB --=20 Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: --G1IH56i3DES2a+WZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBOHrmkN+sBuIhFagtAQGQzQQAhhmok93HxyKQ527OaBDlQdhBMw0wuJeM 9VdoiKb9ldRrgtRnNKd/66NJNALxepS8q89/wvKLjNI380dtbJh9/zMSULgPrJVP +XLT1Glk2TYQ8Gv8qGrpgDzLi3XM5vpU0WHVdzNCEbq9bkkcOK+RaZqsQX19FkIS CxmSw9Qb4mM= =aYAo -----END PGP SIGNATURE----- --G1IH56i3DES2a+WZ-- From owner-netdev@oss.sgi.com Tue Jan 11 05:10:31 2000 Received: by oss.sgi.com id ; Tue, 11 Jan 2000 05:10:12 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:26893 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Tue, 11 Jan 2000 05:09:52 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id QAA10035; Tue, 11 Jan 2000 16:09:31 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200001111309.QAA10035@ms2.inr.ac.ru> Subject: Re: sin6_scope_id To: bound@zk3.dec.com (Jim Bound) Date: Tue, 11 Jan 2000 16:09:31 +0300 (MSK) Cc: sekiya@ISI.EDU, netdev@oss.sgi.com, users@ipv6.org, yoshfuji@ecei.tohoku.ac.jp In-Reply-To: <200001110056.TAA0000006214@quarry.zk3.dec.com> from "Jim Bound" at Jan 10, 0 07:56:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 335 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Everyone has to support sin6_scope_id. Yes, Sir! Are we in the army now? 8) Let me to cite the only intelligible argument for sin6_scope_id (your one, right?) to show people, who did not listen ipng, style of IPng WG discussions, resulting in such decisions: > The WG wants this done in the socket address. :-) Alexey From owner-netdev@oss.sgi.com Tue Jan 11 15:34:09 2000 Received: by oss.sgi.com id ; Tue, 11 Jan 2000 15:33:59 -0800 Received: from [206.171.92.89] ([206.171.92.89]:21260 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Tue, 11 Jan 2000 15:33:53 -0800 Received: (qmail 30411 invoked from network); 11 Jan 2000 23:31:47 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 11 Jan 2000 23:31:47 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id PAA28301; Tue, 11 Jan 2000 15:34:19 -0800 Date: Tue, 11 Jan 2000 15:34:19 -0800 Message-Id: <200001112334.PAA28301@ns1.filetron.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: David Jeffery To: netdev@oss.sgi.com Subject: ip6 addr removal doesn't remove route Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi all. Using either ip or ifconfig, if you delete an ipv6 address you've assigned to an interface, the corrosponding route is not removed. In fact, ifconfig refuses to remove it even manually! ip however will remove the route manually but also fails to remove the route when you delete the address. This was done with kernel 2.3.38, net-tools 1.53, and iproute2-991023 If you need anymore info, let me know David "Lordbeatnik" Jeffery ------ Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com From owner-netdev@oss.sgi.com Tue Jan 11 17:49:49 2000 Received: by oss.sgi.com id ; Tue, 11 Jan 2000 17:49:40 -0800 Received: from alcove.wittsend.com ([130.205.0.20]:12812 "EHLO alcove.wittsend.com") by oss.sgi.com with ESMTP id ; Tue, 11 Jan 2000 17:49:26 -0800 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id UAA11739; Tue, 11 Jan 2000 20:50:25 -0500 Date: Tue, 11 Jan 2000 20:50:25 -0500 From: "Michael H. Warfield" To: Richard Guy Briggs Cc: "Michael H. Warfield" , Greg Simpson , netdev@oss.sgi.com Subject: Re: current IPSEC/SKIP implementations? Message-ID: <20000111205025.C10109@alcove.wittsend.com> References: <20000110150009.A17303@alcove.wittsend.com> <20000111004619.H2961@grendel.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <20000111004619.H2961@grendel.conscoop.ottawa.on.ca>; from rgb@conscoop.ottawa.on.ca on Tue, Jan 11, 2000 at 12:46:19AM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, Jan 11, 2000 at 12:46:19AM -0500, Richard Guy Briggs wrote: > On Mon, Jan 10, 2000 at 03:00:09PM -0500, Michael H. Warfield wrote: > > On Mon, Jan 10, 2000 at 02:32:36PM -0500, Greg Simpson wrote: > > > Do you guys know the status of IPSEC within the linux kernel? > For the foreseeable future, IPSEC CANNOT be included in the kernel > because it is export restricted and it is being maintained and > distributed primarily from the USA. Actually... If everything goes according to schedule (and it looks like it will), it looks like that "forseable future" ends in three days. For those a little behind in US current events... On September 16, 1999, the US administration announced that it was drafting regulations to relax export of commercial mass market cryptography. At that time, they gave no indication that anything was going to change in the open source or free-(beer or speech)-ware arena. Not long after that, Eric Raymond and I decided to include my SSL patches to fetchmail into the main fetchmail sources. I told Eric I was going to run it past the powers-that-be where I work (Internet Security Systems Inc), just so they didn't have any surprises (Keith, the VP of Engineering, hates surprises and he lets me occasionally get away with murder as long as he has no surprises and he retains plausable deniability). ISS surprised me by footing the bill for a little chat with our Washington crypto/export lawyer, just to make sure everyone knew where everyone stood and what was going on. I learned at that time that there was a major shakeup on the way for open source as well. I dropped a few hints on this list a little while later. The SSL patches went into the fetchmail sources and have been on Eric's site for a couple of months now. On November 19, the first draft of the proposed regulations were published. They contained good (but not unmixed) news for the open source community but raised a lot of questions and contained a lot of ambiguities. The proposed date for finalization was around December 15. That never happened. There was apparently significant feedback to the first draft so the finalization was delayed and a second draft published on December 17. That draft is available at: What was good got even better. The open source regs were reduced to three paragraphs in section 740.13... ] SEC. 740.13 TECHNOLOGY AND SOFTWARE < UNRESTRICTED (TSU) ] ] (e) Unrestricted Encryption Source Code ] (1) Encryption source code controlled under 5D002 which would be ] considered publicly available under Section 734.3(b)(3) and which ] is not subject to an express agreement for the payment of a ] licensing fee or royalty for further commercial production or ] sale of any product developed with the source code is released from ] EI controls and may be exported or re-exported without review under ] License Exception TSU, provided you have submitted written ] notification to BXA of the Internet address (e.g. URL) or a copy ] of the source code by the time of export. Submit the notification ] to BXA and send a copy to ENC Encryption Request Coordinator ] (see Section 740.17(g)(5) for mailing addresses). ] ] (2) You may not knowingly export or re-export source code or ] products developed with this source code to Cuba, Iran, Iraq, ] Libya, North Korea, Sudan or Syria. ] ] (3) Posting of the source code on the Internet (e.g., FTP or ] World Wide Web site) where the source code may be downloaded by ] anyone would not establish "knowledge" as described in subparagraph ] (2) of this section. In addition, such posting would not trigger ] "red flags" necessitating the affirmative duty to inquire under ] the "Know Your Customer" guidance provided in Supplement No. 3 ] to Part 732. You'll notice that the second paragraph is the stock "restricted countries" list and the third paragraph is a "safe haven" clause for ftp/http posting. This basically says that crypto source code which is unencumbered may be exported merely by notifying them of the URL (mailto URL's????) where it is available from. No review, no approval, no license, no key length silliness, and no inherited encumberances. :-) I won't post the whole $#@$#@ thing (since you can read it at the CDT site anyways) but for things like "Idea" and "RSA", which ARE encumbered by patents, similar clauses exist at 740.17(a)(5) which say basically the same thing. This is scheduled to become finalized on January 14. Everything I have heard indicates that there will be no significant changes at this point and these will be the new regulations and will be finalized on schedule. > It CAN be added afterwards by anyone (except where local law prohibits > its use, ie. USSR, Cuba, etc...) > This situation could change if the US government gives up its > pointless export restrictions on purely defensive technology, OR, the > main maintenance/distribution of the kernel leaves the US (Hey Linus, > going back to Finland anytime soon?) Looks like he won't even have to do it for 2.4. Linus and HPA have already indicated readiness to included hardened cryptography in the kernel sources, based on the first draft regulations. Second draft goes beyond even that, and they won't even need to go to any special effort to segregate out the crypto code. All they have to do is file the paperwork on the URL for the kernel sources and a-way-we-go. As soon as these regs ARE finalized and we have confirmed that they ARE what we now expect them to be, I think a lot of us are going to lobby Linus, HPA, and Alan Cox to get it done. I would personally love to see KLIPS in 2.4 and that's not totally outlandish considering that the time frames and a 2.4 release date of mid Feb at earliest. > > > I haven't been able to find any good, recently updated resources on this > > > topic, and ppp over ssh isn't perfect - or compatible with routers :) > > http://www.freeswan.org > > Currently in release version 1.2. Daily snapshots are required > > if you are working with the 2.3.x kernels or want the latest toots and > > whistles. Version 1.2 will patch the 2.2.x kernels. Pluto (IKE) supports > > automatic keying. Some patches exist for PKI and certificates. > The version 1.2 patches are fairly important, or get a new snapshot. > Another release is due around the end of January. "Release Early, > Release Often" > > Mailing list: linux-ipsec@clinet.fi > > FTP Site: ftp://ftp.xs4all.nl/pub/crypto/freeswan > > > TIA, > > > -g > > Mike > Thanks Mike! > > -- > > Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com > > (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ > > NIC whois: MHW9 | An optimist believes we live in the best of all > > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! > slainte mhath, RGB > -- > Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada > > Prevent Internet Wiretapping! -- FreeS/WAN: > Thanks for voting Green! -- Marillion: Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-netdev@oss.sgi.com Wed Jan 12 01:30:09 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 01:29:49 -0800 Received: from toad.com ([140.174.2.1]:37136 "EHLO toad.com") by oss.sgi.com with ESMTP id ; Wed, 12 Jan 2000 01:29:22 -0800 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id BAA22616; Wed, 12 Jan 2000 01:30:19 -0800 (PST) Message-Id: <200001120930.BAA22616@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Michael H. Warfield" cc: Richard Guy Briggs , Greg Simpson , netdev@oss.sgi.com, gnu@toad.com Subject: Re: linux-ipsec: Re: current IPSEC/SKIP implementations? In-reply-to: <20000111205025.C10109@alcove.wittsend.com> Date: Wed, 12 Jan 2000 01:30:19 -0800 From: John Gilmore Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > This basically says that crypto source code which is unencumbered > may be exported merely by notifying them of the URL (mailto URL's????) > where it is available from. No review, no approval, no license, no key > length silliness, and no inherited encumberances. :-) Under these draft regs, things are a lot better, though they still restrict Internet distribution in ways that they couldn't get away with for books (e.g. requiring you to notify the gov't when you publish one?!). The court cases will proceed until they really do make it compatible with the First Amendment. In particular it's unclear whether mirror sites also have to mail in their URLs or face prosecution. And if you KNOW that a recipient is in one of the seven verboten countries, e.g. Syria or Cuba, then you are still in trouble. And if you provide technical assistance to someone outside the US, like answering questions on a mailing list, that's still a crime under separate sections of the same regulations. I still plan to run the Linux IPSEC project using the same old rules (avoiding US contributions), at least for a few months, while we see how things shake out. However, the Linux kernel people are free to pick up the code and do what they want with it, including putting it into the main distribution. We were at least hoping we could get the include file and misc "patches" changes into the 2.4 distribution, so we could stop patching a bunch of existing kernel files (making it possible to distribute IPSEC as a module that can be separately compiled, and added to any kernel). Also note that the current IPSEC code only does VPNs and requires manual configuration and debugging. We're shooting for a version that does automatic configuration, and automatically encrypts with anybody else who's also running IPSEC, within the next few months. (We call that a Real Private Network, not a Virtual Private Network.) I'd rather not have a monster user base running the old manual stuff, making it hard to move over to the right stuff. This is a case where the good may be an enemy of the best; the current stuff doesn't scale, but the best stuff will scale to worldwide use. > I won't post the whole $#@$#@ thing (since you can read it at the > CDT site anyways) but for things like "Idea" and "RSA", which ARE encumbered > by patents, similar clauses exist at 740.17(a)(5) which say basically the > same thing. Actually that other section is for published source code that you can't commercialize, like Sun's "Community Source License". Copylefted code, even if it includes patented algorithms, isn't covered. We think. But this part of the regs is particularly unclear. This brings up a separate issue, which kernel folks may not care about since it isn't in kernel code. The Pluto daemon that negotiates keys for the kernel currently implements RSA as one of its options, since it's the best technology, and is available for use everywhere other than the US, as well as in all US Federal sites, and in any big company that has a patent license. That patent expires in October 2000; in the meantime, US folks will run a risk if they don't do something special (like replace the RSA implementation with a paid-for-or-otherwise-licensed one). I think they're OK as long as they don't use the optional RSA feature, but it will become required for automatic configuration, once we have that working. John From owner-netdev@oss.sgi.com Wed Jan 12 08:29:29 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 08:29:10 -0800 Received: from [206.171.92.89] ([206.171.92.89]:63239 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Wed, 12 Jan 2000 08:28:51 -0800 Received: (qmail 11018 invoked from network); 12 Jan 2000 16:26:51 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 12 Jan 2000 16:26:51 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id IAA21097; Wed, 12 Jan 2000 08:29:21 -0800 Date: Wed, 12 Jan 2000 08:29:21 -0800 Message-Id: <200001121629.IAA21097@ns1.filetron.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: David Jeffery To: netdev@oss.sgi.com Subject: ipv6 netfilter 0.3.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi all. My port of netfilter to ipv6 has finally gotten another update. This one supports the netfilter get/setsockopt extentions and has a program to test them. No useful modules have been ported to it but that's on my list of things to do in the future. Highlights: added sockopt extentions ported to 2.3.39 It can be found at http://lordbeatnik.dynodns.net/netfilter David "LordBeatnik" Jeffery ------ Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com From owner-netdev@oss.sgi.com Wed Jan 12 15:48:35 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 15:48:25 -0800 Received: from [206.171.92.89] ([206.171.92.89]:8718 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Wed, 12 Jan 2000 15:48:10 -0800 Received: (qmail 2472 invoked from network); 12 Jan 2000 23:46:12 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 12 Jan 2000 23:46:12 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id PAA20112; Wed, 12 Jan 2000 15:48:42 -0800 Date: Wed, 12 Jan 2000 15:48:42 -0800 Message-Id: <200001122348.PAA20112@ns1.filetron.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: lordbeatnik To: netdev@oss.sgi.com Subject: Re: sin6_scope_id Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing kuznet@ms2.inr.ac.ru wrote: >Hello! > >> Everyone has to support sin6_scope_id. > >Yes, Sir! Are we in the army now? 8) > > >Let me to cite the only intelligible argument for sin6_scope_id >(your one, right?) to show people, who did not listen ipng, >style of IPng WG discussions, resulting in such decisions: well, it's not a very good reason, (there are other ways of getting around it), but for telling which interface a multicast packet came from if you bound your multicast socket to ifindex 0 and as another way to tell what interface to send out a multicast packet. but then, as I said earlier, this can also be done by setting sockets to specific ifindexes when joining a multicast group. It's not much, but it's something to think about. David "LordBeatnik" Jeffery ---------------------- Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com From owner-netdev@oss.sgi.com Wed Jan 12 16:45:45 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 16:45:35 -0800 Received: from laurin.munich.netsurf.de ([194.64.166.1]:19898 "EHLO laurin.munich.netsurf.de") by oss.sgi.com with ESMTP id ; Wed, 12 Jan 2000 16:45:28 -0800 Received: from fred.muc.de (none@ns1188.munich.netsurf.de [195.180.235.188]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id BAA07257; Thu, 13 Jan 2000 01:46:43 +0100 (MET) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 128YPy-00012W-00; Thu, 13 Jan 2000 01:47:14 +0100 Date: Thu, 13 Jan 2000 01:47:14 +0100 From: Andi Kleen To: lordbeatnik Cc: netdev@oss.sgi.com Subject: Re: sin6_scope_id Message-ID: <20000113014714.A3983@fred.muc.de> References: <200001122348.PAA20112@ns1.filetron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <200001122348.PAA20112@ns1.filetron.com>; from lordbeatnik on Thu, Jan 13, 2000 at 12:51:29AM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, Jan 13, 2000 at 12:51:29AM +0100, lordbeatnik wrote: > kuznet@ms2.inr.ac.ru wrote: > >Hello! > > > >> Everyone has to support sin6_scope_id. > > > >Yes, Sir! Are we in the army now? 8) > > > > > >Let me to cite the only intelligible argument for sin6_scope_id > >(your one, right?) to show people, who did not listen ipng, > >style of IPng WG discussions, resulting in such decisions: > > well, it's not a very good reason, (there are other ways of getting around it), but for telling which interface a multicast packet came from if you bound your multicast socket to ifindex 0 and as another way to tell what interface to send out a multicast packet. > > but then, as I said earlier, this can also be done by setting sockets to specific ifindexes when joining a multicast group. > > It's not much, but it's something to think about. Or by using IPV6_PKTINFO Anyways, there is a unused 16bit field in the linux sockaddr_ipv6, so adding it later for source code compatibility is always possible. -Andi -- This is like TV. I don't like TV. From owner-netdev@oss.sgi.com Wed Jan 12 17:35:35 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 17:35:25 -0800 Received: from kanako.isi.edu ([128.9.160.209]:24069 "EHLO v6.linux.or.jp") by oss.sgi.com with ESMTP id ; Wed, 12 Jan 2000 17:35:14 -0800 Received: from localhost (IDENT:sekiya@LOCALHOST [::ffff:127.0.0.1] (may be forged)) by v6.linux.or.jp (8.9.3+3.1W/3.3Wb4) with ESMTP id KAA04453; Thu, 13 Jan 2000 10:36:25 +0900 Date: Thu, 13 Jan 2000 10:36:18 +0900 Message-ID: From: Yuji Sekiya To: ak@muc.de Cc: lordbeatnik@linuxstart.com, netdev@oss.sgi.com Subject: Re: sin6_scope_id In-Reply-To: In your message of "Thu, 13 Jan 2000 01:47:14 +0100" <20000113014714.A3983@fred.muc.de> References: <200001122348.PAA20112@ns1.filetron.com> <20000113014714.A3983@fred.muc.de> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i586-pc-linux) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 990604(IM116) Lines: 18 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Thu, 13 Jan 2000 01:47:14 +0100, Andi Kleen wrote: Hello, > Anyways, there is a unused 16bit field in the linux sockaddr_ipv6, > so adding it later for source code compatibility is always possible. Really ? Where is a unused 16 bit field ?? Furthermore, sin6_socpe_id requires 32bit field. Other operating systems has been implemented sin6_scope_id in sockaddr_in6 already. We encounterd the problem of application portability. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Wed Jan 12 18:12:45 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 18:12:36 -0800 Received: from laurin.munich.netsurf.de ([194.64.166.1]:42489 "EHLO laurin.munich.netsurf.de") by oss.sgi.com with ESMTP id ; Wed, 12 Jan 2000 18:12:15 -0800 Received: from fred.muc.de (none@ns1188.munich.netsurf.de [195.180.235.188]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id DAA13467; Thu, 13 Jan 2000 03:13:28 +0100 (MET) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 128Zlw-000182-00; Thu, 13 Jan 2000 03:14:00 +0100 Date: Thu, 13 Jan 2000 03:13:59 +0100 From: Andi Kleen To: Yuji Sekiya Cc: ak@muc.de, lordbeatnik@linuxstart.com, netdev@oss.sgi.com Subject: Re: sin6_scope_id Message-ID: <20000113031359.A4316@fred.muc.de> References: <200001122348.PAA20112@ns1.filetron.com> <20000113014714.A3983@fred.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Yuji Sekiya on Thu, Jan 13, 2000 at 02:36:36AM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, Jan 13, 2000 at 02:36:36AM +0100, Yuji Sekiya wrote: > > > Anyways, there is a unused 16bit field in the linux sockaddr_ipv6, > > so adding it later for source code compatibility is always possible. > > Really ? Where is a unused 16 bit field ?? > Furthermore, sin6_socpe_id requires 32bit field. Sorry I was wrong. There isn't. With the 32bit requirement it would not have been sufficient anyways. Unfortunately it is rather hard to switch sockaddr* formats in Linux, you would need completely new socket calls and lots of infrastructure. I see no easy way to do it. -Andi -- This is like TV. I don't like TV. From owner-netdev@oss.sgi.com Wed Jan 12 18:13:25 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 18:13:15 -0800 Received: from kanako.isi.edu ([128.9.160.209]:27141 "EHLO v6.linux.or.jp") by oss.sgi.com with ESMTP id ; Wed, 12 Jan 2000 18:13:05 -0800 Received: from localhost (IDENT:sekiya@LOCALHOST [::ffff:127.0.0.1] (may be forged)) by v6.linux.or.jp (8.9.3+3.1W/3.3Wb4) with ESMTP id LAA04540; Thu, 13 Jan 2000 11:14:14 +0900 Date: Thu, 13 Jan 2000 11:14:07 +0900 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: bound@zk3.dec.com, netdev@oss.sgi.com, users@ipv6.org, yoshfuji@ecei.tohoku.ac.jp Subject: Re: sin6_scope_id In-Reply-To: In your message of "Tue, 11 Jan 2000 16:09:31 +0300 (MSK)" <200001111309.QAA10035@ms2.inr.ac.ru> References: <200001110056.TAA0000006214@quarry.zk3.dec.com> <200001111309.QAA10035@ms2.inr.ac.ru> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.2 (beta19) (Shinjuku) (i586-pc-linux) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 990604(IM116) Lines: 20 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Tue, 11 Jan 2000 16:09:31 +0300 (MSK), ++ kuznet@ms2.inr.ac.ru wrote: Hello Alexey, > > Everyone has to support sin6_scope_id. > > Yes, Sir! Are we in the army now? 8) Do you intend to implement this feature in linux-2.5 ? :-) If so, We are very happy !! I think you are now very busy for releasing linux-2.4 kernel. I and Yoshifuji hope that you will let us know if we can help you in any way. Best Regards. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Wed Jan 12 19:58:37 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 19:58:28 -0800 Received: from mailext03.compaq.com ([207.18.199.41]:35053 "HELO mailext03.compaq.com") by oss.sgi.com with SMTP id ; Wed, 12 Jan 2000 19:58:14 -0800 Received: by mailext03.compaq.com (Postfix, from userid 12345) id D4FEE151FE9; Wed, 12 Jan 2000 21:59:36 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id C87C0148506; Wed, 12 Jan 2000 21:59:36 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 17AB3BC4DC; Wed, 12 Jan 2000 21:59:29 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 80001B2A45; Wed, 12 Jan 2000 21:59:28 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000007676; Wed, 12 Jan 2000 22:59:35 -0500 (EST) From: Jim Bound Message-Id: <200001130359.WAA0000007676@quarry.zk3.dec.com> To: Cc: bound@zk3.dec.com (Jim Bound), sekiya@ISI.EDU, netdev@oss.sgi.com, users@ipv6.org, yoshfuji@ecei.tohoku.ac.jp Subject: Re: sin6_scope_id In-reply-to: Your message of "Tue, 11 Jan 2000 16:09:31 +0300." <200001111309.QAA10035@ms2.inr.ac.ru> Date: Wed, 12 Jan 2000 22:59:34 -0500 X-Mts: smtp Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Alexey, >> Everyone has to support sin6_scope_id. > >Yes, Sir! Are we in the army now? 8) You know I did mean it like that. Its a req per the IETF. A platform does not have to implement anything its a matter of what will be expected and compliant by the market. I suggest to you that Linux does not want to be the only platform that does not support scopes. >Let me to cite the only intelligible argument for sin6_scope_id >(your one, right?) to show people, who did not listen ipng, >style of IPng WG discussions, resulting in such decisions: > >> The WG wants this done in the socket address. There were a long list of reasons the WG wants it. It is there because we have link-local and site-local addresses permitted in IPv6. /jim :-) Alexey From owner-netdev@oss.sgi.com Wed Jan 12 20:44:19 2000 Received: by oss.sgi.com id ; Wed, 12 Jan 2000 20:44:00 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:32520 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Wed, 12 Jan 2000 20:43:42 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id NAA12755; Thu, 13 Jan 2000 13:44:01 +0900 To: kuznet@ms2.inr.ac.ru CC: sekiya@ISI.EDU, netdev@oss.sgi.com, users@ipv6.org, bound@zk3.dec.com Subject: Re: sin6_scope_id From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <200001130359.WAA0000007676@quarry.zk3.dec.com> References: <200001111309.QAA10035@ms2.inr.ac.ru> <200001130359.WAA0000007676@quarry.zk3.dec.com> X-Mailer: Mew version 1.94 on XEmacs 20.4 (Emerald) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000113134400K.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Thu, 13 Jan 2000 13:44:00 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 19 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Alexey, In article <200001130359.WAA0000007676@quarry.zk3.dec.com> (at Wed, 12 Jan 2000 22:59:34 -0500), Jim Bound says: > .. I suggest to you that Linux > does not want to be the only platform that does not support scopes. We, Sekiya, I and other Linux IPv6 Users JP members, discussed on this issue, and now we think Linux must not go wrong. Delays are dangerous. Let's make a room for sin6_scope_id as soon as possible. (I know you are busy, but the best to do is to add into 2.3.x kernels.) After that, support code for sin6_scope_id should be added. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Thu Jan 13 11:29:24 2000 Received: by oss.sgi.com id ; Thu, 13 Jan 2000 11:29:14 -0800 Received: from alcove.wittsend.com ([130.205.0.20]:1293 "EHLO alcove.wittsend.com") by oss.sgi.com with ESMTP id ; Thu, 13 Jan 2000 11:28:53 -0800 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id OAA13403; Thu, 13 Jan 2000 14:28:39 -0500 Date: Thu, 13 Jan 2000 14:28:39 -0500 From: "Michael H. Warfield" To: John Gilmore Cc: "Michael H. Warfield" , Richard Guy Briggs , Greg Simpson , netdev@oss.sgi.com, linux-ipsec@clinet.fi Subject: Re: linux-ipsec: Re: current IPSEC/SKIP implementations? Message-ID: <20000113142839.A30881@alcove.wittsend.com> References: <20000111205025.C10109@alcove.wittsend.com> <200001120930.BAA22616@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.2i In-Reply-To: <200001120930.BAA22616@toad.com>; from gnu@toad.com on Wed, Jan 12, 2000 at 01:30:19AM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hey John (et al)... Interim final is up for review on the CDT web site. Basically the same thing as the second draft, but with some clarifications addressing a couple of your issues below... On Wed, Jan 12, 2000 at 01:30:19AM -0800, John Gilmore wrote: > > This basically says that crypto source code which is unencumbered > > may be exported merely by notifying them of the URL (mailto URL's????) > > where it is available from. No review, no approval, no license, no key > > length silliness, and no inherited encumberances. :-) > Under these draft regs, things are a lot better, though they still > restrict Internet distribution in ways that they couldn't get away > with for books (e.g. requiring you to notify the gov't when you > publish one?!). The court cases will proceed until they really do > make it compatible with the First Amendment. Agreed. We're not done yet. We were hoping to get the nose of the camel in the tent and we got the nose, face, front quarters and fanny. It ain't in bed yet and we still have this notification "tail" wagging outside the tent yet, but it's real close. It's interesting that this latest round is now taking explicit notice of the unique nature of "the 'open source' approach to software development". IMHO, this is a good thing on the balance. What's left in these regs, vis-a-vis open source and publicly available source, shouldn't stand too much longer. There just isn't much left there for them to regulate. Conversely, and indirectly, they've actually made it much harder to use lawsuits in the open source arena to attack their key-length limits and other regulations for commodity software and other regulated items. Even if the remaining lawsuits aren't thrown out on their ear as moot, the regs look pretty well compartmentalized that they could throw out the remaining few gotchas for open source (maybe they were left there as throwdowns?) and still retain all of their existing regs for the commercial arena. That angle does not leave me with a warm and fuzzy. > In particular it's unclear whether mirror sites also have to mail in > their URLs or face prosecution. And if you KNOW that a recipient is A clarification there was that the notification was only for "initial" export and that end-users (would a mirror site be a user) would be explicitly exempt from the notification requirement. Mirror sites are still a little bit hazy but looking better. > in one of the seven verboten countries, e.g. Syria or Cuba, then you > are still in trouble. ... Actually, no. Not if it's an ftp or web site. If you SHIP something to them on a CD or in explicit private E-Mail, it may be a different issue. It's pretty well spelled out that posting on an ftp or http site does not establish "knowledge" or a necessity to even ask (don't ask don't tell). You might argue that prior knowledge of individuals on the proscribed list may trigger a requirement to proactively block that access, but since you are not required to screen access to the site (as you are for commercial software downloads), I don't see how that can be made applicable to this particular safe haven clause. They don't even include the "not to government or military users" that still plague the commodity regs for that. The commodity regs still have the screening requirements that include things like ".gov" and ".mil" screening. Gag... None of that applies to open source ftp sites. > ... And if you provide technical assistance to > someone outside the US, like answering questions on a mailing list, > that's still a crime under separate sections of the same regulations. Now here they made a very clear, very explicit clarification. ] Moreover, under §744.9, exporters of unrestricted encryption source ] code are not restrained from providing technical assistance to foreign ] persons working with such source code. That language is pretty clear. One MIGHT argue that one interpretation would be that I could only provide technical assistance for software which I exported, but I don't think that interpretation will hold water. It says "exporters of unrestricted encryption source code" and then refers to "persons working with such source code". I take that to mean "unrestricted encryption source" when they say "such source code" and not to mean "the source code I exported". I think it COULD be argued that this clause doesn't kick in unless I have exported source code, thus triggering a notification clause somewhere else. It would appear on it's face that someone who as never exported unrestricted encryption source code would not be so protected under this clause, but that's a stretch (but a plausable stretch, I'll concede). > I still plan to run the Linux IPSEC project using the same old rules > (avoiding US contributions), at least for a few months, while we see > how things shake out. However, the Linux kernel people are free > to pick up the code and do what they want with it, including putting > it into the main distribution. Makes perfect sense to me. I still look forward to the day when I can stop bitching "IT'S BROKE!" and send it fixes. :-) > We were at least hoping we could get the include file and misc > "patches" changes into the 2.4 distribution, so we could stop patching a > bunch of existing kernel files (making it possible to distribute IPSEC > as a module that can be separately compiled, and added to any kernel). This would be a VERY GOOD THING. :-) I'm working on lobying for at least that very thing. I think HPA has already posted something (prior to the second draft) along the lines that he and Linus have been thinking about it. > Also note that the current IPSEC code only does VPNs and requires > manual configuration and debugging. We're shooting for a version that > does automatic configuration, and automatically encrypts with > anybody else who's also running IPSEC, within the next few months. > (We call that a Real Private Network, not a Virtual Private Network.) > I'd rather not have a monster user base running the old manual stuff, > making it hard to move over to the right stuff. This is a case where > the good may be an enemy of the best; the current stuff doesn't > scale, but the best stuff will scale to worldwide use. Hmmm... Interesting point. But if we worried too much about the old user base stuff, we would have a hard time with any release cycle and would loose out on an expanded bug-fix feedback effect. Most of this is pluto and user-land stuff for keying, though, isn't it? The real biggie for the kernel would be the crypto algorithms and such. I've got and installed base of IPSec out there now (TimeStep, CheckPoint VPN-1 and some OpenBSD). I'm more worried about interoperability and limits on my ability to deploy Linux systems into this existing infrastructure. > > I won't post the whole $#@$#@ thing (since you can read it at the > > CDT site anyways) but for things like "Idea" and "RSA", which ARE encumbered > > by patents, similar clauses exist at 740.17(a)(5) which say basically the > > same thing. > Actually that other section is for published source code that you can't > commercialize, like Sun's "Community Source License". Copylefted > code, even if it includes patented algorithms, isn't covered. We > think. But this part of the regs is particularly unclear. Yeah... I read that several times and I wasn't clear how to interpret it. My original point was to make it clear we were safe no matter which way you interpret it. They added explicit language to clarify that by adding that "Intellectual property protection (e.g., copyright, patent, or trademark) would not, by itself, be construted as an express agreement...." > This brings up a separate issue, which kernel folks may not care about > since it isn't in kernel code. The Pluto daemon that negotiates keys > for the kernel currently implements RSA as one of its options, since > it's the best technology, and is available for use everywhere other > than the US, as well as in all US Federal sites, and in any big > company that has a patent license. That patent expires in October > 2000; in the meantime, US folks will run a risk if they don't do > something special (like replace the RSA implementation with a > paid-for-or-otherwise-licensed one). I think they're OK as long as > they don't use the optional RSA feature, but it will become required > for automatic configuration, once we have that working. John... This one really should be a dead issue. It's been addressed several times over in the SSL libraries, Apache-ssl, mod-ssl, SSH, PGP, and a host of others. People outside the US use the international libraries People inside the US use RSAREF2 (with appropriate overflow patches now) for non-commercial use. People inside the US wanting to use this commercially pay a nominal fee to an appropriate vendor for the flavor that they want. I bought the RedHat E-Commerce package to have a fully licensed, legal for commercial use, Apache-SSL server. If you are using it for commercial use, it won't break your back (especially compared with the REAL commercial stuff). We're already use to working like this. We may not like it, but it beats the hell out of not having it! We've already solved this problem with other apps, pluto is just another app in that regard. Come October, the need for RSAREF2 evaporates as does the commercial licensing issues. I can live with that. > John Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-netdev@oss.sgi.com Thu Jan 13 17:14:09 2000 Received: by oss.sgi.com id ; Thu, 13 Jan 2000 17:13:59 -0800 Received: from [206.171.92.89] ([206.171.92.89]:60943 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Thu, 13 Jan 2000 17:13:40 -0800 Received: (qmail 20547 invoked from network); 14 Jan 2000 01:11:47 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 14 Jan 2000 01:11:47 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id RAA31198; Thu, 13 Jan 2000 17:14:14 -0800 Date: Thu, 13 Jan 2000 17:14:14 -0800 Message-Id: <200001140114.RAA31198@ns1.filetron.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: David Jeffery To: netdev@oss.sgi.com Subject: Re: sin6_scope_id Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) wrote: >Alexey, > >In article <200001130359.WAA0000007676@quarry.zk3.dec.com> (at Wed, 12 Jan 2000 22:59:34 -0500), Jim Bound says: > >> .. I suggest to you that Linux >> does not want to be the only platform that does not support scopes. > >We, Sekiya, I and other Linux IPv6 Users JP members, discussed on this >issue, and now we think Linux must not go wrong. > >Delays are dangerous. Let's make a room for sin6_scope_id as soon as >possible. (I know you are busy, but the best to do is to add into >2.3.x kernels.) After that, support code for sin6_scope_id should be >added. Alexey can't just add the sin6_scope_id field. It would break userspace. for example, the following line from inet6_bind if (addr_len < sizeof(struct sockaddr_in6)) return -EINVAL; would reject current userspace programs without sin6_scope_id. Also, you'd have to make sure copy_from/to_user would copy the proper size. and not copy garbage or overwrite userspace. from my limited experiance with the ip6 stack, it would seem possible to play games like: if (addr_len < SOCKADDR_IN6_MIN)) return -EINVAL; and if(userlen >= sizeof(struct sockaddr_in6)) copy_from_user(..., sizeof(struct sockaddr_in6); else if(userlen >= SOCKADDR_IN6_MIN)) copy_from_user(..., SOCKADDR_IN6_MIN); where SOCKADDR_IN6_MIN is the size of sockaddr_in6 without sin6_scope_id. You'd also have to make sure sin6_scope_id inits to 0 when dealing with scope_id-less userspace Those are just the issues I've seen with a quick scan of the relivant code. Most of my code reading has been with other sections of the stack, so can others more familiar with it speak of any other issues that make it a pain or would break userspace? David "LordBeatnik" Jeffery ---------------------- Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com From owner-netdev@oss.sgi.com Thu Jan 13 18:07:59 2000 Received: by oss.sgi.com id ; Thu, 13 Jan 2000 18:07:50 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:10245 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Thu, 13 Jan 2000 18:07:29 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id LAA08043 for ; Fri, 14 Jan 2000 11:08:43 +0900 To: netdev@oss.sgi.com Subject: Re: sin6_scope_id From: Hideaki YOSHIFUJI In-Reply-To: <200001140114.RAA31198@ns1.filetron.com> References: <200001140114.RAA31198@ns1.filetron.com> X-Mailer: Mew version 1.94 on XEmacs 20.4 (Emerald) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000114110843X.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Fri, 14 Jan 2000 11:08:43 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 27 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In article <200001140114.RAA31198@ns1.filetron.com> (at Thu, 13 Jan 2000 17:14:14 -0800), David Jeffery says: > Alexey can't just add the sin6_scope_id field. It would break userspace. : > from my limited experiance with the ip6 stack, it would seem possible to play games like: > > if (addr_len < SOCKADDR_IN6_MIN)) > return -EINVAL; > > and > if(userlen >= sizeof(struct sockaddr_in6)) > copy_from_user(..., sizeof(struct sockaddr_in6); > else if(userlen >= SOCKADDR_IN6_MIN)) > copy_from_user(..., SOCKADDR_IN6_MIN); > > where SOCKADDR_IN6_MIN is the size of sockaddr_in6 without sin6_scope_id. > You'd also have to make sure sin6_scope_id inits to 0 when dealing with scope_id-less userspace I agree. We've already discussed on this transitional problem, and the solition we reached at that time is similar to yours. The differences is that we should use sizeof(struct sockaddr_in6_min) instead of numeric constant to avoid alignment problem. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Sat Jan 15 09:28:19 2000 Received: by oss.sgi.com id ; Sat, 15 Jan 2000 09:28:00 -0800 Received: from smtp1.libero.it ([193.70.192.51]:36483 "EHLO smtp1.libero.it") by oss.sgi.com with ESMTP id ; Sat, 15 Jan 2000 09:27:53 -0800 Received: from armageddon.allanon.org (151.20.25.4) by smtp1.libero.it; 15 Jan 2000 18:29:31 +0100 Received: by armageddon.allanon.org (Postfix, from userid 0) id 628D35F4E; Sun, 16 Jan 2000 10:36:28 +0100 (CET) Date: Sun, 16 Jan 2000 10:36:28 +0100 From: Gigi Sullivan To: netdev@oss.sgi.com Subject: kernel 2.0.38: getting route entries addendum/patch. Message-ID: <20000116103627.A716@armageddon.libero.it> Reply-To: sullivan@sikurezza.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi all :) First off, I'm sorry if this is the wrong ml. Please forgive me. And ... if this could be useless please forgive me twice ! :) I wrote a little kernel (version 2.0.38) patch (or addendum, callit how you want) to get the list of all the route entries on the system. I know that you can get the same result reading from /proc filesystem, but I was thinking: "We have SIOCADDRT/SIOCDELRT ioctl calls. Why don't to have a SIOCLSTRT ioctl call too ?" Well, the other reason is that /proc could be unmounted and however I'd like to add a "clean" way to get this kind of info. I won't post the patch against 2.0.38 kernel series since, before, I wish to get some feedback, expecially from the maintainers. Just FYI the patch provides a way to get all the route entries, by working just as the SIOCIFCONF ioctl call. Just for example, let's show the little C code from user space: (error condition are unchecked just to be clear) int fd; struct rtconf rtconf; struct rtreq rtreq[16]; rtconf.rt_addr = (caddr_t) rtreq; rtconf.rt_len = sizeof(rtreq); fd = socket(AF_INET, SOCK_DGRAM, 0); ioctl(fd, SIOCLSTRT, &rtconf); rtconf{} and rtreq{} are the two new structures I added both in kernel and user header file. Now rtreq[] will hold all the route entries (er static one, obviously) of our system. rtconf.rt_len will hold the byte effectivly transferred by the kernel to the userspace through the ioctl call. As you can see, the behaviour of this ioctl is like SIOCIFCONF one. For any info, flame, correction and so on feel free to contact me :) THX ! bye bye -- gg sullivan -- Lorenzo Cavallaro `Gigi Sullivan' -- ITALY Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) From owner-netdev@oss.sgi.com Sat Jan 15 09:29:59 2000 Received: by oss.sgi.com id ; Sat, 15 Jan 2000 09:29:49 -0800 Received: from smtp1.libero.it ([193.70.192.51]:31622 "EHLO smtp1.libero.it") by oss.sgi.com with ESMTP id ; Sat, 15 Jan 2000 09:29:42 -0800 Received: from armageddon.allanon.org (151.20.25.4) by smtp1.libero.it; 15 Jan 2000 18:31:20 +0100 Received: by armageddon.allanon.org (Postfix, from userid 0) id A9C9D5F4E; Sun, 16 Jan 2000 10:38:21 +0100 (CET) Date: Sun, 16 Jan 2000 10:36:28 +0100 From: Gigi Sullivan To: netdev@oss.sgi.com Subject: kernel 2.0.38: getting route entries addendum/patch. Message-ID: <20000116103627.A716@armageddon.libero.it> Reply-To: sullivan@sikurezza.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi all :) First off, I'm sorry if this is the wrong ml. Please forgive me. And ... if this could be useless please forgive me twice ! :) I wrote a little kernel (version 2.0.38) patch (or addendum, callit how you want) to get the list of all the route entries on the system. I know that you can get the same result reading from /proc filesystem, but I was thinking: "We have SIOCADDRT/SIOCDELRT ioctl calls. Why don't to have a SIOCLSTRT ioctl call too ?" Well, the other reason is that /proc could be unmounted and however I'd like to add a "clean" way to get this kind of info. I won't post the patch against 2.0.38 kernel series since, before, I wish to get some feedback, expecially from the maintainers. Just FYI the patch provides a way to get all the route entries, by working just as the SIOCIFCONF ioctl call. Just for example, let's show the little C code from user space: (error condition are unchecked just to be clear) int fd; struct rtconf rtconf; struct rtreq rtreq[16]; rtconf.rt_addr = (caddr_t) rtreq; rtconf.rt_len = sizeof(rtreq); fd = socket(AF_INET, SOCK_DGRAM, 0); ioctl(fd, SIOCLSTRT, &rtconf); rtconf{} and rtreq{} are the two new structures I added both in kernel and user header file. Now rtreq[] will hold all the route entries (er static one, obviously) of our system. rtconf.rt_len will hold the byte effectivly transferred by the kernel to the userspace through the ioctl call. As you can see, the behaviour of this ioctl is like SIOCIFCONF one. For any info, flame, correction and so on feel free to contact me :) THX ! bye bye -- gg sullivan -- Lorenzo Cavallaro `Gigi Sullivan' -- ITALY Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) From owner-netdev@oss.sgi.com Sat Jan 15 09:32:30 2000 Received: by oss.sgi.com id ; Sat, 15 Jan 2000 09:32:19 -0800 Received: from smtp1.libero.it ([193.70.192.51]:63369 "EHLO smtp1.libero.it") by oss.sgi.com with ESMTP id ; Sat, 15 Jan 2000 09:32:00 -0800 Received: from armageddon.allanon.org (151.20.25.4) by smtp1.libero.it; 15 Jan 2000 18:33:35 +0100 Received: by armageddon.allanon.org (Postfix, from userid 0) id 5620A5F4E; Sun, 16 Jan 2000 10:40:36 +0100 (CET) Date: Sun, 16 Jan 2000 10:40:36 +0100 From: Gigi Sullivan To: netdev@oss.sgi.com Subject: kernel 2.0.38: getting route entries addendum/patch. (further) Message-ID: <20000116104035.B716@armageddon.libero.it> Reply-To: sullivan@sikurezza.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hey, Hello again :) I forgot to say just a thing. I'm however working (well, plan to do) a 2.2.X port of the SIOCLSTRT ioctl call ... As I said in my previous post, if this just exists or it'useless, please forgive me ! :D bye bye -- gg sullivan -- Lorenzo Cavallaro `Gigi Sullivan' -- ITALY Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) From owner-netdev@oss.sgi.com Mon Jan 17 14:31:13 2000 Received: by oss.sgi.com id ; Mon, 17 Jan 2000 14:30:54 -0800 Received: from tnt.isi.edu ([128.9.128.128]:31423 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Mon, 17 Jan 2000 14:30:23 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA23136; Mon, 17 Jan 2000 14:32:08 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id OAA02605; Mon, 17 Jan 2000 14:32:08 -0800 (PST) Date: Mon, 17 Jan 2000 14:32:07 -0800 Message-ID: From: Yuji Sekiya To: lordbeatnik@linuxstart.com Cc: netdev@oss.sgi.com Subject: Re: sin6_scope_id In-Reply-To: In your message of "Thu, 13 Jan 2000 17:14:14 -0800" <200001140114.RAA31198@ns1.filetron.com> References: <200001140114.RAA31198@ns1.filetron.com> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Thu, 13 Jan 2000 17:14:14 -0800, David Jeffery wrote: > if (addr_len < sizeof(struct sockaddr_in6)) > return -EINVAL; > > would reject current userspace programs without sin6_scope_id. I also agree. It sounds good to introduce SOCKADDR_IN6_MIN into kernel for backword compatibility. I think this method can keep binary backward compatibility for existing IPv6 applications. Many of existing IPv6 applications assume that Linux IPv6 stack doesn't have sin6_scope_id. BTW, in addition to introducing sin6_scope_id into kernel, I think we should intorduce it into glibc functions. It causes not less changes into kernel and glibc. Is there anyone who is a developper of glibc in this mailing list ? -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Mon Jan 17 15:21:04 2000 Received: by oss.sgi.com id ; Mon, 17 Jan 2000 15:20:44 -0800 Received: from [130.131.166.29] ([130.131.166.29]:33412 "EHLO canospam.agcs.com") by oss.sgi.com with ESMTP id ; Mon, 17 Jan 2000 15:20:15 -0800 Received: from frontier. (marshal.agcs.com [130.131.60.2]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id QAA13158 for ; Mon, 17 Jan 2000 16:21:56 -0700 (MST) Received: from bootstrap.agcs.com ([130.131.48.11]) by frontier.agcs.com; Mon, 17 Jan 2000 16:21:44 +0000 (MST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (8.9.3/8.9.1) with ESMTP id QAA25073 for ; Mon, 17 Jan 2000 16:20:58 -0700 (MST) Posted-Date: Mon, 17 Jan 2000 16:20:58 -0700 (MST) Received: from agcs.com ([130.131.166.110]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA6702; Mon, 17 Jan 2000 16:21:42 -0700 Message-ID: <3883A406.6CA8A933@agcs.com> Date: Mon, 17 Jan 2000 16:21:42 -0700 From: Ben Greear Reply-To: greearb@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mellon@vix.com, netdev Subject: Question on binding DHCP to an interface (by ifname, not IP/netmask). Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Basically, I will have a bunch of interfaces, with 10.x ip addresses, and I want to give out DHCP addresses that are completly un-related (say 130.131.3.3). I will know by the physical interface what IP addresses I want to give out. It doesn't look like I can do this with dhcpd (from ISC), as it wants to use an ip/mask to determing a physical interface. So, anyone have any ideas, short of hacking the DHCPd code? Thanks, Ben -- Ben Greear greearb@agcs.com Pager: 202-2717 (623) 581 4980 "More weight!" -- _The Crucible._ http://hydrogen:8080/home/greearb/public_html/index.html From owner-netdev@oss.sgi.com Mon Jan 17 15:40:36 2000 Received: by oss.sgi.com id ; Mon, 17 Jan 2000 15:40:16 -0800 Received: from toccata.fugue.com ([204.152.188.66]:60425 "EHLO toccata.fugue.com") by oss.sgi.com with ESMTP id ; Mon, 17 Jan 2000 15:40:07 -0800 Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA22908; Mon, 17 Jan 2000 15:36:18 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3/8.6.11) with ESMTP id SAA06221; Mon, 17 Jan 2000 18:41:22 -0500 (EST) Message-Id: <200001172341.SAA06221@grosse.manhattan.fugue.com> To: greearb@agcs.com cc: netdev Subject: Re: Question on binding DHCP to an interface (by ifname, not IP/netmask). In-Reply-To: Message from Ben Greear of "Mon, 17 Jan 2000 16:21:42 MST." <3883A406.6CA8A933@agcs.com> Date: Mon, 17 Jan 2000 18:41:22 -0500 From: Ted Lemon Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Sure, use the shared-network statement to group the subnet connected to the interface and the subnet on which you want to assign addresses. For example: shared-network FOO { subnet 10.0.0.0 netmask 255.255.255.0 { } subnet 130.131.3.0 netmask 255.255.255.0 { range 130.131.3.10 130.131.3.250; } } The real trick is that dhcpd doesn't provide support for multiple interfaces on Irix right now. _MelloN_ From owner-netdev@oss.sgi.com Tue Jan 18 07:56:01 2000 Received: by oss.sgi.com id ; Tue, 18 Jan 2000 07:55:42 -0800 Received: from solen.ce.chalmers.se ([129.16.20.244]:33431 "EHLO solen.ce.chalmers.se") by oss.sgi.com with ESMTP id ; Tue, 18 Jan 2000 07:55:18 -0800 Received: from rasputin.ce.chalmers.se (rasputin.ce.chalmers.se [129.16.20.199]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id QAA05208; Tue, 18 Jan 2000 16:57:05 +0100 (MET) From: Florian-Daniel Otel Received: (from otel@localhost) by rasputin.ce.chalmers.se (8.8.8/8.8.8) id QAA13001; Tue, 18 Jan 2000 16:57:05 +0100 (MET) Date: Tue, 18 Jan 2000 16:57:05 +0100 (MET) To: Alexey Kuznetsov Reply-to: otel@ce.chalmers.se, dol@ce.chalmers.se Cc: netdev@oss.sgi.com, linux-kernel@vger.rutgers.edu, dol@ce.chalmers.se Subject: Two Ifaces on same subnet setup (problems). X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14468.30343.129124.662080@rasputin.ce.chalmers.se> Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello there, I write to you because I rember seeing some papers describing the new tools for configuring IPv4 on 2.2 and i have a related question: Setup: One system, having two interfaces with two diffrent addresses but from the same subnetwork _and_ both attached to that subnetwork. Consequently the routing table entries look the same. Problem: Traffic generating from any of the two addresses the system and destined to hosts on the attached subnet exits through only one of the interfaces namely the one corresponding to the first route listed in the routing table. While this is reasonable it is not the desired behaviour. I would like that traffic with different source addresses exits through the corresponding interface, NOT through the same one find by the route lookup. Or, alternatively, how can I achieve load balancing between the interfaces in this setup ? Many thanks, Florian. P.S: Sorry if posted to the wrong forums. From owner-netdev@oss.sgi.com Tue Jan 18 17:14:43 2000 Received: by oss.sgi.com id ; Tue, 18 Jan 2000 17:14:34 -0800 Received: from [130.131.166.29] ([130.131.166.29]:38602 "EHLO canospam.agcs.com") by oss.sgi.com with ESMTP id ; Tue, 18 Jan 2000 17:14:21 -0800 Received: from frontier. (marshal.agcs.com [130.131.60.2]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id SAA02447 for ; Tue, 18 Jan 2000 18:16:07 -0700 (MST) Received: from bootstrap.agcs.com ([130.131.48.11]) by frontier.agcs.com; Tue, 18 Jan 2000 18:15:56 +0000 (MST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (8.9.3/8.9.1) with ESMTP id SAA15396 for ; Tue, 18 Jan 2000 18:15:09 -0700 (MST) Posted-Date: Tue, 18 Jan 2000 18:15:09 -0700 (MST) Received: from agcs.com ([130.131.166.110]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA1902; Tue, 18 Jan 2000 18:15:55 -0700 Message-ID: <3885104A.A73BD54C@agcs.com> Date: Tue, 18 Jan 2000 18:15:55 -0700 From: Ben Greear Reply-To: greearb@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon , netdev Subject: Re: Question on binding DHCP to an interface (by ifname, not IP/netmask). References: <200001180137.UAA06520@grosse.manhattan.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 9630 Lines: 219 Ted Lemon wrote: > > I'll let you know how it goes... > > Okay! Should work fine - this is a very frequently used feature. > You might pick up a copy of the DHCP handbook if you want a good > feature tour... :') > > _MelloN_ If I can get this demo working, I'll get mgt to spring for a handbook :) Well, it's not working, and it *looks* like DHCP is to blame, but it could still easily be something on my end. I'm including a bunch of information here in the hopes that it might make it easy for you to see the root of my problem. Note that I'm using VLAN interfaces, which, at least untill this point, looked exactly like ethernet interfaces to every program I've tried to run. If you are interested in the vlan patches, see my web page at: http://scry.wanfear.com/~greear/vlan.html I forgot to print the route table, but I have host routes to all the 130.X devices hanging off of the 10.x vlan devices. If the routes would be useful, I'll happly go get a capture of them... Thanks a heap!! --Ben Here is the output: ************************************************************************************* I flushed firewall rules: ipchains -F before I did this, just to make sure it wasn't the firewall. [root@linserv /root]# ifconfig -a dummy Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 eth0 Link encap:Ethernet HWaddr 00:60:97:29:6F:B2 inet addr:130.131.190.238 Bcast:130.131.190.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:611 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0xff80 eth1 Link encap:Ethernet HWaddr 00:60:97:3C:E6:09 inet addr:192.168.101.1 Bcast:192.168.101.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:46 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0xff40 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:36 errors:0 dropped:0 overruns:0 frame:0 TX packets:36 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 vlan0000 Link encap:Ethernet HWaddr 00:60:97:3C:E6:09 inet addr:10.1.0.1 Bcast:10.255.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 vlan0001 Link encap:Ethernet HWaddr 00:60:97:3C:E6:09 inet addr:10.1.0.2 Bcast:10.255.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:46 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 vlan0002 Link encap:Ethernet HWaddr 00:60:97:3C:E6:09 inet addr:10.1.0.3 Bcast:10.255.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ****************************************** [ Some notes on the dhcpd.conf file: I want to give, in these cases, exactly one IP out for each VLAN interface. That IP has nothing to do with the interface, as far as IP/Mask is concerned. For example, on vlan0001 (VID 21), I want to serve only the ip address: 130.131.190.212 ****************************************** [root@linserv /root]# more /etc/dhcpd.conf default-lease-time 6000000; max-lease-time 12000000; option routers 130.131.190.254; option domain-name "agcs.com"; option domain-name-servers 130.131.190.254; shared-network vlan0000_20 { subnet 10.1.0.1 netmask 255.255.255.255 { } subnet 130.131.190.211 netmask 255.255.255.255 { range 130.131.190.211 130.131.190.211; } } shared-network vlan0001_21 { subnet 10.1.0.2 netmask 255.255.255.255 { } subnet 130.131.190.212 netmask 255.255.255.255 { range 130.131.190.212 130.131.190.212; } } shared-network vlan0002_22 { subnet 10.1.0.3 netmask 255.255.255.255 { } subnet 130.131.190.213 netmask 255.255.255.255 { range 130.131.190.213 130.131.190.213; } } subnet 130.131.190.238 netmask 255.255.255.255 { } subnet 192.168.101.1 netmask 255.255.255.255 { } # End of customer DHCPd entries. [from /var/log/messages, when dhcpd is started (and while the tcpdump, below, is running) Note that I see absolutely zero messages from DHCP, as though it isn't even getting the requests.] Jan 18 17:48:44 linserv dhcpd: Internet Software Consortium DHCP Server 2.0 Jan 18 17:48:44 linserv dhcpd: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. Jan 18 17:48:44 linserv dhcpd: All rights reserved. Jan 18 17:48:44 linserv dhcpd: Jan 18 17:48:44 linserv dhcpd: Please contribute if you find this software useful. Jan 18 17:48:44 linserv dhcpd: For info, please visit http://www.isc.org/dhcp-contrib.html Jan 18 17:48:44 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Internet Software Consortium DHCP Server 2.0 Jan 18 17:48:45 linserv dhcpd: Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. Jan 18 17:48:45 linserv dhcpd: All rights reserved. Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Please contribute if you find this software useful. Jan 18 17:48:45 linserv dhcpd: For info, please visit http://www.isc.org/dhcp-contrib.html Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Listening on LPF/vlan0002/00:60:97:3c:e6:09/vlan0002_22 Jan 18 17:48:45 linserv dhcpd: Listening on LPF/vlan0002/00:60:97:3c:e6:09/vlan0002_22 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Sending on LPF/vlan0002/00:60:97:3c:e6:09/vlan0002_22 Jan 18 17:48:45 linserv dhcpd: Sending on LPF/vlan0002/00:60:97:3c:e6:09/vlan0002_22 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Listening on LPF/vlan0001/00:60:97:3c:e6:09/vlan0001_21 Jan 18 17:48:45 linserv dhcpd: Listening on LPF/vlan0001/00:60:97:3c:e6:09/vlan0001_21 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Sending on LPF/vlan0001/00:60:97:3c:e6:09/vlan0001_21 Jan 18 17:48:45 linserv dhcpd: Sending on LPF/vlan0001/00:60:97:3c:e6:09/vlan0001_21 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Listening on LPF/vlan0000/00:60:97:3c:e6:09/vlan0000_20 Jan 18 17:48:45 linserv dhcpd: Listening on LPF/vlan0000/00:60:97:3c:e6:09/vlan0000_20 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Sending on LPF/vlan0000/00:60:97:3c:e6:09/vlan0000_20 Jan 18 17:48:45 linserv dhcpd: Sending on LPF/vlan0000/00:60:97:3c:e6:09/vlan0000_20 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Listening on LPF/eth1/00:60:97:3c:e6:09/192.168.101.1 Jan 18 17:48:45 linserv dhcpd: Listening on LPF/eth1/00:60:97:3c:e6:09/192.168.101.1 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Sending on LPF/eth1/00:60:97:3c:e6:09/192.168.101.1 Jan 18 17:48:45 linserv dhcpd: Sending on LPF/eth1/00:60:97:3c:e6:09/192.168.101.1 Jan 18 17:48:45 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Listening on LPF/eth0/00:60:97:29:6f:b2/130.131.190.238 Jan 18 17:48:45 linserv dhcpd: Listening on LPF/eth0/00:60:97:29:6f:b2/130.131.190.238 Jan 18 17:48:46 linserv dhcpd: Jan 18 17:48:45 linserv dhcpd: Sending on LPF/eth0/00:60:97:29:6f:b2/130.131.190.238 Jan 18 17:48:46 linserv dhcpd: Sending on LPF/eth0/00:60:97:29:6f:b2/130.131.190.238 Jan 18 17:48:46 linserv dhcpd: Jan 18 17:48:46 linserv dhcpd: Sending on Socket/fallback/fallback-net Jan 18 17:48:46 linserv dhcpd: Sending on Socket/fallback/fallback-net Jan 18 17:48:46 linserv dhcpd: Jan 18 17:48:46 linserv dhcpd: dhcpd startup succeeded [bootp (dhcp) requests coming in on vlan0001] [root@linserv /root]# tcpdump -n -i vlan0001 Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on vlan0001 17:46:03.890910 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:07.885369 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:14.883378 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:27.881390 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.879998 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.887310 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.891304 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.895329 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.902715 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.906730 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] 17:46:33.910755 B 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x653c6df3 [|bootp] -- Ben Greear greearb@agcs.com Pager: 202-2717 (623) 581 4980 "More weight!" -- _The Crucible._ http://hydrogen:8080/home/greearb/public_html/index.html From owner-netdev@oss.sgi.com Tue Jan 18 22:27:24 2000 Received: by oss.sgi.com id ; Tue, 18 Jan 2000 22:27:14 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:2566 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Tue, 18 Jan 2000 22:26:58 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id PAA04662 for ; Wed, 19 Jan 2000 15:28:29 +0900 To: netdev@oss.sgi.com Subject: sin6_scope_id patch for 2.3.39 (Re: sin6_scope_id) From: Hideaki YOSHIFUJI References: <200001140114.RAA31198@ns1.filetron.com> X-Mailer: Mew version 1.94 on XEmacs 20.4 (Emerald) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000119152828T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 19 Jan 2000 15:28:28 +0900 X-Dispatcher: imput version 990905(IM130) Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 615 Lines: 20 Hi, all! Finally, sin6_scope_id patch for linux-2.3.39 is available!! You can get a copy from: David and we have tested this patch and it seems very ok. (Thanks, David!) Please test it and adopt it for the main (2.3.x) source tree! Thanks in advance. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Wed Jan 19 01:59:25 2000 Received: by oss.sgi.com id ; Wed, 19 Jan 2000 01:59:06 -0800 Received: from salisbury.futuretv.com ([194.216.164.17]:53777 "EHLO salisbury.labs.futuretv.com") by oss.sgi.com with ESMTP id ; Wed, 19 Jan 2000 01:58:54 -0800 Received: from zebra.labs.futuretv.com ([192.0.0.67]) by salisbury.labs.futuretv.com with esmtp (Exim 3.03 #1) id 12ArwK-0002qo-00 for netdev@oss.sgi.com; Wed, 19 Jan 2000 10:02:12 +0000 Received: from [192.0.0.21] (helo=fountain.labs.futuretv.com) by zebra.labs.futuretv.com with esmtp (Exim 3.03 #1) id 12Arus-0001Sq-00; Wed, 19 Jan 2000 10:00:42 +0000 Received: from [127.0.0.1] (helo=fountain) by fountain.labs.futuretv.com with esmtp (Exim 3.03 #1) id 12Arur-0001m1-00; Wed, 19 Jan 2000 10:00:41 +0000 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: Yuji Sekiya cc: lordbeatnik@linuxstart.com, netdev@oss.sgi.com Subject: Re: sin6_scope_id In-Reply-To: Message from Yuji Sekiya of "Mon, 17 Jan 2000 14:32:07 PST." References: <200001140114.RAA31198@ns1.filetron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2000 10:00:41 +0000 From: Philip Blundell Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 369 Lines: 11 >BTW, in addition to introducing sin6_scope_id into kernel, >I think we should intorduce it into glibc functions. It causes not >less changes into kernel and glibc. >Is there anyone who is a developper of glibc in this mailing list ? Yes. I agree; it would be fairly futile to introduce sin6_scope_id into the kernel without having matching changes in glibc. p. From owner-netdev@oss.sgi.com Wed Jan 19 11:26:23 2000 Received: by oss.sgi.com id ; Wed, 19 Jan 2000 11:26:12 -0800 Received: from picard.mcnc.org ([152.45.4.100]:55709 "EHLO anr.mcnc.org") by oss.sgi.com with ESMTP id ; Wed, 19 Jan 2000 11:26:05 -0800 Received: from anr.mcnc.org (lore.mcnc.org [152.45.4.102]) by anr.mcnc.org (8.9.1/8.9.1) with ESMTP id OAA28821 for ; Wed, 19 Jan 2000 14:27:46 -0500 (EST) Message-ID: <38861042.9B1DA953@anr.mcnc.org> Date: Wed, 19 Jan 2000 14:28:02 -0500 From: Ilia Baldine Organization: MCNC/ANR X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: sk_buff question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 305 Lines: 12 Hi, I'm mucking around in 2.2.12 (the IP stack part) and as part of some mods I've been doing I ended up adding a __u8 field at the end of the sk_buff. I was wondering if any of the gurus care to comment as to how permissible this is - any alignment, performance issues I should be aware of? TIA -ilia From owner-netdev@oss.sgi.com Wed Jan 19 14:45:23 2000 Received: by oss.sgi.com id ; Wed, 19 Jan 2000 14:45:03 -0800 Received: from toccata.fugue.com ([204.152.188.66]:37901 "EHLO toccata.fugue.com") by oss.sgi.com with ESMTP id ; Wed, 19 Jan 2000 14:44:48 -0800 Received: from grosse.manhattan.fugue.com (tundruk.manhattan.fugue.com [160.79.19.71]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id OAA06480; Wed, 19 Jan 2000 14:41:17 -0800 (PST) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3/8.6.11) with ESMTP id RAA15355; Wed, 19 Jan 2000 17:45:58 -0500 (EST) Message-Id: <200001192245.RAA15355@grosse.manhattan.fugue.com> To: greearb@agcs.com cc: netdev Subject: Re: Question on binding DHCP to an interface (by ifname, not IP/netmask). In-Reply-To: Message from Ben Greear of "Tue, 18 Jan 2000 18:15:55 MST." <3885104A.A73BD54C@agcs.com> Date: Wed, 19 Jan 2000 17:45:58 -0500 From: Ted Lemon Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 1225 Lines: 25 > If I can get this demo working, I'll get mgt to spring for a handbook :) Please don't think of buying the handbook as a reward to me for helping you with your problem - the royalties on the book you buy amount to maybe a buck. I suggest buying the book because I'd rather help you help yourself than have to guide you through the entire process - while I do enjoy helping people, I prefer help that provides leverage. > Note that I'm using VLAN interfaces, which, at least untill this > point, looked exactly like ethernet interfaces to every program I've > tried to run. If you are interested in the vlan patches, see my web > page at: http://scry.wanfear.com/~greear/vlan.html It's probably a "bug" in your VLAN interface. What happens if, on your VLAN interface, I try to send a packet with an IP destination of 255.255.255.255? What does it do if it receives a packet to 255.255.255.255? Remember that this is going through LPF. I would strongly resist any attempt to blame this on the DHCP server before you've verified the path of packets of the described type through the kernel, and through your VLAN, however it works. Also, do you actually have LPF support in your VLAN driver? _MelloN_ From owner-netdev@oss.sgi.com Wed Jan 19 14:45:23 2000 Received: by oss.sgi.com id ; Wed, 19 Jan 2000 14:45:13 -0800 Received: from tnt.isi.edu ([128.9.128.128]:36351 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Wed, 19 Jan 2000 14:44:49 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA24909; Wed, 19 Jan 2000 14:46:36 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id OAA03313; Wed, 19 Jan 2000 14:46:35 -0800 (PST) Date: Wed, 19 Jan 2000 14:46:35 -0800 Message-ID: From: Yuji Sekiya To: pb@labs.futuretv.com Cc: lordbeatnik@linuxstart.com, netdev@oss.sgi.com Subject: Re: sin6_scope_id In-Reply-To: In your message of "Wed, 19 Jan 2000 10:00:41 +0000" References: <200001140114.RAA31198@ns1.filetron.com> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 981 Lines: 27 At Wed, 19 Jan 2000 10:00:41 +0000, Philip Blundell wrote: Hello, > >BTW, in addition to introducing sin6_scope_id into kernel, > >I think we should intorduce it into glibc functions. It causes not > >less changes into kernel and glibc. > >Is there anyone who is a developper of glibc in this mailing list ? > > Yes. I agree; it would be fairly futile to introduce sin6_scope_id into the > kernel without having matching changes in glibc. Yoshifuji has made a patch for supporting sin6_scope_id. It works well with current glibc which has no sin6_scope_id. The patch can intorduce sin6_scope_id function into kernel without any problem of existing userland applications. But, in order to use sin6_scope_id function from userland application, we have to take a crack at glibc. I hope that the patch is applied to linux kernel... -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Sat Jan 22 14:01:29 2000 Received: by oss.sgi.com id ; Sat, 22 Jan 2000 14:01:10 -0800 Received: from [206.171.92.89] ([206.171.92.89]:8711 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Sat, 22 Jan 2000 14:00:44 -0800 Received: (qmail 25650 invoked from network); 22 Jan 2000 22:00:01 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 22 Jan 2000 22:00:01 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id OAA02613; Sat, 22 Jan 2000 14:02:22 -0800 Date: Sat, 22 Jan 2000 14:02:22 -0800 Message-Id: <200001222202.OAA02613@ns1.filetron.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: David Jeffery To: netdev@oss.sgi.com Subject: [rfc] nf6 patch Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 488 Lines: 6 At http://lordbeatnik.dynodns.net/netfilter is a patch against 2.3.40 that adds netfilter hooks to ipv6. I'm looking for any feedback on it and recommendations on who to send it to get it admitted into the kernel. Or is it too late now? Very little code is added or changed. Most of it is just moving code around into smaller functions. David "LordBeatnik" Jeffery ---------------------- Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com From owner-netdev@oss.sgi.com Sun Jan 23 06:49:38 2000 Received: by oss.sgi.com id ; Sun, 23 Jan 2000 06:49:29 -0800 Received: from tazenda.demon.co.uk ([158.152.220.239]:6916 "EHLO kings-cross.london.uk.eu.org") by oss.sgi.com with ESMTP id ; Sun, 23 Jan 2000 06:49:16 -0800 Received: from localhost ([::ffff:127.0.0.1] helo=kings-cross.london.uk.eu.org ident=phil) by kings-cross.london.uk.eu.org with esmtp (Exim 3.11 #1) id 12COH3-0000BU-00; Sun, 23 Jan 2000 14:45:53 +0000 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: David Jeffery cc: netdev@oss.sgi.com Subject: Re: [rfc] nf6 patch In-Reply-To: Message from David Jeffery of "Sat, 22 Jan 2000 14:02:22 PST." <200001222202.OAA02613@ns1.filetron.com> References: <200001222202.OAA02613@ns1.filetron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Jan 2000 14:45:53 +0000 From: Philip Blundell Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 718 Lines: 16 >At http://lordbeatnik.dynodns.net/netfilter is a patch against 2.3.40 that add >s netfilter hooks to ipv6. I'm looking for any feedback on it and recommendat >ions on who to send it to get it admitted into the kernel. Or is it too late >now? Very little code is added or changed. Most of it is just moving code ar >ound into smaller functions. It looks good to me. I'd like to see something like this included before 2.4; IPv6 isn't a great deal of use to me without firewalling. Are you working on the netfilter support code for IPv6? I started looking at this a month or so back but didn't get especially far. It's mostly an exercise in copying from the IPv4 version and changing some names. :-) p. From owner-netdev@oss.sgi.com Wed Jan 26 05:42:44 2000 Received: by oss.sgi.com id ; Wed, 26 Jan 2000 05:42:24 -0800 Received: from lorraine.loria.fr ([152.81.1.17]:12419 "EHLO lorraine.loria.fr") by oss.sgi.com with ESMTP id ; Wed, 26 Jan 2000 05:42:01 -0800 Received: from chaumousey.loria.fr (IDENT:root@chaumousey.loria.fr [152.81.7.178]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id OAA06603 for ; Wed, 26 Jan 2000 14:44:18 +0100 (MET) Received: from chaumousey.loria.fr (IDENT:sdalu@localhost.localdomain [127.0.0.1]) by chaumousey.loria.fr (8.9.3/8.9.3/8.9.3-client/JCG) with ESMTP id OAA01619 for ; Wed, 26 Jan 2000 14:44:47 +0100 Message-Id: <200001261344.OAA01619@chaumousey.loria.fr> To: netdev@oss.sgi.com Subject: IPv6 small bugs Date: Wed, 26 Jan 2000 14:44:46 +0100 From: "Stephane D'Alu" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 469 Lines: 20 - csum_ipv6_magic @ include/asm-*/checksum.h unsigned short int csum_ipv6_magic (struct in6_addr *saddr, struct in6_addr *daddr, __u16 len, unsigned short proto, unsigned int sum) the checksum is computed using the IPv6 pseudo header but the length should be a 32 bits, not 16. - ipv6_setsockopt @ net/ipv6/ipv6_sockglue.c sk->family = PF_INET; seems to be missing in the IPV6_ADDRFORM case, when used with UDP. -- Stephane From owner-netdev@oss.sgi.com Wed Jan 26 08:25:26 2000 Received: by oss.sgi.com id ; Wed, 26 Jan 2000 08:25:17 -0800 Received: from castillo.torrentnet.com ([4.18.161.34]:57861 "EHLO castillo.torrentnet.com") by oss.sgi.com with ESMTP id ; Wed, 26 Jan 2000 08:25:12 -0800 Received: from soco.torrentnet.com (soco.torrentnet.com [4.18.161.90]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id LAA04724 for ; Wed, 26 Jan 2000 11:27:40 -0500 (EST) Received: (from jleu@localhost) by soco.torrentnet.com (8.8.5/8.8.5) id LAA23016 for netdev@oss.sgi.com; Wed, 26 Jan 2000 11:27:40 -0500 (EST) Message-ID: <20000126112739.B8033@torrentnet.com> Date: Wed, 26 Jan 2000 11:27:39 -0500 From: "James R. Leu" To: netdev@oss.sgi.com Subject: New feature for kernle distribution Reply-To: jleu@torrentnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Organization: Ericsson Datacom Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 273 Lines: 9 I have been working on MPLS for the Linux kernel for the last year. I have what I think is a version that "plays well" with the rest of the networking stack. What is the first step I need to take towards getting it added to the main kernel distribution? -- James R. Leu From owner-netdev@oss.sgi.com Wed Jan 26 12:24:41 2000 Received: by oss.sgi.com id ; Wed, 26 Jan 2000 12:24:32 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:12305 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 26 Jan 2000 12:24:24 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA31000; Wed, 26 Jan 2000 23:26:31 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200001262026.XAA31000@ms2.inr.ac.ru> Subject: Re: IPv6 small bugs To: sdalu@loria.FR (Stephane D'Alu) Date: Wed, 26 Jan 2000 23:26:31 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <200001261344.OAA01619@chaumousey.loria.fr> from "Stephane D'Alu" at Jan 26, 0 05:13:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 553 Lines: 21 Hello! > unsigned short int csum_ipv6_magic (struct in6_addr *saddr, > struct in6_addr *daddr, > __u16 len, > unsigned short proto, > unsigned int sum) > > the checksum is computed using the IPv6 pseudo header but > the length should be a 32 bits, not 16. Opla! Indeed, I tested jumbograms only on loopback, where this function is skipped! Thank you. > - ipv6_setsockopt @ net/ipv6/ipv6_sockglue.c > sk->family = PF_INET; > seems to be missing in the IPV6_ADDRFORM case, when used with UDP. Thank you. Alexey From owner-netdev@oss.sgi.com Fri Jan 28 11:37:04 2000 Received: by oss.sgi.com id ; Fri, 28 Jan 2000 11:36:45 -0800 Received: from zuzana.cb.ipex.cz ([212.71.133.2]:43104 "EHLO zuzana.cb.ipex.cz") by oss.sgi.com with ESMTP id ; Fri, 28 Jan 2000 11:36:28 -0800 Received: from localhost (feela@localhost) by zuzana.cb.ipex.cz (8.8.7/8.8.7/IPEX-2.1) with ESMTP id UAA01357; Fri, 28 Jan 2000 20:38:58 +0100 Date: Fri, 28 Jan 2000 20:38:57 +0100 (MET) From: feela@ipex.cz X-Sender: feela@zuzana.cb.ipex.cz To: netdev@oss.sgi.com cc: kuznet@ms2.inr.ac.ru, Petr Kadlec Subject: Linux & gated problem Message-ID: X-NCC-RegID: cz.ipexnet X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 765 Lines: 27 Hello , I've a a Linux (2.2.13) router connected to 3 full-bgp peers. It has about 9 (of 16 now) 2Mbps connections (HDLC, running OSPF or BGP) and 100Mbps full duplex eth (Multiple OSPF neighbor). Gated is 3.5.10 with ANK patches. Router works quite fine, but sometimes happens this: Gated starts to consume some CPU time and all interfaces (wan and eth) drops some packets. (But nothing appears in /proc/net/dev) CPU is probably fast enough, if I run some other processes, net works fine. Have somebody any idea? Shall I use plain gated (maybe is a netlink related problem)? HW: Pentium II - 233, Memory 128Mbps, 16Mb flash.... Feela -- Ondrej Feela Filip E-mail: feela@ipex.cz WWW: http://feela.network.cz PGP: finger feela@atrey.karlin.mff.cuni.cz From owner-netdev@oss.sgi.com Mon Jan 31 10:11:16 2000 Received: by oss.sgi.com id ; Mon, 31 Jan 2000 10:11:07 -0800 Received: from devserv.devel.redhat.com ([207.175.42.156]:267 "EHLO devserv.devel.redhat.com") by oss.sgi.com with ESMTP id ; Mon, 31 Jan 2000 10:10:43 -0800 Received: from localhost (bcrl@localhost) by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id NAA30682; Mon, 31 Jan 2000 13:12:31 -0500 X-Authentication-Warning: devserv.devel.redhat.com: bcrl owned process doing -bs Date: Mon, 31 Jan 2000 13:12:31 -0500 (EST) From: Ben LaHaise X-Sender: bcrl@devserv.devel.redhat.com To: jamal cc: Andi Kleen , "David S. Miller" , sparclinux-cvs@vger.rutgers.edu, alan@redhat.com, kuznet@ms2.inr.ac.ru, Paul Mackerras , netdev@oss.sgi.com Subject: PPP(oE) (Re: CVS Update@vger.rutgers.edu: linux) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 2951 Lines: 60 Hey folks, Sorry if I've messed up the attribution of things, but I'm replying off of text copied from a web page since I'm not on the sparclinux-cvs list. I've added netdev to the cc list since that seems more appropriate coverage. jamal sayth: > On Mon, 31 Jan 2000, Andi Kleen wrote: > > Sorry for the confusion. There seems to be some inflation of PPPoE > > clients on linux at the moment (The Spellcaster guys apparently > > released another one with their PPP code, there are various user space > > versions floating around etc.) > The spellcaster one requires a replacement of the PPP stack in the > kernel as well. This is a good thing! =) I wrote that pppoe code as a quick hack one night after looking at the userspace implementations... It does the discovery in userspace, then does a 'dial' with the target MAC address and session id. That PPP stack is the way it is mostly because it wasn't being merged at the time it was being developed, so it couldn't patch anything else in the kernel and it had to run across 2.0/2.2/2.3. If I were to do any work on it now, I'd make it use a PPP socket instead of the charater device. The biggest benefit of the code is that it handles all PPP connections in a single daemon, so it requires a lot less from a system than using pppd. The multilink code is also well abused, and performs well against just about everything out there if the underlying device gives sufficient back pressure on transmit. Suffice it to say that I wouldn't expect to see the Babylon code merged as is, but there are useful bits and ideas in it. > > The problem with jamal's 2.3 code is that it doesn't use the ppp > > channel support in 2.3 yet, it still runs over a line discipline with > > the tty PPP like the 2.2 version. I think porting it to ppp channel > > would be straight forward and jamal planned this anyways very soon. > It is straight forward. I have been hesitant doing so because i am > trying to be a minimalist. I have asked Paul Mackerras (Cced in this > mail) if i could make some small changes to remove what i think is a > small limitation to the Channel stuff and make it more generic. This way > we dont have to modify it for PPP over UDP(L2TP), PPP over ATM > etc. Paul will hopefully give me the green light. My secondary goal is > to get speed. And so if it turns the current tty design is faster than > the channel mode, then i'd rather stick to the tty mode. I'll just say that the tty subsystem sucks. You haven't tried writing a driver for a DMA driven board with an ARM processor driving the DSPs that does all of the PPP framing for you, but can also be a tty (yet it still likes getting its data in chunks) -- flip buffers are a pain. The tty code gets in your way big time, and sucks alot of performance out of the system. -ben (who's also of the opinion that most of the i4l stack should be in user space, especially that evil modem emulator) From owner-netdev@oss.sgi.com Mon Jan 31 11:31:57 2000 Received: by oss.sgi.com id ; Mon, 31 Jan 2000 11:31:27 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:34277 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Mon, 31 Jan 2000 11:31:06 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id OAA06986; Mon, 31 Jan 2000 14:33:54 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id OAA18247; Mon, 31 Jan 2000 14:33:55 -0500 (EST) Date: Mon, 31 Jan 2000 14:33:55 -0500 (EST) From: jamal To: Ben LaHaise cc: Andi Kleen , "David S. Miller" , sparclinux-cvs@vger.rutgers.edu, alan@redhat.com, kuznet@ms2.inr.ac.ru, Paul Mackerras , netdev@oss.sgi.com Subject: Re: PPP(oE) (Re: CVS Update@vger.rutgers.edu: linux) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 5220 Lines: 116 Ben, I like the architectural approach you took. My comments below: On Mon, 31 Jan 2000, Ben LaHaise wrote: > Hey folks, > > Sorry if I've messed up the attribution of things, but I'm replying off of > text copied from a web page since I'm not on the sparclinux-cvs > list. I've added netdev to the cc list since that seems more appropriate > coverage. > > jamal sayth: > > > On Mon, 31 Jan 2000, Andi Kleen wrote: > > > > Sorry for the confusion. There seems to be some inflation of PPPoE > > > clients on linux at the moment (The Spellcaster guys apparently > > > released another one with their PPP code, there are various user space > > > versions floating around etc.) > > > The spellcaster one requires a replacement of the PPP stack in the > > kernel as well. > > This is a good thing! =) I wrote that pppoe code as a quick hack one > night after looking at the userspace implementations... It does the > discovery in userspace, then does a 'dial' with the target MAC address and > session id. > That PPP stack is the way it is mostly because it wasn't > being merged at the time it was being developed, so it couldn't patch > anything else in the kernel and it had to run across 2.0/2.2/2.3. Fair, you folks have customers to take care of. Linux on the other hand has no loyalty to backward compatibility. Thats one thing that makes it tick i guess ;-> > If I > were to do any work on it now, I'd make it use a PPP socket instead of the > charater device. The biggest benefit of the code is that it handles all > PPP connections in a single daemon, so it requires a lot less from a > system than using pppd. The multilink code is also well abused, and > performs well against just about everything out there if the underlying > device gives sufficient back pressure on transmit. > I would like to do a performance analysis for channel vs the tty option. Should the channel stuff prove to be faster (seems like it will), it is trivial to change my code in 2.3 to use channels. In 2.2 it will have to stay using ttys. Generally, I dont wanna use a feature just simply because it is there. Speed as well as flexibility are extremely important. Bundling everything under one daemon i think is a bad solution. >From a generecity aspect PPPOE is a protocol on its own as is L2TP etc; each has their own connection setup/teardown and discovery (which could be changing). They just happen to use PPP to transport things. You dont wanna keep changing pppd everytime one of these PPPoX things changes. PPP is an extremely popular framing scheme. I suspect there will be a lot more "PPP over X" protocols that havent been added yet. It is also a connection management nightmare to have pppd do everything. Let "your_favorite_pppoxd" tell pppd to just start or stop connections ('dial' or 'disconnect' to use your lingo). Use some other tricks to discover services (eg sockets in L2TP etc). I just saw another implementation of PPP over ATM which copies Michal's approach; I think we need to put a check on this NOW before it goes out of control. OTOH, if your pppoe babylon code was part of the kernel code i would never have written mine ;-> (you should have open sourced sooner than you did) The architectural split between user space and kernel is very clean. It is *exactly* the way i have it minus the tty approach. I love it other than the one glitch that you are adding another PPP stack. Perhaps, you folks can contribute to the current Linux PPP stack if you think it has weaknesses. My understanding is you guys have a very good MPPP. I am no expert in that area to comment however. > Suffice it to say that I wouldn't expect to see the Babylon code merged as > is, but there are useful bits and ideas in it. > true. > > > The problem with jamal's 2.3 code is that it doesn't use the ppp > > > channel support in 2.3 yet, it still runs over a line discipline with > > > the tty PPP like the 2.2 version. I think porting it to ppp channel > > > would be straight forward and jamal planned this anyways very soon. > > > It is straight forward. I have been hesitant doing so because i am > > trying to be a minimalist. I have asked Paul Mackerras (Cced in this > > mail) if i could make some small changes to remove what i think is a > > small limitation to the Channel stuff and make it more generic. This way > > we dont have to modify it for PPP over UDP(L2TP), PPP over ATM > > etc. Paul will hopefully give me the green light. My secondary goal is > > to get speed. And so if it turns the current tty design is faster than > > the channel mode, then i'd rather stick to the tty mode. > > I'll just say that the tty subsystem sucks. You haven't tried writing a > driver for a DMA driven board with an ARM processor driving the DSPs that > does all of the PPP framing for you, but can also be a tty (yet it still > likes getting its data in chunks) -- flip buffers are a pain. The tty > code gets in your way big time, and sucks alot of performance out of the > system. > The channel stuff in the current 2.3 is not tty based. so no flip buffers to worry about. Infact if you look at my current implementation, i also dont worry about flip buffers. cheers, jamal From owner-netdev@oss.sgi.com Mon Jan 31 16:15:59 2000 Received: by oss.sgi.com id ; Mon, 31 Jan 2000 16:15:50 -0800 Received: from devserv.devel.redhat.com ([207.175.42.156]:59402 "EHLO devserv.devel.redhat.com") by oss.sgi.com with ESMTP id ; Mon, 31 Jan 2000 16:15:28 -0800 Received: from localhost (bcrl@localhost) by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id TAA22276; Mon, 31 Jan 2000 19:17:02 -0500 X-Authentication-Warning: devserv.devel.redhat.com: bcrl owned process doing -bs Date: Mon, 31 Jan 2000 19:17:02 -0500 (EST) From: Ben LaHaise X-Sender: bcrl@devserv.devel.redhat.com To: jamal cc: Andi Kleen , "David S. Miller" , sparclinux-cvs@vger.rutgers.edu, alan@redhat.com, kuznet@ms2.inr.ac.ru, Paul Mackerras , netdev@oss.sgi.com Subject: Re: PPP(oE) (Re: CVS Update@vger.rutgers.edu: linux) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 3835 Lines: 76 Hello jamal, On Mon, 31 Jan 2000, jamal wrote: ... > I would like to do a performance analysis for channel vs the tty option. > Should the channel stuff prove to be faster (seems like it will), it is > trivial to change my code in 2.3 to use channels. In 2.2 it will have to > stay using ttys. Generally, I dont wanna use a feature just simply > because it is there. Speed as well as flexibility are extremely > important. I still haven't had a close look at your code yet, I'll try to do so tonight before I comment =) > Bundling everything under one daemon i think is a bad solution. > >From a generecity aspect PPPOE is a protocol on its own as is L2TP > etc; each has their own connection setup/teardown and discovery > (which could be changing). They just happen to use PPP to transport > things. You dont wanna keep changing pppd everytime one > of these PPPoX things changes. PPP is an extremely popular framing scheme. > I suspect there will be a lot more "PPP over X" protocols that havent been > added yet. It is also a connection management nightmare to have pppd do > everything. Let "your_favorite_pppoxd" tell pppd to just start or stop > connections ('dial' or 'disconnect' to use your lingo). Use some other > tricks to discover services (eg sockets in L2TP etc). > I just saw another implementation of PPP over ATM which copies Michal's > approach; I think we need to put a check on this NOW before it goes out > of control. Even though everything normally runs under one daemon, it does not have to. In fact, during development I'd test things by running two copies of the daemon on the same machine for testing PPP negotiations. Also, the program that does the PPPoE negotiations is separate from the PPP daemon, and I strongly agree that the daemon core should know little about actually making connections, and instead rely on helper programs (or libraries). But keeping PPP negotiations in one daemon is something I believe in, just like ISDN signalling or L2TP negotiations. Btw, last time I looked, L2TP is a horrendously broken protocol; don't ever expect multilink to work over it until flow control is added back in (sound of head banging against wall). > OTOH, if your pppoe babylon code was part of the kernel code i would never > have written mine ;-> (you should have open sourced sooner than you did) I didn't own the rights to that code, hence I couldn't make that decision. You should note that I've changed employers since that code was written. > The architectural split between user space and kernel is very > clean. It is *exactly* the way i have it minus the tty approach. I love it > other than the one glitch that you are adding another PPP stack. Perhaps, > you folks can contribute to the current Linux PPP stack if you think it > has weaknesses. It's my intention to merge it once I'm released from certain strings. > > I'll just say that the tty subsystem sucks. You haven't tried writing a > > driver for a DMA driven board with an ARM processor driving the DSPs that > > does all of the PPP framing for you, but can also be a tty (yet it still > > likes getting its data in chunks) -- flip buffers are a pain. The tty > > code gets in your way big time, and sucks alot of performance out of the > > system. > > > > The channel stuff in the current 2.3 is not tty based. so no flip buffers > to worry about. Infact if you look at my current implementation, i also > dont worry about flip buffers. These comments were more on the nature of the PPP & TTY subsystems in general (not about PPPoE), since they're heavily dependant on each other, I thought I'd mention it -- we need to modernize the tty driver interface. I'm hoping other people out there will come forward and mention their needs of such an interface, 'cause it has to be done sometime. -ben