The following reply was made to PR kern/156180; it has been noted by GNATS.
From: Gleb Smirnoff <gleb...@freebsd.org> To: Karim Fodil-Lemelin <fodillemlinka...@gmail.com> Cc: bug-follo...@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. _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
