From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 6 17:00:32 2011 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DC7D1065707 for ; Wed, 6 Apr 2011 17:00:32 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 468378FC1D for ; Wed, 6 Apr 2011 17:00:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p36H0Lk9028837 for ; Wed, 6 Apr 2011 17:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p36H0LXu028836; Wed, 6 Apr 2011 17:00:21 GMT (envelope-from gnats) Date: Wed, 6 Apr 2011 17:00:21 GMT Message-Id: <201104061700.p36H0LXu028836@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/156180 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:00:32 -0000 The following reply was made to PR kern/156180; it has been noted by GNATS. From: Gleb Smirnoff To: Karim Fodil-Lemelin Cc: bug-followup@freebsd.org Subject: Re: kern/156180 Date: Wed, 6 Apr 2011 20:59:22 +0400 Hi, Karim! On Wed, Apr 06, 2011 at 10:36:46AM -0400, Karim Fodil-Lemelin wrote: K> Thanks for the patch it does work in FBSD although it does not work in my K> setup since I have extended TCP option checking into another ipfw action and K> while I could add the check you've proposed for tcpop_match I would prefer a K> more generic approach where the m_pullup call is done for all TCP packets K> with options (basically in the case IPPROTO_TCP). K> K> The rationale behind this is such that there is a guarantee that tcpop_match K> will work but also that any future extensions based on TCP options would K> also work saving the hard to debug situation that a missing call to m_pullup K> can create. Currently almost all TCP traffic has TCP options. And currently most, I suppose > 90%, installations, that use ipfw(4) do not have rules with 'tcpoptions' keyword. So, we would add extra pullup, that is not needed in most cases and may have a performance impact. In case of future extensions the hard to debug situation won't happen if a developer analyses the function he modifies thoroughly. So, can you please confirm, that if you adding this string PULLUP_LEN(hlen, ulp, (TCP(ulp)->th_off << 2)); into your new ipfw action, solves the discussed problem? -- Totus tuus, Glebius.