From owner-freebsd-net Mon Feb 25 21:38:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 420F437B400; Mon, 25 Feb 2002 21:38:36 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:e028:ba95:b8bc:b5a5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1Q5cTo11094; Tue, 26 Feb 2002 14:38:29 +0900 (JST) Date: Tue, 26 Feb 2002 14:38:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edwin Groothuis Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 In-Reply-To: References: <0D9185CE635BD511ACA50090277A6FCF1359DB@axcs18.cos.agilent.com> <20020216130842.A19081@energyhq.homeip.net> <20020217122510.D491@k7.mavetju.org> <20020222234829.F492@k7.mavetju.org> <20020223084616.G492@k7.mavetju.org> <20020225221827.F491@k7.mavetju.org> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 52 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Finally I figured out the problem. The essential reason for this weirdness was that the kernel did not set the in_conninfo.inc_isipv6 member of a PCB entry correctly. As a result of this, once a cached route stored in the PCB has become invalid, the kernel would try to get a new route with an AF_INET destination. Neighbor solicitation messages on the gif link, which might invalidate the cached route, are also bogus, but they are not directly related to this particular problem. So, we should deal with this trouble as follows: 1. set the inc_isipv6 member correctly. The patch attached to this message should work for this (I checked the patch on a 4.5 RELEASE box). 2. prohibit the kernel from sending the bogus neighbor solicitations. This can be done by a patch I proposed last week in a different thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=345287+0+archive/2002/freebsd-net/20020224.freebsd-net BTW: I believe we should not rely on the inc_isipv6 member, which tends to introduce this type of bug. We should probably detect the correct family by the addresses themselves. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp *** tcp_usrreq.c.orig Tue Feb 26 14:00:22 2002 --- tcp_usrreq.c Tue Feb 26 14:05:43 2002 *************** *** 375,380 **** --- 375,381 ---- } inp->inp_vflag &= ~INP_IPV4; inp->inp_vflag |= INP_IPV6; + inp->inp_inc.inc_isipv6 = 1; if ((error = tcp6_connect(tp, nam, p)) != 0) goto out; error = tcp_output(tp); *** tcp_syncache.c.orig Tue Feb 26 10:52:39 2002 --- tcp_syncache.c Tue Feb 26 10:52:49 2002 *************** *** 552,557 **** --- 552,558 ---- /* * Insert new socket into hash list. */ + inp->inp_inc.inc_isipv6 = sc->sc_inc.inc_isipv6; #ifdef INET6 if (sc->sc_inc.inc_isipv6) { inp->in6p_laddr = sc->sc_inc.inc6_laddr; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message