From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Hans Schillstrom <hans.schillstrom@ericsson.com>
Cc: "kaber@trash.net" <kaber@trash.net>,
"jengelh@medozas.de" <jengelh@medozas.de>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"hans@schillstrom.com" <hans@schillstrom.com>
Subject: Re: [v12 PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark
Date: Mon, 7 May 2012 11:03:28 +0200 [thread overview]
Message-ID: <20120507090328.GA27650@1984> (raw)
In-Reply-To: <201205071020.44449.hans.schillstrom@ericsson.com>
On Mon, May 07, 2012 at 10:20:42AM +0200, Hans Schillstrom wrote:
> On Monday 07 May 2012 00:57:38 Pablo Neira Ayuso wrote:
> > Hi Hans,
> >
> > [...]
> > > > > > Regarding ICMP traffic, I think we can use the ID field for the
> > > > > > hashing as well. Thus, we handle ICMP like other protocols.
> > > > >
> > > > > Yes why not, I can give it a try.
> > > > >
> > >
> > > I think we wait with this one..
> >
> > I see. This is easy to add for the conntrack side, but it will require
> > some extra code for the packet-based solution.
>
> Actually I think there is very little gain to spread with type
> and then we must add a user mode possibility to turn it off
> i.e. a --hmark-icmp-type-mask
>
> > Not directly related to this but, I know that your intention is to
> > make this as flexible as possible. However, I still don't find how I
> > would use the port mask feature in any of my setups. Basically, I
> > don't come up with any useful example for this situation.
>
> We have plenty of rules where just source port mask is zero.
> and the dest-port-mask is 0xfffc (or 0xffff)
0xffff and 0x0000 means on/off respectively.
Still curious, how can 0xfffc be useful?
> > I'm also telling this because I think that ICMP support will be
> > easier to add if port masking is removed.
> >
> > [...]
> > > This is what I have done.
> > >
> > > - I reduced the code size a little bit by combining the hmark_ct_set_htuple_ipvX into one func.
> > > by adding a hmark_addr6_mask() and hmark_addr_any_mask()
> > > Note that using "otuple->src.l3num" as param 1 in both src and dst is not a typo.
> > > (it's not set in the rtuple)
> >
> > Good one, this made the code even smaller.
> >
> > > - Made the if (dst < src) swap() in the hmark_hash() since it should be used by every caller.
> >
> > Not really, you don't need for the conntrack part. The original tuple
> > is always the same, not matter where the packet is coming from. I have
> > removed this again so it only affects packet-based hashing.
>
> Yes original tuple is always the same but not always less than the rtuple.
> If you have two nodes that should produce the same hmark,
> one with conntrack an one without you must make a compare to make it consistent.
I see, for consistency still makes sense although this seems to me
like still strange configuration. In what scenario would you use two
different approaches?
> > > - Moved the L3 check a little bit earlier.
> >
> > good.
> >
> > > - changed return values for fragments.
> >
> > With this, you're giving up on trying to classify fragments. Do you
> > really want this?
> >
> > From my point of view, if your firewalls (assuming they are the HMARK
> > classification) are stateless, it still makes sense to me to classify
> > fragments using the XT_HMARK_METHOD_L3_4.
>
> I do agree, it is back to "return 0" again.
OK.
next prev parent reply other threads:[~2012-05-07 9:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 13:35 [v12 PATCH 0/3] NETFILTER new target module, HMARK Hans Schillstrom
2012-04-23 13:35 ` [v12 PATCH 1/3] NETFILTER added flags to ipv6_find_hdr() Hans Schillstrom
2012-05-09 11:01 ` Pablo Neira Ayuso
2012-04-23 13:35 ` [v12 PATCH 2/3] NETFILTER module xt_hmark, new target for HASH based fwmark Hans Schillstrom
2012-05-02 0:34 ` Pablo Neira Ayuso
2012-05-02 7:55 ` Hans Schillstrom
2012-05-02 8:09 ` Pablo Neira Ayuso
2012-05-02 17:49 ` Hans Schillstrom
2012-05-06 22:57 ` Pablo Neira Ayuso
2012-05-07 8:20 ` Hans Schillstrom
2012-05-07 9:03 ` Pablo Neira Ayuso [this message]
2012-05-07 9:14 ` Hans Schillstrom
2012-05-07 11:56 ` Pablo Neira Ayuso
2012-05-07 12:09 ` Hans Schillstrom
2012-05-07 12:22 ` Pablo Neira Ayuso
2012-05-07 12:57 ` Hans Schillstrom
2012-05-07 14:54 ` Pablo Neira Ayuso
2012-05-08 7:37 ` Hans Schillstrom
2012-05-09 10:38 ` Pablo Neira Ayuso
2012-05-09 13:36 ` Hans Schillstrom
2012-04-23 13:35 ` [v12 PATCH 3/3] NETFILTER userspace part for target HMARK Hans Schillstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120507090328.GA27650@1984 \
--to=pablo@netfilter.org \
--cc=hans.schillstrom@ericsson.com \
--cc=hans@schillstrom.com \
--cc=jengelh@medozas.de \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).