From owner-freebsd-net@FreeBSD.ORG Thu Oct 19 04:02:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0E8016A416; Thu, 19 Oct 2006 04:02:19 +0000 (UTC) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.net (pc1.alaxala.net [203.178.142.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C3ED43D4C; Thu, 19 Oct 2006 04:02:18 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.net (Postfix) with ESMTP id 92BF9B936; Thu, 19 Oct 2006 13:02:17 +0900 (JST) X-Virus-Scanned: amavisd-new at alaxala.net Received: from pc1.alaxala.net ([127.0.0.1]) by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suexi-P66H7u; Thu, 19 Oct 2006 13:02:09 +0900 (JST) Received: from flora220.uki-uki.net (pc2.alaxala.net [203.178.142.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.net (Postfix) with ESMTP id BA279B82C; Thu, 19 Oct 2006 13:02:09 +0900 (JST) Date: Thu, 19 Oct 2006 13:02:08 +0900 Message-ID: From: SUZUKI Shinsuke To: chenxiaochen@emcite.com,gnn@freebsd.org X-cite: xcite 1.33 In-Reply-To: References: <200610181908570311458@emcite.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Networking Technology Development Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, liangbing@emcite.com Subject: Re: Problems under test of IPv6 Ready Logo Program Phase-2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 04:02:19 -0000 Hello, Here's my comment based on my IPv6Ready Logo(Ph.2) work in KAME Project. >>>>> On Wed, 18 Oct 2006 15:52:48 -0700 >>>>> gnn@freebsd.org said: > Though some of us are using TAHI I do not believe the project itself > is going for the Logo Program. TAHI Project is one of the major member of the Logo program. (TAHI provides a automatic testing tool for the Logo program) Please see the following pages for further detail. http://www.ipv6ready.org/about_logo_program.html > > 1. Section 5: RFC 2463 - ICMPv6 > > "case 11 Part B: Multicast Destination" --- fail > > After TN send Echo Request to global multicast > > address(ff1e::1:2), the following words appear on NUT's > > screen-----rl1:discard oversize frame (ether type 86dd flags 3 > > len 1514 > max 1294 ) > > However, "case 10 Part A: Unicast Destination" passes. Judging from the above message and the source code, it seems like you've configured rl1's MTU as 1280 and send a 1500-byte packet on rl1. You should send the packet on rl0 (where its MTU is 1500). > > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 > > "127 Part C: Sending Unsolicited RA (Min Values)" --- fail > > After NUT excutes rtadvd, TN says "Could't observe RA". #This is a test item to see the interval of the RA messages. So NUT #must run rtadvd (by hand or automatic operation by TAHI-tool) This message appears even when TN receives an RA (with an unexpected parameter). You should carefully check the log of the self-test tool to see what is an unexpected parameter. > > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration > > All cases fail > > Reason----TN can't observe DAD process. > > I can't capture DAD packages by Ethereal in the network start process. (snip) > I have not heard of this and don't have that hardware so can't check it. I've encountered the same phenomenon sometimes. It seems like there's a short amount of time where IFF_UP bit changes from off to on, but the hardware is not ready to send a packet. (appears like an ethernet auto-negotiation has not been completely finished) Since DAD process is kicked just after link-local address configuration (normally when IFF_UP bit changes from OFF to ON), it is inevitable in such drivers. My recommendation is either of the following two. (only to pass the IPv6-Ready Logo testing) - set net.inet6.ip6.auto_linklocal to 0 - manually configures a link-local address after the auto-negotiation has been completely finished or - disable auto-negotiation or (to make all the freebsd users happy:-)) - hack the device driver to make IFF_UP on after the hardware is ready to send a packet Thanks, ---- SUZUKI, Shinsuke @ KAME Project