From owner-freebsd-pf@FreeBSD.ORG Wed Apr 5 12:42:13 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 5F54A16A401; Wed, 5 Apr 2006 12:42:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D6543D4C; Wed, 5 Apr 2006 12:42:10 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.94] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1FR7Kq1TwF-0001nA; Wed, 05 Apr 2006 14:42:08 +0200 From: Max Laier Organization: FreeBSD To: Daniel Hartmeier Date: Wed, 5 Apr 2006 14:41:09 +0200 User-Agent: KMail/1.9.1 References: <20060402054532.GF17711@egr.msu.edu> <20060404145704.GW2684@insomnia.benzedrine.cx> <20060404153443.GX2684@insomnia.benzedrine.cx> In-Reply-To: <20060404153443.GX2684@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1276437.b4U7kJYxsO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604051441.16865.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Andrew Thompson , freebsd-pf@freebsd.org 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: Wed, 05 Apr 2006 12:42:13 -0000 --nextPart1276437.b4U7kJYxsO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 04 April 2006 17:34, Daniel Hartmeier wrote: > Ok, I found the reason for all these IP checksum problems. The reason is > that OpenBSD's bridge code always recalculates the IP checksum, while > FreeBSD's doesn't. > ... > What I missed before is in bridge_filter(), right after the pf_test() > call: > > if (pf_test(dir, ifp, &m, eh) !=3D PF_PASS) > goto dropit; > if (m =3D=3D NULL) > goto dropit; > > /* Rebuild the IP header */ > if (m->m_len < hlen && ((m =3D m_pullup(m, hlen)) =3D=3D = NULL)) > return (NULL); > if (m->m_len < sizeof(struct ip)) > goto dropit; > ip =3D mtod(m, struct ip *); > ip->ip_sum =3D 0; > ip->ip_sum =3D in_cksum(m, hlen); > > FreeBSD has no such part that I can find. Hence, when pf_test() returns > a packet with an invalid IP checksum, nothing fixes the checksum, maybe > except for hardware-checksumming NICs. > > Andrew, what do you suggest we do about this? Are the FreeBSD semantics > very clear and state that the IP checksum is pfil hook's responsibility, > and other pfil hooks (besides pf) are doing exactly that? I haven't used > the FreeBSD bridge code with other packet filters beside pf, so I simply > don't know. > > If pf should return only IP packets to bridge which have correct IP > checksums already, we can either force an unconditional recomputation in > pf's pfil hook function (which wraps pf_test()), or we can go further > down the road of doing incremental checksum fixups whenever pf changes > the IP header internally. Once that would be complete, OpenBSD's bridge > could remove the unconditional checksum recomputation, too. > > But I'm not sure what's cheaper, on average, fixing up the checksum > on each header change (there might be multiple changes per packet > processed), or simply doing it once, unconditionally, at the end. > > Right now, we're in the suboptimal middle. pf does some incremental > fixups, but leaves the checksum incorrect in other cases. AFAIR, we somewhat keep track of the checksum status with csum_flags in the= =20 pkthdr. We have still some 8 bit left to use if we need them, but I think = we=20 can express everything that might happen already. If we did that pf (or an= y=20 other pfil consumer) could decide if it is worth to recalculate the cksum o= r=20 if it is something to leave to the bridge/ip_output. If it decides to fix= =20 the checksum no other action is required, if it decides not to fix the=20 checksum it sets a flag indicating that the checksum needs to be=20 recalculated. The bridge code would then check with the outgoing interface= 's=20 hardware capabilities and either leave the job to the hardware or do it in= =20 software itself. The other big problem that just crossed my mind: Reassembly in the bridge= =20 path!? It doesn't look like the current bridge code on either OS is ready = to=20 deal with packets > MTU coming out of the filter. The question here is=20 probably how much IP processing we want to do in the bridge code? =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 --nextPart1276437.b4U7kJYxsO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEM7rsXyyEoT62BG0RArlgAJ9qv+o4u2KA/qoA58x024JvA3TtPgCfbAPH vk14TtASyR+52PKp5Jpr5WM= =JEXv -----END PGP SIGNATURE----- --nextPart1276437.b4U7kJYxsO--