<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:jeremy@azazel.net" title="Jeremy Sowden <jeremy@azazel.net>"> <span class="fn">Jeremy Sowden</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - iptables -m string not working with --algo bm and OUTPUT chain under 5.3.x"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1390">bug 1390</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
                
           </td>
           <td>jeremy@azazel.net
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - iptables -m string not working with --algo bm and OUTPUT chain under 5.3.x"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1390#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - iptables -m string not working with --algo bm and OUTPUT chain under 5.3.x"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1390">bug 1390</a>
              from <span class="vcard"><a class="email" href="mailto:jeremy@azazel.net" title="Jeremy Sowden <jeremy@azazel.net>"> <span class="fn">Jeremy Sowden</span></a>
</span></b>
        <pre>There are two possible reasons why BM might not match.  Both affect packets
which are stored by the kernel in multiple discontiguous blocks.  One of them
is a known limitation and is described in the kernel source:

 *   Note: Since Boyer-Moore (BM) performs searches for matchings from right 
 *   to left, it's still possible that a matching could be spread over 
 *   multiple blocks, in that case this algorithm won't find any coincidence.
 *   
 *   If you're willing to ensure that such thing won't ever happen, use the
 *   Knuth-Pratt-Morris (KMP) implementation instead. In conclusion, choose 
 *   the proper string search algorithm depending on your setting. 
 *
 *   Say you're using the textsearch infrastructure for filtering, NIDS or 
 *   any similar security focused purpose, then go KMP. Otherwise, if you 
 *   really care about performance, say you're classifying packets to apply
 *   Quality of Service (QoS) policies, and you don't mind about possible
 *   matchings spread over multiple fragments, then go BM.

The second is a kernel bug: the offset at which the implementation start
searching in each block is not reset when a new block is read, so for the
subsequent blocks matches at the beginning of the block are likely to be
missed.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>