From owner-freebsd-net@FreeBSD.ORG Thu Apr 3 12:55:40 2003 Return-Path: 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 E8A7037B401; Thu, 3 Apr 2003 12:55:40 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6EF43FBF; Thu, 3 Apr 2003 12:55:39 -0800 (PST) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h33KtcRp018050; Thu, 3 Apr 2003 22:55:38 +0200 Received: (nullmailer pid 3161 invoked by uid 1000); Thu, 03 Apr 2003 20:55:25 -0000 Date: Thu, 3 Apr 2003 22:55:25 +0200 From: Mark Santcroos To: Craig Boston Message-ID: <20030403205524.GA2346@laptop.6bone.nl> References: <1049304662.10796.27.camel@owen1492.uf.corelab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1049304662.10796.27.camel@owen1492.uf.corelab.com> User-Agent: Mutt/1.4.1i X-Handles: MS6-6BONE, MS18417-RIPE cc: net@freebsd.org Subject: Re: IPv6 MTU bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Apr 2003 20:55:41 -0000 [ moved to net@; current@ bcc'ed ] Hi Craig, I think I saw the same behaviour while developing a path-mtu discovery tool. As I'm quite busy right now I didn't really dig into it, but I will at some point. I took the liberty to reply to freebsd-net@, because this is not only a -CURRENT problem. Mark On Wed, Apr 02, 2003 at 11:31:02AM -0600, Craig Boston wrote: > I was trying some network diagnostics yesterday and needed to generate a > continuous stream of small packets going across a few routers. So I > used ifconfig to set my MTU to some very low values (100, 300, 500, and > a few others). I know there's probably a better way to accomplish that, > but couldn't think of any at the time so that's what I did :) > > Anyway, when I was done, I reset the MTU on my ethernet interface back > to 1500. IPv4 is working fine, but IPv6 is still acting like I have a > low MTU set. All IPv6 TCP connections are limiting the MSS to around 28 > bytes of data per packet, and ping6 complains with ping sizes more than > around 50. > > I think I've tracked down the problem to this code in nd6.c, > specifically in nd6_setmtu(ifp). > > Note that at this point ndi->maxmtu has just been set to > MIN([user-requested MTU], [biggest MTU possible for this interface > type]). ndi->linkmtu hasn't been touched yet and is still set to > whatever the previous linkmtu was. > > if (ndi->linkmtu == 0 || > ndi->maxmtu < ndi->linkmtu) { > ndi->linkmtu = ndi->maxmtu; > /* also adjust in6_maxmtu if necessary. */ > if (oldlinkmtu == 0) { > /* > * XXX: the case analysis is grotty, but > * it is not efficient to call in6_setmaxmtu() > * here when we are during the initialization > * procedure. > */ > if (in6_maxmtu < ndi->linkmtu) > in6_maxmtu = ndi->linkmtu; > } else > in6_setmaxmtu(); > } > > It looks to me that in the case of raising an interface's MTU, > ndi->maxmtu will be >= ndi->linkmtu, causing linkmtu to never get > reset. I may be missing something, but I can't quite figure out the > logical reason for that test. > > Luckily I had a kernel.debug lying around so I used gdb to peek into the > kernel memory. In the nd_ifinfo for that interface, linkmtu=100 and > maxmtu=1500. Once I manually reset linkmtu to 1500, IPv6 started > working properly again, without having to sacrifice my uptime :) > > Anyway, the behavior looks like a bug, but the code makes it look like > this may be an intentional effect. Any kernel networking gurus care to > comment? > > Thanks, > Craig > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM