advanced logging, etc.

[Harald Welte]

Hi!

I'm sitting in the Montreal Airport and waiting for my flight back from 
OLS2000 to germany.

I've been thinking about our logging problem. At OLS2000 I made the proposal
to pass all packets to be logged thrugh a netlink socket in the userspace.
A special userspace netfilter logging daemon may then log those packets
to a logfile, SQL server or whatever. Rusty agreed that this was the
most useful way to do advanced logging. 
I'm willing to do this logging module (and a corresponding userspace daemon
of course) after finishing the ip_nat_irc stuff.

=>
There are several ways to do that. 

My first thought was to generate a specially formatted logging message and
then pass this message to userspace. This is very ugly because of the 
output formatting inside kernelspace, which doesn't really belong there
(see ipt_LOG.c for further details :)

The second possibility is to create an almost identical copy of the QUEUE
target module. Using that would pass the raw packets from kernel to user,
where a daemon can process them. 
There are two disadvantages from my point of view:

1. 
We would have two pieces of code doing almost the same thing. Bad.

2.
Once a raw packet arrives in userspace there's no way to know where and why
they got logged. It was nice if they had some information attached (like
"logged due to line 12 in table foo"). I'm currently not sure if that is 
possible at all (without doing major changes).

So the ideal solution was to pass the packets inside of a struct which 
add two fields (line and name of table) before passing them to userspace.
But even then we have two parts of code doing almost the same thing.

So why don't change the already existing ipq_packet_msg to pass some 
additional information along to userspace ?
If we had a common way to do this, it was useful for the new DROP-chain 
Rusty is going to add, too. Here we face the same problem: How do we pass
some out-of-band data along the packet to userspace? Just misusing the mark
field to pass something which isn't really a netfilter packet mark?

=>
Another design issue regarding the kernel/userspace passing I've came to: 
If I understood the current behaviour correctly, only one proccess is able
to connect to our netlink socket for fetching packets from the QUEUE target.
That's a very unconvenient restriction. From the kernel point of view it
is simplifying thing a lot. But what if we have a bunch of userspace 
processes which wish to receive packets from netfilter chains? This may seem
unlikly in the present, but just think about the future. If we once have 
some daemons using the netfilter userspace queuing, we end up having a problem.

Adding more complexity to the kernel is always bad, so why don't provide a
kind of packet demultiplexer for userspace. This packet demux attaches to
the netlink socket and provides unix-domain-sockets for other processes
to connect to. A connecting process must have means to specify which packets/
protocol it is interested.

Please think of this mail as a request for comments. It seems that I've 
got very interested in the netfilter framework. I was very pleased if I 
could do my part in netfilter improvement / extensions. But I won't end
up doing some things in the wrong direction.


-- 
Live long and prosper
- Harald Welte / laforge@sunbeam.franken.de    http://www.sunbeam.franken.de
============================================================================
GCS/E d- s-/ a--- C+++ UL++++$ P+++ L+++$ E+ W+++ N++ K- w--- O M-- PS+ PE++
Y-- PGP++ t+++ 5-- !X !R tv- b+++ DI? D+ G+ e* h++ r++ y+(*)