advanced logging, etc.
Tue, 25 Jul 2000 01:17:56 +0200
On Tue, Jul 25, 2000 at 12:25:27AM +1000, Harald Welte wrote:
> to a logfile, SQL server or whatever. Rusty agreed that this was the
> most useful way to do advanced logging.
Great... Long time ago Rusty told me that there is no need for this :)
> 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.
If we would implement something like NF_CONTINUE as verdict for the QUEUE
target, it would be as simple as possible - this verdict should pass
control over to the next entry in table without decision...
> We would have two pieces of code doing almost the same thing. Bad.
Aha.. See above :)
> 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).
Or someting like: -j QUEUE --qmark 777 (special mark value for the QUEUE
target - as of me it seems a little bit strange to use mangle table to
mark packets then to process them in user space).
> 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.
IMHO, it has some disadvantage - what if rules were rearranged? Something
like qmark would be better, though no one can stop us to pass rule number
and table name (would be useful as well).
> So why don't change the already existing ipq_packet_msg to pass some
> additional information along to userspace ?
Yes, yes, yes, yes!!! :)) (I vote :) I need this feature as well but
for packet accounting, anyway targets are similar :)
> 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?
Here is the reason for my proposal: --qmark
> 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.
In my tests it is possible to have at least two processes - each will get
packets. Though I didn'y tested it in deep... Anyway ip_queue has no support
for multiple processes, but it would be useful. Say, special command like
set_filter(qmark) or something more advanced like set_filter(and, xor)...
> 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.
I see at least two daemons running on my box - one for logging and one for
accounting. BTW, what about passing MAC address as well to userspace? IP is
not always enough...
> Adding more complexity to the kernel is always bad, so why don't provide a
> kind of packet demultiplexer for userspace.
I think simple filter is not a bad idea even for kernel space, but I am pretty
sure that Rusty will disagree :)
> This packet demux attaches to
> the netlink socket and provides unix-domain-sockets for other processes
> to connect to.
...and the it gets killed/crashed. Oops :))
> could do my part in netfilter improvement / extensions. But I won't end
> up doing some things in the wrong direction.
IMHO, you are going in the right direction, at least now I know that I am
not alone who needs something similar :)