Messages in this thread | | | Subject | Re: Masquerade bean-counting | From | dans@chiark ... | Date | Fri, 21 Jan 2000 22:30:56 +0100 |
| |
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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |