From owner-freebsd-net@FreeBSD.ORG Mon Dec 7 18:37:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1ECB1065672; Mon, 7 Dec 2009 18:37:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 490C08FC12; Mon, 7 Dec 2009 18:37:29 +0000 (UTC) Received: by gxk10 with SMTP id 10so3438194gxk.3 for ; Mon, 07 Dec 2009 10:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Kg6/tlnkhEuvFq63u2nII51G1RsTakGSecaGs5dczvY=; b=e76Oey/6+3YTaAx9zNrg+0DBZX1BcztTTe5+c/WvOmNijd5egF6TLDoc7k7SAfvM7N yiy9vS2/ZYzDp9zw4KaRDAKFTD+XVyzy1SQl50yMw40zHx4n++cPphKqbzbcZI4PpP72 sbQKGS0thhCJ+huGpxtPSyqFiIRscWpWxTvpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZOxqqihyBK8CgPm57ukU5ZML24txocoB4pFhA/P8IN05r423URtqqySduURff2xkWE YkszjgfP7sMdBz5UYz0AV8Fc5ywj4MppjdNJFhqI7pLOiVjg5jevFD0EqpiWPqGGpm+5 3EHOFINTfpq/57+Hxj0Iql9vGIhcbM+nW85JM= Received: by 10.101.6.29 with SMTP id j29mr725553ani.166.1260211048485; Mon, 07 Dec 2009 10:37:28 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 9sm2094518ywf.50.2009.12.07.10.37.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 10:37:26 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 7 Dec 2009 10:37:13 -0800 From: Pyun YongHyeon Date: Mon, 7 Dec 2009 10:37:13 -0800 To: Mark Abene Message-ID: <20091207183712.GA1366@michelle.cdnetworks.com> References: <200912070140.nB71e4Kw039201@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <200912070140.nB71e4Kw039201@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, darren@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/106438: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 18:37:30 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 07, 2009 at 01:40:04AM +0000, Mark Abene wrote: > The following reply was made to PR kern/106438; it has been noted by GNATS. > > From: Mark Abene > To: bug-followup@FreeBSD.org, mala@hinterbergen.de > Cc: > Subject: Re: kern/106438: [ipf] ipfilter: keep state does not seem to allow > replies in on spar64 (and maybe others) > Date: Sun, 06 Dec 2009 20:26:25 -0500 > > It's been several years since this was first reported, and I can confirm > that it's still a problem in FreeBSD 8.0-RELEASE on i386 with an fxp > interface. I just wasted nearly two days trying to figure out why our > ipfilter rules which have been in use for years on our firewall suddenly > locked the machine out when we upgraded from a rather old version of > FreeBSD to 8.0-RELEASE. > > Same exact problem, same exact symptoms. Disabling checksumming on the > interface resolved the problem completely, otherwise ipfilter was rather > broken. I'm really glad I found this bug report, though not soon > enough. This is a rather serious problem. > I think the bug is in ipfilter's checksum computation. Unlike other operating systems, FreeBSD also supports cheap controllers that lacks pseudo checksum operation. These controllers just compute partial checksum without pseudo header and drivers(fxp(4), hme(4) and gem(4)) that take advantage of this feature insert a tag which indicates pseudo checksum is required in upper stack. The checksum computation code in ipfilter didn't account for IP header length so it always computed checksum wrong. I guess the following patch may fix the issue. The patch is not tested and wouldn't be complete as it assumes IPv4. However no other driver in tree set CSUM_DATA_VALID without CSUM_PSEUDO_HDR for IPv6 at this moment. Darren, would you review the patch? Because ipfilter lives in contrib I think it should go upstream first. > -Mark --C7zPtVaVf+AK4Oqc Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ipfilter.csum.patch" Index: sys/contrib/ipfilter/netinet/ip_fil_freebsd.c =================================================================== --- sys/contrib/ipfilter/netinet/ip_fil_freebsd.c (revision 200222) +++ sys/contrib/ipfilter/netinet/ip_fil_freebsd.c (working copy) @@ -1357,7 +1357,9 @@ else sum = in_pseudo(ip->ip_src.s_addr, ip->ip_dst.s_addr, htonl(m->m_pkthdr.csum_data + - fin->fin_ip->ip_len + fin->fin_p)); + fin->fin_ip->ip_len - + (fin->fin_ip->ip_hl << 2) + + fin->fin_p)); sum ^= 0xffff; if (sum != 0) { fin->fin_flx |= FI_BAD; --C7zPtVaVf+AK4Oqc--