<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 10/19/2011 04:55 PM, David Stevens wrote:
    <blockquote
cite="mid:OFB4EE789C.6FB521B9-ON8725792E.0072EF27-8725792E.0072EF33@us.ibm.com"
      type="cite"><font face="Default Sans
        Serif,Verdana,Arial,Helvetica,sans-serif" size="2">
        <div><br>
        </div>
        <font color="#990099">-----Stefan Berger <a
            moz-do-not-send="true" class="moz-txt-link-rfc2396E"
            href="mailto:stefanb@linux.vnet.ibm.com"><stefanb@linux.vnet.ibm.com></a>
          wrote: -----<br>
        </font>    <br>
        >      <br>
>    The problem is that at the moment rules (in the 'root' table) can<br>
>    have priorities [0, 1000]. So nothing prevents one to write a<br>
        >rule<br>
>    with priority 0. However, due to how nwfilters works right now<br>
        >the<br>
>    jumps into the protocol-specific tables will always be created<br>
>    *before* those rules. I am trying to address this now with<br>
        >assigning<br>
>    negative numbers to the chains to achieve the same sorting and<br>
        >    maintain backwards compatibility.<br>
        <br>
              Priorities aren't directly line numbers, but I think
        extending negative<br>
        numbers to be "from the end" as ebtables/iptables would be a
        useful<br>
        thing (and less arcane due to the precedent already there).<br>
              But since you are extending to allow more chains, couldn't
        you<br>
        in fact just expose the root chain to XML and create a default
        that<br>
      </font></blockquote>
    It's already exposed.. you can add the following rule to the
    'clean-traffic' filter<br>
    <br>
    <rule action='drop' direction='inout' priority='999'><br>
        <arp/><br>
      </rule><br>
    <br>
    and it will appear in the interface root chain.<br>
    <br>
    <blockquote
cite="mid:OFB4EE789C.6FB521B9-ON8725792E.0072EF27-8725792E.0072EF33@us.ibm.com"
      type="cite"><font face="Default Sans
        Serif,Verdana,Arial,Helvetica,sans-serif" size="2">does the
        protocol switch that's generated in code now? Then, you<br>
      </font></blockquote>
    The protocol 'switch', assuming we both talk about 'the same',
    becomes a lot more flexible and dynamic with this patch series. It
    lets you insert jumps to new chains (whose names have known protocol
    names as prefixes) and interleave them with rules in the 'root'
    table.<br>
    <blockquote
cite="mid:OFB4EE789C.6FB521B9-ON8725792E.0072EF27-8725792E.0072EF33@us.ibm.com"
      type="cite"><font face="Default Sans
        Serif,Verdana,Arial,Helvetica,sans-serif" size="2">could insert
        new chains before the standard ones, reorder, or do<br>
        anything you want -- with "RETURN" as the policy or action for
        acceptable<br>
        frames in the early chains so later chains are still run.<br>
      </font></blockquote>
    I do have the intention to accept your 'RETURN' and 'CONTINUE'
    patch. So that's not going to be the problem. I just have some
    concerns about how the multiple IP address support is implemented. I
    don't think it works with multiples of anything else than what is in
    the IP variable, i.e., comma-separated 'items' in other variables.<br>
    <blockquote
cite="mid:OFB4EE789C.6FB521B9-ON8725792E.0072EF27-8725792E.0072EF33@us.ibm.com"
      type="cite"><font face="Default Sans
        Serif,Verdana,Arial,Helvetica,sans-serif" size="2">     If you
        didn't want to expose libvirt-{I,O}-vnetXX chains, couldn't you<br>
        at least accomplish the same thing with new chains in the
        code-generated<br>
        chains by adding a "pre-protocol" chain assuming "RETURN" is
        available.<br>
        Then, a filter that adds to "pre-protocol" (or whatever you call
        it) would always<br>
        happen before the standard chains. A similar chain hook could be
        done for<br>
        post-protocol chains, if those were converted to do "RETURN"
        instead of<br>
        ACCEPT/DROP too.<br>
           <br>
>                    Using priorities in multiple places is very<br>
        >          like programming in basic<br>
        ><br>
>          and what both ebtables/iptables and nwfilters could use<br>
        >better<br>
        >          I think would<br>
        ><br>
        >          be the capability to label rules by name and reference
        d<br>
        >          label to identify the<br>
        ><br>
>          rule location. Then you might, e.g., add a rule at "myrules<br>
        >+<br>
        >          5" and don't care<br>
        ><br>
        >          what particular priority/line number "myrules" is.<br>
        ><br>
        >        <br>
        >      <br>
        >    You have patches for that?<br>
        <br>
                Actually, you do. If the labels are new chains then<br>
        the existing priority within that chain is essentially the same.
        But the<br>
        existing priority mechanism doesn't have the full flexibility
        available in<br>
        ebtables/iptables with "insert before", "append", "offset from
        beginning",<br>
        "offset from end". Wouldn't you get that with the combination of
        user-defined<br>
        chains, a user-modifiable root chain, and priorities
        interpretted like this:<br>
        <br>
      </font></blockquote>
    Priorities are used for sorting and not for absolute position of a
    rule within a chain. You can compose filters of building blocks and
    leave some building blocks out and you'll end up missing rules with
    certain priorities. So the mapping to positions from priorities
    directly is not possible in that way.<br>
    <br>
       Stefan<br>
    <blockquote
cite="mid:OFB4EE789C.6FB521B9-ON8725792E.0072EF27-8725792E.0072EF33@us.ibm.com"
      type="cite"><font face="Default Sans
        Serif,Verdana,Arial,Helvetica,sans-serif" size="2">0 - insert at
        beginning<br>
        N - insert at N<br>
        MAX - append at end (and this ought to be 2G-1, not 1000)<br>
        -N - insert at END-N.<br>
        ?<br>
                                                                                    
        +-DLS<br>
        <br>
      </font></blockquote>
    <br>
  </body>
</html>