All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four@googlemail.com>
To: netfilter-devel@vger.kernel.org
Cc: Richard Weinberger <richard@nod.at>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Jan Engelhardt <jengelh@medozas.de>
Subject: Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules
Date: Fri, 21 Jan 2011 15:09:05 +0000	[thread overview]
Message-ID: <4D39A191.1050703@googlemail.com> (raw)
In-Reply-To: <201101211438.31772.richard@nod.at>


>>> All I want is a friendlier output from conntrack, why should I reinvent
>>> the wheel?
>>>       
>> Why doing things in user-space is reinventing the wheel?
>>     
>
> When I'm using TRACE I'll get a lot of log messages.
> But I'm not interested in logs, I have already enough of them.
> I want a session table where I can see what sessions are allowed by
> which rules.
> I would have to write a tool like conntrack which builds me a session table
> from all these logs.
>   
I personally like the patch and find it quite useful, though I also 
think that tracing/tracking/matching sessions and rules could be 
improved and made more easier for the end user. That is especially true 
when one has a large number of rules in a particular chain.

As things stand, in order to trace a particular session and match it 
with a rule (using your patch) I have to execute iptables (or conntrack) 
twice in order to get what I need. Even if I use the line-numbers option 
to show rule numbers in a particular chain, that won't be straight 
forward when I have large number of rules.

It would be better if this matching is done (again, by using the rule 
numbers provided by your patch) with a userspace tool, may be conntrack, 
or similar, which shows those matches as well as the rules in question, 
and present them in a form, which does not require me to scan for those 
matches over and over. Just my two pence, of course, and I hope I am 
on-topic this time!


  parent reply	other threads:[~2011-01-21 15:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-20 22:47 [PATCH 0/3][RFC] Relationship between conntrack and firewall rules Richard Weinberger
2011-01-20 22:47 ` [PATCH 1/3] netfilter: add ruleid extension Richard Weinberger
2011-01-20 22:47   ` [PATCH 2/3] netfilter: add APPROVE target Richard Weinberger
2011-01-20 22:47     ` [PATCH 3/3] netfilter: implement ctnetlink_dump_ruleid() Richard Weinberger
2011-01-20 22:47       ` [PATCH] iptables: Add APPROVE target Richard Weinberger
2011-01-20 22:47         ` [PATCH] conntrack: Implement ruleid support Richard Weinberger
2011-01-20 23:17     ` [PATCH 2/3] netfilter: add APPROVE target Jan Engelhardt
2011-01-20 23:22       ` Richard Weinberger
2011-01-20 23:27         ` Jan Engelhardt
2011-01-20 23:30           ` Richard Weinberger
2011-01-20 22:52 ` [PATCH 0/3][RFC] Relationship between conntrack and firewall rules Jan Engelhardt
2011-01-20 23:02   ` Richard Weinberger
2011-01-21 10:00     ` Pablo Neira Ayuso
2011-01-21 11:13       ` Richard Weinberger
2011-01-21 11:26         ` Pablo Neira Ayuso
2011-01-21 11:56           ` Richard Weinberger
2011-01-21 12:24             ` Pablo Neira Ayuso
2011-01-21 12:53               ` Richard Weinberger
2011-01-21 13:25                 ` Pablo Neira Ayuso
2011-01-21 13:38                   ` Richard Weinberger
2011-01-21 13:57                     ` Pablo Neira Ayuso
2011-01-21 14:11                       ` Richard Weinberger
2011-01-21 15:09                     ` Mr Dash Four [this message]
2011-01-21  0:04 ` Mr Dash Four
2011-01-21  0:10   ` Richard Weinberger
2011-01-21  0:13     ` Mr Dash Four
2011-01-21  9:58       ` secctx support for conntrack-tools [was Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules] Pablo Neira Ayuso
2011-01-21  9:56   ` [PATCH 0/3][RFC] Relationship between conntrack and firewall rules Pablo Neira Ayuso

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=4D39A191.1050703@googlemail.com \
    --to=mr.dash.four@googlemail.com \
    --cc=jengelh@medozas.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=richard@nod.at \
    /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.