Re: real-time monitor question

["Jeffrey D. Brower" <jeff@pointhere.net>]

> I think that ulogd, and the ULOG target which feeds it, are the best
> solution in this case.

Based on that statement I got more deeply into the ULOG and it looks good.
I found an extention in the CVS called ulogd_OPRINT.c which (although I can
not find the documentation on its use) LOOKS like it is almost exactly what
I need.  Can it be that my solution could be as simple as replacing the
_output_print() function with my own function that prints to the circuit
board?


> Why is that? It seems to be the best way to distinguish between packets
> being dropped in different places.

I was really refering to the horrors of a huge syslog as each packet gets
logged and reading that log file to drive the circuit board and all the
maintenance nightmares with it.


>  If you only want a graph of ALL packets
> accepted and ALL packets dropped, then just create a couple of chains:
>
>   iptables -N my_accept
>   iptables -A my_accept -j ULOG --ulog-prefix "ACCEPT"
>   iptables -A my_accept -j ACCEPT
>
>   iptables -N my_drop
>   iptables -A my_drop -j ULOG --ulog-prefix "DROP"
>   iptables -A my_drop -j DROP

This confused me until I realized that the ULOG returns the packets for
further processing.  I had (in error) thought that I would have to deal with
the packet resolution in userspace.


> > It occurs to me that there might be something I can do with the /proc
files.
>
> As far as I know there are no counters of ACCEPTed/DROPped packets in
/proc

Another suggestion that I got kind of steered me toward lookng at bytes
rather than packets and I wonder if I can't just read one of the /proc files
to see the number of bytes accepted and denyed - the assumption being that I
could log bytes to the board and let the log files watch for connections
keeping the size of the log file down while still presenting a real-time
interface for the operator via the circuit board.  As I understand it, I can
read a /proc file 10 times a second with little impact on the system (as
bizzare as that sounds to me).


> but you could run "iptables -L -n -v" and parse the output to see  the
number of
> packets dropped at each rule.

seems like a lot of overhead.


> Maybe have a process which fork()s with either end of a pipe(). One
> process reads from Netfilter and writes to the pipe every so often (with a
> non-blocking write), while the other process reads from the pipe and
> writes to the hardware.

Never having done a fork(), nor a pipe() nor reads from Netfilter - this
sounds like a lot of fun to me (but like a heck of a learning curve).  It
sounds like what I envisioned, but I wonder if the pipe won't get stuffed
too fast and halt the input side causing lost packets, etc.  It really seems
like this exactly what I need to code in the  _output_print() function of
the ulogd_OPRINT.c program - but again, how do I keep it from over-running
the pipe?


> Hope this helps!

Yes it did.