kern/156180

[Gleb Smirnoff]

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

From: Gleb Smirnoff <glebius at freebsd.org>
To: Karim Fodil-Lemelin <fodillemlinkarim at gmail.com>
Cc: bug-followup at 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.