netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Richard Weinberger <rw@linutronix.de>
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org
Subject: Re: Netfilter: New target: RLOG
Date: Thu, 19 Jan 2012 10:12:48 +0100	[thread overview]
Message-ID: <20120119091248.GA32391@1984> (raw)
In-Reply-To: <1326926610-17830-1-git-send-email-rw@linutronix.de>

Hi Richard,

On Wed, Jan 18, 2012 at 11:43:25PM +0100, Richard Weinberger wrote:
> RLOG is a new log target, it works like LOG with the exception that it writes to ring buffers.
> It makes use of Steven Rostedt's ring_buffer subsystem. 
> I've used Steve's ring buffer because it allows concurrent writes. IOW it's very fast.
> For more details see: Documentation/trace/ring-buffer-design.txt.
> 
> Each ring buffer is represented as a pipe-like file in /proc/net/netfilter/xt_RLOG/.
> You can read from it with and program you like (cat, syslog, etc...).
> The default size is 1MiB. With this size it can store approximately 5000 messages.
> 
> - Why not LOG?
> I like the LOG target a lot but I really hat it when it floods my kernel syslog.
> dmesg becomes useless.
> Writing all log messages to a file using syslogd also not always the best solution.
> Most of the time my firewall logs just waste disk space.
> 
> Compared with Steve's ring_buffer, the kernel syslog is rather slow.
> Especially when the firewall logs very much syslog becomes a bottleneck.
> As we all know printk() is not fast.
> 
> - Why not ULOG/NFLOG?
> Because it cannot replace LOG.
> Details like PHYSIN and PHYSOUT are not available form the packet headers.
> Also on many Linux systems ulogd is not available/supported.  

We only include physin and phyout if netfilter bridge is enabled. I
may be missing anything but, why can these be useful if bridging is not
enabled?

> - Why RLOG?
> Using RLOG you can have many ring buffers with all kind of logs.
> If your firewall goes nuts you don't have to mess you rule-set with adding
> new LOG rules to find out what's going on.
> Just install a few RLOG rules with small buffer sized and read them if you don't
> know what's going on.
> If you make you firewall rule-set per default verbose using LOG or NFLOG it will 
> generate lot's of useless messages which you'll never ever read.
> With RLOG you can bypass this problem.
> On my firewall I record only useful data to the disk. Everything else goes into RLOG.
> If your firewall is really busy and you want to log nearly everything, c
> reate a big ring buffer and read from is using your favorite userspace tool.
> In case the buffer fills faster than the userspace consumes it, RLOG will warn you.
> I'd also possible to resize the buffer.

I still think this can be useful.

But, why don't you add this to the LOG target as an extension instead
of yet another target?

  parent reply	other threads:[~2012-01-19  9:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-18 22:43 Netfilter: New target: RLOG Richard Weinberger
2012-01-18 22:43 ` [PATCH 1/5] ring_buffer: Export for_each_buffer_cpu() Richard Weinberger
2012-01-19  1:18   ` Steven Rostedt
2012-01-18 22:43 ` [PATCH 2/5] xt_log: Make printk() in sb_close() optional Richard Weinberger
2012-01-19  1:20   ` Steven Rostedt
2012-01-18 22:43 ` [PATCH 3/5] nf_log: Export dump_packet() and dump_mac_header() functions Richard Weinberger
2012-01-19  1:21   ` Steven Rostedt
2012-01-18 22:43 ` [PATCH 4/5] netfilter: Implement xt_RLOG Richard Weinberger
2012-01-18 22:43 ` [PATCH 5/5] xt_RLOG: add userspace-components Richard Weinberger
2012-01-19  9:12 ` Pablo Neira Ayuso [this message]
2012-01-19  9:21   ` Netfilter: New target: RLOG Richard Weinberger
2012-01-19  9:26     ` Eric Dumazet
2012-01-19  9:46       ` Jan Engelhardt
2012-01-19 10:31         ` Richard Weinberger
2012-01-19  9:25   ` Pablo Neira Ayuso
2012-01-19  9:29     ` Richard Weinberger

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=20120119091248.GA32391@1984 \
    --to=pablo@netfilter.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=rw@linutronix.de \
    /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).