6
6
<meta http-equiv="Window-target" content="_top">
7
7
<meta name="description" content="ntop (http://www.ntop.org) FAQ file.">
8
8
<meta name="author" content="ntop">
9
<meta name="generator" content="ntop 3.0">
10
<link rel="stylesheet" type="text/css" href="style.css">
11
<title>ntop FAQ</title>
9
<meta name="generator" content="ntop 3.3">
10
<title>ntop FAQ</title>
11
<script SRC="/functions.js" TYPE="text/javascript" LANGUAGE="javascript"></script>
12
<link rel="stylesheet" href="/style.css" TYPE="text/css">
13
<!--#include virtual="/menuHead.html" -->
13
<body background="white_bg.gif">
15
<body link="blue" vlink="blue">
16
<!--#include virtual="/menuBody.html" -->
15
18
<p>This is an unsophisticated, automated conversion of the source file, docs/FAQ into html.
16
19
Please report problems to the ntop-dev mailing list.
17
20
But remember, it's not about making it look good, it's about making the content available.</p>
23
Where can I find ntop?
27
The official website can be found at http://www.ntop.org/.
32
Where do I get the source?
36
SourceForge -- http://sourceforge.net/projects/ntop/
39
There is also a cvs (current development) maintained at cvs.ntop.org.
23
<h2>TOP 10 - the questions everyone asks...</h2>
25
<p><b>Q0.</b> I downloaded the source and ./configure doesn't work.</p>
26
<p><b>A.</b> Yup.</p>
27
<p> There is a long history of warfare between the versions of the GNU
28
autotools we use to build the distribution files and the ones installed
29
on your host. So during the 3.3 development cycle, Luca finally gave in
30
and stopped distributing a generated configure file.
32
<p> Instead there is a script, autogen.sh, which uses the version(s) of the
33
tools installed on your system to create configure and then run it.
35
<p> Yes, this means you MUST have the following tools installed:
44
<p> We are talking only about people who are compiling from source. Those
45
tools are pretty much required for ANY source. Live with it.
48
<p><b>Q1(a).</b> Can I store data in a SQL database?</p>
50
<p><b>Q1(b).</b> When ntop stops I lose all my data. Why?</p>
52
<p><b>Q1(c).</b> Why doesn't the -S option work?</p>
53
<p><b>A.</b> ntop used to optionally store some data in a SQL database. The code was broken, difficult to maintain, etc. and was removed. A LONG TIME AGO.
54
If you are reading about this in 'some' documentation - update.
56
<p> Current ntop is 3.1, which is the only version we support.
58
<p> There are scripts that various users have offered to take the data dump
59
and insert it into a SQL database. Search the back traffic on the mailing
62
<p> Yes, ntop uses memory based structures to hold usage data and they are lost
63
when you reset or restart ntop.
65
<p> Persistent storage is in the RRD databases - there's a paper @ SourceForge
68
<p> There was another option for some persistence - it was -S - look in FAQarchive
69
for an article about it, "What was the -S option?".
72
<p><b>Q2.</b> The archive isn't indexed, so I can't search it.</p>
73
<p><b>A.</b> Yes, but it's easy to search using search engines or mail archives.</p>
74
<p> Google: You need to restrict the search to the U of Pisa mail list
79
site:listgateway.unipi.it ntop freebsd
81
<p> Two 'mail archive' sites that I know of (as of March 2005) are:
83
<p> gmane: http://search.gmane.org (our lists are renamed as gmane.linux.ntop.general
84
and gmane.linux.ntop.devel).
90
http://www.mail-archive.com/ntop-dev@unipi.it/
91
http://www.mail-archive.com/ntop@unipi.it/
94
<p><b>Q3.</b> ntop crashed and the last log message is "xxxxx".</p>
95
<p><b>A.</b> Sorry, that's useless. ntop is multi-threaded and processes 100s or 1000s of packets per second. The last log message is probably from the wrong thread
96
and many seconds out of date.
98
<p> To capture the true 'failure point information', you need to run under the
99
debugger (gdb) and send us the various outputs. Instructions are at the bottom
100
of this document. Look for "GDB ultraMini-tutorial".
102
<p> Yes, you will need the source and a compiler.
105
<p><b>Q3(a).</b> What about the backtrace?</p>
106
<p><b>A.</b> Again, probably useless. Use gdb and capture the full failure point info. If you want to see more, look for "Q. What about the backtrace?" below.
109
<p><b>Q4.</b> I'm running out of memory.</p>
110
<p><b>A.</b> Basically ntop uses a lot of memory - it stores a chunk of information about each and every host it's monitoring. See "Q. Why does ntop use so much memory ?" and
111
the following articles below.
114
<p><b>Q5.</b> Dropped packets?</p>
115
<p><b>A.</b> There are lots of reasons - look for "Q. Why does ntop drop packets?" below. Short version, is that as long as it's random, the information you glean from ntop
116
(32% of our usage is P2P Music) is still valid. But you are probably understating
120
<p><b>Q6.</b> The docs at ntop.org say ...</p>
121
<p><b>A.</b> Stop right there. They're out of date (notice, for example, the man page is July 2002?).
123
<p> The only current stuff is this FAQ (which gets out of date quickly) the other files
124
in the distribution and the mailing lists.
126
<p> You can access the updated FAQ from docs/FAQ in the cvs or from your ntop instance
127
(click on the (?) icon in the "About" menu and read down 1/2 a page or so.
130
<p><b>Q7.</b> How do I report a problem?</p>
131
<p><b>A.</b> Best way is to use the PR (Problem Report) form - it automatically includes a lot of the important information about your ntop instance. In the "About" menu, click on the
132
"Bug" icon. This generates a text form you can copy into your email program, update
136
<p><b>Q8.</b> HACK ALERT HACK ALERT - ntop is sending information to some machine called "jake".</p>
137
<p><b>A.</b> Chill. Take a deep breath.</p>
138
<p> Jake is the cannonical name for version.ntop.org. All you are seeing is the version
139
check. See "Q. What's with the version check?" below.
142
<p><b>Q9.</b> The program asks for password for "ntop HTTP server". When I started NTOP for the first time, it asked me to set admin password, and i put "xxxxxxxx". The user is "xxxxxxxxxx"
143
but I get "Unauthorized to access the document". Why?
145
<p><b>A.</b> The correct user to specify for the ntop web server is admin. The -u value in the command line or parameter file is the account ntop runs under.
148
<p><b>Q10.</b> I'm not getting any rrd output.</p>
149
<p><b>A.</b> First, make sure that the plugin is installed (you should see it in the web interface under plugins). Make sure it is configured and active.
151
<p> The default configuration does NOT include per-host .rrd files, because these can take
152
up a lot of space. But you probably want them and at the medium or high level of detail.
155
<p><b>Q11.</b> Single Threaded ntop?</p>
156
<p><b>A.</b> Gone. Poof. We're in a multi-threaded world, so live with it.</p>
158
<p><b>Q.</b> Where can I find ntop?</p>
159
<p><b>A.</b> The official website can be found at http://www.ntop.org/.</p>
161
<p><b>Q.</b> Where do I get the source?</p>
162
<p><b>A.</b> SourceForge -- http://sourceforge.net/projects/ntop/</p>
163
<p> There is also a cvs (current development) maintained at cvs.ntop.org.
40
164
(instructions are on the download page of www.ntop.org)
44
DO NOT (under ANY circumstances) USE THE SOURCE FILES FROM
45
http://snapshot.ntop.org!!!!! They are broken, incomplete and
46
WILL NOT WORK. (See 'snapshot, cvs and the Wiki' below)
55
ntop is an open source network top - it monitors a network and collects
56
information about the protocols and hosts for display.
61
Um, so it's like mrtg (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/)?
68
Yes in that both are analyzers of network packets.
71
Yes in that both display information about your network.
74
No in that they take very different approaches to collecting information.
77
No in that they display different types of information.
86
mrtg creates a picture of the network centered on the device on the link
87
between devices (and aggregations of devices and links).
90
Tobias (Tobi) Oetiker describe mrtg as:
167
<p><b>Q.</b> What is ntop?</p>
168
<p><b>A.</b> ntop is an open source network top - it monitors a network and collects information about the protocols and hosts for display.
171
<p><b>Q.</b> Um, so it's like mrtg (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/)?</p>
172
<p><b>A.</b> Yes and no...</p>
173
<p> Yes in that both are analyzers of network packets.
175
<p> Yes in that both display information about your network.
177
<p> No in that they take very different approaches to collecting information.
179
<p> No in that they display different types of information.
182
<p><b>Q.</b> So mrtg...</p>
183
<p><b>A.</b> mrtg creates a picture of the network centered on the device on the link between devices (and aggregations of devices and links).
185
<p> Tobias (Tobi) Oetiker describe mrtg as:
204
262
available for ntop. An ISP using ntop to monitor a couple of T3s needs a
205
263
FAST computer and A LOT of memory.
208
ntop also requires access to the physical network (either directly via a
265
<p> ntop also requires access to the physical network (either directly via a
209
266
network card or indirectly via a netFlow/sFlow probe). This limits ntop's
210
267
(usefullness|ability) to work across sites.
213
Once you learn what they do (mrtg and ntop), you'll probably discover that
269
<p> Once you learn what they do (mrtg and ntop), you'll probably discover that
219
What's this 'layer' crud?
223
Network layers come from a widely cited but never implemented model, the OSI
224
(Open System Interconnect ) networking model from the ISO (International
273
<p><b>Q.</b> What's this 'layer' crud?</p>
274
<p><b>A.</b> Network layers come from a widely cited but never implemented model, the OSI (Open System Interconnect ) networking model from the ISO (International
225
275
Standards Organization).
228
Google for it - for example
277
<p> Google for it - for example
231
280
http://www.ussg.iu.edu/usail/network/nfs/network_layers.html
236
So ntop is like netFlow (Cisco), sFlow (RFC 3176, http://www.sflow.org) or
241
Not really, actually those are all protocols for sending and receiving
242
information about the network.
245
ntop has lots in common with the tools that USE those protocols.
248
And there are lots of tools - some proprietary, many open source.
251
The devices/programs that collect the information and send it out in netFlow,
283
<p><b>Q.</b> So ntop is like netFlow (Cisco), sFlow (RFC 3176, http://www.sflow.org) or RMON (HP)?
285
<p><b>A.</b> Not really, actually those are all protocols for sending and receiving information about the network.
287
<p> ntop has lots in common with the tools that USE those protocols.
289
<p> And there are lots of tools - some proprietary, many open source.
291
<p> The devices/programs that collect the information and send it out in netFlow,
252
292
sFlow or RMON format are usually called (by me) 'probes'. The devices and/or
253
293
programs that receive the netFlow, sFlow or RMON formatted information and do
254
294
things with it are called 'collectors' (if they process it and forward it on)
255
295
or called 'displays'.
258
In fact, ntop can receive netFlow packets and both send and receive sFlow
297
<p> In fact, ntop can receive netFlow packets and both send and receive sFlow
259
298
packets. It can be a 'probe' or a 'display'. (ntop used to be able to send
260
299
netFlow packets - that was removed 2004-03 by Luca).
265
So ntop is like Nagios or Ipswitch's - WhatsUp Gold?.
269
Nope - those are layer 4 and higher (application) monitoring programs.
302
<p><b>Q.</b> So ntop is like Nagios or Ipswitch's - WhatsUp Gold?.</p>
303
<p><b>A.</b> Nope - those are layer 4 and higher (application) monitoring programs.</p>
278
Enough already - if you search Freshmeat.net,
279
http://freshmeat.net/search/?q=network+monitor§ion=projects
305
<p><b>Q.</b> So it's like ...</p>
306
<p><b>A.</b> Enough already - if you search Freshmeat.net, http://freshmeat.net/search/?q=network+monitor§ion=projects
280
307
you will find (as of 18Aug2003):
284
311
Topic :: System :: Networking :: Monitoring (654 projects)
287
We'll be here all day. ntop is ntop.
313
<p> We'll be here all day. ntop is ntop.
292
Ok, so ntop is a unique TCP/IP analyzer.
299
First off, ntop pretty much doesn't care about the lowest (layer 1 or wire)
316
<p><b>Q.</b> Ok, so ntop is a unique TCP/IP analyzer.</p>
317
<p><b>A.</b> Not exactly.</p>
318
<p> First off, ntop pretty much doesn't care about the lowest (layer 1 or wire)
300
319
layer. It leaves dealing with that to a library, libpcap, which hides most
304
ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer
322
<p> ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer
305
323
(layer 2) nor a pure TCP/IP analyzer (layer 3).
308
ntop gets the data at the layer 2 (frame) level, which could be Ethernet
325
<p> ntop gets the data at the layer 2 (frame) level, which could be Ethernet
309
326
or another protocol. Beyond Ethernet, ntop has minimal smarts about FDDI,
310
327
PPP, RAW and TOKEN-RING frames. That is, at least enough for some basic
311
328
counts or to extract the (layer 3) TCP/IP data in side.
314
ntop 3.0 adds TWO (three?) HUGE areas of new protocol support.
330
<p> ntop 3.0 adds TWO (three?) HUGE areas of new protocol support.
317
ntop 3.0 supports IPv6, thanks to code contributed by Olivier Festor
332
<p> ntop 3.0 supports IPv6, thanks to code contributed by Olivier Festor
318
333
<Olivier.Festor@loria.fr> and Abdelkader Lahmadi <Abdelkader.Lahmadi@loria.fr>
319
334
of the MADYNES Research Time (Managing DYnamic NEtworks and Services), see
320
335
http://madynes.loria.fr/.
323
ntop 3.0 has more than a fair amount of smarts about FibreChannel and SCSI
337
<p> ntop 3.0 has more than a fair amount of smarts about FibreChannel and SCSI
324
338
thanks to code contributed by Dinesh G Dutt <ddutt@cisco.com> of Cisco.
327
However, since most of ntop's displayed counts are at the TCP/IP level, it
340
<p> However, since most of ntop's displayed counts are at the TCP/IP level, it
328
341
confuses people into thinking ntop is purely a TCP/IP analyzer.
331
ntop is a traffic monitor with it's own network interfaces, which monitors
343
<p> ntop is a traffic monitor with it's own network interfaces, which monitors
332
344
what it sees (or is told about through netFlow or sFlow probes).
341
ntop is known to work under Linux, Mac OS X, FreeBSD, OpenBSD (3.4, nothing
342
earlier) NetBSD (with issues) and Win32.
345
ntop development is done primarily on RedHat Linux and Mac OS.
348
Luca also does a port to Win32 (MS Visual C++) and works in the Sun
352
I (Burton) usually work under RedHat Linux, but have a multi-boot system
353
for testing that runs various Linux distros, FreeBSD (4.9 and 5.2),
354
NetBSD, Solaris 8 i86 and OpenBSD.
357
During the ntop 3.0 development cycle, we did some development and
358
testing on various platforms. Here's data from the version.xml log
359
showing what people were running while testing 2.2.98 and 2.2.99:
364
------- ------- --------------
366
90 Windows WinNT/2K/XP
375
and <5 records for FreeBSD 4.6.2, 4.8, 5.0, 5.2.1; OpenBSD 3.4;
383
Solaris 8 / 9 work, 2.6 and 7 probably would...
384
FreeBSD 4.6.2/4.8/4.9 and 5.1/5.2
388
NetBSD doesn't seem to have been tested.
391
Lots of Different Linuxes... of the ones we recognize:
396
------- --------- --------
402
15 debian (probably 3.0)
414
and < 5 records for arch 0.6; aurora 1.0; aurox 9.2; fedora 0.95;
415
gentoo 1.4.2.9, 1.4.3.10 and 1.4.3.12; immunix 7.0; mandrake 8.1 and 8.2;
416
pld 1.1; redhat 1, 2.1, 6.2, 7.0, 7.1; slackware 7.1.0, 8.1 and 9.0-beta;
417
suse 6.3, 7.0, 8.0 and 8.1; and yellowdog 3.0.
421
Running under pretty much any *nix is at least theoretically possible.
422
But it takes interested party/parties and access to resources - some of the
423
things that ntop does such as libpcap and loading plugins are tied tighter
424
to the OS than you might like.
428
There are sections below about each specific OS.
347
<p><b>Q.</b> ntop runs under?</p>
348
<p><b>A.</b> ntop is known to work under Linux, Mac OS X, FreeBSD, Solaris and Win32.</p>
349
<p> ntop development is done primarily on Fedora Linux.
351
<p> Luca also does a port to Win32 (MS Visual C .Net) and used to work in the Sun
352
Solaris environment. He also seems to work with FreeBSD 5.4.
354
<p> I (Burton) usually work under Fedora Linux, but use Microsoft's VPC 2004 and
355
VMware Workstation 5 to test under other Linux distros and OSes.
357
<p> Our users run under many other platforms - Here's data from the version.xml log
358
records showing what people were running while testing 3.2:
360
<p> (This data covered approximately the first two weeks of July 2005)
375
------- ------- --------------
377
3566 Windows WinNT/2K/XP
378
1752 Unknown Windowsv3.1
379
1018 Unknown Windowsv3.0
384
<p> Of course, this is self-selected - people can turn off the logging.
386
<p> Linux covers lots of Different Linuxes... of the ones we recognize:
391
------- --------- --------
410
<p> The jump in 'SuSE' may represent nothing more than improved detection
411
in the 3.2/3.1 scripts vs. 3.0. We used to have a huge 'unknown' count.
415
Running under pretty much any *nix is at least theoretically possible.
416
But it takes interested party/parties and access to resources - some of the
417
things that ntop does such as libpcap and loading plugins are tied tighter
418
to the OS than you might like.
422
There are sections below about each specific OS.
430
424
<h2>Features</h2>
434
What determines the features of ntop?
438
<laugh>Whatever Luca wants</laugh>
426
<p><b>Q.</b> What determines the features of ntop?</p>
427
<p><b>A.</b> <laugh>Whatever Luca wants</laugh></p>
443
Why did you do this "x" instead of feature "y"?
447
Don't know. I could guess...
450
Imagine you are the network manager for a large University network and have
429
<p><b>Q.</b> Why did you do this "x" instead of feature "y"?</p>
430
<p><b>A.</b> Don't know. I could guess...</p>
431
<p> Imagine you are the network manager for a large University network and have
451
432
to crack down on users who are illegally exchanging copyrighted files or
452
433
using University resources to run a business without paying for the resources
459
You are a major vendor of infrastructure, whose customers are using networks
438
<p> You are a major vendor of infrastructure, whose customers are using networks
460
439
for new features such as storage area networks and you want to give them
461
440
the ability to monitor these.
467
You have a really cool technology that you've just donated to the community
444
<p> You have a really cool technology that you've just donated to the community
468
445
via an RFC and wish to jump-start adoption of it.
474
You are moving heavily into IPv6 and need to be able to monitor your 'new'
449
<p> You are moving heavily into IPv6 and need to be able to monitor your 'new'
475
450
network just like you monitored the IPv4 one.
481
You really, really, really hate that ntop generates such lousy html code
454
<p> You really, really, really hate that ntop generates such lousy html code
482
455
and you decide to scratch that itch.
485
or (what should happen)
457
<p> or (what should happen)
488
A major corporation, with out resources, time, skills and/or inclination
459
<p> A major corporation, with out resources, time, skills and/or inclination
489
460
to do it themselves sponsors the development of a feature that's critical
496
Then again, it could just be because it's cool...
505
Probably - as long as it doesn't move the tool away from it's purpose and
506
it's strengths, almost anything is possible - especially as a plugin.
515
Maybe - if it's of interest to a developer, or you provide the code such
516
that it can be merged in, or if you're willing to sponsor the development
465
<p> Then again, it could just be because it's cool...
468
<p><b>Q.</b> Could ntop do "x"</p>
469
<p><b>A.</b> Probably - as long as it doesn't move the tool away from it's purpose and it's strengths, almost anything is possible - especially as a plugin.
472
<p><b>Q.</b> Will you do "x"</p>
473
<p><b>A.</b> Maybe - if it's of interest to a developer, or you provide the code such that it can be merged in, or if you're willing to sponsor the development
517
474
effort (contact us through http://www.ntop.org/consultancy.html).
519
476
<h2>Documentation</h2>
523
Why isn't there (any)(more)(better) documentation.
527
(A personal peeve from Burton...)
530
I get real tired of people complaining that there isn't any documentation
478
<p><b>Q.</b> Why isn't there (any)(more)(better) documentation.</p>
479
<p><b>A.</b> (A personal peeve from Burton...)</p>
480
<p> I get real tired of people complaining that there isn't any documentation
531
481
and then being unwilling to contribute even the simplest stuff. I've said
532
482
I'll edit and assemble whatever people send me... and since I started working
533
483
with ntop in November 2001, I've received maybe six pages of stuff.
536
I'm trying to get people - who aren't coders - to contribute to ntop the
485
<p> I'm trying to get people - who aren't coders - to contribute to ntop the
537
486
project. The contribution that ANYONE can make is "documentation". A task-
538
487
specific HOWTO... some sample screen shots... An FAQ entry...
541
I've tried being nice.
489
<p> I've tried being nice.
542
490
I've tried asking.
543
491
I've tried shaming people into it.
546
What have I gotten? Zip.
493
<p> What have I gotten? Zip.
549
Nasty is all that's left... This is your fair warning. If you show up on
495
<p> Nasty is all that's left... This is your fair warning. If you show up on
550
496
the ntop mailing lists and complain about documentation, you will get
559
Ok, where can I find what does exist.
563
http://www.ntop.org has pointers and some (dated) documents.
566
The documentation in the docs/ directory, the Documentation files at SourceForge
502
<p><b>Q.</b> Ok, where can I find what does exist.</p>
503
<p><b>A.</b> http://www.ntop.org has pointers and some (very out-dated) documents.</p>
504
<p> The documentation in the docs/ directory, the Documentation files at SourceForge
567
505
and some at http://www.ntopsupport.com are basically all that there is.
570
Search the ntop mailing lists at gmane, http://search.gmane.org. The lists
507
<p> Search the ntop mailing lists at gmane, http://search.gmane.org. The lists
571
508
are called gmane.linux.ntop.general and gmane.linux.ntop.devel.
574
Please contribute to the ntop community by writing things up for inclusion
510
<p> Please contribute to the ntop community by writing things up for inclusion
575
511
in this FAQ or other documents!
578
You can even do this all by yourself at the ntop Wiki,
579
http://www.burtonstrauss.com/pmwiki/pmwiki.php?pagename=Ntop.HomePage
580
(But note that whether it remains available depends on whether people
586
I can't find a file at SourceForge!
590
You can reach the archives through any SourceForge mirror, e.g.
514
<p><b>Q.</b> I can't find a file at SourceForge!</p>
515
<p><b>A.</b> You can reach the archives through any SourceForge mirror, or the main site:</p>
594
http://telia.dl.sourceforge.net/sourceforge/ntop/
595
^^^^^ change that qualifier to one that's close to you.
518
http://prdownloads.sourceforge.net/n/nt/ntop
598
It has ALL the files unless we explicitly delete them...
520
<p> It has ALL the files unless we explicitly delete them...
600
522
<h2>Problems</h2>
608
Make sure it's a supported release!
611
We support only the current versions of ntop. This is either:
524
<p><b>Q.</b> I have a problem...</p>
525
<p><b>A.</b> Make sure it's a supported release!</p>
526
<p> We support only the current versions of ntop. This is either:
615
* the last release, e.g. v3.0.
530
* the last release, e.g. v3.1.
616
531
* the current cvs (cvs.ntop.org)
617
532
* the latest development version posted at SourceForge (if one)
620
If you use a port/package and the latest version available for your
534
<p> If you use a port/package and the latest version available for your
621
535
OS is some release candidate from a year ago, sorry. Contact the
622
536
packager and ask them to get current.
625
Luca usually asks people to try the latest cvs (development) version
538
<p> Luca usually asks people to try the latest cvs (development) version
626
539
because problems are frequently already fixed in there.
631
I'm running something supported and I've tried the latest & greatest.
632
Still, I have a problem.
636
Read the ntop mailing lists.
639
The ntop mailing lists are at
542
<p><b>Q.</b> I'm running something supported and I've tried the latest & greatest. Still, I have a problem.
544
<p><b>A.</b> Read the ntop mailing lists.</p>
545
<p> The ntop mailing lists are at
642
548
http://listgateway.unipi.it/mailman/listinfo/ntop
644
549
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
551
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
647
If you're having non-user problems OR you are using the cvs, you should be
553
<p> If you're having non-user problems OR you are using the cvs, you should be
648
554
reading and posting ntop-dev (for example, the cvs commit messages are posted
555
there). Stuff unrelated to baseline ntop (PF_RING) belongs in ntop-misc.
652
You can read the lists through gmane (or other gateways) if you don't
557
<p> You can read the lists through gmane (or other gateways) if you don't
653
558
want to subscribe, but only subscribers can post.
656
You can download the older messages in large chunks from the mailing list
560
<p> You can download the older messages in large chunks from the mailing list
657
561
subscription pages. Look for "To see the collection of prior postings to
663
I looked and I didn't find my problem.
667
Join the mailing list(s) and ask for help.
670
Before you post, check the "HowTo Ask for Help" at the end of this FAQ.
673
Please, if at all possible, use the built in PR_ form (the little 'bug' icon
565
<p><b>Q.</b> I looked and I didn't find my problem.</p>
566
<p><b>A.</b> Join the mailing list(s) and ask for help.</p>
567
<p> Before you post, check the "HowTo Ask for Help" at the end of this FAQ.
569
<p> Please, if at all possible, use the built in PR_ form (the little 'bug' icon
674
570
on the 'About' tab).
677
Guidelines for asking questions:
681
ONE and only ONE problem / issue / question per message.
685
With a meaningful subject.
572
<p> Guidelines for asking questions:
574
<p> ONE and only ONE problem / issue / question per message.
576
<p> With a meaningful subject.
689
580
The goal is that if you're asking a common question, the
690
581
subject would have allowed you to find it in the back
691
582
traffic for the mailing list.
695
Post the information about your environment we ask for.
584
<p> Post the information about your environment we ask for.
699
588
We STRONGLY suggest you use the automatically generated "Problem
700
589
Report" form that since it contains much of the necessary information.
704
Make sure you're in a supported environment (./configure --showoses).
591
<p> Make sure you're in a supported environment (./configure --showoses).
708
595
If it's an unsupported environment, we're interested in your efforts to
709
596
make ntop work, but we don't have the time, resources, knowledge and/or
710
597
interest to do it ourselves.
714
For software 'crashes', please run ntop under the gdb debugger and capture
715
the full failure information.
599
<p> For software 'crashes', please run ntop under the gdb debugger and capture
600
the full failure information.
719
604
Brief instructions on using gdb are at the end of this file (docs/FAQ).
724
I posted to the list and nobody answered me.
728
ntop is open source, and the lists are a community resource. If nobody
729
answered your question, then nobody knew the answers off-hand and nobody
607
<p><b>Q.</b> I posted to the list and nobody answered me.</p>
608
<p><b>A.</b> ntop is open source, and the lists are a community resource. If nobody answered your question, then nobody knew the answers off-hand and nobody
730
609
wanted to spend THEIR time solving YOUR problem.
735
Do you offer paid support?
739
Yes - contact us through http://www.ntop.org/consultancy.html
612
<p><b>Q.</b> Do you offer paid support?</p>
613
<p><b>A.</b> Yes - contact us through http://www.ntop.org/consultancy.html</p>
741
614
<h2>Configuring ntop</h2>
745
What does ./configure do?
749
./configure checks for the tools installed on your system - configuring
750
ntop to compile with the ones you have and skip the ones you don't (or
616
<p><b>Q.</b> What does ./configure do?</p>
617
<p><b>A.</b> ./configure checks for the tools installed on your system - configuring ntop to compile with the ones you have and skip the ones you don't (or
751
618
to tell you if you're missing something critical).
756
Why bother - just compile the code.
760
Then you would have to have a machine configured EXACTLY like Luca's.
761
Nothing else would work. Various OSes and Linux distributions package
621
<p><b>Q.</b> Why bother - just compile the code.</p>
622
<p><b>A.</b> Then you would have to have a machine configured EXACTLY like Luca's. Nothing else would work. Various OSes and Linux distributions package
762
623
the files in different ways and put them in different places. Plus some
763
624
packages put files into directories with release information in them, etc.
772
Is how you tell ntop where to find things. A lot of stuff it can figure
773
out on it's own, but if things get put in 'strange' places, ntop's
627
<p><b>Q.</b> OK, so ./configure</p>
628
<p><b>A.</b> Is how you tell ntop where to find things. A lot of stuff it can figure out on it's own, but if things get put in 'strange' places, ntop's
774
629
./configure has switches you use to tell where to find things.
783
./configure --help shows the whole list. It's a bit confusing because
784
there are standard options and ntop options mixed in there.
788
So, first let's look at the 'where are things' options. There are two
789
types of files ntop is looking for, '.h' files and libxxxx files.
792
.h files are also called 'includes' and libxxxx files are called libraries
632
<p><b>Q.</b> And the list is?</p>
633
<p><b>A.</b> ./configure --help shows the whole list. It's a bit confusing because there are standard options and ntop options mixed in there.
635
<p><b>A.</b> So, first let's look at the 'where are things' options. There are two types of files ntop is looking for, '.h' files and libxxxx files.
637
<p> .h files are also called 'includes' and libxxxx files are called libraries
796
.h files are the C source for functions provided by the OS or by libraries.
640
<p> .h files are the C source for functions provided by the OS or by libraries.
797
641
They are typically in a directory named /usr/include, but they can be
801
lib files are compiled libraries of these functions (the .h tells ntop
644
<p> lib files are compiled libraries of these functions (the .h tells ntop
802
645
how to call something, the lib file is the actual code). Their names
803
646
usually begin libxxxx (so the library gd is named libgd).
806
By convention, libraries end in .so or .a. A .so library is a shared
648
<p> By convention, libraries end in .so or .a. A .so library is a shared
807
649
library (Windows DLL), where one copy of the library is used by all
808
650
programs that want it's functions. A .a library is a non-shared or
809
651
static library, which must be merged (the technical term is linked)
813
ntop uses both - the myrrd library is a static, .a library. When it
654
<p> ntop uses both - the myrrd library is a static, .a library. When it
814
655
comes to things like libpcap or libgd, we use shared (.so) libraries.
817
Library files are typically placed in /usr/lib, where the gnu linker
657
<p> Library files are typically placed in /usr/lib, where the gnu linker
818
658
(ld), 'knows' automatically how to find them. However, from OS to
819
659
OS and distribution to distribution, there are many other common places.
820
660
Some OSes even have a file telling ld all the places to look.
825
So ntop looks for these .h and library thingies in a couple of places.
826
What if it doesn't find them?
830
If a basic ./configure can't find something, you'll have to tell ntop
834
It's complex and OS/distro dependent. For example, if you install libgd
663
<p><b>Q.</b> So ntop looks for these .h and library thingies in a couple of places. What if it doesn't find them?
665
<p><b>A.</b> If a basic ./configure can't find something, you'll have to tell ntop where to look.
667
<p> It's complex and OS/distro dependent. For example, if you install libgd
835
668
from the Sun Freeware site on to a Solaris machine, the files get put
836
669
into /usr/local/include and /usr/local/lib, which are not on the lists
837
670
of 'standard' places for Solaris' versions of gcc (the Gnu c compiler)
838
671
or ld. So to compile ntop, you have to tell gcc to look in these
839
672
additional locations.
842
The things ntop might be looking for are in this part of the
674
<p> The things ntop might be looking for are in this part of the
843
675
./configure --help output:
1591
1217
/usr/include/linux/if_ether.h:#define ETH_ALEN 6
1592
1218
/usr/include/net/ethernet.h:#define ETHER_ADDR_LEN ETH_ALEN
1595
And post that information with your error report. The reason is that these
1220
<p> And post that information with your error report. The reason is that these
1596
1221
field definitions are often placed in very different places in different
1597
1222
OSes and even in different distributions.
1600
FWIW, if you look in the older configure.in:
1224
<p> FWIW, if you look in the older configure.in:
1604
1228
AC_CHECK_HEADERS([linux/if_pppox.h], [], [], [net/if.h
1605
1229
netinet/if_ether.h])
1231
<p> should have been
1612
1235
AC_CHECK_HEADERS([linux/if_pppox.h], [], [], [#include <net/if.h>
1613
1236
#include <netinet/if_ether.h>])
1616
because the macro doesn't do the #include automatically.
1238
<p> because the macro doesn't do the #include automatically.
1621
Nope, it's not ./configure...
1625
If it's not the configuration, then it's usually a problem with your specific
1241
<p><b>Q.</b> Nope, it's not ./configure...</p>
1242
<p><b>A.</b> If it's not the configuration, then it's usually a problem with your specific system, either:
1630
1246
- A new release of a supported OS.
1631
1247
- An uncommon option/configuration of a supported OS.
1634
In other words, something is different from what we've seen or expected.
1249
<p> In other words, something is different from what we've seen or expected.
1637
Review the output from make. The error message will usually give you a
1251
<p> Review the output from make. The error message will usually give you a
1638
1252
Somewhat cryptic description of what's wrong and where. Look for messages
1639
1253
about missing files. Post as much information as you can - do locates for
1640
1254
the missing files, etc. The more you give us the less we will have to ask
1641
1255
you to provide.
1644
Remember, we can't see your box - all that the people on the list see is the
1257
<p> Remember, we can't see your box - all that the people on the list see is the
1645
1258
information you give in your message.
1650
Compile dies because it's missing depcomp
1654
automake/autoconf issue. The problem should have been fixed. If not, just
1655
Copy the missing file (or make a symbolic link) into the ntop source
1261
<p><b>Q.</b> Compile dies because it's missing depcomp</p>
1262
<p><b>A.</b> automake/autoconf issue. The problem should have been fixed. If not, just Copy the missing file (or make a symbolic link) into the ntop source
1659
It's in /usr/share/automake on my Linux boxes. Another user reports it is in
1265
<p> It's in /usr/share/automake on my Linux boxes. Another user reports it is in
1660
1266
/usr/local/share/automake in sun8.
1663
If you have automake installed, this will do it automatically:
1268
<p> If you have automake installed, this will do it automatically:
1667
1272
$ automake --add-missing --gnu -c
1672
Make fails with a message about being unable to create a .deps file.
1676
Check the permissions on the (hidden) .deps (and .libs) directories - if root
1677
owns them your non-root userid may not be able to create files in there.
1682
Make fails with a message about a missing .deps file
1686
Basically, it's a automake 1.5 bug, related to dependency tracking.
1689
If you don't have automake installed, you shouldn't see this problem.
1692
ntop requires automake 1.6+ - that dependency is EXPLICT in the Makefile.am!
1695
If you do have automake installed, it's possible to hit this problem -
1696
especially if it's one of those Linux distributions that have three versions
1697
of automake installed and a (broken) script that's supposed to figure out
1698
which version to actually run.
1701
Since we distribute ntop with scripts generated from 1.6.3, you would *think*
1702
they should work, regardless of what version of automake is installed.
1705
That's not the case. The problem occurs because automake gets invoked by
1706
./configure to copy the missing gnu files such as depcomp. If you have 1.5
1707
installed, it then remakes the plugins/Makefile as a 1.5 version, which
1711
The problem should be trapped and worked around, however, so report the
1712
problem to the list.
1717
Why is the .deps problem mostly happening under FreeBSD?
1721
Because the FreeBSD ports tree only has 1.5, but that's a FreeBSD ports
1722
problem, not ntop's. If you search the FreeBSD lists on Google, there's lots
1723
of traffic about a 1.6 version for FreeBSD, but it doesn't seem to be in the
1724
tree. What's there is:
1732
-- which does NOT work
1737
So how do I work around the problem?
1741
Install 1.6.3. It's quite easy, does NOT require root. The steps are listed
1742
in the ./configure message, repeated below:
1746
Download automake 1.6.3 from gnu
1747
$ wget http://ftp.gnu.org/gnu/automake/automake-1.6.3.tar.gz
1752
$ tar xfvz automake-1.6.3.tar.gz
1758
$ ./configure --prefix=/home/<whatever>/automake163
1764
Add it to your path (this is bash, but other shells, can do it too)
1768
$ PATH=/home/<whatever>automake163/bin:$PATH
1773
And then untar, ./configure and make ntop.
1778
Make fails with a message like this:
1275
<p><b>Q.</b> Make fails with a message about being unable to create a .deps file.</p>
1276
<p><b>A.</b> Check the permissions on the (hidden) .deps (and .libs) directories - if root owns them your non-root userid may not be able to create files in there.
1279
<p><b>Q.</b> Make fails with a message like this:</p>
1781
1281
/bin/ld: Warning: size of symbol `pcap_open_dead' changed from 100 to 67
2291
1640
24/Jul/2003 15:15:23 Initializing IP services...
2293
1642
24/Jul/2003 15:15:23 Initializing GDBM...
2294
24/Jul/2003 15:15:23 Database '/var/ntop/addressCache.db' open failed: File
1643
24/Jul/2003 15:15:23 ***FATAL_ERROR*** open of ...name... failed: can't be writer
2296
1644
24/Jul/2003 15:15:23 Possible solution: please use '-P <directory>'
2300
Multiple possible choices...
2303
1. The directory /var/ntop doesn't exist. Create it or, as the message
2304
says, use the -P parameter to point ntop at another directory.
2305
2. You many not have read/write rights in /var/ntop - if you're running in
2306
non-promiscuous mode from a user other than root.
2307
3. Another instance of ntop may already be running, so it has the file open
1646
<p><b>A.</b> Multiple possible choices...</p>
1647
<p> * Another ntop already running
1649
<p> (Most common) You forgot the -P parameter, and ntop is using a default value that
1650
doesn't exist. Just as the message says, use the -P parameter to point ntop at
1651
the directory you want it to use.
1653
<p> * Some sort of file system problem (non-existent directory, permissions, etc.)
1655
<p> 1. The directory shown doesn't exist. Create it.
1657
<p> 2. You many not have read/write rights in that directory.
1658
This can occur if you run ntop both as root and (as recommended) as a non-root user.
1660
<p> 3. Another instance of ntop may already be running, so it has the file open and locked.
2313
What's inside the .db files and what's their format?
2317
The files are stored in GDBM format. You can dump their content using tools like
2318
this: http://tboudet.free.fr/dumpgdbm/. In principle you should not be
1663
<p><b>Q.</b> What's inside the .db files and what's their format?</p>
1664
<p><b>A.</b> The files are stored in GDBM format. You can dump their content using tools like this: http://tboudet.free.fr/dumpgdbm/. In principle you should not be
2319
1665
interested in the file content as they are temporary caches and contain the
2320
1666
configuration as well as the MD5 hash of the web passwords.
2323
I posted a trivial dumpgdbm.c to gmane - search for it.
1668
<p> I posted a trivial dumpgdbm.c to gmane - search for it.
2328
ntop starts up with this:
2329
WARNING: Discarded network 172.20.0.0/16: this is the local network.
1671
<p><b>Q.</b> ntop starts up with this: WARNING: Discarded network 172.20.0.0/16: this is the local network.
2333
No worries. The message means exactly what it says - it's a warning that
2334
you gave the local network as one of the parameter(s) to -m. Since the
1673
<p><b>A.</b> No worries. The message means exactly what it says - it's a warning that you gave the local network as one of the parameter(s) to -m. Since the
2335
1674
local networks are always local, ntop doesn't need to make them pseudo-local.
2340
What are ntop's options?
2344
There are a couple of options that appear only if they're not compiled in,
2345
and a few that depend on various external libraries, e.g. openSSL.
2348
The best way to see what is actually available is to run ntop with the -h or
1677
<p><b>Q.</b> What are ntop's options?</p>
1678
<p><b>A.</b> There are a couple of options that appear only if they're not compiled in, and a few that depend on various external libraries, e.g. openSSL.
1680
<p> The best way to see what is actually available is to run ntop with the -h or
2349
1681
--help options and see. Also read man ntop.
2352
Here is the FULL set of real, working options as of February 2004
2357
Use IPv4 connections (for the ntop web server)
2359
Use IPv6 connections (for the ntop web server)
2363
-a <file> | --access-log-file <file>
2364
File for ntop web server access log
2368
-b | --disable-decoders
2369
Disable protocol decoders
2374
Idle hosts are not purged from memory
2379
Run ntop in daemon mode
2383
-e <number> | --max-table-rows <number>
2384
Maximum number of table rows to report
2388
-f <file> | --traffic-dump-file <file>
2389
Traffic dump file (see tcpdump)
2393
-g | --track-local-hosts
2394
Track only local hosts
2399
Display help and exit
2403
-i <name> | --interface <name>
2404
Interface name or names to monitor
2408
-j | --create-other-packets
2409
Create file ntop-other-pkts.XXX.pcap file
2414
ntop will trust just IP addresses (no MACs)
2418
-k | --filter-expression-in-extra-frame
2419
Show kernel filter expression in extra frame
2423
-l <path> | --pcap-log <path>
2424
Dump packets captured to a file (debug only!)
2428
-m <addresses> | --local-subnets <addresses>
2429
Local subnetwork(s) (see man page)
2433
-n | --numeric-ip-addresses
2434
Numeric IP addresses - no DNS resolution
2438
-p <list> | --protocols <list>
2439
List of IP protocols to monitor (see man page)
2443
-q | --create-suspicious-packets
2444
Create file ntop-suspicious-pkts.XXX.pcap file
2448
-r <number> | --refresh-time <number>
2449
Refresh time in seconds, default is 120
2453
-s | --no-promiscuous
2454
Disable promiscuous mode
2458
-t <number> | --trace-level <number>
2463
-u <user> | --user <user>
2464
Userid/name to run ntop under (see man page)
2468
-x <max num hash entries>
2469
Max num. hash entries ntop can handle (default 4294967295)
2473
-w <port> | --http-server <port>
2474
Web server (http:) port (or address:port) to listen on
2478
-z | --disable-sessions
2479
Disable TCP session tracking
2484
Ask admin user password and exit
2488
--set-admin-password=<pass>
2489
Set password for the admin user to <pass>
2494
Add extra headers to make better html
2498
-B <filter> | --filter-expression
2499
Packet filter expression, like tcpdump
2503
-D <name> | --domain <name>
2504
Internet domain name
2508
-F <spec> | --flow-spec <specs>
2509
Flow specs (see man page)
2519
Do logging via syslog
2523
--use-syslog=<facility>
2524
Do logging via syslog, facility ('=' is REQUIRED)
2528
-M | --no-interface-merge
2529
Don't merge network interfaces (see man page)
2534
Map file providing map of WWN to FCID/VSAN
2538
-O <path> | --pcap-file-path <path>
2539
Path for log files in pcap format
2543
-P <path> | --db-file-path <path>
2544
Path for ntop internal database files
2548
-U <URL> | --mapper <URL>
2549
URL (mapper.pl) for displaying host location
2554
Output version information and exit
2558
-X <max num TCP sessions>
2559
Max num. TCP sessions ntop can handle (default 4294967295)
2563
-W <port> | --https-server <port>
2564
Web server (https:) port (or address:port) to listen on
2568
--disable-instantsessionpurge
2569
Disable instant FIN session purge
2573
--disable-mutexextrainfo
2574
Disable extra mutex info
2578
--disable-schedyield
2579
Turn off sched_yield() calls, if ntop is deadlocking on them
2584
Capture packets even if there's no memory left
2589
Display only Fibre Channel statistics
2594
Disable processing & Display of Fibre Channel
2599
Don't display Invalid LUN information
2604
Set return value for p3p compact policy, header
2609
Set return value for p3p policyref header
2613
--set-pcap-nonblocking
2614
Call pcap_setnonblock
2618
--skip-version-check
2619
Skip ntop version check
2624
Use ssl watchdog (NS6 problem)
2633
The default for the ntop web server is to connect to any address and any family
2634
of addresses, so if the NIC has both IPv4 and IPv6 addresses it should respond
1684
<p><b>Q.</b> -4 and -6?</p>
1685
<p><b>A.</b> The default for the ntop web server is to connect to any address and any family of addresses, so if the NIC has both IPv4 and IPv6 addresses it should respond
2635
1686
to both. Use these to restrict the web server.
2644
The settings 0..4 control the amount of information logged or displayed.
2645
5 adds a [MSGIDnnnn] field and 6 adds the file:line where the message originated.
2646
-t 5 can be useful with a log watch type package, -t 6 is mostly for debugging.
1689
<p><b>Q.</b> --trace-level?</p>
1690
<p><b>A.</b> The settings 0..4 control the amount of information logged or displayed. DETAIL (5) adds a [MSGIDnnnn] field and (VERYNOISY) 6 or greater adds the
1691
file:line where the message originated.
1693
<p> -t 5 can be useful with a log watch type package, -t 6 is mostly for debugging.
2652
1698
[MSGID8757584] OSFP: scanFingerprintLoop() checked 1, resolved 1
2658
1703
[MSGID8757584] [ntop:698] OSFP: scanFingerprintLoop() checked 1, resolved 1
1705
<p> With 3.2 we've added VERYNOISY and (7) BEYONDNOISY ... they do pretty much what they
1706
say. Have LOTS of log space available.
2663
ntop starts up find and then seems to die.
2667
Are the ntop threads still there? Use ps to check, for example:
2668
# ps -C ntop -m -o "uid,pid,ppid,stat,time,command"
1709
<p><b>Q.</b> ntop starts up find and then seems to die.</p>
1710
<p><b>A.</b> Are the ntop threads still there? Use ps to check, for example: # ps -C ntop -m -o "uid,pid,ppid,stat,time,command"
3592
2387
disappear (http: opens a lot, does a small retrieval and closes them), ssh
3593
2388
may last for days. etc. Memory is consumed tracking them too.
3598
So what does the purge do?
3602
ntop purges idle hosts. Period.
3605
Idle being defined as having not had packet traffic for a #define able
2390
<p> It's not just one table entry per host - there are a lot of ancillary tables
2391
which only get allocated if you have data for them.
2394
<p><b>Q.</b> Got a guess?</p>
2395
<p><b>A.</b> Sure. Look in textinfo.html and you will see the line:</p>
2398
(very) Approximate memory per host.....4.4KB
2400
<p> I'm not sure how much I trust this and I wrote it. This calculation just
2401
computes the (current usage - baseline) / # of hosts.
2404
<p><b>Q.</b> So ntop's memory usage is dependent upon?</p>
2406
<p><b>Q.</b> So what does the purge do?</p>
2407
<p><b>A.</b> ntop purges idle hosts. Period.</p>
2408
<p> Idle being defined as having not had packet traffic for a #define able
3606
2409
period, 5 minutes by default.
3609
Because of the amount of linked data, these purges take time (lots of
2411
<p> Because of the amount of linked data, these purges take time (lots of
3610
2412
free() calls on all those char* values), so we don't purge in 'real time'.
3611
2413
First we build a list of idle hosts, then we purge from that list.
3612
2414
Any idle host is eligible for purge (unless you tell ntop not to purge idle
3613
2415
hosts, which is usable only on small networks).
3616
Over time, all idle hosts are purged. Only to be perturbed by the
2417
<p> Over time, all idle hosts are purged. Only to be perturbed by the
3617
2418
next burst of activity - say a port scan or everybody logging in back
3618
2419
in after lunch. Eventually, there's some form of steady state, but it's
3619
2420
HIGHLY dependent upon network activity. Which, remember, is external to
3620
2421
ntop and can't be predicted.
3629
Think about the overhead of sorting this huge structure by 'last packet
3630
seen time'. 1GB of ram is something like 80K+ hosts and takes a long
2424
<p><b>Q.</b> Why?</p>
2425
<p><b>A.</b> Think about the overhead of sorting this huge structure by 'last packet seen time'. 1GB of ram is something like 80K+ hosts and takes a long
3631
2426
time to sort (let alone free). During which time, on that busy network,
3632
2427
a couple of dozen packets are processed... Meaning maybe your list of idle
3633
2428
hosts is wrong.
3638
So how about a hard memory limit?
3642
There's no way to make a hard limit without purging ACTIVE hosts (or
3643
non-IDLE given ntop's definition of idle).
3646
Think about it ... you're at that 1GB limit and you find a new host.
2431
<p><b>Q.</b> So how about a hard memory limit?</p>
2432
<p><b>A.</b> There's no way to make a hard limit without purging ACTIVE hosts (or non-IDLE given ntop's definition of idle).
2434
<p> Think about it ... you're at that 1GB limit and you find a new host.
3647
2435
Do you kick off an interim purge (with it's huge overhead?) And wait
3648
2436
2 or 3 s for an available slot?? While 1000s of other packets appear??
3657
It might, might, be possible as a soft limit - but it's got a lot of
3661
First off, tracking memory usage of the hosts tables is itself a huge
2439
<p><b>Q.</b> Soft limit?</p>
2440
<p><b>A.</b> It might, might, be possible as a soft limit - but it's got a lot of issues.
2442
<p> First off, tracking memory usage of the hosts tables is itself a huge
3662
2443
job. There are multiple places were stuff is purged, added to the
3663
2444
structures as pointers, etc. and there's a queue of purged entries
3664
2445
for reuse to cut down on the malloc() calls.
3667
Secondly, the purge is resource intensive, and has been the cause of
2447
<p> Secondly, the purge is resource intensive, and has been the cause of
3668
2448
deadlocks before - you don't dare lock the structures for too long -
3669
2449
packets keep arriving, and FAST on the busy network that has the memory
3670
2450
issues in the first place. Since you can't lock for long, you can only
3671
2451
purge a small # of entries.
3676
Why does ntop drop packets?
3680
Short Answer: You need a faster processor. Maybe.
3684
Long Answer: There are four places packets drop "in" ntop. One in
3685
the NIC, one in the OS kernel, one in the libpcap library and one
3689
First off, this is largely NOT controlled by ntop. It's inside the network
3690
card, the network card driver and libpcap. All ntop does is use the stats
3691
provided by libpcap, pcap_stats:
3695
"int pcap_stats() returns 0 and fills in a pcap_stat struct. The
3696
values represent packet statistics from the start of the run to
3697
the time of the call. If there is an error or the under lying
3698
packet capture doesn't support packet statistics, -1 is returned
3699
and the error text can be obtained with pcap_perror() or
3703
to get the value and reports it in report.con the Stats | Traffic
3704
page, some in the configuration report (info.html) and also on
3705
the problem report skeleton.
3708
The information on the Stats | Traffic page is simply the best available.
3709
However, this data is not always easy to obtain nor interpret.
3712
It looks great, but the reality is that the stats provided by libpcap
3722
The network card (NIC) reads packets from the wire into a small buffer.
3723
That buffer is emptied by the OS into it's own buffers which are then
3724
passed to libpcap. libpcap filters the packets (if requested) and
3725
passes the packets to ntop.
3728
Packets may be dropped at any or all of these stages, even on a system
3729
that does not appear to be exceptionally busy.
3734
How can packets be lost in the NIC?
3738
A NIC has a small buffer - modern cards have 8K, 12K, even more buffer
3739
space. But if traffic comes in off the wire faster than the processes
3740
are pulling it out of the NIC, well that buffer gets over-written and
3741
packets get dropped.
3744
Every time a packet comes in (or on some newer cards after a few packets
3745
are recevied), the NIC interrupts the processor (CPU) to tell it to do
3746
something. This isn't a problem - some NICs with larger buffers
3747
internally queuing a number of packets before interrupting the OS to
3751
Check ifconfig for this:
3755
eth0 Link encap:Ethernet HWaddr 00:D0:09:77:85:B9
3756
inet addr:192.168.42.6 Bcast:192.168.42.255 Mask:255.255.255.0
3757
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
3758
RX packets:3892397 errors:30 dropped:0 overruns:0 frame:33
3760
TX packets:473009 errors:0 dropped:0 overruns:0 carrier:0
3762
collisions:1073 txqueuelen:100
3763
RX bytes:2606704447 (2485.9 Mb) TX bytes:70474880 (67.2 Mb)
3764
Interrupt:11 Base address:0xc000
3767
Now, if it's an occasional burst, losing 1 or 2 packets won't kill
3768
you. TCP/IP recovers. And ntop's statistics aren't life-critical.
3769
If, however, it's continuous, on-going and the count is growing - i.e.
3770
the NIC/CPU combo can't keep up with the AVERAGE network flow?
3777
Upgrade the Processor or NIC. Maybe.
3782
Can you tell if the NIC is the bottleneck?
3786
Probably not. Different NIC cards (and NIC card drivers) record different
3787
information. Different tools present pieces and parts of it differently.
3790
For example, a runt packet - one that is too short to really be a packet
3791
is supposed to be discarded according to the tcp/ip standard. But do you
3792
count it as a packet received??
3795
On many systems, interface level (NIC) statistics are available through
3796
the ifconfig (or similar) command. But what is available and what they
3797
mean can be different - even though they're presented in the same format.
3798
Different programs can read the 'same' data and show different things.
3801
For example - eth1 is an Intel Ethernet Pro/100, eth2 a 3c905...
3805
Kernel Interface table
3806
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
3807
eth1 1500 0 50752227 0 0 0 0 0 0 0 BMPRU
3808
eth2 1500 0 145053154 0 0 0 0 0 0 0 BMPRU
3811
No errors - great, right? But look at ifconfig, a few seconds earlier:
3815
eth1 Link encap:Ethernet HWaddr 00:03:47:B1:62:27
3818
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
3819
RX packets:50754251 errors:0 dropped:0 overruns:0 frame:3454146
3820
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
3821
collisions:0 txqueuelen:100
3822
RX bytes:667103055 (636.1 Mb) TX bytes:0 (0.0 b)
3823
Interrupt:9 Base address:0x1000
3826
eth2 Link encap:Ethernet HWaddr 00:60:97:04:30:33
3829
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
3830
RX packets:145056087 errors:0 dropped:0 overruns:0 frame:0
3831
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
3832
collisions:0 txqueuelen:100
3833
RX bytes:1784472399 (1701.8 Mb) TX bytes:0 (0.0 b)
3834
Interrupt:9 Base address:0xb800
3837
If I'm reading the code right, then the frame:nnnn count is set here:
3841
sp->stats.rx_frame_errors += le32_to_cpu(sp->lstats->rx_align_errs);
3844
Meaning? No clue - the writer of the driver had to sign an NDA and so
3845
couldn't explain a lot of what the driver does. Besides, that data
3846
isn't available to ntop anyway.
3851
How can packets can be lost in the kernel?
3855
Each time that interrupt occurs, the kernel processes it by moving
3856
the data from the NIC to a kernel buffer, then re-enable interrupts.
3862
Actually, in Linux (and other OSes), the Kernel interrupt handler is
3863
broken in half - called in Linux the top and bottom. The bottom
3864
interrupt works with processor interrupts off to grab the data and
3865
buffer it and does only minimal processing as fast as possible so
3866
interrupts can be turned back on. Then the top half is scheduled
3867
and processes as a Kernel process (high priority), but it is less
3871
However, if the kernel can't process the bottom half in time - because
3872
there isn't enough memory and/or the processor isn't fast enough to
3873
respond to the interrupt, you do have a problem. The small buffer
3874
in the NIC will overflow and packets are dropped (this is the ONE place
3875
where a better NIC, with a larger buffer, MIGHT help).
3878
While there are LOTS of possible causes, if the kernel is *routinely*
3879
dropping packets, it's almost certainly an interrupt/processor
3880
speed/buffering issue.
3883
So, I guess what I'm saying is that the dropped: count from ifconfig
3884
might not be the NIC's fault - and that's why a faster processor is a
3885
better choice than an expensive server class NIC.
3890
But at least I can trust the libpcap reported counts, right?
3894
Nope. You need to treat the pcap reported drops with more than a few
3895
grains of salt. See this thread, for example:
3898
http://www.tcpdump.org/lists/workers/2001/07/msg00018.html
3900
http://www.mcabee.org/lists/snort-users/Jan-02/msg00771.html
3903
There's a lot of other stuff about pcap problems, especially from
3904
snort (another package that stresses libpcap) -
3905
STFW for "libpcap ps_drop".
3908
See, the call to pcap_stats reads internal counters - maybe they come
3909
from the NIC and maybe they're just maintained by the kernel. That's a
3910
function of how the low level NIC driver is written to handle certain
3911
calls from higher level drivers. So it's a function of the specific
3912
NIC card, something we try to hide from everyone, ntop included.
3915
Ultimately, some piece of hardware or software SHOULD be counting packets
3916
and dropped packets.
3919
But, remember also, that - AT THE INSTANT OF THE pcap_stats call -
3920
there can be packets queued in any of these buffers (NIC, kernel, libpcap).
3923
Put the two together and I wouldn't trust 'em.
3926
Want more fear? Read the comments through out the libpcap code. Like
3927
this gem from pcap-linux.c:
3931
* Get the statistics for the given packet capture handle.
3932
* Reports the number of dropped packets iff the kernel supports
3933
* the PACKET_STATISTICS "getsockopt()" argument (2.4 and later
3934
* kernels, and 2.2[.x] kernels with Alexey Kuznetzov's turbopacket
3935
* patches); otherwise, that information isn't available, and we lie
3936
* and report 0 as the count of dropped packets.
3939
And this from pcap-bpf.c:
3944
* "ps_recv" counts packets handed to the filter, not packets
3945
* that passed the filter. This includes packets later dropped
3946
* because we ran out of buffer space.
3948
* "ps_drop" counts packets dropped inside the BPF device
3949
* because we ran out of buffer space. It doesn't count
3950
* packets dropped by the interface driver. It counts
3951
* only packets that passed the filter.
3953
* Both statistics include packets not yet read from the kernel
3954
* by libpcap, and thus not yet seen by the application.
3958
As you see from the comments in the code, the interpretation of even
3959
those counts differs between operating systems and even between minor versions
3960
of the same OS (e.g. Linux 2.4.8 vs. 2.4.9). For example, some systems
3961
do not maintain a dropped count and will always report zero. Differences
3962
may also occur on the same system for different NIC drivers.
3965
If a BPF filter (-B option) is in place, the differences between OSes are
3981
Sure. ntop runs multiple threads (we call them "NPS - Network Packet Sniffer"
3982
or something similar), one to handle each incomming device. These operate
3983
much like the bottom-half interrupt - they accept the packet and queue it
3984
to another thread ("NPA - Network Packet Analyzer") for the analysis.
3987
Ultimately, we're interested in the counter droppedPkts, which is
3988
incremented in only one place, pbuf.c around 1398, which this is where
3989
NPS is trying to queue a packet for NPA.
3992
Now, you can increase PACKET_QUEUE_LENGTH
3996
ntop.h: 693 #define PACKET_QUEUE_LENGTH 2048
3999
but if you're routinely dropping packets here it's because ntop can't
4000
keep up with the flow. Increasing the queue length will ONLY help if
4001
it's an occasional huge peak with times where the network is quiet
4002
enough to allow you to work off the queue. And each packet buffer
4003
in use takes up memory - (about 1.5MB for a queue of size 2048).
4006
The instantaneous and maximum value for the queue are reported in
4007
the configuration report:
4011
# Queued Pkts to Process 0
4015
But, again, the best answer for dropped packets is probably a
4016
faster processor... (Upgrading to an expensive faster NIC with a
4017
larger internal buffer is rarely the best "bang for the buck" - if
4018
you were running a server, then a server class NIC is a good idea,
4019
but for workstations or network monitors, etc. you just need something
4020
that can keep up with the network flow.)
4025
So what do you show?
4029
The kicker is that accurate counts of raw and dropped packets do not exist
4030
or are not available without using low-level, system specific logic.
4033
The counts that ARE available in a system-independent way are what is
4034
reported in the statistics on the Stats | Traffic page.
4039
So what is reported?
4043
ntop reports the packet and dropped counts as reported by libpcap and the
4044
received, dropped and processed counts it maintains internally.
4049
So what does ntop do with what it does receive?
4053
ntop processes or queues all packets received from libpcap but may drop
4054
packets if the processing queue fills up. Losing a few packets inside
4055
ntop due to a rare burst of traffic is just that - rare, and is not a
4059
If you consistently see packets dropped by ntop then you probably need
4060
to use a faster processor (increasing the buffer size beyond the default
4061
of 2K packets will usually not help).
4070
You can monitor the queue size on the 'Configuration' (info.html) page.
4075
What about the other dropped items?
4079
If you consistently see packets dropped at either the interface or
4080
libpcap level, there is not much we can offer in the way of help for you.
4083
The best suggestion is to try another NIC or a faster machine.
4092
Some NICs - especially ISA ones - are just too slow at moving packets
4093
off of the card. Measurements I did on an old SMC 10BaseT card in 1993
4094
showed that the best it could do - ISA bus, windows overhead, etc. all
4095
rolled together was about 1.7Mbps.
4098
Memory bus speeds (e.g. PC100 vs PC133, DDR333 vs DDR400, etc.) can also
4099
affect moving packets from the NIC to main memory.
4104
Won't a faster CPU help?
4108
Maybe. Some network card drivers are processor intensive - and would
4109
benefit - but others offload most of the processing to the NIC, and so a
4110
faster CPU wouldn't matter.
4113
Even a fancy (read as expensive) NIC may not work well - the drivers
4114
for the NIC on one OS may take advantage of features the card provides
4115
and be 'faster', while the driver for the same NIC on another OS may
4116
not take advantage of these features and be 'slower'.
4128
So, remember - ntop drops packets, the kernel drops packets, libpcap drops
4129
packets and none of 'em do it the same way. Don't bet the farm on counting
4130
every packet with absolute accuracy and use ntop the way it was meant to
4131
be used - showing the overall usage and flows on the network.
4134
Still it's not all gloom and doom!
4137
Even if you're only processing 90% of the traffic, since the drops are
4138
pretty random, it's a decent bet that if 90% of what you DO see is MP3s,
4139
then 90% of the whole traffic flow is probably MP3s.
4144
ntop stops capturing packets, except ARP and other broadcasts. Why?
4148
Check if you have a daemon running that periodically checks for and
4149
resets interfaces in promiscuous mode? If that happens, all you
2454
<p><b>Q.</b> But what about -x and -X.</p>
2455
<p><b>A.</b> Ah, yes, grasshopper - you have been reading the man page. Good user. The -x and -X options are pretty crude. They say "if you have allocated
2456
n (hosts|sessions), fail the allocation of (host|session) n+1".
2458
<p> It works in the context of preventing memory exhaustion - if you can calculate
2459
the right values based on your available memory (and remember that 4K or 12K or
2460
whatever per host value is an AVERAGE).
2462
<p> And, no, you can't make them memory dependent - it's all ultimately virtual and
2463
ntop doesn't get indication of whether a malloc() call causes swapping. It either
2464
works because the allocation (total) is under your limit (or the hard limit of real
2465
memory + swap space - OS usage), or it fails.
2467
<p> This type of limit can't make sure you save only the RIGHT hosts.
2470
<p><b>Q.</b> These options aren't very smart, are they?</p>
2471
<p><b>A.</b> No. They don't know anything about the hosts. Just the # of them. So failing an allocation might hurt in that the n+1th host might be an important one and yet
2472
host #2 is basically trivial junk (the printer that sends and "I'm here" message
2473
every three minutes).
2475
<p> It also causes overhead, because the next packet for host n+1 will attempt to
2476
allocate a record and fail. Again and again.
2478
<p> But these options may keep ntop from crashing and that's a good thing.
2480
<p> If you use them, I would recommend setting them very high - just at the limit
2481
of what your memory permits. Use this as a last resort - say you get hit by
2484
<p> I recommend that you use other options such as filter and track-local-hosts for
2485
the day-to-day controls on what ntop tracks.
2488
<p><b>Q.</b> Why does ntop drop packets?</p>
2489
<p><b>A.</b> We used to have an extensive discussion here. But with Luca's merge of ntop-ht into baseline, we shouldn't be dropping packets beyond whatever the OS is dropping.
2491
<p> Until we've learned enought about ntop 3.2 and following, the whole discussion
2492
has been moved to FAQarchive.
2495
<p><b>Q.</b> ntop stops capturing packets, except ARP and other broadcasts. Why?</p>
2496
<p><b>A.</b> Check if you have a daemon running that periodically checks for and resets interfaces in promiscuous mode? If that happens, all you
4150
2497
would see were broadcast packets like ARPs...
4153
Check back in the log and see if there is a message about the interface
2499
<p> Check back in the log and see if there is a message about the interface
4154
2500
changing status. Determine why.
4159
How much horsepower do I need to run ntop on a network of size x?
4163
Nobody really knows. ntop needs enough memory to store the active
4164
hosts and enough cpu to keep up with the average packet flow. The
2503
<p><b>Q.</b> How much horsepower do I need to run ntop on a network of size x?</p>
2504
<p><b>A.</b> Nobody really knows. ntop needs enough memory to store the active hosts and enough cpu to keep up with the average packet flow. The
4165
2505
buffer will handle the occasional peak, but if you see frequent
4166
2506
lost packets, you're in trouble.
4169
Note that a few packets occasionally lost isn't a big deal for most
2508
<p> Note that a few packets occasionally lost isn't a big deal for most
4170
2509
users. After all, the network itself has losses - I've seen my AT&T
4171
2510
Broadband connection have spurts of 30% packet loss. Ideally in a
4172
2511
LAN environment, the packet loss should be down in the small #s...
4173
2512
the Ethernet standard allows 1 error in 100,000,000(10^8), but most
4174
2513
vendors beat that by a long margin (even as high as 1 in 10^12).
4177
Of course, those are lab measurements. In the real world? Not that good.
2515
<p> Of course, those are lab measurements. In the real world? Not that good.
4178
2516
Electrical noise can be a real bugaboo. Remember, at a certain point, if
4179
2517
the NIC doesn't understand what it's seeing, it throws it away and
4180
2518
declares an error. The key is to keep up with the traffic.
4183
Similarly, the OS kernel does the same thing in it's interrupt handling
2520
<p> Similarly, the OS kernel does the same thing in it's interrupt handling
4184
2521
(throw away packets). Last resort, but better than hanging up the whole
4188
ntop drops packets when the queue gets longer than the permitted length.
2524
<p> ntop drops packets when the queue gets longer than the permitted length.
4189
2525
You can see this in the configuration page as # Queued Pkts to Process
4190
2526
and # Max Queued Pkts.
4193
One or two or a small number (you pick your tolerance) is ok, but constant
2528
<p> One or two or a small number (you pick your tolerance) is ok, but constant
4194
2529
losses isn't. What I'm saying is that as long as ntop can keep up with the
4195
2530
NIC, then the data is as good as it gets... if ntop can't keep up, then the
4196
2531
data isn't very good.
4199
If you have measurements - network size, traffic flow and %CPU used (with
2533
<p> If you have measurements - network size, traffic flow and %CPU used (with
4200
2534
the hardware info, of course), shoot them over to us on ntop and someday
4201
2535
maybe we'll be able to give better #s.
4206
What about my Frobozz Model xx Magic Network card? Is it good enough?
4210
Probably. Well, a lot of the cheapos just don't have the buffering
4211
and cpu offload of a 3c905c or such. If the network isn't that busy,
2538
<p><b>Q.</b> What about my Frobozz Model xx Magic Network card? Is it good enough?</p>
2539
<p><b>A.</b> Probably. Well, a lot of the cheapos just don't have the buffering and cpu offload of a 3c905c or such. If the network isn't that busy,
4212
2540
anything will do. For a busy network, buy a decent PCI NIC.
4221
No clue. Remember that you can suck a lot more traffic over that
4222
network than an old PC can handle (i.e. the bandwidth limitations
2543
<p><b>Q.</b> Gigabit Ethernet?</p>
2544
<p><b>A.</b> No clue. Remember that you can suck a lot more traffic over that network than an old PC can handle (i.e. the bandwidth limitations
4223
2545
of 32bit PCI and PC100/133 RAM, heck even PC2700 DDR).
4228
Do "zero copy" drivers help?
4232
Yeah. Maybe. Once upon a time, I read about "zero copy" - look here
4233
http://people.freebsd.org/~ken/zero_copy/ for the FreeBSD stuff. Quoting:
2548
<p><b>Q.</b> Do "zero copy" drivers help?</p>
2549
<p><b>A.</b> Yeah. Maybe. Once upon a time, I read about "zero copy" - look here http://people.freebsd.org/~ken/zero_copy/ for the FreeBSD stuff. Quoting:
4373
2659
12-xxx-xxx-yyy.client.attbi.com 12.xxx.xxx.yyy
4378
What does this log message (and others like it) mean?
4379
**WARNING** releaseMutex() call with an UN-LOCKED mutex [hash.c:559] last
2662
<p><b>Q.</b> What does this log message (and others like it) mean? **WARNING** releaseMutex() call with an UN-LOCKED mutex [hash.c:559] last
4382
2665
unlock [pid 22176, pbuf.c:2598]
4386
Those messages are part of an error check in our mutex handling routines.
4389
Actually they pretty much mean what they say.
4392
releaseMutex() call with an UN-LOCKED mutex means that the corresponding
2667
<p><b>A.</b> Those messages are part of an error check in our mutex handling routines.</p>
2668
<p> If things are working properly, then these messages tell us things are
2669
really, really, really wrong.
2671
<p> releaseMutex() call with an UN-LOCKED mutex means that the corresponding
4393
2672
accessMutex() call never occured.
4396
releaseMutex() call with an UN-INITIALIZED mutex means that the
2674
<p> releaseMutex() call with an UN-INITIALIZED mutex means that the
4397
2675
access/release occured before the createMutex().
4400
The file/line comments, [hash.c:559] last unlock [pid 22176, pbuf.c:2598],
4401
tell you where the access/release was called from (e.g. hash.c @ 559) and
4402
where the last recorded release was.
4405
There are others, look in leaks.c for the entire set.
4410
How serious are they?
4414
None of these stop ntop from processing, but they're indications of
4415
unprotected accesses to shared data areas, which could lead to lost counts.
4418
Now understand that there's one set of conditions where I believe it doesn't
4419
matter, and that's when there are multiple NICs and multiple processors.
4420
Under some circumstances - not well understood - gcc with the -O2 option
4421
reorders the executable code in such a way as to cause these messages.
4425
But for most users, these warning messages shouldn't be ignored if they occur
4429
The problem is that a POSIX mutex doesn't allow for additional data,
4430
such as we're using to track the access / release information. So that
4431
data is, itself protected by a single global mutex. You can't hold that
4432
global mutex across an access call, or you'll deadlock ntop (either through
4433
normal mutex processing or something called 'priority inversion').
4436
So we use this pattern instead:
4440
access(stateChangeMutex)
4442
release(stateChangeMutex)
4446
access(mutex) or release(mutex)
4450
access(stateChangeMutex)
4452
release(stateChangeMutex)
4455
The problem is that these updates aren't atomic, so it's possible to have
4456
the state data updated by another thread:
4460
---------thread A--------- ---------thread B---------
4461
access(stateChangeMutex)
4463
access(stateChangeMutex)
4465
release(stateChangeMutex)
4468
release(stateChangeMutex)
4473
access(stateChangeMutex)
4475
release(stateChangeMutex)
4479
access(stateChangeMutex)
4481
release(stateChangeMutex)
4485
Unfortunately, this is equally likely:
4489
---------thread A--------- ---------thread B---------
4490
access(stateChangeMutex)
4492
access(stateChangeMutex)
4494
release(stateChangeMutex)
4497
release(stateChangeMutex)
4502
access(stateChangeMutex)
4504
release(stateChangeMutex)
4505
access(stateChangeMutex)
4507
release(stateChangeMutex)
4510
So at the end, you have an inaccurate picture in the state table.
4519
There's a good set of articles on POSIX threads at
2677
<p> The file/line comments, e.g. [hash:559], tell you where the access/release
2678
was called from (e.g. hash.c @ 559) and where the last recorded release was.
2680
<p> There are others, look in leaks.c for the entire set.
2683
<p><b>Q.</b> How serious are they?</p>
2684
<p><b>A.</b> None of these stop ntop from processing, but they're indications of unprotected accesses to shared data areas, which could lead to lost counts.
2686
<p> In the development cycle after 3.1 was released, I was able to track down
2687
and fix the remaining cause of spurious messages (but I've thought this was
2690
<p> For most users, these warning messages shouldn't be ignored.
2692
<p> The root of the problem is that POSIX mutexes are stupid and don't record
2693
a lot of state information. To debug things like deadlock, it's really,
2694
really, nice to know where the mutex was locked from.
2696
<p> So ntop has added 'extra' information to the mutex data for recording this.
2697
This added data is not protected by the mutex and could get out of sync.
2698
So we lock a state change mutex whenever we are changing the state data.
2700
<p> BUT: You can't hold the state change mutex while waiting for the main mutex
2703
<p> So the 'access' call becomes this pattern (see utils.c):
2705
<p> lock(statechangemutex)
2714
unlock(statechangemutex)
2715
lock(mutex) <-- which may block, but does not hold the statechangemutex!
2716
lock(statechangemutex)
2719
unlock(statechangemutex)
2722
<p><b>Q.</b> Threads. ugh...</p>
2723
<p><b>A.</b> There's a good set of articles on POSIX threads at</p>
4522
2725
http://www-106.ibm.com/developerworks/library/l-posix1/,
4523
2726
http://www-106.ibm.com/developerworks/library/l-posix2/ and
4524
2727
http://www-106.ibm.com/developerworks/library/l-posix3/.
4529
What does the message "URL security(1): ERROR: Found percent in
4530
URL...DANGER... rejecting request" mean?
2730
<p><b>Q.</b> What does the message "URL security(1): ERROR: Found percent in URL...DANGER... rejecting request" mean?
4534
It means that ntop received a request with a percent sign (%) in it, often
4535
used as part of Unicode exploits against various web servers. Since there is
2732
<p><b>A.</b> It means that ntop received a request with a percent sign (%) in it, often used as part of Unicode exploits against various web servers. Since there is
4536
2733
no situation where ntop should process this, we reject it.
4537
2734
URLsecurity in http.c is the place where these tests occur.
4542
What does the message "Rejected request from address x.y.z.t (it previously
4543
sent ntop a bad request)" mean?
2737
<p><b>Q.</b> What does the message "Rejected request from address x.y.z.t (it previously sent ntop a bad request)" mean?
4547
Once you send ntop a request that URLsecurity rejects, the sending address
4548
goes into a ring buffer on a 5 minute timeout where we simply drop subsequent
2739
<p><b>A.</b> Once you send ntop a request that URLsecurity rejects, the sending address goes into a ring buffer on a 5 minute timeout where we simply drop subsequent
4549
2740
requests... rather than waste cycles ignoring an attack...
4554
What are the other URL security(#) codes?
4558
1. Found a % in the request (Unicode problems)
4559
2. Found a parameter type code (//, &&, ??)
2743
<p><b>Q.</b> What are the other URL security(#) codes?</p>
2744
<p><b>A.</b> 1. Found a % in the request (Unicode problems) 2. Found a parameter type code (//, &&, ??)
4560
2745
3. Found a directory transversal code (..)
4561
2746
4. Found a prohibited (RFC1945) character
4562
2747
5. Found a bad extension
4567
ntop doesn't report any traffic at all.
4571
Understand how ntop works: It simply listens on the interface(s) for
4572
packets, then counts and interprets them. If there aren't any packets, ntop
2750
<p><b>Q.</b> ntop doesn't report any traffic at all.</p>
2751
<p><b>A.</b> Understand how ntop works: It simply listens on the interface(s) for packets, then counts and interprets them. If there aren't any packets, ntop
4573
2752
doesn't count things.
4576
ntop does not sample. It processes every packet it sees and counts them.
2754
<p> ntop does not sample. It processes every packet it sees and counts them.
4577
2755
Only if there is more traffic than ntop can handle for a long period of time
4578
2756
will the packet queue hit it's limit and packets be lost. But this is still
4582
Make sure that there's traffic on the interface(s) you are using. You can
2759
<p> Make sure that there's traffic on the interface(s) you are using. You can
4583
2760
use tcpdump or a similar network sniffer tool to check.
4586
If you are on a segmented network (i.e. switched), you may not see traffic
2762
<p> If you are on a segmented network (i.e. switched), you may not see traffic
4587
2763
that isn't destined for the ntop machine unless you configure the switch to
4588
2764
set the port for the ntop host into "mirror" or "management" mode (different
4589
2765
vendors call it different things, but it's a mode where ALL traffic is copied
4590
2766
to a specific port, regardless of which port the destination host is on).
4593
If there is more than one interface in the ntop host, perhaps you aren't
2768
<p> If there is more than one interface in the ntop host, perhaps you aren't
4594
2769
listening on the one that has traffic? Check using ifconfig:
4597
eth0 Link encap:Ethernet HWaddr 00:D0:09:77:85:B9
2771
<p> eth0 Link encap:Ethernet HWaddr 00:D0:09:77:85:B9
4600
2774
inet addr:192.168.0.34 Bcast:192.168.0.255 Mask:255.255.255.0
4623
2794
collisions:0 txqueuelen:100
4624
2795
RX bytes:566953031 (540.6 Mb) TX bytes:0 (0.0 b)
4627
You can select an interface using the '-i' flag, e.g. -i eth1 or
2797
<p> You can select an interface using the '-i' flag, e.g. -i eth1 or
4633
ntop doesn't understand xxxxx?
4637
True. IP Packets have a source address & port and a destination address &
4638
port... you MUST get your head out of the application layers and revert to
2801
<p><b>Q.</b> ntop doesn't understand xxxxx?</p>
2802
<p><b>A.</b> True. IP Packets have a source address & port and a destination address & port... you MUST get your head out of the application layers and revert to
4639
2803
that simple concept.
4642
How does Apache handle virtual hosts? It analyzes the flow at the
2805
<p> How does Apache handle virtual hosts? It analyzes the flow at the
4643
2806
application level (layer 4) not the wire/packet/protocol (layers 1, 2 and
4644
2807
3). It does this by re-assembling packets into a layer 4 message (e.g. GET
4645
2808
http://virtual.host.name.com/page.html)...
4648
Now there are some layer 4 analysis routines - virtual hosts was added in
2810
<p> Now there are some layer 4 analysis routines - virtual hosts was added in
4649
2811
2.2 (and the folks who have virtual hosts have been pretty pleased), ftp,
4650
2812
http, and some others - mostly looking for traffic on non-standard
4654
So, since ntop works at the packet level, it doesn't understand virtual
2815
<p> So, since ntop works at the packet level, it doesn't understand virtual
4655
2816
hosts. Unless it's SPECIFICALLY coded for. ntop is a NETWORK analyzer, not
4656
2817
an application level one.
4661
tcpwrappers doesn't work
4665
Oh yes it does... for http: connections
4668
1) You have to configure it this way before compiling ntop:
2820
<p><b>Q.</b> tcpwrappers doesn't work</p>
2821
<p><b>A.</b> Oh yes it does... for http: connections</p>
2822
<p> 1) You have to configure it this way before compiling ntop:
4671
2825
./configure --enable-tcpwrap
4674
2) You must have the headers and libraries installed on the build machine
2827
<p> 2) You must have the headers and libraries installed on the build machine
4677
2830
(and on the execution machine if they aren't the same).
4680
Remember to make the appropriate entries in hosts.allow (e.g.
2832
<p> Remember to make the appropriate entries in hosts.allow (e.g.
4681
2833
ntop:192.168.0.) and hosts.deny (e.g. ntop:ALL)
4684
However, tcpwrappers and https:// is known not to work - see docs/KNOWN_BUGS
2835
<p> However, tcpwrappers and https:// is known not to work - see docs/KNOWN_BUGS
4689
My filter doesn't work! I'm running ntop like this:
2838
<p><b>Q.</b> My filter doesn't work! I'm running ntop like this:</p>
4692
/usr/local/bin/ntop -u nobody -L -d -E -w 3000 -S 2 \
2840
/usr/local/bin/ntop -u nobody -L -d -E -w 3000 \
4693
2841
-m 192.168.10.0/24,xxx.xxx.xxx.xxx/32 \
4694
2842
-M -i eth0,eth1 \
4695
2843
(src net 192.168.10.0/24 or src host xxx.xxx.xxx.xxx ) \
4696
2844
and not dst net 192.168.10.0/24
4700
Yup, it doesn't work. Use the -B option and put the filter in quotes:
2846
<p><b>A.</b> Yup, it doesn't work. Use the -B option and put the filter in quotes:</p>
4703
2848
-B "(src net 192.168.10.0/24 or src host xxx.xxx.xxx.xxx ) and
4704
2849
not dst net 192.168.10.0/24"
4707
ntop used to assume anything it didn't recognize was a filter. But not since
2851
<p> ntop used to assume anything it didn't recognize was a filter. But not since
4708
2852
2.1.3. If you try this now, you should see a log warning that says maybe you
4709
2853
forgot the quotes
4714
I have experienced problems defining multiple filters: ntop reports 'syntax
2856
<p><b>Q.</b> I have experienced problems defining multiple filters: ntop reports 'syntax error'
4719
If you believe the filter is syntactically correct then it's likely that the
4720
Libpcap you have used has been compiled using an old non-reentrant version of
2858
<p><b>A.</b> If you believe the filter is syntactically correct then it's likely that the Libpcap you have used has been compiled using an old non-reentrant version of
4721
2859
flex. Please make sure you're using version 2.5.4 or above.
4726
Can you give some additional examples of filters?
4730
man tcpdump -- see "expression"
4733
A couple of simple examples, courtesy of B. Loic:
2862
<p><b>Q.</b> Can you give some additional examples of filters?</p>
2863
<p><b>A.</b> man tcpdump -- see "expression"</p>
2864
<p> A couple of simple examples, courtesy of B. Loic:
4737
2868
-B "host not 192.168.1.100 and not 192.168.1.101"
4740
to exclude hosts 192.168.1.100 and 192.168.1.101 from tracking (FQDN
2870
<p> to exclude hosts 192.168.1.100 and 192.168.1.101 from tracking (FQDN
4741
2871
such as www.yahoo.com will work too).
4744
If you need to exclude a full IP range, you will want to use something like
2873
<p> If you need to exclude a full IP range, you will want to use something like
4748
2877
-B "net not 192.168.1.0/24"
2880
<p><b>Q.</b> What about the backtrace?</p>
2881
<p><b>A.</b> Sadly, probably useless. Why? Too much information isn't available:</p>
2884
Here's one (and a pretty good, obvious one at that):
2888
ntop[23720]: **FATAL_ERROR** RRD: caught signal 11 SIGSEGV
2889
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: backtrace is:
2890
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 1. /usr/bin/ntop [0x42028c48]
2891
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 2. /usr/bin/ntop(getopt_long+0x43) [0x420c4e83]
2892
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 3. /usr/lib/ntop/plugins/rrdPlugin.so(rrd_update+0x61) [0x44157f7d]
2893
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 4. /usr/lib/ntop/plugins/rrdPlugin.so [0x441481a2]
2894
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 5. /usr/lib/ntop/plugins/rrdPlugin.so(updateCounter+0x19) [0x44148a15]
2895
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 6. /usr/lib/ntop/plugins/rrdPlugin.so [0x4414ba49]
2896
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 7. /lib/i686/libpthread.so.0 [0x41138941]
2897
ntop[23720]: **FATAL_ERROR** RRD: BACKTRACE: 8. /usr/bin/ntop(__clone+0x3a) [0x420da1ca]
2901
See: It doesn't give the routines, just the hex offsets from some points in the executable.
2902
It seems to say that rrdPlugin's updateCounter called rrd_update which called getopt_long. But
2903
then getopt_long called something else and that's what died... plus we don't see the parameters.
2907
Sometimes it works great for me on my box, because I can use the tools to figure out precisely
2908
where it means. But often I use gdb too. Move off my box and the odds of your compile and my
2909
compile (and our ./configure and all the tool versions) matching so that the offsets mean something
2913
<p><b>Q.</b> What do these log messages mean?</p>
2916
**ERROR** mVLAN: Host (identical IP/MAC) found on multiple VLANs
2917
mVLAN: ntop continues but will consolidate and thus probably overcount this traffic
2918
mVLAN: Up to 10 examples will be printed
2919
mVLAN: Host 192.168.aaa.bbb (00:12:17:xx:yy:zz) VLANs 3 and 4
2921
<p><b>A.</b> Once again, they mean what they say. ntop found something pretty weird. It found packets for the same 'host' (that is the same IP and MAC address) on two different VLANs. In this
2922
case, IP 192.168.aaa.bbb, MAC 00:12:17:xx:yy:zz on VLAN 3 and VLAN 4.
2924
<p> It's not WRONG, but it's definitely odd. If we see a packet twice, we count it twice, so -
2925
via this message - we're warning you that we might be double counting some traffic. We warn
2926
you ONCE per host (per ntop run) and for only up to 10 hosts, so as not to innundate you with
2927
meaningless warnings.
2929
<p> On the about page is a count (if you've even seen this junk), in the "Host/Session counts - global"
2930
section. If it's just a couple, ignore it.
2932
<p> If you see a lot of this stuff, you may want to rethink your ntop sensor placement or at least
2933
understand what you are doing. On my home LAN, I use a 802.1q VLAN trunk to move traffic between
2934
two switches and have a passive tap on the trunk. Traffic to/from the firewall moves over this trunk,
2935
so I see the same packet on the YELLOW(DMZ) VLAN and the GREEN(TRUSTED) VLAN all the time.
2937
<p> Why even bother trapping and warning? Well, there is one bad thing from ntop's perspective with
2938
duplicated hosts, which would occur if we didn't trap this, and that is that you would also
2939
see a lot of RRD errors when ntop tries to update the same host twice:
2941
<p> **WARNING** RRD: rrd_update(/usr/.../ipBytesSent.rrd) error: illegal attempt to update using time
2944
1109523297 when last update time is 1109523297 (minimum one second step)
4750
2946
<h2>Running - Web Server</h2>
4754
ntop shows an older, single menu interface
4758
If ntop is unable to find the file index.html it generates the page
4759
internally. That page refers to 'leftindex.html' which is the all-in-one menu
4760
you see, similar to the v1.3 menu.
4763
To find the html files, ntop looks in the html subdirectory in two places:
4767
1. In the current directory (i.e. ./html),
4769
2. In '[prefix]/share/ntop/html'
4770
(where [prefix] is set by the --prefix option of your ./configure
4778
1. Is manually installing ntop in an unusual place, having forgotten to
4779
update DATAFILE_DIR in config.h. Or forgetting to copy the html
4780
subdirectories, etc.
4784
2. Forgetting to run './autogen.sh -1' first and 'make install' last when
4785
first building ntop from source.
4789
3. Running ntop with an explicit path from somewhere other that the
4790
directory it's installed into. For example, if you install ntop
4791
into /root/ntop, but run it like this:
4800
It will look 1st in /usr/bin/html and then in [prefix]/share/ntop
4801
and not find the html files in /root/ntop/html!
4804
This often occurs when running ntop as a daemon, because the current
4805
working directory of the script is not what you expect it to be!
4810
Why does ntop display bits of my web site, instead of its own pages?
4814
ntop is designed to search the current working directory for data files,
4815
such as the html subdirectory, before it searches the default directories.
4821
You are one of those rare souls who happen to have had an unrelated
2948
<p><b>Q.</b> Why does ntop display bits of my web site, instead of its own pages?</p>
2949
<p><b>A.</b> ntop is designed to search the current working directory for data files, such as the html subdirectory, before it searches the default directories.
2951
<p> This is a feature.
2953
<p> You are one of those rare souls who happen to have had an unrelated
4822
2954
subdirectory 'html' with a file named 'index.html' as a subdirectory
4823
2955
of the current working directory at the time that you launched ntop.
4824
2956
cd to an acceptable directory, such as /usr/share/ntop, before
4825
2957
launching ntop.
4830
What are High/Medium/Low risk flags
4834
They are set in reportUtils.c based on fairly self-obvious functions
4835
Well documented in the help.html page, reachable by clicking on
2960
<p><b>Q.</b> What are High/Medium/Low risk flags</p>
2961
<p><b>A.</b> They are set in reportUtils.c based on fairly self-obvious functions Well documented in the help.html page, reachable by clicking on
4836
2962
the problem descriptions or via http://127.0.0.1:3000/help.html
4839
Often seen if you are monitoring a backbone or common network (high)
2964
<p> Often seen if you are monitoring a backbone or common network (high)
4840
2965
or if you have cloned MAC addresses for, say, a home Firewall box.
4845
What does the "Users" flag mean on a host?
4849
If you go to the "Info about host xxxx" page, there will be data
4850
in the "Known Users" section, if it's acting as a server for certain
2968
<p><b>Q.</b> What does the "Users" flag mean on a host?</p>
2969
<p><b>A.</b> If you go to the "Info about host xxxx" page, there will be data in the "Known Users" section, if it's acting as a server for certain
4854
In sessions.c, the function updateHostUsers() is used to maintain the list
2972
<p> In sessions.c, the function updateHostUsers() is used to maintain the list
4855
2973
of "users" of a host. In handleSession(), as part of the protocol level
4856
2974
analysis, the "user" information for various protocols is pulled out of the
4857
2975
packets. Stuff like the "X-Kazaa-Username" header, the "MAIL FROM:" header,
4861
We tag users as one or more of the following types:
2978
<p> We tag users as one or more of the following types:
4864
2981
P2P_USER, SMTP_USER, FTP_USER, POP_USER, IMAP_USER
4867
Note that for P2P, we also record - where possible - whether this user is
2983
<p> Note that for P2P, we also record - where possible - whether this user is
4868
2984
in P2P_UPLOAD_MODE and/or P2P_DOWNLOAD_MODE.
4873
Why are some of the host names in different colors?
4877
Colors are used on several of the ntop pages to convey extra
4878
information to the user. (in particular the ACTIVE TCP SESSIONS
2987
<p><b>Q.</b> Why are some of the host names in different colors?</p>
2988
<p><b>A.</b> Colors are used on several of the ntop pages to convey extra information to the user. (in particular the ACTIVE TCP SESSIONS
4879
2989
and the LOCAL HOST STATS pages). There are five colors used to
4880
2990
depict how long ago the host was first seen by ntop.
4883
The pages which display these colors use a html style sheet called
2992
<p> The pages which display these colors use a html style sheet called
4884
2993
style.css located in the normal html subdirectory (where ntop is
4885
2994
installed). This happens by setting the 'class=' parameter of
4886
2995
the html 'A' (Anchor or hyper-link) tag. The style sheet defines
5422
3398
handed directly to the Proxy engine, it can't be HTTPS or ntop's web server
5423
3399
will not recognize it.
5426
Now, you should be able to simply connect to
3401
<p> Now, you should be able to simply connect to
5427
3402
https://secure.tobiasly.com/ntop/ , and you're ready to go!
3404
<p> NOTE courtesy of Bruno Lebayle <lebayle@esrf.fr>
3406
<p> I had many problems with the "Rewrite" stuff described in the FAQ. After
3407
some Google search, it appears that HTTP_REFERER is sometimes not
3408
reliable, and the browser I am using (Firefox/Solaris) does not seem to
3409
present this header properly.
3410
So I've found an other way to do it, and this proves to work with many
3413
<p> within mod_proxy.c:
3416
ProxyPass /ntop/ http://localhost:3000/
3417
ProxyPassReverse /ntop/ http://localhost:3000/
3419
<p> <IfModule mod_rewrite.c>
3424
RewriteLog logs/rewrite_log
3425
RewriteCond %{REQUEST_URI} !^/$
3426
RewriteCond %{REQUEST_URI} !^/home.html$
3427
RewriteCond %{REQUEST_URI} !^/ntop/
3428
RewriteRule ^/([^/]+\.[a-z]+)$ http://nms.my.domain:my_port/ntop/$1[L,P]
3431
<p> Where http://nms.my.domain:my_port is:
3432
- the host where the network management tools are located with the
3433
proper authentication
3434
- the host where the above Apache config has to be set
3435
- the host where ntop is installed on port 3000 in this example
3436
Where the Web site on this host has no URL in the form of /xxx.xxx aprt
3437
from / and /home.html (additions can be made in the RewriteCond)
3439
<p> Especially, the trailing "/" after /ntop in the RewriteCond is
3440
mandatory, since e.g. the Ntop logo is /ntop_logo.gif and would match
3443
<p> # Rewrite help summary:
3444
# HTTP_REFERER = pattern in the name of the page from which the request comes
3445
# THIS IS NOT RELIABLE AND DIFFERS AMONG BROWSERS !!!
3446
# REQUEST_URI = contents of the request (^ = start of line, $ = end of line,
3447
# ! = not the text which follows
3448
# All conditions preceding a rule are evaluated
3449
# All rules are processed in sequence
3450
# Rewrite: () = group of text used for the substitution,
3451
# . = any char, * = repeated 0-N times,
3452
# + = repeated 1-N times, ^ = not this char, [chars] = one of chars
3453
# special characters escaped by \ e.g. the dot as \.
3454
# $1 means the 1st group of text between ()
3455
# Flags L = last (i.e. exit from the rewriting process)
3456
# P = proxy (i.e. use the proxy module for this URL)
3458
# Full doc in http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
3459
# Useful help in http://rewrite.drbacchus.com/rewritewiki/
5429
3461
<h2>Running - Web Server - i18n</h2>
5433
Is ntop localized for language x? (i18n)
5437
No. ntop wasn't really written with i18n in mind.
5440
Most of the text is generated in-line, on the fly. Plus ntop must
3463
<p><b>Q.</b> Is ntop localized for language x? (i18n)</p>
3464
<p><b>A.</b> No. ntop wasn't really written with i18n in mind.</p>
3465
<p> Most of the text is generated in-line, on the fly. Plus ntop must
5441
3466
dynamically support multiple locales simultaneously.
5444
However, beginning with v2.1.56 (2.2 development release), there is limited,
3468
<p> However, beginning with v2.1.56 (2.2 development release), there is limited,
5445
3469
optional, i18n support in ntop.
5450
So, what internationalization (i18n) support does ntop provide.
5454
The key word is LIMITED
5457
This only applies to the pages that are pulled from .html files, NOT those
3472
<p><b>Q.</b> So, what internationalization (i18n) support does ntop provide.</p>
3473
<p><b>A.</b> The key word is LIMITED</p>
3474
<p> This only applies to the pages that are pulled from .html files, NOT those
5458
3475
created internally. This includes the menus and the few static text pages,
5459
3476
but none of the pages with interesting data on them.
5462
The localized pages must be placed in parallel directories to the existing
3478
<p> The localized pages must be placed in parallel directories to the existing
5466
For example, if ntop is installed in /usr/share/ntop, the html files are in
3481
<p> For example, if ntop is installed in /usr/share/ntop, the html files are in
5467
3482
/usr/share/ntop/html.
5470
To support them Canadians, then, you would need to create a
3484
<p> To support them Canadians, then, you would need to create a
5471
3485
/usr/share/ntop/html_en_CA AND that locale would need to be installed on the
5472
3486
ntop host system.
5475
Note that there are NO i18n files distributed with ntop (yet!)
3488
<p> Note that there are NO i18n files distributed with ntop (yet!)
5478
At ./configure time, you enable support via --enable-i18n. ntop MUST be told
3490
<p> At ./configure time, you enable support via --enable-i18n. ntop MUST be told
5479
3491
how to find the locale files. In ./configure, a "standard" location is
5480
3492
defined per OS.
5483
(Initially only the value for FreeBSD is populated). All others assume the
3494
<p> (Initially only the value for FreeBSD is populated). All others assume the
5484
3495
"default", /usr/lib/locale. If that isn't right for your OS, then you MUST
5485
3496
use the optional parameter --with-localedir= to tell ntop where to find the
5489
At run time, ntop scans the host for the installed locales (locale -a should
3499
<p> At run time, ntop scans the host for the installed locales (locale -a should
5490
3500
- on most systems give you a list) and checks if a comparable html_cc_XX
5491
3501
directory exists.
5494
This builds a list of supported languages, which (along with i18n status) is
3503
<p> This builds a list of supported languages, which (along with i18n status) is
5495
3504
shown on the configuration pages, info.html and textinfo.html.
5498
When an http request is made, your browser sends a list of languages it is
3506
<p> When an http request is made, your browser sends a list of languages it is
5499
3507
willing to accept in the http Accept-Language: header.
5502
(check View | Internet Options | Languages in IE to see what you're sending)
3509
<p> (check View | Internet Options | Languages in IE to see what you're sending)
5509
3515
Accept-Languages: en_US, en
5512
Means that you prefer US English, but will accept any English dialect if US
3517
<p> Means that you prefer US English, but will accept any English dialect if US
5513
3518
English isn't available.
5516
Be aware that the locale settings and Accept-Language settings are not well
3520
<p> Be aware that the locale settings and Accept-Language settings are not well
5517
3521
standardized, nor common and may not necessarily map very cleanly. You
5518
3522
should see what's defined (perhaps it's locale 'german' instead of 'gr') and
5519
3523
make or link directories as necessary. You can always create the directory
5520
3524
you tell ntop to use via --with-localedir= in the /usr/share/ntop structure
5521
3525
and create links from there to the real locale directories!
5524
Limits in the per-request and total # of languages to support are in
3527
<p> Limits in the per-request and total # of languages to support are in
5525
3528
globals-defines.h
5528
Because of directory structure limits, a lack of interest in multiple
3530
<p> Because of directory structure limits, a lack of interest in multiple
5529
3531
character sets, etc. the locale and accept-language headers are coerced into
5530
3532
a common format:
5533
locales are ll[_XX][.char][@modifier]
3534
<p> locales are ll[_XX][.char][@modifier]
5809
3691
lawsuit, arbitration proceeding, etc. in conjunction with your use of
5810
3692
the sample p3p file.
5813
Since your legal department would be nuts to agree to that I doubt it will
3694
<p> Since your legal department would be nuts to agree to that I doubt it will
5819
So How do I create a .p3p file?
5823
There are tools available to create p3p policy files - search the web for
5824
'p3p editor'. One that I've used is a zero cost albeit beta tool, p3peditor
3698
<p><b>Q.</b> So How do I create a .p3p file?</p>
3699
<p><b>A.</b> There are tools available to create p3p policy files - search the web for 'p3p editor'. One that I've used is a zero cost albeit beta tool, p3peditor
5825
3700
from IBM (http://www.alphaworks.ibm.com/tech/p3peditor).
5827
3702
<h2>Networks, Network cards and Networking</h2>
5831
My security people won't let me run in promiscuous mode.
5838
Or, use the -s option and accept the limitations...
5841
Ask them "honestly, what is the problem" - other than having an interface
3704
<p><b>Q.</b> My security people won't let me run in promiscuous mode.</p>
3705
<p><b>A.</b> Tough...</p>
3706
<p> Or, use the -s option and accept the limitations...
3708
<p> Ask them "honestly, what is the problem" - other than having an interface
5842
3709
in promiscuous mode is a signature of a sniffer and security folks look for
5843
3710
unauthorized sniffers?
5846
ntop needs promiscuous mode so that it sees the full range of traffic. Any
3712
<p> ntop needs promiscuous mode so that it sees the full range of traffic. Any
5847
3713
similar product will do the same thing.
5850
If the security people think traffic on the wire is secure, they're wrong!
3715
<p> If the security people think traffic on the wire is secure, they're wrong!
5851
3716
Face facts - just about every Windows user, except for 2K/XP Pro (and then
5852
3717
only if TBTP have especially locked them down) can install the windows
5853
3718
version of tcpdump...
5856
If it's a checklist item, just gen up a form to "authorize" it, have the
3720
<p> If it's a checklist item, just gen up a form to "authorize" it, have the
5857
3721
boss and VP/CIO sign it and give it to them.
5862
What is Ethernet and TCP/IP and how do they differ?
5866
Both are protocols - that is the definition of how
5867
to interpret bits on wires (or in packets) into
3724
<p><b>Q.</b> What is Ethernet and TCP/IP and how do they differ?</p>
3725
<p><b>A.</b> Both are protocols - that is the definition of how to interpret bits on wires (or in packets) into
5868
3726
meaningful conversations.
5871
Ethernet is the lower level, wire (or wireless) protocol,
3728
<p> Ethernet is the lower level, wire (or wireless) protocol,
5872
3729
concerned with moving the physical bits of data.
5875
TCP/IP is the higher-level protocol, which explains
3731
<p> TCP/IP is the higher-level protocol, which explains
5876
3732
how to interpret the block of bits (frame).
5879
TCP/IP uses a familiar 32-bit "IP" address, e.g.
3734
<p> TCP/IP uses a familiar 32-bit "IP" address, e.g.
5883
Ethernet uses a less familiar, 48 bit unique to the NIC
3737
<p> Ethernet uses a less familiar, 48 bit unique to the NIC
5884
3738
(some times called "burned in") address, e.g.
5885
3739
00:40:05:DE:AD:00. This is called the MAC (Media
5886
3740
Access Control) address.
5889
FYI: The official IEEE MAC address lookup is at
3742
<p> FYI: The official IEEE MAC address lookup is at
5892
3745
http://standards.ieee.org/regauth/oui/index.shtml
5893
3746
(Look up the first six digits, separated by -s, e.g. 00-40-05)
5898
OK, but how is stuff sent from my computer to, say, Yahoo!?
5902
First off, your computer does a lookup - using a service
5903
called DNS (Domain Name Service) to convert www.yahoo.com
3749
<p><b>Q.</b> OK, but how is stuff sent from my computer to, say, Yahoo!?</p>
3750
<p><b>A.</b> First off, your computer does a lookup - using a service called DNS (Domain Name Service) to convert www.yahoo.com
5904
3751
to a numeric value, such as 66.218.71.80.
5907
Then it builds a collection of characters that says send
3753
<p> Then it builds a collection of characters that says send
5908
3754
this data from me, 192.168.0.1 to Yahoo at 66.218.71.80.
5909
3755
This is called a packet. That gets wrapped in an Ethernet
5910
3756
frame (addressed from 00:40:05:DE:AD:00 to the MAC address
5911
3757
of the local gateway router, 0:d0:9e:6:38:00 and squirts it
5912
3758
out the router.
5915
Packets are forwarded step by step along a path from you
3760
<p> Packets are forwarded step by step along a path from you
5916
3761
to Yahoo by computers called routers. This is done based
5917
3762
on the 32 bit IP address and the router's knowledge of the
5921
Each router sees a Ethernet frame addressed to it (by
3765
<p> Each router sees a Ethernet frame addressed to it (by
5922
3766
MAC address), checks the TCP/IP address to figure out
5923
3767
where to send it next, re-wraps the TCP/IP packet in a new
5924
3768
Ethernet frame (with the from MAC as it's own and the to
5925
3769
MAC as the next hop).
5928
This happens until the TCP/IP packet reaches the final
3771
<p> This happens until the TCP/IP packet reaches the final
5929
3772
segment (the last router). Once it reaches a router that
5930
3773
knows it has addresses 66.218.71.0-66.218.71.255 on one
5931
3774
of it's interface, the routing stops using the TCP/IP
5935
The last hop is done (like each intermediate hop - at the
3777
<p> The last hop is done (like each intermediate hop - at the
5936
3778
lowest level) based on the MAC address! Specifically, the
5937
3779
last router does an "ARP" (Address Resolution Protocol") query,
5938
3780
to find out "Who Has" address 66.218.71.80. The NIC responds
6201
3989
Host 1: IP 192.168.1.1 MAC 00:00:00:aa:aa:aa
6202
3990
Host 3: IP 192.168.1.3 MAC 00:00:00:cc:cc:cc
6205
If somebody has the incorrect hosts table, dns, cached, whatever
3992
<p> If somebody has the incorrect hosts table, dns, cached, whatever
6206
3993
but has the info that Host 1 is 192.168.1.3 and is on the same
6207
3994
subnet, then it will send a packet where the Ethernet layer and
6208
3995
the ip are nonsense. But because it's on the same wire, the ip
6212
(Ethernet from:00:00:00:dd:dd:dd to:00:00:00:aa:aa:aa)
3998
<p> (Ethernet from:00:00:00:dd:dd:dd to:00:00:00:aa:aa:aa)
6215
4001
(tcp s=192.168.1.4 d=192.168.1.3)
6218
ntop will read both out of the packet and create the association
4003
<p> ntop will read both out of the packet and create the association
6222
4007
192.168.1.3=00:00:00:aa:aa:aa
6225
Since it doesn't know better.
6231
(Ethernet from:00:00:00:ee:ee:ee to:00:00:00:cc:cc:cc)
4009
<p> Since it doesn't know better.
4011
<p> Then when it sees
4013
<p> (Ethernet from:00:00:00:ee:ee:ee to:00:00:00:cc:cc:cc)
6234
4016
(tcp s=192.168.1.5 d=192.168.1.3)
6237
It will create the multihomed association...
4018
<p> It will create the multihomed association...
6242
So what's a hub vs. a Switch
6246
A hub is a device that links a bunch of computers together
6247
at the wire (Ethernet) level. Logically, Ethernet is a bus,
4021
<p><b>Q.</b> So what's a hub vs. a Switch</p>
4022
<p><b>A.</b> A hub is a device that links a bunch of computers together at the wire (Ethernet) level. Logically, Ethernet is a bus,
6248
4023
that is everybody sees all the traffic, just like cars crossing
6249
4024
under a highway bridge. Physically, Ethernet is wired like
6250
4025
a star - with all the wires coming back to a central "hub".
6251
4026
The hub is just the device that makes the electric star look
6252
4027
like a shared bus.
6255
Switches and Hubs operate at the Ethernet level, not TCP/IP.
4029
<p> Switches and Hubs operate at the Ethernet level, not TCP/IP.
6259
Watch out for 'Switched hubs', which are hubs that include an
6260
internal switch between 2 or more segments (for example, BUT
4031
<p><b>A.</b> Watch out for 'Switched hubs', which are hubs that include an internal switch between 2 or more segments (for example, BUT
6261
4032
NOT LIMITED TO a 10BaseT and 100BaseT) segment. These are hubs
6262
4033
within a segment, but switches across segments. ntop may not
6263
4034
see the traffic you expect if you have a 'switched hubs' and
6264
4035
manufacturers are pretty bad about marking them. See
6265
4036
http://article.gmane.org/gmane.linux.ntop.general/5081
6269
A switch is a smart hub.
6272
Switches improve performance by creating a virtual Ethernet
4038
<p><b>A.</b> A switch is a smart hub.</p>
4039
<p> Switches improve performance by creating a virtual Ethernet
6273
4040
bus for the duration of the packet that joins JUST the source
6274
4041
and destination ports.
6277
A switch operates via an internal table of MAC addresses.
4043
<p> A switch operates via an internal table of MAC addresses.
6278
4044
It learns (or is programmed) that 0:d0:9e:6:38:00 is on
6279
4045
port 1, while 00:40:05:DE:AD:00 is on port 3.
6282
A packet coming in port 1, destined for 00:40:05:DE:AD:00
4047
<p> A packet coming in port 1, destined for 00:40:05:DE:AD:00
6283
4048
is sent out ONLY port 3.
6286
If the switch doesn't know (or the packet is a broadcast),
4050
<p> If the switch doesn't know (or the packet is a broadcast),
6287
4051
it gets sent out all ports.
6290
This doesn't make for MORE bandwidth, but it does use it
4053
<p> This doesn't make for MORE bandwidth, but it does use it
6291
4054
more efficiently. That is in addition to the session between
6292
4055
ports 1 and 3 at 100Mbps, a second, simultaneous 100Mbps
6293
4056
session can occur between ports 2 and 4.
6298
How do I use ntop in a switched network?
6302
First off, you need to be or have the support of
6303
your network administrator. (Yes, you can do something
4059
<p><b>Q.</b> How do I use ntop in a switched network?</p>
4060
<p><b>A.</b> First off, you need to be or have the support of your network administrator. (Yes, you can do something
6304
4061
called "ARP poisoning" to - maybe - get the switch to send
6305
4062
you all the traffic, but that's beyond this FAQ... STFW)
6308
Many switches (although not the USD$50 cheap "workgroup" units)
4064
<p> Many switches (although not the USD$50 cheap "workgroup" units)
6309
4065
have a special port or mode, where by all the traffic for the
6310
4066
entire network gets copied out that port, in addition to the
6311
4067
normal switch action.
6314
When you invoke the monitoring mode (called span, mirror, monitor,
4069
<p> When you invoke the monitoring mode (called span, mirror, monitor,
6315
4070
analysis, etc.), you are forcing the entire switch bandwidth out one
6316
4071
port. This may exceed the bandwidth of the port. 100Mbps+100Mbps
6320
Traffic that is being sent to the monitoring port in excess of the
4074
<p> Traffic that is being sent to the monitoring port in excess of the
6321
4075
capacity of that port is usually dropped. It should NOT slow down
6322
4076
the switch on other ports.
6325
Some switches have some buffering capability and it *may* be able to
4078
<p> Some switches have some buffering capability and it *may* be able to
6326
4079
keep up with an occasional burst of traffic, as long as the average
6327
4080
is below the port capacity and the buffer isn't exceeded.
6330
See, for example, http://www.cisco.com/warp/public/473/41.html#archXL.
4082
<p> See, for example, http://www.cisco.com/warp/public/473/41.html#archXL.
6333
One list of switch manufacturers is the document is titled "REFERENCE:
4084
<p> One list of switch manufacturers is the document is titled "REFERENCE:
6334
4085
Configuring a Switch to Monitor All Traffic" from Elron Software. (The
6335
4086
URL is long, do a Google search for "site:elronsoftware.com wi6038").
6337
4088
<h2>Dumping data</h2>
6341
Can I use ntop from php/perl?
6345
Yes you can. Please see the www directory under the ntop source tree.
6349
Look at the Admin | Dump Data page.
4090
<p><b>Q.</b> Can I use ntop from php/perl?</p>
4091
<p><b>A.</b> Yes you can. Please see the www directory under the ntop source tree.</p>
4092
<p><b>A.</b> Look at the Admin | Dump Data page.</p>
6351
4093
<h2>rrd (myrrd)</h2>
6355
How do I save data between runs?
4095
<p><b>Q.</b> How do I save data between runs?</p>
4096
<p><b>A.</b> Use rrd.</p>
6368
There's a 12 page writeup on what rrd is and what ntop does with it.
6369
A pdf version is posted at SourceForge in the "Documentation" release.
4098
<p><b>Q.</b> What's rrd?</p>
4099
<p><b>A.</b> There's a 12 page writeup on what rrd is and what ntop does with it. A pdf version is posted at SourceForge in the "Documentation" release.
6370
4100
Download it and read it.
6379
Yup - the pretty pictures won't work in this FAQ.
6388
ntop includes a frozen and slightly patched version of rrd 1.0.42 in the
6389
ntop source tree. This is called myrrd.
6392
As of rrdtool 1.0.46 was released 04-Jan-2004.
6401
You should not need to do anything to get rrd (see myrrd, above).
6404
The home page for rrd is
4103
<p><b>Q.</b> Do I gotta?</p>
4104
<p><b>A.</b> Yup - the pretty pictures won't work in this FAQ.</p>
4106
<p><b>Q.</b> I'm lazy - What is rrd?</p>
4107
<p><b>A.</b> RRD stands for "round-robin database". It is a special type of database designed for holding sequences of information over periods of time, without growing in size.
4109
<p> Rrdtool is a tool for manipulating RRDs. The home page for rrdtool is at
4110
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
4112
<p> What do they do? Well, suppose you want to compute the average of the traffic to your
4113
web site for the last fifteen minutes. If you record the data each minute and save it
4114
in a traditional database it looks like this:
4125
<p> While you have the data to compute the total, the database grows in size forever. And
4126
all you really need are the last 15 values. Certainly you can create a purge routine
4127
and periodically remove the old data. But this type of constantly growing SQL database
4128
- even with a prune process - will require reorganization and rebuilds over time.
4130
<p> Suppose you had some kind of data structure where the last value was thrown away each
4131
time you added a new one. When it comes time to store the 11:01 value, you overlay the
4132
10:46 value. At any time, you still have the last 15 values. That - slightly simplified -
4133
is an RRD. The benefit is that your database never grows in size. The down side is that
4134
everything else in your history is gone - if your needs ever change, tough.
4136
<p> The ring buffers are called round-robin archives or RRAs. The RRA actually stores the
4137
RATE (bits per second), so the 10:47 value of 0.27 Megabytes is 0.27 * 1024*1024 * 8 / 60
4138
or 37748.736 (bits per second). But it functions just like the rings described above.
4140
<p> ntop uses RRDs to store data over long periods of time. Separate files are created for
4141
each counter, in a structure that reflects the interfaces and hosts ntop sees. The specifics
4142
of what's recorded - interfaces or not, hosts or not, etc. is controlled by switches on the
4145
<p> (Read the paper - it goes on from here, with specific details on how ntop uses RRDs).
4148
<p><b>Q.</b> What's myrrd?</p>
4149
<p><b>A.</b> ntop includes a frozen and slightly patched version of rrd 1.0.49 in the ntop source tree. This is called myrrd.
4151
<p> rrdtool 1.0.49 was released 08-Aug-2004.
4154
1.0.50 was released 25-Apr-2005.
4156
<p> rrdtool 1.2.x began to be released in Apr 2005.
4159
<p><b>Q.</b> What's rrdtool?</p>
4160
<p><b>A.</b> rrdtool is the packaged program to access the various rrd routines (export, dump, graph) from the command line.
4163
<p><b>Q.</b> How do I get it?</p>
4164
<p><b>A.</b> The myrrd version included with ntop doesn't have rrdtool. Assuming you haven't installed an rrdtools package (which ntop ignores), here is how to get rrdtool:
4166
<p> The myrrd version is a frozen copy of rrdtool 1.0.49, so your best bet is to go to the
4167
rrdtool home page, http://www.rrdtool.com/ or the download page,
4168
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/ and download rrdtool-1.0.49.tar.gz.
4170
<p> Once you have it, it's pretty standard.
4172
<p> $ tar xfvz rrdtool-1.0.49.tar.gz $ cd rrdtool-1.0.49 $ ./configure
4174
<p> (You can add --prefix=/usr if you want)
4178
<p> This runs a few minutes.
4184
<p> but remember, ntop just ignores this, so why bother? All you really need are the rrdtool
4185
executable program (src/rrdtool) and maybe a few of the files in the doc/ directory. Just
4186
copy them where you want them and then delete the whold build directory.
4189
<p><b>Q.</b> Where do I get rrd?</p>
4190
<p><b>A.</b> Unless you need rrdtool, you should not need to do anything to get rrd (see myrrd, above).</p>
4191
<p> The home page for rrd is
6405
4192
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
6408
rpm's are available at
4194
<p> rpm's are available at
6409
4195
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub
6414
What about the multi-threaded development version?
6418
Stay away. I only experimented with it a little bit, but it was not
4198
<p><b>Q.</b> What about the multi-threaded development version?</p>
4199
<p><b>A.</b> Stay away.</p>
4200
<p> (UPDATED) I was able to patch ntop to work with 1.2.7+ and experimented with it a little bit.
4202
<p> The binary .rrd file formats are different, so if you try 1.2.x, any new .rrd files which are
4203
created are incompatible.
4205
<p> The new version doesn't use freetype, it uses libart, which introduces a different (not better,
4206
nor worse) chain of dependencies.
6436
4223
A: Create the rrd directory and make sure that the -u userid has read/write
6437
4224
access to it (typically /usr/share/ntop/rrd).
6442
rrdPlugin - problem with rrd/myrrd?
6446
By default, ntop's Makefile binds the static libmyrrd library to create ntop's
6447
rrdPlugin shared library. THIS IS DELIBERATE so that you use the myrrd library
4229
A: Remember to activate the plugin. You will need to configure it, and remember that
4230
the default configuration does not include per-host data.
4233
<p><b>Q.</b> What's the difference in the Host Detail Level for RRDs?</p>
4234
<p><b>A.</b> Low is just the bare counts, pktSent/pktRcvd and bytesSent/bytesRcvd.</p>
4239
pktDuplicatedAckSent/pktDuplicatedAckRcvd,
4240
pktBroadcastSent, bytesBroadcastSent,
4241
pktMulticastSent, bytesMulticastSent,
4242
pktMulticastRcvd, bytesMulticastRcvd,
4243
bytesSentLoc, bytesSentRem, bytesRcvdLoc, bytesRcvdFromRem,
4244
ipBytesSent, ipBytesRcvd,
4245
tcpSentLoc, tcpSentRem, tcpRcvdLoc, tcpRcvdFromRem, tcpFragmentsSent, tcpFragmentsRcvd,
4246
udpSentLoc, udpSentRem, udpRcvdLoc, udpRcvdFromRem, udpFragmentsSent, udpFragmentsRcvd,
4247
icmpSent, icmpRcvd, icmpFragmentsSent, icmpFragmentsRcvd,
4260
arp_rarpSent, arp_rarpRcvd, arpReqPktsSent, arpReplyPktsSent, arpReplyPktsRcvd,
4261
decnetSent, decnetRcvd,
4262
appletalkSent, appletalkRcvd,
4263
netbiosSent, netbiosRcvd,
4264
otherSent, otherRcvd
4268
And the per-protocol Sent/Rcvd
4274
totContactedSentPeers, totContactedRcvdPeers
4278
And the per-IP-protocol Sent/Rcvd, e.g. IP_HTTP...
4281
<p><b>Q.</b> rrdPlugin - problem with rrd/myrrd?</p>
4282
<p><b>A.</b> By default, ntop's Makefile binds the static libmyrrd library to create ntop's rrdPlugin shared library. THIS IS DELIBERATE so that you use the myrrd library
6448
4283
and not some other version of rrd that's installed somewhere else on your system.
6451
Sometimes this causes problems, where there are special tricks required to tell
4285
<p> Sometimes this causes problems, where there are special tricks required to tell
6452
4286
(a non gnu ld) loader about static (.a) libraries, which ntop doesn't have in
6453
4287
the Makefile nor the configureextra files.
6456
As a SHORT TERM WORK-AROUND, you can TRY this:
4289
<p> As a SHORT TERM WORK-AROUND, you can TRY this:
4295
<p> Edit Makefile --
6467
4299
all: $(LIBRRD) libmyrrd.so
6468
4300
^^^^^^^^^^^ add this
4302
<p> Add these lines:
6475
4306
libmyrrd.so: $(OBJECTS)
6476
4307
<tab>ld -shared -o libmyrrd.so $(OBJECTS)
6479
Now do make. You should see a libmyrrd.so file.
4309
<p> Now do make. You should see a libmyrrd.so file.
6482
The main 'make' should now complete. Copy that libmyrrd.so file where the other
4311
<p> The main 'make' should now complete. Copy that libmyrrd.so file where the other
6483
4312
ntop library files are, and it MIGHT work.
6486
However, the whole idea behind having a static libmyrrd.a is to prevent version
4314
<p> However, the whole idea behind having a static libmyrrd.a is to prevent version
6487
4315
conflicts and use a stable version of rrd.
6490
The right fix is to get the configureextra/<whatever> file changed.
4317
<p> The right fix is to get the configureextra/<whatever> file changed.
6492
4319
<h2>netFlow and sFlow</h2>
6496
How do I access netFlow or sFlow data from ntop?
6500
You need to configure ntop as a listener (it can also be a collector, but
6501
that data shows up in the receiving interface, not under netFlow/sFlow).
6504
First, use the appropriate plugin to set the parameters - basically the port
4321
<p><b>Q.</b> How do I access netFlow or sFlow data from ntop?</p>
4322
<p><b>A.</b> You need to configure ntop as a listener.</p>
4323
<p> First, use the appropriate plugin to set the parameters - basically the port
6505
4324
you want ntop to listen on. Then, using the Admin | Set Interface menu item,
6506
4325
switch ntop to report on the sFlow/netFlow pseudo-device (NetFlow-device or
6512
Is there any parameter to set to tell sFlow which interface/ip address
6513
to use when exporting the flows?
6517
No. All ntop does is send a packet to the network addressed to the
6518
destination you request.
6521
Typically if the ntop host is multihomed, the routing service will pick the
6522
the MOST SPECIFIC route with the lowest metric # that is selected. E.g., if
6523
this is the routing table:
6526
Kernel IP routing table
6527
Destination Gateway Genmask Flags Metric Ref Use Iface
6528
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
6529
192.168.2.129 0.0.0.0 255.255.255.128 U 0 0 0 eth2
6530
192.168.2.146 0.0.0.0 255.255.255.255 U 0 0 0 eth1
6531
192.168.2.146 0.0.0.0 255.255.255.255 U 1 0 0 eth2
6532
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
6533
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0
6536
A packet to 192.168.2.146 goes via eth1 (equally specific routes, so it
6537
chooses based on the metric 0 vs. 1)
6540
A packet to 192.168.2.145 goes via eth2 (192.168.2.129/25 is more specific
6541
than 192.168.2.0/24)
6544
A packet to 192.168.2.46 goes via eth0
6547
A packet to 10.1.1.1 goes via eth0 (the gateway is the least specific route,
6548
but it is the best match)
6551
But how it goes out (and thus the source IP address) is totally up to the OS.
6552
Just be aware when it gets to the sflow collector, it might have an
6553
unexpected ip address as the source.
4329
<p><b>Q.</b> Can I use ntop as a netflow collector.</p>
4330
<p><b>A.</b> Not in the current versions - you used to be able, but that code was removed.</p>
6555
4331
<h2>netFlow</h2>
6559
Which versions of netFlow.
6564
And v1/v7/v9 - in that internally a v1/v7/v9 flow is copied to a v5 buffer and then
4333
<p><b>Q.</b> Which versions of netFlow.</p>
4334
<p><b>A.</b> v5 And v1/v7/v9 - in that internally a v1/v7/v9 flow is copied to a v5 buffer and then
6565
4335
processed. We default/ignore fields that are different.
6566
4336
And nFlow - similar conversion.
6571
netFlow doesn't work.
6575
You MUST make sure the ntop plugin is ACTIVE. With the change to allow
6576
setting parameters while inactive, it's easy to miss that last step.
4339
<p><b>Q.</b> netFlow doesn't work.</p>
4340
<p><b>A.</b> You MUST make sure the ntop plugin is ACTIVE. With the change to allow setting parameters while inactive, it's easy to miss that last step.
6577
4341
If you don't activate the plugin, you'll still have the netflow-device, but
6578
4342
no data on it...
6583
What's Virtual NetFlow Interface?
6587
Be sure and set it. It's important for pseudo-local classification, which
6588
affects L R reporting. You need to set it to the (network) and mask for
4345
<p><b>Q.</b> What's Virtual NetFlow Interface?</p>
4346
<p><b>A.</b> Be sure and set it. It's important for pseudo-local classification, which affects L R reporting. You need to set it to the (network) and mask for
6589
4347
the netFlow collector. So ntop knows 'where' the data is coming from.
6594
'splain some more, Lucy...
6601
It's best to think of netFlow like this:
6604
The physical interface which is monitoring the packets is like a
4350
<p><b>Q.</b> 'splain some more, Lucy...</p>
4351
<p><b>A.</b> OK.</p>
4352
<p> It's best to think of netFlow like this:
4354
<p> The physical interface which is monitoring the packets is like a
6605
4355
temperature probe you stick into a roast.
6608
Even though the display of the data can be right there at the probe, or
4357
<p> Even though the display of the data can be right there at the probe, or
6609
4358
the other end of a (long) wire, or somewhere entirely elsewhere via a
6610
4359
wireless connection, the probe is monitoring at the tip. If it says 145F,
6611
4360
that's the temperature of the meat - not the oven and not the kitchen.
6614
Similarly, the netFlow data ntop is receiving is based on the probe
4362
<p> Similarly, the netFlow data ntop is receiving is based on the probe
6618
So, if you have a router and are monitoring a single interface to collect
4365
<p> So, if you have a router and are monitoring a single interface to collect
6619
4366
netFlow data, then the ip address you want to give to ntop is that of
6620
4367
the router interface.
6623
If you are monitoring a router with more than one interface, you will
4369
<p> If you are monitoring a router with more than one interface, you will
6624
4370
need to give ntop ONE of those addresses and use the -m | --local-subnets
6625
4371
option to tell it that the other addresses are also local.
6630
Where is info about netflow?
6634
Dale Reed pointed out a good tech doc (no flak, just the formats) for netflow
4374
<p><b>Q.</b> Where is info about netflow?</p>
4375
<p><b>A.</b> Dale Reed pointed out a good tech doc (no flak, just the formats) for netflow</p>
6705
4434
show ip cache flow
6706
4435
show ip cache verbose flow
6709
Obviously, there is a lot more to it than this, for more information, see the
4437
<p> Obviously, there is a lot more to it than this, for more information, see the
6710
4438
Cisco web site: http://www.cisco.com/go/netflow
6713
4441
(Created by sholmes at snapshot, 02Feb2003)
4444
<p><b>Q.</b> Can I run ONLY w/ netFlow (Running ntop as a Collector for Net Flow only)</p>
4445
<p><b>A.</b> Sure.</p>
4446
<p> ntop is usually configured to capture all traffic from local interfaces. If no
4447
interface is given (e.g. option -i|--interface is missing), the "first" interface
4448
is taken. This value, typically eth0 on linux boxes, may not be what you wanted.
4450
<p> If you want to use ntop as a collector for Net Flow traffic only, you may want to
4451
supress all local traffic.
4453
<p> In this case use -i none or --interface none.
4455
<p> Remember to activate Net Flow plugin from Menu Admin->Plugin and to configure the
4456
plugin by setting "Local Collector UDP Port".
6723
The core component of the sFlow toolkit is the sflowtool command line
6724
utility. sflowtool interfaces to utilities such as tcpdump, ntop and Snort
4460
<p><b>Q.</b> What is sFlow</p>
4461
<p><b>A.</b> The core component of the sFlow toolkit is the sflowtool command line utility. sflowtool interfaces to utilities such as tcpdump, ntop and Snort
6725
4462
for detailed packet tracing and analysis, NetFlow compatible collectors for
6726
4463
IP flow accounting, and provides text based output that can be used in
6727
4464
scripts to provide customized analysis and reporting and for integrating with
6728
4465
other tools such as MRTG or rrdtool.
6734
http://www.inmon.com/sflowTools.htm
4469
<p> http://www.inmon.com/sflowTools.htm
6735
4470
http://www.faqs.org/rfcs/rfc3176.html
6740
I have activated the sFlow plugin in ntop. But it doesn't seem to
6741
generate any output based on the collected sflow datagrams.
6745
sFlow can be a collector or a receiver or both, depending on the
6746
settings configured via the plugin.
6749
If you configure ntop as an sFlow collector, it will use sFlow data
4473
<p><b>Q.</b> I have activated the sFlow plugin in ntop. But it doesn't seem to generate any output based on the collected sflow datagrams.
4475
<p><b>A.</b> sFlow can be a collector or a receiver or both, depending on the settings configured via the plugin.
4477
<p> If you configure ntop as an sFlow collector, it will use sFlow data
6750
4478
for generating reports, treating the remote collector(s) as another
6751
4479
network interface - see Admin | Switch NIC.
6753
<h2>snapshot, cvs and the Wiki</h2>
6757
What was "snapshot"?
6761
Snapshot was a community FAQ and documentation resource at
6762
http://snapshot.ntop.org. It's was also the site of "the snapshots".
6765
Unfortunately, snapshot seems to have 'Gone to Atlanta' (404), with
6766
the web server no longer responding in February 2004.
6769
Nicolai Petri's efforts were appreciated. But snapshot was an effort
6770
of love by a gentleman who hasn't had time for the effort in quite
6776
Is there a community resource that replaces (enhances) snapshot.
6780
Yes. There is now an ntop Wiki at
6783
http://www.burtonstrauss.com/pmwiki/pmwiki.php?pagename=Ntop.HomePage
6784
Whether it remains available depends on whether people contribute.
6789
What was "a snapshot" or "the snapshots"?
6793
A snapshot was a dump of the ntop cvs structure, automatically generated
6794
every day at 5 minutes after midnight (Pisa time).
6797
Snapshots were named with their creation date, in the form of
6801
Snapshots were neither polished nor even "releases". They contained any
6802
update(s) checked into the cvs during the prior day. No more, no less.
6805
cvs checkins (commits) are usually tested by the developer, but perhaps only
6806
in one (limited) environment. Occasionally a file is missed or a typo occurs
6807
and a snapshot wouldn't compile. Snapshots frequently introduced bugs that aren't
6808
apparent on a quick review. Snapshots were basically a point-in-time capture
6809
of the moving development environment. No more and no less.
6812
With release 2.2, rapid development occurred after general release and using
6813
the latest snapshot was your best bet. With 3.0, after a short period of stability
6814
(releases 2.2b and 2.2c), the development again outpaced the stable version and
6815
using the cvs again was almost manditory.
6818
If the 3.0 release doesn't work, drop by the mailing lists and check the back
6819
traffic to see if this is a common problem. If it's not, try the latest
6820
snapshot or ask for a recommendation of which version is the best to use.
6823
As with 2.2, we plan to have a cvs branch to allow for 3.0a/b/c
6824
releases while 3.1 is being developed (3.1.1, 3.1.2, etc.).
6827
Note that the ntop_2_2_patches branch broke the snapshot extract script, so
6828
snapshots ARE NO LONGER RECOMENDED OR SUPPORTED.
6830
<h2>Old answers, but goodies</h2>
6838
Obsolete code is code that is no longer being maintained nor part of ntop,
6839
but it's stuck off in that directory because 1) storage is cheap and 2) it
6840
might have usage someday and 3) somebody might be interested in resurrecting
6844
Code in obsolete/ IS NOT MAINTAINED, even minimally.
6847
Specifics? (As of June 2002)
6851
Various programs and functions which supported "rules" were determined to
6852
be obsolete were removed from ntop in late March 2002. This included a
6853
substantial number of lines of code, which was simply removed. Entire
6854
modules were placed into the obsolete/ directory.
6863
Various plugin programs, which were no longer being supported, were
6864
removed from ntop in late March 2002. These entire modules were placed
6865
into the obsolete/ directory.
6872
Various lines of code (totaling a substantial number, widely scattered
6873
Throughout ntop), which had provided compile-time selectable support
6874
(#define ENABLE_NAPSTER) for analysis of the (late) Napster protocol were
6875
removed on 4Apr2002.
6880
I get an error, libtool: link: CURRENT `-release' is not a nonnegative
6885
This is an autoconf problem. It should be fixed.
6886
The whole set of messages is typically:
6890
> libtool: link: CURRENT `-release' is not a nonnegative integer
6891
> libtool: link: `-release' is not valid version information
6892
> make[2]: *** [libntop.la] Error 1
6893
> make[2]: Leaving directory `/usr/local/src/ntop'
6894
> make[1]: *** [all-recursive] Error 1
6895
> make[1]: Leaving directory `/usr/local/src/ntop'
6896
> make: *** [all-recursive-am] Error 2
6903
"AFAIK this is a bug of autoconf that's not able to expand some macros,
6904
namely those that contain the version number. The workaround is to
6905
downgrade to the previous autoconf version."
6910
- downgrade to a stable autoconf version
6911
- edit all the ntop Makefile(s), add "0:0:0" behind any
6912
occurrence of "version-info" and "2.0" behind
6919
1) Burton posted a personal patch to do the above for Makefile.am on
6922
Thu Dec 20 2001 - "Compile problems with -release". Check the ntop-dev
6926
2) Older versions (e.g. Slackware 7.xx) of Linux installations have older
6929
versions of automake, which don't exhibit the bug.
6932
3) (Sean O'Neill) "I cheated a bit and hacked libtool by changing the
6945
4) The new ./configure scripts - call it versions after Nov2002 - fix this.
6949
Q, How to Build the (obsolete) RMON plugin
6953
Without any guarantees...
6957
0) Please do NOT use a precompiled UCD package unless you know what you're
6962
1) Fetch UCD-SNMP [See http://net-snmp.sourceforge.net/developer.html]
6966
2) Compile the stuff as specified as follows :
6967
[see also http://net-snmp.sourceforge.net/tutorial/toolkit/demon/]
6968
> ./configure --with-mib-modules="agentx"
6974
3) Once you this stuff ready you can build the ntop/RMON plugins.
6982
5) The ntop/RMON plugin listens on port 161 (the default SNMP port).
6983
If you want to test the agent you can use the 'tkMib' tool that comes
6984
with UCD-SNMP [see http://net-snmp.sourceforge.net/tkmib.jpg].
6987
NOTE: If you use tkMib do not forget to do "setenv MIBS ALL" (csh shells),
6990
otherwise you won't see the RMON MIB.
6993
How to Build the RMON plugin (bis) created 04/03 2002 by pierlo
6996
The following works with :
7006
* Make sure that ntop works properly
7010
* Make sure that openSSL & openSSL libraries are correctly installed
7011
(no WARNING when ntop is started !). If not, download and install
7012
the latest versions)
7016
* fetch & install UCD-SNMP :
7017
tar -xvzf XXXXX.tar.gz
7018
./configure --enable-shared
7025
1. uncomment lines around 474 and 1035 in configure.in file :
7029
dnl>OPTIONAL UCD-SNMP
7030
dnl>AC_HAVE_HEADERS(ucd-snmp/ucd-snmp-agent-includes.h)
7032
dnl> check for `UCD-SNMP' library by University of California
7033
[http://ucd-snmp.ucdavis.edu]
7034
dnl>AC_CHECK_LIB(ucdagent, register_mib, [AC_DEFINE(HAVE_SNMP)
7035
SNMPLIBS="-L/usr/local/lib -lsnmp -lucdagent -lucdmibs"],
7036
, -lsnmp -lucdagent -lucdmibs $LIBS $MORELIBS)
7040
(remove the dnl> from the AC_ lines)
7044
* in /ntop/plugins/rmonPlugin.c file, replace :
7048
line 702 approx. : droppedPackets with droppedPkts
7049
(there is only one occurence, so it may not be difficult to find)
7054
if (header_simple_table (vp,name,length,exact,var_len,
7055
write_method,numDevices)
7063
if (header_simple_table(vp,name,length,exact,var_len,
7064
write_method,myGlobals.numDevices)
7072
long_ret = (long)(device[ifNum]
7080
long_ret = (long)(myGlobals.device[ifNum]
7084
(lines 690 to 782 approx., about 13 occurences to change)
7088
2. launch /ntop/autogen.sh -1
7092
3. launch /ntop/configure
7100
* there is no warning about openSSL libraries !
7104
* the following checks are successful :
7105
" Step 4. Looking for both required and optional system headers....
7107
checking for ucd-snmp/ucd-snmp-agent-includes.h... yes"
7112
"Step 7. Looking for optional GPLed libraries....
7114
checking for register_mib in -lucdagent... yes"
7118
-> NO warning about openSSL libraries here ! If any trouble,
7119
check config.log file, which may help to get round the problem...
7120
Looking at ls.so.conf file and checking libraries pathes may also be
7125
3. edit /ntop/plugins/Makefile : replace every ocurence of "icmpPlugin"
7130
4. Launch /ntop/plugins/make
7134
5. Theoretically, RMON plugin is built and is ready to work ! If you have
7135
a error message like "undefined symbol..." when ntop started...
7136
I don't know how to fix it.
7140
Hope I didn't forget anything... Have fun !
7149
I don't understand -j | --border-sniffer-mode
7153
Welcome to the club <grin />
7156
Quoting from Luca's comment:
7159
"-j is used when you are starting ntop on a mirrored interface where you
7160
cannot trust MAC addresses."
7163
ntop uses MAC addresses for many things to differentiate among machines.
7164
IP addresses and names can mean many things, but hardware addresses are
7165
supposed to be unique. This is usually true, but gets hairy when you
7166
introduce a switch into the network which is also copying all of the
7167
packets it sees to a monitoring port.
7170
Understand how a switch works: In short, a switch monitors the network it
7171
sees and knows which mac address(es) are on which ports. When it received a
7172
packet, it forwards it to only that port. Broadcasts are forwarded to all
7176
So an ntop instance, sniffer, whatever only sees a fraction of the traffic.
7179
In many managed switches, there is an option for a "repeater" or "monitoring"
7180
or "spanned" port, which receives all traffic, so that network monitoring can
7184
However, When the switch sends out packets on the monitoring port, it must
7185
rewrite them to be valid Ethernet packets with a valid (i.e. the switch's)
7186
MAC address and ntop gets confused.
7192
1. -j usually requires you to specify the local network (-m) as a mirrored
7195
interface might have a wrong/ip-less/privare IP address.
7198
2. -j disables some features as TCP session tracking etc.
7201
In future versions -j will disappear and it will be replaced with more flags
7202
for better controlling all these options.
7205
With multiple switches in a hierarchy, you have to place the ntop instance
7206
or instances carefully, depending upon what you want to monitor.
7209
For example, most lans have a switch in each area with its uplink connected
7210
to a backbone switch. Servers and gateways are then placed off one or more
7211
backbone ports. This keeps departmental traffic isolated from each other,
7212
while making enterprise wide and inter-department traffic feasible. ntop
7213
would have to be monitoring the backbone switch, but you would need to be
7214
aware of what ntop is NOT seeing and place additional monitors.
7217
For example, you could place additional ntop instances in the departments,
7218
using the netflow or sFlow plugins to receive flow information from them
7219
which wouldn't be visible to the backbone instance. (I'll note that I haven't
7220
actually tried this, myself. -----Burton)
7225
When I run with -j | --border-sniffer-mode, there are different menus.
7232
The menus are just html files. There is a set for regular mode and a
7233
j_xxx.html set for border sniffer mode. Why? Because there are things
7234
that simply don't work in border-sniffer-mode, so why let the user
7235
request those pages.
7240
OK, but it changed after 2.1.2 (i.e. in 2.1.50) what are the NEW parameters?
7244
There were four new parameters introduced when -j | --border-sniffer-mode
7245
was removed. Whether the old parameter really did all the same things as
7246
the new ones is irrelevant and left to code-archeologists. What matters
7247
is what the new ones are and what they do!
7252
What was the -S option?
7256
The -S option was the --store-mode option, or the "Persistent storage mode"
7257
Ntop's internal structures are basically an array of devices (network
7258
interfaces), which contains an array of hosts (specific machines seen on the
7262
So device[0] is the 1st network interface, and device[2] the third.
7263
device[0].host[0] would be, say, the local file server and device[0].host[1]
7264
would be a simple host. device[1].host[1] is a completely different set of
7265
counts from device[0].host[1].
7268
The -S options tells ntop to store information about a specific host in a
7269
database from run to run (-S 0 none, -S 1 all and -S 2 only local hosts).
7272
This is only the count information about the host and does not store the
7273
information about a device (a network interface). Further, items of
7274
dynamically allocated storage (the devices name) are not stored.
7277
Data is retrieved on a subsequent run ONLY when traffic is seen from that
7278
host after the restart. (I suppose you could script a ping to each host you
7279
care about and force the reload that way, but it hasn't been tested...)
7282
So if you go into the host details (e.g. the 192.168.1.1.html page) you
7283
should see prior-run information.
7286
But if you're looking for device throughput to be preserved... nope...
7289
Also, ntop stores the information during 1) reset and 2) shutdown. So if ntop
7290
crashes, the persistent data will be lost.
7293
This option was removed from ntop in the 2.1.52 development version.
7298
What was the -A option, a/k/a --accuracy-level?
7302
This option was used to set ntop into various modes which performed less
7303
processing, in order to handle higher traffic volumes.
7306
It was added on 14Dec2001 (just before v2.0) and was removed on 11Mar2002,
7307
although traces survived in usage() until April 2002.
7310
Note that the CODE remains in initialize.c for use by EXPERTS if necessary.
7315
What was the --no-admin-password-hint option?
7319
This option was used to remove the hint text from the administrative password
7323
It was added 4Feb2002 and removed 8Mar2002 (the last traces, in usage(), were
7324
removed on 4Apr2002).
4482
<p><b>Q.</b> sFlow doesn't work.</p>
4483
<p><b>A.</b> Check this out:</p>
4486
This talks about a bad experience I had setting up sFlow reception. For the longest
4487
time, I could see that ntop was getting sflow packets, but no data would show up.
4488
It turns out the switch I was exporting from didn't see any real traffic, and it was
4489
just sending COUNTERSAMPLE packets.....
4493
- - - - - - - - I figured out that it was indeed "invalid" sflow packets.
4497
Apparently, sflow sends COUNTERSAMPLE and FLOWSAMPLE packets. COUNTERSAMPLE packets
4498
give a quick look at interface counters on the machine, whereas FLOWSAMPLE packets
4499
are actual packet fragments from IP connections. Ntop seems to simply parse,
4500
debug_print, and discard COUNTERSAMPLE packets...which made it confusing to look at
4501
the debug output and say "wow, lots of sflow coming in!" when in fact it was just for
4502
show, as Burton suggested. I added more switches (with active connections) to the
4503
switches sending sflow packets and I now have hosts with pretty graphs.
7326
4505
<h2>Solaris</h2>
7329
During the ntop 2.2 development cycle,
7330
we did development/testing under:
7331
Solaris 2.5, 7 and 8 (i86)
7335
During the ntop 3.0 development cycle,
7336
we did development/testing under:
7337
Solaris 8 (i86) and 9
7342
How do I install the ntop package on Solaris?
7346
For instance do 'pkgadd -d ntop-2.2-solaris.i386'
7351
What c compiler do I need?
7355
Sun's cc or gnu's gcc.
7360
What about /usr/ucb/cc is that the one?
7364
No. cc is software you pay for. /usr/ucb/cc is a stub compiler and good for,
7365
recompiling the kernel and absolutely nothing else.
7368
The cc I mean is Sun's Commercial Compiler.
7374
When I type 'make' it complains about a makefile error.
7378
Always remember to use gnu make.
7381
On many *BSD systems which have other 'make's, gnu make is called gmake.
4507
<p><b>Q.</b> How do I install the ntop package on Solaris?</p>
4508
<p><b>A.</b> For instance do 'pkgadd -d ntop-2.2-solaris.i386'</p>
4510
<p><b>Q.</b> What c compiler do I need?</p>
4511
<p><b>A.</b> Sun's cc or gnu's gcc.</p>
4513
<p><b>Q.</b> What about /usr/ucb/cc is that the one?</p>
4514
<p><b>A.</b> No. cc is software you pay for. /usr/ucb/cc is a stub compiler and good for, recompiling the kernel and absolutely nothing else.
4516
<p> The cc I mean is Sun's Commercial Compiler.
4518
<h2>BSD - FreeBSD</h2>
4521
During the ntop 3.2 development cycle,
4522
we did development/testing under:
4527
<p><b>Q.</b> When I type 'make' it complains about a makefile error.</p>
4528
<p><b>A.</b> Always remember to use gnu make.</p>
4529
<p> On many *BSD systems which have other 'make's, gnu make is called gmake.
7382
4530
Try make --version -- if it shows a Gnu version stamp you're ok, otherwise
7385
<h2>BSD - FreeBSD</h2>
7388
During the ntop 2.2 development cycle,
7389
we did development/testing under:
7395
Users reported success with:
7401
During the ntop 3.0 development cycle,
7402
we did development/testing under:
7408
Users reported success with:
7415
I can't compile ntop under FreeBSD 5.0 or 5.1.
7419
In some situations, we produce gcc link lines which expose a conflict 'tween
7420
FreeBSD 5.x and libtool.
7423
You will see the following error messages:
7427
expr: illegal option -- l
7428
usage: expr [-e] expression
7432
See the release notes for FreeBSD 5.0 and the expr(1) man page:
7436
http://www.freebsd.org/releases/5.0R/DP2/relnotes-i386.html
7437
http://www.freebsd.org/cgi/man.cgi?query=expr&sektion=1&manpath=FreeBSD+5.0-current
7440
Solve this by setting the compatibility flag before running make.
7444
$ export EXPR_COMPAT=Y
7447
configure.in and configure have been updated to do warn you to do this.
7452
I get "ntop: /dev/bpf0: Device not configured", what's wrong?
7456
This is because bfpX has not been configured inside the generic bsd-kernel
7460
If you use generic kernel config file put "pseudo-device bpfilter 16" in
4534
<p><b>Q.</b> I get "ntop: /dev/bpf0: Device not configured", what's wrong?</p>
4535
<p><b>A.</b> This is because bfpX has not been configured inside the generic bsd-kernel config file.
4537
<p> If you use generic kernel config file put "pseudo-device bpfilter 16" in
7461
4538
kernel config file and rebuild the kernel.
7466
I remember rumors about something not being right under FreeBSD with
7471
Yes. See FreeBSD bug bin/17437 at
7472
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17437
7475
Basically, due to limits in FreeBSD, there is no pthread_atfork() function.
4541
<p><b>Q.</b> I remember rumors about something not being right under FreeBSD with threads?
4543
<p><b>A.</b> Yes. See FreeBSD bug bin/17437 at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17437
4545
<p> Basically, due to limits in FreeBSD, there is no pthread_atfork() function.
7476
4546
So, when ntop does it's fork() call to create http pages, it can't fixup
7477
4547
the Mutexes. It wrong and could conceivably cause problems.
7480
However - ntop ran for years without the pthread_atfork() code, so we're
4549
<p> However - ntop ran for years without the pthread_atfork() code, so we're
7481
4550
no worse off in 3.0 under FreeBSD than in 2.2 or 2.1...
7484
There was a flurry of problems late in the 3.0 development cycle having to
7485
do with a seeming deadlock of the ntop web server (it's actually not dead,
4553
<p><b>Q.</b> The web server problem?</p>
4554
<p><b>A.</b> There was a flurry of problems late in the 3.0 development cycle having to do with a seeming deadlock of the ntop web server (it's actually not dead,
7486
4555
just walking at about 0.001KPH).
7489
Thanks to Yeoman efforts by Stanley Hopcroft, Michal Meloun and, well, me,
4557
<p> Thanks to Yeoman efforts by Stanley Hopcroft, Michal Meloun and, well, me,
7490
4558
we have a work-around.
7493
If you're running under FreeBSD, use the flag, --set-pcap-nonblocking.
7496
For more on this, read the threads at gmane - look for "FreeBSD and pthreads" -
4560
<p> With 3.1 we tried to automate this workaround, but fell a foul of FreeBSD's
4561
fixes. So in 3.2 we've reverted to requiring the command line flag.
4563
<p> If you're running under FreeBSD and have problems, use the flag, --set-pcap-nonblocking.
4565
<p> For more on this, read the threads at gmane - look for "FreeBSD and pthreads" -
7497
4566
that's probably the best summary. But there's stuff on this back at least to
7498
4567
October 2003 - look for Stanley's problems with CPU usage.
7503
Um... something about bad fds?
7507
Oh yes, see bug bin/51535: uthreads bug: new opened files may get stale fcntl flags
7510
They fixed the code, sort of:
7515
------- --------------
7523
There's a work-around in ntop, called the HAVE_FILEDESCRIPTORBUG fix.
7524
If you even might possibly need it, it should be set in configureextra/ but
7525
go ahead and set it anyway, it can't hurt.
7527
<h2>BSD - OpenBSD</h2>
7530
During the ntop 3.0 development cycle,
7531
we tried development/testing under:
7541
3.1 - I could never make it work. Problem seems to be that the gnu tools such
7542
as ld don't support a.out systems very well.
7546
3.4 - Should work. Julien Touche <julien.touche@lycos.com> sweated buckets
7547
to make this work and reported that it did in January 2004.
7549
<h2>BSD - NetBSD</h2>
7552
During the ntop 2.3 development cycle,
7553
we tried development/testing under:
7565
Some testing was done using - ntop works only in SINGLE THREADED mode and so
7575
There isn't (yet) a standard POSIX thread package for NetBSD. Both "proven"
7576
and "unproven" threads have issues. One user was bound and determined to
7577
make GNU Pth work, but pth isn't quite POSIX threads and he's didn't get
7583
But there IS a POSIX threads...
7587
Yes. And when NetBSD -current finally incorporates the POSIX threads (its
7588
been committed but not yet part of a release) this should be revisited.
4569
<p><b>A.</b> Also, understand that --set-pcap-nonblocking is going to increase ntop's cpu usage. It will probably come close to pegging the CPU at 100%. Yet
4570
strangely other processes won't seem to be impacted. (Of course, you really
4571
should be running ntop on it's own host, anyway, right?).
4573
<p> This is because of how the work-around is coded. ntop should step aside
4574
briefly and let them run.
4576
<p> Just be aware of it and don't ask on the mailing lists.
4578
<p> It's not giant lock vs. fine grained, etc., it's really the handling of
4579
signals (user interrupts) that is different.
4581
<p> Say you have a process, A running.
4583
<p> In linux, POSIX thread x is kernel process x' and POSIX thread y is kernel
4584
process y'. Now the POSIX standard doesn't prevent thread y from receiving
4585
a signal 'intended' for x, so you have to code for that. But when a thread
4586
'sleeps', the process sleeps, which is something the kernel understands and
4587
so the kernel can do other work.
4589
<p> In a userland threads model (i.e. xBSD), POSIX thread x and POSIX thread y
4590
are both parts of kernel process A. To implement the POSIX threading, the
4591
thread library code creates a thread manager, thread z'. That thread receives
4592
all signals, interupts etc. and parcels the work back out.
4594
<p> This too is perfectly within the POSIX model.
4596
<p> BUT: To implement the thread manager implies that the user task (A+x+y+z) is
4597
active whenever it's waiting for ANYTHING. How well this works depends upon
4598
the sophistication of kernel processes that recognize when the user task is
4599
'idle', meaning it is spinning waiting for somethings, vs. doing useful work.
4601
<p> In FreeBSD 4.x, we see that this recognition is not very sophisticated when
4602
it comes to the bpf pseudo driver and so ntop will use 100% of the available CPU.
4603
Even so, the scheduler bounces between tasks of equal priority, so productive
4604
work does get done, but you see the high CPU usage charged to your task.
7590
4606
<h2>Linux - all</h2>
7593
During the ntop 2.2 development cycle,
7594
we did development and/or testing under:
7596
LinuxFromScratch 3.0pre3
7597
RedHat AS2.1, 7.2, 7.3, 8.0
7601
During the ntop 3.0 development cycle,
7602
we did development and/or testing under:
7604
Gentoo 1.4 (rc5 and released)
7605
LinuxFromScratch 3.0pre3
7607
RedHat AS2.1, 7.3, 8.0 and 9
7613
And loads more - see the list above.
4609
During the ntop 3.2 development cycle,
4610
we did development and/or testing under:
4616
The cvs version was run by users on many