Simple LAN IP accounting

[Nash Nipples]

Oh come on guys, are we talking about accounting or packets sniffing? if so, i believe that tcpdump should be rewritten into tcpacc with no ability to see packets. and make it more flexible.

i believe there are number of reasons why guys at FreeBSD do not document the traffic accounting process. They not just 'missed out' the matter for so many years. That could be because 1. Its Free, so if you want to make profit you better invest into commercial applications. 2. There is no standard approach to satisfy everyone's needs and security considerations for automated hijacking of resources as soon as standard is derived. 3. at this point you should really be able to make it what you want it to be.

Ofcourse we can end up blaming all the ports because the authors shared what they did and left the sources for people who need them different.

I also believe that a custom accounting program would be a big deal of programming experience handling strings, streams, various types of data and pretty formatted output with no limits but time against needs and talk against deeds. 

nash

p.s. i like to write this crap lol!

Brian Candler <B.Candler at pobox.com> wrote: On Sun, Jun 18, 2006 at 07:26:44AM -0700, Nash Nipples wrote:
>    ipfw add 5 skipto 500 ip from 192.168.110.1 to any out via tun0 
>  ipfw add 10 skipto 500 ip from any to 192.168.110.1 to any in via tun0
>  ipfw add .. skipto 500 ip from 192.168.110... to any out via tun0
>  ...
>  ipfw add 500 divert from any to any in via tun0 #back to normal rules
>  
>  ipfw show 
>  00005 274943  64986791 ip from 192.168.110.1 to any out via tun0
>  00010 274943  64986791 ip from any to 192.168.110.1 in via tun0
>  
>  thats pretty stupid but works. and you need a program to proccess the output
>  thats what im working on time to time :)
>  
>  it doesnt overload the filter cuz a matching rule is passed once at a time and the unmatched skipped to normal rules. if you get out of ipfw rules limits you might consider to split.. lol
>  
>  anyone else?

Another approach is to capture absolutely everything using libpcap into a
userland process, and then post-process afterwards. This is how 'ntop'
works. At a very simplistic level you could just use tcpdump -w  to
capture the packets (or packet headers) into a file, and then tcpdump -r
 to pipe them into a script to analyse them, such as totalising the
sizes of all packets to/from a particular IP address.

Another approach is to use statistical sampling - pick packets at random, so
that overall you capture, say, 1 packet in 128, and analyse those. This is
the approach used by sflow. If you have an sflow-capable switch, this is a
very efficient way of doing this analysis. You can turn the sflow data into
simple CSV records using 'sflowtool', or ntop has an sflow module.

This assumes that taking the sampled data and multiplying it by 128 will be
sufficiently accurate for your purposes, of course.

Regards,

Brian.


 		
---------------------------------
Yahoo! Groups gets better. Check out the new email design. Plus there’s much more to come.