<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body><span class="vcard"><a class="email" href="mailto:fmyhr@fhmtech.com" title="Frank Myhr <fmyhr@fhmtech.com>"> <span class="fn">Frank Myhr</span></a>
</span> changed
              <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Rules in first chain same hook ignored if second chain has policy drop"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1305">bug 1305</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>fmyhr@fhmtech.com
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Rules in first chain same hook ignored if second chain has policy drop"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1305#c12">Comment # 12</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Rules in first chain same hook ignored if second chain has policy drop"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1305">bug 1305</a>
              from <span class="vcard"><a class="email" href="mailto:fmyhr@fhmtech.com" title="Frank Myhr <fmyhr@fhmtech.com>"> <span class="fn">Frank Myhr</span></a>
</span></b>
        <pre>@Alexander S.: I think the packet flow diagram posted by Egbert S. is correct,
i.e. output hook comes *after* routing decision. As is also shown here:
<a href="https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg">https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg</a>

As to Marco's proposal of quick-accept and delayed-drop statements: neat idea.
As pointed out, they would make hook priority more powerful than it currently
is. But as Brian points out, when using nftables only (no legacy iptables
stuff), then the same effect can be achieved with a single base chain (hook)
using multiple jump (or goto) statements. For this case, I wonder how the
computational efficiency of multiple jumps vs. multiple hooks compares? Maybe
the single base chain with multiple jumps is more efficient, if less elegant,
than multiple base chains?

In cases where legacy iptables stuff is in simultaneous use, I agree that the
proposed quick-accept / delayed-drop additions would make the combined policy
far less confusing than it currently is.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>