Date: Wed, 6 Apr 2011 17:00:21 GMT From: Gleb Smirnoff <glebius@freebsd.org> To: freebsd-ipfw@FreeBSD.org Subject: Re: kern/156180 Message-ID: <201104061700.p36H0LXu028836@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/156180; it has been noted by GNATS. From: Gleb Smirnoff <glebius@freebsd.org> To: Karim Fodil-Lemelin <fodillemlinkarim@gmail.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104061700.p36H0LXu028836>