All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	Netfilter Development Mailing list
	<netfilter-devel@vger.kernel.org>
Subject: Re: libnftables set element printing, DATA_CHAIN
Date: Thu, 16 Jan 2014 10:40:53 +0000	[thread overview]
Message-ID: <20140116104053.GA28413@macbook.localnet> (raw)
In-Reply-To: <CAOkSjBjD7VBgErC08C387u6Lgetx8m7mtBfe4khpRLWbahsHJA@mail.gmail.com>

On Thu, Jan 16, 2014 at 11:30:26AM +0100, Arturo Borrero Gonzalez wrote:
> On 15 January 2014 23:50, Patrick McHardy <kaber@trash.net> wrote:
> > [resending because of incorrect list address]
> >
> > I was looking at some incorrect output in netlink debugging for set elements
> > and noticed a few things that seem odd:
> >
> > First, the regular netlink debugging seems very incomplete, it doesn't
> > print verdict types, it prints [end] whether the set contains intervals
> > and the set is an interval end or not and its messing up the output.
> >
> 
> It's true, most of the development went to the JSON/XML formats, not
> the default one.
> 
> > Next I'm wondering about what DATA_CHAIN is supposed to be. I guess its
> > the chain for a jump or goto verdict, This is even encoded in the
> > XML and JSON output. This seems wrong to me, there is no DATA_CHAIN,
> > there are JUMP or GOTO verdicts that include a chain. The specific
> > verdict is also missing, so its not possible to distinguish these
> > two cases.
> >
> 
> Ok, let's fix that. Do you have a proposal?
> 
> This is what I think you want:
> 
> * a <data_reg type=value> with raw data.
> * a <data_reg type=verdict> with a concrete verdict (eg drop accept)
> * a <data_reg type=jump> with a chain to jump to.
> * a <data_reg type=goto> with a chain to go to.
> 
> Or maybe:
> 
> * a <data_reg type=value> with raw data.
> * a <data_reg type=verdict> with a concrete verdict (eg drop accept)
> and if verdict == jump or goto, then a <chain> with the destination.

Yes, this is what I think we should do.

> > I could fix up the debugging output, but this looks like someone more
> > familiar with the XML and JSON stuff should have a look at this and
> > fix all of this consistently before we release it as wire format.
> 
> I can handle it.

Great, thanks a lot.

      reply	other threads:[~2014-01-16 10:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15 22:50 libnftables set element printing, DATA_CHAIN Patrick McHardy
2014-01-16 10:30 ` Arturo Borrero Gonzalez
2014-01-16 10:40   ` Patrick McHardy [this message]

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=20140116104053.GA28413@macbook.localnet \
    --to=kaber@trash.net \
    --cc=arturo.borrero.glez@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.