I would like not to rely on NTop summarizing statistics, but instead having
complete visibility on everything that passes on the network.
The man page for the -p option says:
-p | --protocols
It is used to specify the TCP/UDP protocols that ntop will monitor. The
format is <label>=<protocol list> [, <label>=<protocol list>], where label
is used to symbolically identify the <protocol list>. The format of
<protocol list> is <protocol>[|<protocol>], where <protocol> is either a
valid protocol specified inside the /etc/services file or a numeric port
range (e.g. 80, or 6000-6500).
So the solution could be to replicate the whole services file into the
protocol list. Such an approach seems encouraged by the following remark,
found on line 1078 of ntop.h :
/* The constant below is so large due to the
huge service table that Doug Royer <[EMAIL PROTECTED]>
has to handle. I have no clue what's inside such /etc/services
file. However, all this is quite interesting....
*/
#define SERVICE_HASH_SIZE 50000
A services file can indeed be quite large. For a couple of examples see the
official IANA list, available at this URL:
http://www.iana.org/assignments/protocol-numbers
or the following one, suggested in the file nmap-services of NMap:
http://www.graffiti.com/services
I'm confident that NTop is capable of dealing with such a huge list without
wasting too much memory, but I'm concerned of what I'll find in the
dumpData.html statistics, since every protocol creates an entry even when
there's been no traffic for it.
The simplest thing would be a way to say to NTop: "Just give me everything
you see". It could reuse the port numbers as labels, and only create entries
in the dumpData.html output for services with actual traffic.
--
Nicola Larosa
Direttore Tecnico - Araknos srl
[EMAIL PROTECTED]
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
