From owner-freebsd-pf@FreeBSD.ORG  Sun Feb 26 14:50:11 2006
Return-Path: <owner-freebsd-pf@FreeBSD.ORG>
X-Original-To: freebsd-pf@hub.freebsd.org
Delivered-To: freebsd-pf@hub.freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5387F16A420
	for <freebsd-pf@hub.freebsd.org>; Sun, 26 Feb 2006 14:50:11 +0000 (GMT)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C89E143D48
	for <freebsd-pf@hub.freebsd.org>; Sun, 26 Feb 2006 14:50:10 +0000 (GMT)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1])
	by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1QEoADU075551
	for <freebsd-pf@freefall.freebsd.org>; Sun, 26 Feb 2006 14:50:10 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1QEoAEq075550;
	Sun, 26 Feb 2006 14:50:10 GMT (envelope-from gnats)
Date: Sun, 26 Feb 2006 14:50:10 GMT
Message-Id: <200602261450.k1QEoAEq075550@freefall.freebsd.org>
To: freebsd-pf@FreeBSD.org
From: Pieter de Boer <pieter@thedarkside.nl>
Cc: 
Subject: Re: sparc64/93530: Incorrect checksums when using pf's route-to on
	sparc64
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Pieter de Boer <pieter@thedarkside.nl>
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, 26 Feb 2006 14:50:11 -0000

The following reply was made to PR sparc64/93530; it has been noted by GNATS.

From: Pieter de Boer <pieter@thedarkside.nl>
To: bug-followup@freebsd.org,
 pieter@thedarkside.nl
Cc:  
Subject: Re: sparc64/93530: Incorrect checksums when using pf's route-to on sparc64
Date: Sun, 26 Feb 2006 15:48:18 +0100

 I've investigated some more and found an interesting heisenbug.
 
 =46rom pf.c, pf_route():
 
                 ip->ip_sum =3D 0;
                 if (sw_csum & CSUM_DELAY_IP) {
                         /* From KAME */
                         if (ip->ip_v =3D=3D IPVERSION &&
                             (ip->ip_hl << 2) =3D=3D sizeof(*ip)) {
                                 ip->ip_sum =3D in_cksum_hdr(ip);
                         } else {
                                 ip->ip_sum =3D in_cksum(m0, ip->ip_hl << 2);
                         }
                 }
 
 In the tests I've run, the in_cksum_hdr()-function is called, not the=20
 in_cksum() function. Ok,  I inserted some printf's to find the problem. My=
 =20
 new code looks like this:
 
                 ip->ip_sum =3D 0;
                 if (sw_csum & CSUM_DELAY_IP) {
 //                      printf("pf_route(): B1\n");
                         /* From KAME */
                         if (ip->ip_v =3D=3D IPVERSION &&
                             (ip->ip_hl << 2) =3D=3D sizeof(*ip)) {      =20
 //                              printf("pf_route: B2\n");     =20
                                 ip->ip_sum =3D in_cksum_hdr(ip);    =20
                         } else {
                         //      printf("pf_route: B3\n");
                                 ip->ip_sum =3D in_cksum(m0, ip->ip_hl << 2);
                         }
                 }
 With the printf B1 and B2 commented out, the checksums are wrong. With eith=
 er=20
 printf B1 or B2 not commented out, then the checksums are correct. My theor=
 y=20
 is that there's some caching issue between the ip->ip_sum =3D 0; at the top=
  and=20
 the assembly-code of in_cksum_hdr(). When a printf is inserted between the=
 =20
 ip->ip_sum =3D 0; and the in_cksum_hdr(), the cache is invalidated long bef=
 ore=20
 in_cksum_hdr() is called.=20
 
 Perhaps a Sparc64-hacker could take a look at the assembly output of=20
 pf_route() and determine whether this could be the case? :)