From owner-freebsd-pf@FreeBSD.ORG  Sun Apr  2 05:45:34 2006
Return-Path: <owner-freebsd-pf@FreeBSD.ORG>
X-Original-To: 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 11EF816A401
	for <pf@freebsd.org>; Sun,  2 Apr 2006 05:45:34 +0000 (UTC)
	(envelope-from mcdouga9@daemon.egr.msu.edu)
Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CE99843D46
	for <pf@freebsd.org>; Sun,  2 Apr 2006 05:45:33 +0000 (GMT)
	(envelope-from mcdouga9@daemon.egr.msu.edu)
Received: by daemon.egr.msu.edu (Postfix, from userid 21281)
	id E51451CC34; Sun,  2 Apr 2006 00:45:32 -0500 (EST)
Date: Sun, 2 Apr 2006 00:45:32 -0500
From: Adam McDougall <mcdouga9@egr.msu.edu>
To: pf@freebsd.org
Message-ID: <20060402054532.GF17711@egr.msu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.11
Cc: 
Subject: 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\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
	<mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf>
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
	<mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Apr 2006 05:45:34 -0000

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).

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 someone take a look and help me out, or let me know how I can help?
Thanks.