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?
next prev parent reply other threads:[~2012-01-19 9:12 UTC|newest]
Thread overview: 18+ 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:26 ` Eric Dumazet
2012-01-19 9:46 ` Jan Engelhardt
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 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.