Man Linux: Main Page and Category List


       ntop - display top network users


       ntop  [@filename] [-a|--access-log-file <path>] [-b|--disable-decoders]
       [-c|--sticky-hosts]    [-e|--max-table-rows]    [-f|--traffic-dump-file
       file>] [-g|--track-local-hosts] [-h|--help] [-j|--create-other-packets]
       [-l|--pcap-log <path>] [-m|--local-subnets <addresses>]  [-n|--numeric-
       ip-addresses]   [-o|--no-mac]   [-p|--protocols  <list>]  [-q|--create-
       suspicious-packets] [-r|--refresh-time <number>]  [-s|--no-promiscuous]
       [-t|--trace-level  <number>]  [-x  <max_num_hash_entries>]  [-w|--http-
       server   <port>]    [-z|--disable-sessions]    [-A|--set-admin-password
       password]   [-B|--filter-expression   expression]   [-C   <configmode>]
       [-D|--domain <name>] [-F|--flow-spec <specs>] [-M|--no-interface-merge]
       [-N|--wwn-map <path>] [-O|----output-packet-path <path>] [-P|--db-file-
       path  <path>]   [-Q|--spool-file-path   <path>]   [-U|--mapper   <URL>]
       [-V|--version]       [-X       <max_num_TCP_sessions>]      [--disable-
       instantsessionpurge] [--disable-mutexextrainfo]  [--disable-schedyield]
       [--disable-stopcap]  [--fc-only]  [--instance] [--no-fc] [--no-invalid-
       lun] [--p3p-cp] [--p3p-uri] [--skip-version-check] [--w3c]  [-4|--ipv4]

       Unix options:

       [-d|--daemon]  [-i|--interface <name>] [-u|--user <user>] [-K|--enable-
       debug]    [-L]    [--pcap_setnonblock]    [--use-syslog=    <facility>]
       [--webserver-queue <number>]

       Windows option:

       [-i|--interface <number|name>]

       OpenSSL options:

       [-W|--https-server <port>] [--ssl-watchdog]


       ntop  shows the current network usage. It displays a list of hosts that
       are currently using the network and reports information concerning  the
       (IP  and non-IP) traffic generated and received by each host.  ntop may
       operate as a front-end collector (sFlow and/or netFlow plugins) or as a
       stand-alone  collector/display  program.  A  web  browser  is needed to
       access the information captured by the ntop program.

       ntop is a hybrid layer 2 / layer 3 network monitor, that is by  default
       it  uses the layer 2 Media Access Control (MAC) addresses AND the layer
       3 tcp/ip addresses.  ntop is capable of associating the two, so that ip
       and non-ip traffic (e.g. arp, rarp) are combined for a complete picture
       of network activity.


        The text of filename is copied -  ignoring  line  breaks  and  comment
        lines  (anything following a #) - into the command line.  ntop behaves
        as if all of the text had simply been typed directly  on  the  command
        line.   For example, if the command line is "-t 3 @d -u ntop" and file
        d contains just the line ’-d’, then the effective command line is -t 3
        -d  -u  ntop.   Multiple  @s are permitted. Nested @s (an @ inside the
        file) are not permitted.

        Remember, most ntop options are "sticky", that is  they  just  set  an
        internal  flag.  Invoking  them  multiple  times doesn’t change ntops
        behavior. However, options that set a value,  such  as  --trace-level,
        will  use  the  LAST value given: --trace-level 2 --trace-level 3 will
        run as --trace-level 3.

        Beginning with 3.1, many command-line options may also be set via  the
        web  browser  interface.  These changes take effect on the next run of
        and on each subsequent run until changed.

       -a | --access-log-file
        By default ntop does not maintain  a  log  of  HTTP  requests  to  the
        internal  web  server.   Use  this parameter to request logging and to
        specify the location of the file where these HTTP requests are logged.

        Each  log  entry is in Apache-like style.  The only difference between
        Apache and ntop logs is that an additional column has been added which
        has  the time (in milliseconds) that ntop needed to serve the request.
        Log entries look like this: - - [04/Sep/2003:20:38:55 -0500] - "GET / HTTP/1.1" 200 1489 4 - - [04/Sep/2003:20:38:55 -0500] - "GET /index_top.html HTTP/1.1" 200 1854 4 - - [04/Sep/2003:20:38:55 -0500] - "GET /index_inner.html HTTP/1.1" 200 1441 7 - - [04/Sep/2003:20:38:56 -0500] - "GET /index_left.html HTTP/1.1" 200 1356 4 - - [04/Sep/2003:20:38:56 -0500] - "GET /home_.html HTTP/1.1" 200 154/617 9 - - [04/Sep/2003:20:38:56 -0500] - "GET /home.html HTTP/1.1" 200 1100/3195 10 - - [04/Sep/2003:20:38:56 -0500] - "GET /About.html HTTP/1.1" 200 2010 10

        This parameter is the complete file name of the access log.  In  prior
        releases it was erroneously called --access-log-path.

       -b | --disable-decoders
        This parameter disables protocol decoders.

        Protocol  decoders  examine  and  collect  information  about  layer 2
        protocols such as NetBIOS or Netware SAP, as well  as  about  specific
        tcp/ip (layer 3) protocols, such as DNS, http and ftp.

        This  support is specifically coded for each protocol and is different
        from the capability to count raw information (packets  and  bytes)  by
        protocol specified by the -p | --protocols parameter, below.

        Decoding protocols is a significant consumer of resources. If the ntop
        host is underpowered or monitoring a very busy network, you  may  wish
        to  disable  protocol  decoding  via  this  parameter.  It may also be
        appropriate to use  this  parameter  if  you  believe  that  ntop  has
        problems handling some protocols that occur on your network.

        Even  if  decoding  is  disabled, ftp-data traffic is still decoded to
        look for passive ftp port commands.

       -c | --sticky-hosts
        Use this parameter to  prevent  idle  hosts  from  being  purged  from

        By  default  idle  hosts are periodically purged from memory.  An idle
        host is identified when no packets from or  to  that  host  have  been
        monitored   for   the   period   of  time  defined  by  the  value  of
        PARM_HOST_PURGE_MINIMUM_IDLE in globals-defines.h.

        If you use this option, all hosts - active and idle - are retained  in
        memory for the duration of the ntop run.

        P2P  users,  port  scans,  popular web servers and other activity will
        cause ntop to record data about a large number of hosts.  On an active
        network, this will consume a significant - and always growing - amount
        of memory.  It is  strongly  recommended  that  you  use  a  filtering
        expression  to  limit  the hosts which are stored if you use --sticky-

        The idle purge is a statistical  one  -  a  random  selection  of  the
        eligible  hosts will be purged during each cycle.  Thus it is possible
        on a busy system for an idle host to remain in  the  ntop  tables  and
        appear ’active’ for some considerable time after it is truly idle.

       -d | --daemon
        This  parameter causes ntop to become a daemon, i.e. a task which runs
        in the background without connection to a specific terminal.   To  use
        ntop other than as a casual monitoring tool, you probably will want to
        use this option.

        WARNING: If you are running as a daemon, the messages from  ntop  will
        be  ’printed’  on to stdout and thus dropped.  You probably don’t want
        to do this.  So remember to also use the -L or --use-syslog options to
        save the messages into the system log.

       -e | --max-table-rows
        This  defines  the  maximum  number of lines that ntop will display on
        each generated HTML page. If there are more lines to be displayed than
        this  setting permits, only part of the data will be displayed.  There
        will be page forward/back arrows placed at the bottom of the page  for
        navigation between pages.

       -f | --traffic-dump-file
        By  default, ntop captures traffic from network interface cards (NICs)
        or from netFlow/sFlow probes.  However, ntop can also read data from a
        file  - typically a tcpdump capture or the output from one of the ntop
        packet capture options.

        if you specify -f, ntop will not capture any traffic from NICs  during
        or after the file has been read.  netFlow/sFlow capture - if enabled -
        would still be active.

        This option is mostly used for debug purposes.

       -g | --track-local-hosts
        By default, ntop tracks all hosts that it sees from  packets  captured
        on  the various NICs.  Use this parameter to tell ntop to capture data
        only about  local  hosts.   Local  hosts  are  defined  based  on  the
        addresses  of  the NICs and those networks identified as local via the
        -m | --local-subnets parameter.

        This parameter is useful on large networks  or  those  that  see  many
        hosts,  (e.g.  a  border  router  or gateway), where information about
        remote hosts is not desired/required to be tracked.

       -h | --help
        Print help information for ntop, including usage and parameters.

       -i | --interface
        Specifies the network interface or interfaces to be used by  ntop  for
        network monitoring.

        If  multiple  interfaces  are  used (this feature is available only if
        ntop is compiled with thread support) their names  must  be  separated
        with a comma. For instance -i "eth0,lo".

        If not specified, the default is the first Ethernet device, e.g. eth0.
        The specific device  that  is  ’first’  is  highly  system  dependent.
        Especially  on  systems where the device name reflects the driver name
        instead of the type of interface.

        By default, traffic information obtained  by  all  the  interfaces  is
        merged together as if the traffic was seen by only one interface.  Use
        the -M parameter to keep traffic separate by interface.

        If you do not want ntop to monitor any interfaces, use -i none.

        Under Windows, the  parameter  value  is  either  the  number  of  the
        interface  or  its name, e.g.  {6252C14C-44C9-49D9-BF59-B2DC18C7B811}.
        Run ntop -h to see a list of interface name-number  mappings  (at  the
        end of the help information).

       -j | --create-other-packets
        This  parameter  causes  ntop  to  create  a  dump file of the ’other’
        network traffic captured.   One  file  is  created  for  each  network
        interface  where <path>/ntop-other-pkts.<device>.pcap, where <path> is
        defined by the -O |  --output-packet-path  parameter.   This  file  is
        useful for understanding these unclassified packets.

       -l | --pcap-log
        This parameter causes a dump file to be created of the network traffic
        captured by ntop in tcpdump (pcap) format.  This file  is  useful  for
        debug,  and may be read back into ntop by the -f | --traffic-dump-file
        parameter.  The dump is made after processing any filter expression  (
        never even sees filtered packets).

        The  output  file  will  be named <path>/<log>.<device>.pcap (Windows:
        <path>/<log>.pcap ), where <path> is defined by  the  -O  |  --output-
        packet-path  parameter  and  <log>  is defined by this -l | --pcap-log

       -m | --local-subnets
        ntop  determines  the  ip  addresses  and  netmasks  for  each  active
        interface.   Any  traffic on those networks is considered local.  This
        parameter  allows  the  user  to  define   additional   networks   and
        subnetworks  whose  traffic  is also considered local in ntop reports.
        All other hosts are considered remote.

        Commas separate  multiple  network  values.   Both  netmask  and  CIDR
        notation   may   be   used,   even   mixed   together,   for  instance

        The local subnet - as defined by the interface  address(es)  -  is/are
        always local and do not need to be specified.  If you do give the same
        value as a NIC’s local address, a harmless warning message is  issued.

       -n | --numeric-ip-addresses
        By  default,  ntop resolves IP addresses using a combination of active
        (explicit)  DNS  queries  and  passive  sniffing.   Sniffing  of   DNS
        responses  occurs  when  ntop receives a network packet containing the
        response  to  some  other  user’s  DNS  query.   ntop  captures   this
        information  and  enters  it  into ntops DNS cache, in expectation of
        shortly  seeing  traffic  addressed  to  that  host.  This  way   ntop
        significantly reduces the number of DNS queries it makes.

        This  parameter  causes  ntop  to  skip  DNS  resolution, showing only
        numeric IP addresses instead of the symbolic names.  This  option  can
        useful when the DNS is not present or quite slow.

       -o | --no-mac
        ntop is a hybrid layer 2/3 network monitor.  That is, it uses both the
        lower level, physical device address - the MAC (Media Access  Control)
        address  - and the higher level, logical, tcp/ip address (the familiar or address).  This allows ntop to  link  the
        logical  addresses to a physical machine with multiple addresses (This
        occurs with virtual hosts or  additional  addresses  assigned  to  the
        interface, etc.)  to present consolidated reporting.

        This  parameter specifies that ntop should not trust the MAC addresses
        but just use the IP addresses.

        Normally, since the MAC address must  be  globally  unique,  the  dual
        nature  of ntop is a benefit and provides far better information about
        the network than is available via a pure  layer  2  or  pure  layer  3

        Under certain circumstances - whenever ntop is started on an interface
        where MAC addresses cannot be really trusted - you  may  require  this

        Situations  which  may  require  this option include port/VLAN mirror,
        some cases with switches and spanning tree protocol, and  (reportedly)
        some specific models of Ethernet switches which re-write MAC addresses
        of the packets they process.  Normally, you discover that this  option
        is  necessary  when  you  observe  that  hosts  seem  to  change their
        addresses or information about different machines get lumped together.

        Note  that  with  this option, information which is dependent upon the
        MAC addresses (non tcp/ip protocols like IPX) will  not  be  collected
        nor displayed.

       -p | --protocols
        This parameter 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).

        A simple example is --protocols="HTTP=http|www|https|3128,FTP=ftp|ftp-
        data",  which  reduces  the  protocols  displayed on the "IP" pages to

        Host                      Domain Data          HTTP   FTP   Other IP             <flag>  954 63.9 %      0     0        954  <flag>  240 16.1 %    240     0          0   <flag>  240 16.1 %    240     0          0 <flag>   60 4.0 %      60     0          0

        If the <protocol list> is very long you may store it in  a  file  (for
        instance  protocol.list).   To do so, specify the file name instead of
        the <protocol list> on the command line.  e.g.  ntop -p protocol.list

        If the -p parameter is omitted the following default value is used:

          HTTP=http|www|https|3128     3128 is Squid, the HTTP cache

          Peer-to-Peer Protocols
          DirectConnect=0      Dummy port as this is a pure P2P protocol

          Instant Messenger

        NOTE: To  resolve  protocol  names  to  port  numbers,  they  must  be
        specified in the system file used to list tcp/udp protocols and ports,
        which is typically /etc/services file.  You will  have  to  match  the
        names  in  that  file, exactly.  Missing or unspecified (non-standard)
        ports must be specified by number, such as 3128 in our examples above.

        If  you have a file named /etc/protocols, don’t get confused by it, as
        that’s the Ethernet  protocol  numbers,  which  are  not  what  you’re
        looking for.

       -q | --create-suspicious-packets
        This parameter tells ntop to create a dump file of suspicious packets.

        There are many, many, things that cause a  packet  to  be  labeled  as
        ’suspicious’, including:

          Detected ICMP fragment
          Detected Land Attack against host
          Detected overlapping/tiny packet fragment
          Detected traffic on a diagnostic port
          Host performed ACK/FIN/NULL scan
          Host rejected TCP session
          HTTP/FTP/SMTP/SSH detected at wrong port
          Malformed TCP/UDP/ICMP packet (packet too short)
          Packet # %u too long
          Received a ICMP protocol Unreachable from host
          Sent ICMP Administratively Prohibited packet to host
          Smurf packet detected for host
          TCP connection with no data exchanged
          TCP session reset without completing 3-way handshake
          Two MAC addresses found for the same IP address
          UDP data to a closed port
          Unknown protocol (no HTTP/FTP/SMTP/SSH) detected (on port 80/21/25/22)
          Unusual ICMP options

        When  this  parameter  is  used,  one file is created for each network
        interface where suspicious packets are found. The file is  in  tcpdump
        (pcap)  format and is named <path>/ntop-suspicious-pkts.<device>.pcap,
        where <path> is defined by the -O | --output-packet-path parameter.

       -r | --refresh-time
        Specifies the delay (in seconds) between automatic screen updates  for
        those  generated HTML pages which support them.  This parameter allows
        you to leave your browser window open and have  it  always  displaying
        nearly real-time data from ntop.

        The default is 3 seconds.  Please note that if the delay is very short
        (1 second for instance), ntop might not be able to process all of  the
        network traffic.

       -s | --no-promiscuous
        Use  this  parameter  to  prevent  from  setting the interface(s) into
        promiscuous mode.

        An interface in promiscuous mode  will  accept  ALL  Ethernet  frames,
        regardless  of  whether  they  directed  (addressed)  to  the specific
        network interface (NIC) or not.  This is an essential part of enabling
        ntop  to  monitor  an entire network.  (Without promiscuous mode, ntop
        will only see traffic directed to the specific host it is running  on,
        plus broadcast traffic such as the arp and dhcp protocols.

        Even  if  you  use  this  parameter,  the  interface  could well be in
        promiscuous mode if another application enabled it.

        ntop passes this setting on to libpcap, the  packet  capture  library.
        On  many systems, a non-promiscuous open of the network interface will
        fail, since the libpcap function on most systems require it to capture
        raw  packets  (  ntop  captures  raw  packets  so that we may view and
        analyze the layer 2 - MAC - information).

        Thus on most systems, ntop must probably still be started as root, and
        this  option  is  largely  ornamental.   If  it  fails, you will see a
        ***FATALERROR*** message referring to  pcap_open_live()  and  then  an
        information  message,  "Sorry,  but  on  this system, even with -s, it
        appears that ntop must be started as root".

       -t | --trace-level
        This parameter specifies the ’information’ level of messages that  you
        wish  ntop to display (on stdout or to the log).  The higher the trace
        level number the more information that is displayed.  The trace  level
        ranges between 0 (no trace) and 5 (full debug tracings).

        The default trace value is 3.

        Trace  level  0  is  not quite zero messages. Fatal errors and certain
        startup/shutdown messages are always displayed.  Trace level 1 is used
        to  display  errors  only,  level  2 for both errors and warnings, and
        level 3 displays error, warning and informational messages.

        Trace level 4 is called ’noisy’ and it is - generating  many  messages
        about  the  internal functioning of ntop.  Trace level 5 and above are
        ’noisy’ plus extra logs, i.e. all possible messages, with a  file:line
        tag prepended to every message.

       -u | --user
        Specifies the user ntop should run as after it initializes.

        ntop  must  normally  be  started  as  root  so that it has sufficient
        privileges to open the network interfaces in promiscuous mode  and  to
        receive  raw  frames.   See  the  discussion  of -s | --no-promiscuous
        above, if you wish to try starting ntop as a non-root user.

        Shortly after starting up, ntop becomes the  user  you  specify  here,
        which  normally has substantially reduced privileges, such as no login
        shell.  This is the userid  which  owns  ntops  database  and  output

        The  value  specified  may  be either a username or a numeric user id.
        The group id used will be the primary group of the user specified.

        If this parameter is not specified, ntop will try to switch  first  to
        ’nobody’ and then to ’anonymous’ before giving up.

        NOTE:  This  should  not  be  root  unless  you  really understand the
        security risks. In order to prevent this by accident, the only way  to
        run ntop as root is to explicitly specify -u root.  Dont do it.


        ntop creates a new hash/list entry for each new host/TCP session seen.
        In case of DOS (Denial Of Service) an attacker can easily exhaust  all
        the  host  available memory because ntop is creating entries for dummy
        hosts. In order to avoid this you can set an upper limit in  order  to
        limit the memory ntop can use.

       -w | --http-server

       -W | --https-server
        ntop offers an embedded web server to present the information that has
        been so painstakingly  gathered.   An  external  HTTP  server  is  NOT
        required  NOR  supported.   The  ntop  web server is embedded into the
        application.  These parameters specify the port  (and  optionally  the
        address (i.e. interface)) of the ntop web server.

        For  example,  if  started with -w 3000 (the default port), the URL to
        access  ntop  is  http://hostname:3000/.   If  started  with  a   full
        specification,  e.g.  -w,  ntop listens on only that
        address/port combination.

        If -w is set  to  0  the  web  server  will  not  listen  for  http://

        -W  operates  similarly,  but  controls  the  port  for  the  https://

        Some examples:

        ntop -w 3000 -W 0 (this is the default setting) HTTP requests on  port
        3000 and no HTTPS.

        ntop  -w 80 -W 443 Both HTTP and HTTPS have been enabled on their most
        common ports.

        ntop -w 0 -W 443 HTTP disabled, HTTPS enabled on the common port.

        Certain sensitive, configuration pages of  the  ntop  web  server  are
        protected  by  a  userid/password.  By default, these are the user/URL
        administration,  filter,  shutdown  and  reset  stats   are   password
         and  are  accessible initially only to user admin with a password set
        during the first run of ntop.

        Users can modify/add/delete users/URLs using ntop  itself  -  see  the
        Admin tab.

        The  passwords,  userids and URLs to protect with passwords are stored
        in a database file.  Passwords are stored in an encrypted form in  the
        database  for further security.  Best practices call for securing that
        database so that only the ntop user can read it.

        There is a discussion in docs/FAQ  about  further  securing  the  ntop

       -z | --disable-sessions
        This  parameter  disables  TCP  session  tracking.   Use it for better
        performance or when you don’t really need/care to track sessions.

       -A | --set-admin-password
        This parameter is used to start ntop ,  set  the  admin  password  and
        quit. It is quite useful for installers that need to automatically set
        the password for the admin user.

        -A and --set-admin-password (without a value) will prompt the user for
        the password.

        You  may  also use this parameter to set a specific value using --set-
        admin-password=value.  The = is REQUIRED and no spaces are  permitted!

        If  you  attempt to run ntop as a daemon without setting a password, a
        FATAL ERROR message is generated and ntop stops.

       -B | --filter-expression
        Filters allows the user to restrict the traffic seen by ntop  on  just
        about any imaginable item.

        The filter expression is set at run time by this parameter, but it may
        be changed during the ntop run on the Admin | Change Filter web  page.

        The basic format is -B filter , where the quotes are REQUIRED

        The syntax of the filter expression uses the same BPF (Berkeley Packet
        Filter) expressions used by other packages such as tcpdump

        For  instance,  suppose  you  are  interested  only  in  the   traffic
        generated/received  by  the  host   ntop  can  then be
        started with the following filter:

        ntop -B src host or dst host

        or in shorthand:

        ntop -B host or host

        See the ’expression’  section  of  the  tcpdump  man  page  -  usually
        available  at  -  for further
        information  and  the  best  quick  guide  to  BPF  filters  currently

        WARNING: If you are using complex filter expressions, especially those
        with =s or meaningful spaces in them, be sure and use the long  option
        format, --filter-expression="xxxx" and not -B "xxxx".

       -C |
        This  instruments  ntop  to  be  used  in two configurations: host and
        network mode. In host mode (default)  ntop  works  as  usual:  the  IP
        addresses  received  are  those  of  real  hosts.  In host mode the IP
        addresses received are those of  the  C-class  network  to  which  the
        address  belongs.  Using ntop in network mode is extremely useful when
        installed in a traffic exchange (e.g. in the middle of  the  Internet)
        whereas  the  host  mode  should be used when ntop is installed on the
        edge  of  a  network  (e.g.  inside  a  company).  The  network   mode
        significantly  reduces  the  amount of work ntop has to perform and it
        has to be used whenever ntop is used  to  find  out  how  the  network
        traffic flows and not to pin-point specific hosts.

       -D | --domain
        This  identifies  the  local  domain suffix, e.g.  It may be
        necessary, if ntop  is  having  difficulty  determining  it  from  the

       -F | --flow-spec
        It  is  used  to  specify  network  flows  similar  to  more  powerful
        applications such as NeTraMet.  A flow is a stream of captured packets
        that match a specified rule. The format is

        <flow-label>=<matching          expression>[,<flow-label>=<matching

        , where the label is used to symbolically identify the flow  specified
        by  the  expression.  The expression is a bpf (Berkeley Packet Filter)
        expression. If  an  expression  is  specified,  then  the  information
        concerning  flows  can be accessed following the HTML link named ’List

        For  instance  define  two  flows  with   the   following   expression
        LucaHosts=host              or            host,GatewayRoutedPkts=gateway

        All   the   traffic   sent/received   by   hosts    or  is  collected  by  ntop  and added to the LucaHosts
        flow, whereas all the packet routed by  the  gateway
        are  added  to  the  GatewayRoutedPkts flow. If the flows list is very
        long you may store in a file (for instance flows.list) and specify the
        file name instead of the actual flows list (in the above example, this
        would be ’ntop -F flows.list’).

        Note that the double quotations around the entire flow expression  are

       -K | --enable-debug
        Use  this  parameter  to  simplify  application  debug.  It does three
        things: 1. Does not fork() on the "read only" html pages.  2. Displays
        mutex  values on the configuration (info.html) page.  3. (If available
        - glibc/gcc) Activates an automated backtrace on application errors.

       -L | --use-syslog=facility
        Use this parameter to send log messages to the system log  instead  of

        -L  and  the  simple  form  --use-syslog use the default log facility,
        defined as LOG_DAEMON in the #define symbol DEFAULT_SYSLOG_FACILITY in

        The  complex  form, --use-syslog=facility will set the log facility to
        whatever value (e.g. local3, security) you specify.  The = is REQUIRED
        and no spaces are allowed!

        This  setting  applies  both  to  ntop  and  to any child fork()ed for
        reporting.  If this parameter is not  specified,  any  fork()ed  child
        will  use  the  default value and will log it’s messages to the system
        log (this occurs because the fork()ed child must give up  it’s  access
        to the parents stdout).

        Because  various  systems do not make the permissible names available,
        we  have  a  table  at  the   end   of   globals-core.c.    Look   for

       -M | --no-interface-merge
        By  default, ntop merges the data collected from all of the interfaces
        (NICs) it is monitoring into a single set of counters.

        If you have a simple network, say a small LAN with a connection to the
        Internet, merging data is good as it gives you a better picture of the
        whole network.  For larger, more complex networks,  this  may  not  be
        desirable.   You  may  also  have other reasons for wishing to monitor
        each interface separately, for example DMZ vs. LAN traffic.

        This option instructs ntop not to merge network  interfaces  together.
        This  means  that  ntop will collect statistics for each interface and
        report them separately.

        Only ONE interface may be reported on at a time  -  use  the  Admin  |
        Switch  NIC  option  on  the  web  server to select which interface to
        report upon.

        Note that activating either the  netFlow  and/or  sFlow  plugins  will
        force the setting of -M.  Once enabled, you cannot go back.

       -N | --wwn-map
        This options names the file providing the map of WWN to FCID/VSAN ids.

       -O | --output-packet-path
        This  parameter  defines  the  base  path  for  the   ntop-suspicious-
        pkts.XXX.pcap and normal packet dump files.

        If  this parameter is not specified, the default value is the config.h
        parameter CFG_DBFILE_DIR, which is set  during  ./configure  from  the
        --localstatedir=  parameter.   If --localstatedir is not specified, it
        defaults to the --prefix value plus /var (e.g. /usr/local/var).

        Be aware that this may not be what you expect when running ntop  as  a
        daemon or Windows service. Setting an explicit and absolute path value
        is STRONGLY recommended if you use this facility.

       -P | --db-file-path

       -Q | --spool-file-path
        These parameters specify where ntop stores database files.

        There are two types, ’temporary’ - that is  ones  which  need  not  be
        retained  from  ntop  run  to ntop run, and ’permanent’, which must be
        retained (or recreated).

        The ’permanent’ databases are the preferences, "prefsCache.db" and the
        password  file, "ntop_pw.db".  These are stored in the -P | --db-file-
        path specified location.

        Certain plugins use the -P |  --db-file-path  specified  location  for
        their  database  ("LsWatch.db")  or  (as  a  default  value) for files

        The ’temporary’ databases are the  address  queue,  "addressQueue.db",
        the  cached  DNS resolutions, "dnsCache.db" and the MAC prefix (vendor
        table), "macPrefix.db".

        If only -P | --db-file-path is specified, it is used for both types of

        The  directories  named must allow read/write and file creation by the
        ntop user.  For security, nobody else should have even read access  to
        these files.

        Note  that the default value is the config.h parameter CFG_DBFILE_DIR.
        This is set during ./configure from  the  --localstatedir=  parameter.
        If --localstatedir is not specified, it defaults to the --prefix value
        plus /var (e.g. /usr/local/var).

        This may not be what you expect when  running  ntop  as  a  daemon  or
        Windows service.

        Note that on versions of ntop prior to 2.3, these parameters defaulted
        to "." (the current working directory, e.g.  the value returned by the
        pwd  command)  and  caused havoc as it was different when ntop was run
        from  the  command  line,  vs.  run  via  cron,  vs.   run   from   an
        initialization script.

        Setting an explicit and absolute path value is STRONGLY recommended.

       -U | --mapper
        Specifies the URL of the utility.

        If  provided,  ntop  creates  a clickable hyperlink on the ’Info about
        host xxxxxx’ page to this URL by appending ?host=xxxxx.  Any  type  of
        host  lookup  could  be  performed, but this is intended to lookup the
        geographical location of the host.

        A cgi-based mapper interface to is part of the
        ntop distribution [see www/Perl/]).

       -V | --version
        Prints ntop version information and then exits.

       -W | --https-server
        (See the joint documentation with the -w parameter, above)

        ntop sets completed sessions as ’timed out’ and then purge them almost
        instantly, which is  not  the  behavior  you  might  expect  from  the
        discussions  about purge timeouts.  This switch makes ntop respect the
        timeouts for completed sessions.  It is NOT the default because a busy
        web server may have 100s or 1000s of completed sessions and this would
        significantly increase the amount of memory ntop uses.

        ntop stores extra information about  the  locks  and  unlocks  of  the
        protective mutexes it uses. Since ntop uses fine-grained locking, this
        information is updated frequently.  On some  OSes,  the  system  calls
        used  to  collect  this  information (getpid() and gettimeofday()) are
        expensive.  This option disables the  extra  information.   It  should
        have no processing impact on ntop
         -   however   should  ntop  actually  deadlock,  we  would  lose  the
        information that sometimes tells us why.

        ntop uses sched_yield()  calls  for  better  interactive  performance.
        Under  some  situations,  primarily  under  RedHat Linux 8.0, this can
        deadlock, causing the ntop web server  to  stop  responding,  although
        ntop  appears to still be operational according to the ps command. Use
        this switch to disable these calls, IF you are seeing deadlocks.

        Return ntop to the old (v2.1) behavior on a memory error.  The default
        of  stopcap  enabled  makes  the  web  interface available albeit with
        static content until ntop is shutdown.


        Display only Fibre Channel statistics.


        You can run multiple instances of ntop  simultaneously  by  specifying
        different  -P values (typically through separate ntop.conf files).  If
        you set a value for this parameter  (available  only  on  the  command
        line),  you  (1) display the ’instance’ name on every web page and (2)
        alter the log prefix from "NTOP" to your chosen value.

        If you want to make the tag more obvious, create a .instance class  in
        style.css, e.g.:

           .instance {
             color: #666666;
             font-size: 18pt;

        Note  (UNIX): To run completely different versions of the ntop binary,
        you need to compile  and  install  into  a  different  library  (using
        ./configure  --prefix)  and  then  specify  the LD_LIBRARY_PATH before
        invoking, e.g.

        LD_LIBRARY_PATH=/devel/lib/ntop/:... /devel/bin/ntop ...args...

        If present, a file of the form <instance>_ntop_logo.gif will  be  used
        instead of the normal ntop_logo.gif.  This is tested for ONLY once, at
        the beginning of the run.  The EXACT word(s) of  the  --instance  flag
        are  used,  without testing if they make a proper file name.  If - for
        any reason - the file is not found, an informational message is logged
        and the normal logo file is used.  To construct your own logo, make it
        a 300x40 transparent gif.

        NOTE: On the web pages, ntop uses the dladdr() function.  The original
        Solaris  routine  had a bug, replicated in FreeBSD (and possibly other
        places) where it uses the ARGV[0] value - which might be  erroneous  -
        instead  of  the  actual file name.  If the ’running from’ value looks
        bogus but the ’libraries in’ value looks OK, go with the library.


        Disable processing & Display of Fibre Channel


        Don’t display Invalid LUN information.



        P3P  is  a  W3C  recommendation  -  -   for
        specifying  personal information a site collects and what it does with
        the information.  These parameters allow to  return  P3P  information.
        We do not supply samples.

        On some platforms, the ntop web server will hang or appear to hang (it
        actually just responds incredibly slowly to the first request  from  a
        browser session), while the rest of ntop runs just fine. This is known
        to be an issue under FreeBSD 4.x.

        This option sets the non-blocking option (assuming it’s  available  in
        the version of libpcap that is installed).

        While  this  works  around the problem (by turning an interrupt driven
        process into a poll), it also MAY significantly increase the CPU usage
        of  ntop.   Although  it  does not actually interfere with other work,
        seeing ntop use 80-90% or more of the cpu is not uncommon - don’t  say
        we didn’t warn you.

        THIS OPTION IS OFFICIALLY UNSUPPORTED and used at your own risk.  Read
        the docs/FAQ write-up.

        By default, ntop accesses a remote file to periodically check  if  the
        most  current  version  is  running.  This option disables that check.
        Please review the privacy notice at the bottom of this page  for  more
        information.   By default, the recheck period is slightly more than 15
        days.  This can be adjusted via a constant in  globals-defines.h.   If
        the  result  of the initial check indicates that the ntop version is a
        ’new development’ version (that is newer  than  the  latest  published
        development  version), the recheck is disabled.  This is because which
        fixes and enhancements were present/absent from the code.

        NOTE: At present, the recheck does not work under Windows.


        Enable a watchdog for  webserver  hangs.  These  usually  happen  when
        connecting  with  older browsers. The user gets nothing back and other
        users can’t connect. Internally, packet processing continues but there
        is  no  way to access the data through the web server or shutdown ntop
        cleanly.  With the watchdog, a timeout occurs  after  3  seconds,  and
        processing  continues with a log message. Unfortunately, the user sees
        nothing - it just looks like a failed connection. (also available as a
        ./configure option, --enable-sslwatchdog)

        By  default, ntop generates displayable but not great html.  There are
        a number of tags we do not generate because they cause  problems  with
        older  browsers which are still commonly used or are important to look
        good on  real-world  browsers.   This  flag  tells  ntop  to  generate
        ’BETTER’  (but not perfect) w3c compliant html 4.01 output. This in no
        way addresses all of the compatibility and markup issues.  Over  time,
        we would like to make ntop more compatible, but it will never be 100%.
        If you find any issues, please report them to ntop-dev.

       -4 | --ipv4
        Use IPv4 connections.

       -6 | --ipv6
        Use IPv6 connections


       While  ntop  is  running,  multiple  users  can  access   the   traffic
       information  using  their web browsers.  ntop does not generate ’fancy’
       or ’complex’ html, although it does use frames, shallowly nested tables
       and makes some use of JavaScript and Cascading Style Sheets.

       Beginning  with  release  3.1,  the  menus  are cascading dropdowns via
       JSCookMenu.  With release 3.2, this extends to plugins.

       We do not expect problems with any current web browser, but our ability
       to  test  with  less common ones is very limited.  Testing has included
       Firefox and Internet Explorer,  with  very  limited  testing  on  other
       current common browsers such as Opera.

       In  documentation  and  this  man page, when we refer to a page such as
       Admin | Switch NIC, we mean the Broad category "Admin" and the detailed
       item "Switch NIC" on that Admin menu.


       ntop  requires  a  number  of  external tools and libraries to operate.
       Certain  other  tools  are  optional,  but   add   to   the   program’s

        Specifies  the  maximum  number  of web server requests for the tcp/ip
        stack to retain in it’s  queue  awaiting  delivery  to  the  ntop  web
        server.  Requests in excess of this queue may be dropped (allowing for
        retransmission) or rejected at the tcp/ip stack level, depending  upon
        the  OS.   Whatever  happens,  happens  at  the  OS level, without any
        information being delivered to ntop

        Required libraries include:

        libpcap from, version 0.7.2 or newer. 0.8.3 or
        newer is strongly recommended.

        The  Windows  version makes use of WinPcap (libpcap for Windows) which
        may be downloaded from

        WARNING: The 2.x releases of WinPcap will NOT support SMP machines.

        gdbm from

        ntop requires a POSIX threads library. As of  ntop  3.2,  the  single-
        threaded version of ntop is no longer available.

        The  gd  2.x  library,  for  the  creation  of png files, available at

        The libpng 1.2.x library, for the creation of png files, available  at

        ntop  should  support  both gd 1.X and libpng 1.0.x libraries but this
        has not been tested.  Note that there  are  incompatibilities  if  you
        compile  with  one  version  of  these libraries and then run with the
        other.  Please read the discussion in docs/FAQ  before  reporting  ANY
        problems of this nature.

        (if  an  https://  server is desired) openSSL from the OpenSSL project
        available at

        The rrdtool library is required by the rrd  plugin.   rrdtool  creates
        ’Round-Robin  databases’  which are used to store and graph historical
        data in a format that permits long duration retention without  growing
        larger     over     time.      The     rrdtool     home     page    is

        ntop includes a limited  version  of  rrdtool  1.0.49  in  the  myrrd/
        directory.   Users of ntop 3.2 should not need to specifically install

        The sflow Plugin is courtesy of and supported  by  InMon  Corporation,

        There are other optional libraries.  See the output of ./configure for
        a fuller listing.

        Tool locations are current as of August 2005 - please  send  email  to
        report new locations or dead links.


       top(1), tcpdump(8).  pcap(3).


       By  default at startup and at periodic intervals, the ntop program will
       retrieve a file containing current ntop  program  version  information.
       Retrieving  this  file  allows this ntop instance to confirm that it is
       running the most current version.

       The retrieval is done  using  standard  http://  requests,  which  will
       create log records on the hosting system.  These log records do contain
       information which identifies a specific ntop  site.   Accordingly,  you
       are  being  notified that this individually identifiable information is
       being transmitted and recorded.

       You may request - via the --skip-version-check run-time option  -  that
       this  check  be  eliminated.   If  you use this option, no individually
       identifiable information is transmitted or recorded, because the entire
       retrieval and check is skipped.

       We  ask you to allow this retrieval and check, because it benefits both
       you and the ntop developers.  It  benefits  you  because  you  will  be
       automatically notified if the ntop program version is obsolete, becomes
       unsupported or is no longer current.  It  benefits  the  developers  of
       ntop  because  it  allows  us  to  determine  the number of active ntop
       instances, and the operating system/versions  that  users  are  running
       ntop  under.   This allows us to focus development resources on systems
       like those our users are using ntop on.

       The individually identifiable  information  is  contained  in  the  web
       server  log  records  which  are  automatically  created  each time the
       version file is retrieved.  This is a function of the  web  server  and
       not of ntop , but we do take advantage of it.  The log record shows the
       IP address of the requestor (the ntop instance) and a User-Agent header
       field.  We place information in the User-Agent header as follows:

           host/<name from config.guess>
           distro/<if one>
           release/<of the distro, also if one>
           kernrlse/<kernel version or release>
           config() <condensed parameters from ./configure>
           run()    <condensed flags - no data - from the execution line>
           access/<http, https, both or none>
           interfaces() <given interface names>

       For example:

           ntop/2.2.98    host/i686-pc-linux-gnu    distro/redhat    release/9
           GCC/3.2.2  config(i18n)  run(i;  u;   P;   w;   t;   logextra;   m;
           schedyield; d; usesyslog=; t) gdbm/1.8.0 openssl/0.9.7a zlib/1.1.4
           access/http interfaces(eth0,eth1)

       Distro  and  release  information  is  determined  at  compile time and
       consists  of  information  typically  found  in  the  /etc/release  (or
       similar)  file.  See  the  ntop  tool  linuxrelease  for  how  this  is

       gcc compiler version (if available) is the internal version #s for  the
       gcc compiler, e.g. 3.2.3.

       kernrlse  is  the  Linux  Kernel  version or the xBSD ’release’ such as
       4.9-RELEASE and is determined from the uname data (if it’s  available).

       The ./configure parameters are stripped of directory paths, leading -s,
       etc. to create a short form that shows us what  ./configure  parameters
       people are using.

       Similarly, the run time parameters are stripped of data and paths, just
       showing which flags are being used.

       The libpcap, gdbm, openssl and zlib  versions  come  from  the  strings
       returned by the various inquiry functions (if they’re available).

       Here’s a sample log record:  -  -  [28/Dec/2003:12:11:46  -0500]  "GET  /version.xml
         200 1568 "-"  "ntop/2.2.98  host/i686-pc-linux-
         distro/redhat release/9 kernrlse/2.4.20-8smp GCC/3.2.2 config(i18n)
         run(i; u; P; w; t; logextra; m; instantsessionpurge; schedyield; d;
         usesyslog=)    libpcap/0.8   gdbm/1.8.0   openssl/0.9.7a   zlib/1.1.4
         interfaces(eth0,eth1,eth2)" "-"


       Please send bug reports to  the  ntop-dev  <>  mailing
       list. The ntop <> mailing list is used for discussing ntop
       usage issues.  In  order  to  post  messages  on  the  lists  a  (free)
       subscription is required to limit/avoid spam. Please do NOT contact the
       author directly unless this is a personal question.

       Commercial support is available upon request. Please see the ntop  site
       for further info.

       Please send code patches to <>.


       ntop’s  author  is Luca Deri ( who can be reached
       at <>.


       ntop is distributed under the GNU GPL licence (


       The author acknowledges the Centro Serra of  the  University  of  Pisa,
       Italy ( for hosting the ntop sites (both web
       and mailing lists), and Burton Strauss <> for his
       help    and    user   assistance.   Many   thanks   to   Stefano   Suin
       <> and Rocco Carbone <> for  contributing
       to the project.

                            August 2005 (ntop 3.2)