Received: with ECARTIS (v1.0.0; list netdev); Thu, 21 Aug 2003 22:55:28 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h7M5tKoO021663 for ; Thu, 21 Aug 2003 22:55:21 -0700 Received: from monza.miyazawa.org ([2001:200:103:3:2d0:59ff:feab:4ac0]) (AUTH: LOGIN kazunori, ) by miyazawa.org with esmtp; Fri, 22 Aug 2003 14:46:17 +0900 Date: Fri, 22 Aug 2003 14:55:53 +0900 From: Kazunori Miyazawa To: "David S. Miller" , latten@austin.ibm.com Cc: netdev@oss.sgi.com Subject: Re: IPSecv6/Neighbor discovery crash Message-Id: <20030822145553.0ca08046.kazunori@miyazawa.org> In-Reply-To: <20030821184640.2cb89b87.davem@redhat.com> References: <200308220149.h7M1nlAU017798@faith.austin.ibm.com> <20030821184640.2cb89b87.davem@redhat.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 5196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 1404 Lines: 50 On Thu, 21 Aug 2003 18:46:40 -0700 "David S. Miller" wrote: > On Thu, 21 Aug 2003 20:49:47 -0500 > latten@austin.ibm.com wrote: > > > EIP is at ndisc_build_ll_hdr+0x17/0x1e0 > > So what exactly is NULL in ndisc_build_ll_hdr(), is > it 'dev'? That'd be really weird... > I had same crach. I guess it is due to xfrm cache. My impression about the problem is likes this. When we configure IPsec and src and dst of neighbour discoery match the configuration occasionally, The kernel creates and caches the stackable dst like this because ndisc_send_* want to use it dst->output(ah6_output) +- child->output(ndisc_output) Then it receives icmpv6 echo request. It replys by using the cached stackable dst like above. The kernel however must use another stackable dst like dst->output(ah6_output) +- child->output(ip6_output) It is the issue. The kernel can not tell first stackable dst from second stackable dst because it can not know the last output function. I believe we need to change the kernel to use ip6_output ( or another common output function) to send neighbour discovery packet instead of ndisc_output essentially. But it may make the kernel be unstable. I think there is not so much request to use IPsec with neighbour discovery. I think it is better to remove xfrm_lookup from ndisc_send_* functions at the moment. Best regards, --Kazunori Miyazawa