From owner-freebsd-net@FreeBSD.ORG Tue Apr 12 04:57:55 2005 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 99C2116A4CE; Tue, 12 Apr 2005 04:57:55 +0000 (GMT) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id D649A43D31; Tue, 12 Apr 2005 04:57:54 +0000 (GMT) (envelope-from keiichi@iijlab.net) Received: OTM-MO id j3C4vdIx006280; Tue, 12 Apr 2005 13:57:40 +0900 (JST) Received: OTM-MIX0 id j3C4vd3U006603; Tue, 12 Apr 2005 13:57:39 +0900 (JST) Received: JC-SMTP from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) id j3C4vcSv001850; Tue, 12 Apr 2005 13:57:39 +0900 (JST) Date: Tue, 12 Apr 2005 13:57:23 +0900 (JST) Message-Id: <20050412.135723.92413233.keiichi@iijlab.net> To: snap-users@kame.net, gnn@freebsd.org From: Keiichi SHIMA In-Reply-To: References: X-Mailer: Mew version 4.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: rwatson@freebsd.org cc: sam@errno.com Subject: Re: (KAME-snap 9008) Please review this diff... 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: Tue, 12 Apr 2005 04:57:55 -0000 Hi, From: gnn@freebsd.org Date: Sat, 09 Apr 2005 22:30:45 +0900 > I would like to check in the following diff against FreeBSD-CURRENT > and to get feedback from the Kame folks on the general usefulness of > these fixes. All changes are against icmp6.c. > > The first part of the diff removes dead code as I suspect MCLBYTES, > the size of a cluster, will never be less than 48, which is the size > of maxlen set above those lines. I checked the log when the code was added, but found no useful information. Maybe it is intended to handle a special architecture which MCLBYTES is very small. I don't know such an architecture, though... > The second part checks for error returns from the duplication of the > packets before starting to copy things around. These error checks seems correct. We will update our code too. Thank you for your pointing them out. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME project