From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 15:35:18 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B31B16A401 for ; Sun, 2 Apr 2006 15:35:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7557643D46 for ; Sun, 2 Apr 2006 15:35:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.168] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1FQ4bX3eCL-0002M3; Sun, 02 Apr 2006 17:35:16 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Sun, 2 Apr 2006 17:34:00 +0200 User-Agent: KMail/1.9.1 References: <20060402054532.GF17711@egr.msu.edu> In-Reply-To: <20060402054532.GF17711@egr.msu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5297090.4mF7Div0Ti"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604021734.09622.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 15:35:18 -0000 --nextPart5297090.4mF7Div0Ti Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 02 April 2006 07:45, Adam McDougall wrote: > I have been using 'ls' on a directory to test my ruleset and effects > of scrubbing rules. My latest discovery is if I use 'scrub .... fragment > reassemble', the packet on the outgoing interface will have a wildly > incorrect IP checksum (ethereal says 0x7b49 should be 0x688d for example). Is this ethereal on the sending or on the receiving side? Note that with=20 hardware checksums (as em(4) usually does) you will see corrupted checksums= =20 in ethereal as it is computed by the hardware later on. Please verify that= =20 you are seeing corruption on the receiving side or turn off the hardware=20 checksum calculation (ifconfig em0 -txcsum) > I am using pf over a bridge with two 'em' interfaces, and encountered > other code paths in the recent past in pf_norm.c that did not recalculate > the checksum for changes it made, but in essence I think this time pf is > generating this packet as a reassembly of 5 fragments (total size 6296) > and doesn't seem to be applying a correct ip header checksum. The > header checksum is not even similar to the checksum of the last fragment > when entering the firewall (0xbfa4). Right now, I increased the outgoing > em1 interface to mtu 8000 just so the outgoing nic will not get wedged in > OACTIVE with 100% reproducability (more on that later). Can you give us a more detailed overview of your scenario and testcase? I = am=20 not quite sure what you are trying to do and how it fails. Also, which typ= e=20 of bridge are you using? > Can someone take a look and help me out, or let me know how I can help? > Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5297090.4mF7Div0Ti Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEL+7xXyyEoT62BG0RAl6dAJsGFjmWUfjuxEm9KNf5A4E2u477qgCfZ2n+ noKd+4eapYKFV0n+8XGKrSw= =P1f1 -----END PGP SIGNATURE----- --nextPart5297090.4mF7Div0Ti--