From owner-freebsd-stable@FreeBSD.ORG Sun Jan 21 02:11:18 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A5F716A400 for ; Sun, 21 Jan 2007 02:11:18 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from mx1.irtnog.org (24-123-13-51.irtnog.org [24.123.13.51]) by mx1.freebsd.org (Postfix) with ESMTP id F0AC713C459 for ; Sun, 21 Jan 2007 02:11:17 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from localhost (unknown [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 18FAB114E5 for ; Sat, 20 Jan 2007 20:46:02 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by localhost (cinep010bsdmx.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lR57+enshksc for ; Sat, 20 Jan 2007 20:45:56 -0500 (EST) Received: from irtnog.org (svr1.irtnog.org [10.63.0.100]) by mx1.irtnog.org (Postfix) with ESMTP id 6ED06114E3 for ; Sat, 20 Jan 2007 20:45:56 -0500 (EST) Date: Sat, 20 Jan 2007 20:45:44 -0500 Message-ID: MIME-Version: 1.0 In-Reply-To: <45B09856.8080600@IPricot.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: tcpdump, rl, sis, fxp and multicast problems X-MimeOLE: Produced By Microsoft Exchange V6.5 thread-index: Acc7saUuFDx1W8J6ROahG7ZTX5lNWwBS6Ckg References: <45AF8586.8080908@IPricot.com><20070118235125.GA80971@xor.obsecurity.org> <45B09856.8080600@IPricot.com> From: "Matthew X. Economou" To: Subject: RE: tcpdump, rl, sis, fxp and multicast problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2007 02:11:18 -0000 > not very important but wouldn't it be better to set the checksum > to 0 instead of some arbitrary (?) and confusing value then ? No, as not setting the checksum is a (minor) optimization. Setting that field to any arbitrary constant means at least one completely unnecessary CPU instruction per datagram. Best wishes, Matthew=20 --=20 "Rogues are very keen in their profession, and know already much more than we can teach them respecting their several kinds of roguery." - A. C. Hobbs in _Locks and Safes_ (1853)