advanced logging, etc.

[Alexander Demenshin]

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...

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

  Aha.. See above :)

> 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).

  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 :)
  
/Al