Masquerade bean-counting

[dans en chiark.greenend.org.uk]

Mark Hahn wrote:
>> - The D'oh factor: Is there an easy way of doing this already?
>
>can't this be done with numerous user-level programs?
>
>> - Vehement objections to the whole idea.
>
>this, and quotas/accounting in general, are things that only
>interest certain specialized constituencies.  as such, 
>they do not belong in the mainstream kernel if they impose 
>any performance overhead at all, or more than a minor code overhead.

Michael Clark wrote:
>> What I'm asking then, is if it would be sensible for me to write a
>> patch which maintains records of what passes through the masquerading
>> process, and produces a summary of bytes/packets masqueraded to each
>> ip address, and made the results available in, say, /proc.
>
>You could use NeTraMet (Network Traffic Meter) which is a mature user
>mode solution that uses libpcap to snoop traffic and record traffic
>summariess using a simple packet matching rule language. You could
>easily configure it to record a summary of traffic on gateway's interior
>interface between say <internal RFC1918 address> and <public addresses>
>aggregated by internal address.
>
>Source:  ftp://ftp.auckland.ac.nz/pub/iawg/NeTraMet/NeTraMet43.tar.gz
>Docs:    ftp://ftp.auckland.ac.nz/pub/iawg/NeTraMet/ntm43.pdf

Thank you both for your help.

NeTraMet looks like it is the right solution, I'll recommend it if I'm
ever asked. 

In my particular case I hacked up a kernel patch before I received
these messages, which seems to be working well[1]. It's parallel to
the masquerading modules system in that a hook is provided for
accounting modules where, if they are registered, they get iphdr's at
the right point in the masquerading/demasquerading process. The
example module I wrote maintained a hash table and wrote stuff to
/proc. It seems to work, but given Mark's comments on the limited
constituency and on user-space solvability of the problem (which are
certainly true) and Michael's post on mature software which solves the
problem, I'll keep the patches to myself and suggest NeTraMet if I'm
ever asked.

  [1] It turned out that it was only 300 lines or so, mainly /proc
      handling.

Thanks again for listening,
Dan.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/