Following points aren't draft no more! They are more or less implemented.
- division into three parts:
- daemon process (netrafd) -
capturing packets and analyzing them (according to
fully-configurable user-defined filters),
- daemon process (netrafl) -
logging statistics to files,
- interactive
(NCURSES)
program (netrafg) showing
"what's happening" live, and - in some way - remote control for daemon
processes described above,
- immune to sudden restarts of machine and electric power shortage,
- ability to log certain network traffic informations (depending on applied filter type):
- gathering statistics by network interface(s):
- amount of data (RX and TX) bytes,
- count of transferred packets and IP packets,
- count of transferred Broadcast, Multicast and
"routed-through" packets,
- gathering statistics by network MAC addresses:
- amount of data (RX and TX) bytes per MAC,
- count of transferred packets and IP packets per MAC,
- average data rates,
- gathering statistics by network TCP connections:
- amount of data (DOWN and UP) bytes per one TCP connection,
- count of transferred IP packets per connection,
- average data rates for choosen connection,
- gathering statistics by network IP addresses:
- amount of data (IN and OUT) bytes per IP address,
- count of transferred IP packets,
- modularized structure witch allow users to write their own filters and
logging rules,
- user-defined filter consist of:
- source or destination MAC address,
- source or destination IP address,
- source or destination TCP/UDP port,
- network interface to listen on,
- perl-compatible regular expression to be matched to packet data,
- user-defined logging rule consist of:
- whether captured packets should be logged to file,
- if above is true, what is the period the log-file should be updated,
- directory path, where the log-file should be stored,
|