← Back to branch summary

~ubuntu-branches/ubuntu/natty/ntop/natty

« back to all changes in this revision

Viewing changes to html/faq.html

  • Committer: Bazaar Package Importer
  • Author(s): Ola Lundqvist
  • Date: 2005-01-30 21:59:13 UTC
  • mfrom: (2.1.1 warty)
  • Revision ID: james.westby@ubuntu.com-20050130215913-xc3ke963bw49b3k4
Tags: 2:3.0-5
http://bugs.debian.org/291794
http://bugs.debian.org/287802
http://bugs.debian.org/252352
http://bugs.debian.org/267248
http://bugs.debian.org/269321
http://bugs.debian.org/269319
* Updated README.Debian file so users will understand what to do at
  install, closes: #291794, #287802.
* Updated ntop init script to give better output.
* Also changed log directory from /var/lib/ntop to /var/log/ntop,
  closes: #252352.
* Quoted the interface list to allow whitespace, closes: #267248.
* Added a couple of logcheck ignores, closes: #269321, #269319.

Show diffs side-by-side

added added

removed removed

Lines of Context:
html/faq.html
 
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 
2
<html>
 
3
<head>
 
4
<!--meta http-equiv="Content-Type" content="text/html; charset=utf-8" -->
 
5
<meta http-equiv="Content-Style-Type" content="text/css">
 
6
<meta http-equiv="Window-target" content="_top">
 
7
<meta name="description" content="ntop (http://www.ntop.org) FAQ file.">
 
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>
 
12
</head>
 
13
<body background="white_bg.gif">
 
14
<h3>ntop FAQ...</h3>
 
15
<p>This is an unsophisticated, automated conversion of the source file, docs/FAQ into html.
 
16
Please report problems to the ntop-dev mailing list.
 
17
But remember, it's not about making it look good, it's about making the content available.</p>
 
18
<hr>
 
19
</p>
 
20
<br>
 
21
<p>
 
22
<b>Q.</b>&nbsp;
 
23
 Where can I find ntop?
 
24
</p>
 
25
<p>
 
26
<b>A.</b>&nbsp;
 
27
 The official website can be found at http://www.ntop.org/.
 
28
</p>
 
29
<br>
 
30
<p>
 
31
<b>Q.</b>&nbsp;
 
32
 Where do I get the source?
 
33
</p>
 
34
<p>
 
35
<b>A.</b>&nbsp;
 
36
 SourceForge -- http://sourceforge.net/projects/ntop/
 
37
</p>
 
38
<p>
 
39
   There is also a cvs (current development) maintained at cvs.ntop.org.
 
40
   (instructions are on the download page of www.ntop.org)
 
41
</p>
 
42
 
 
43
<pre>
 
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)
 
47
</pre>
 
48
<br>
 
49
<p>
 
50
<b>Q.</b>&nbsp;
 
51
 What is ntop?
 
52
</p>
 
53
<p>
 
54
<b>A.</b>&nbsp;
 
55
 ntop is an open source network top - it monitors a network and collects
 
56
   information about the protocols and hosts for display.
 
57
</p>
 
58
<br>
 
59
<p>
 
60
<b>Q.</b>&nbsp;
 
61
 Um, so it's like mrtg (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/)?
 
62
</p>
 
63
<p>
 
64
<b>A.</b>&nbsp;
 
65
 Yes and no...
 
66
</p>
 
67
<p>
 
68
   Yes in that both are analyzers of network packets.
 
69
</p>
 
70
<p>
 
71
   Yes in that both display information about your network.
 
72
</p>
 
73
<p>
 
74
   No in that they take very different approaches to collecting information.
 
75
</p>
 
76
<p>
 
77
   No in that they display different types of information.
 
78
</p>
 
79
<br>
 
80
<p>
 
81
<b>Q.</b>&nbsp;
 
82
 So mrtg...
 
83
</p>
 
84
<p>
 
85
<b>A.</b>&nbsp;
 
86
 mrtg creates a picture of the network centered on the device on the link
 
87
   between devices (and aggregations of devices and links).
 
88
</p>
 
89
<p>
 
90
   Tobias (Tobi) Oetiker describe mrtg as:
 
91
</p>
 
92
 
 
93
<pre>
 
94
       "The Multi Router Traffic Grapher (MRTG) is a tool to monitor
 
95
        the traffic load on network-links. MRTG generates HTML pages
 
96
        containing graphical images which provide a LIVE visual
 
97
        representation of this traffic."
 
98
</pre>
 
99
<br>
 
100
<p>
 
101
<b>Q.</b>&nbsp;
 
102
 And mrtg works how?
 
103
</p>
 
104
<p>
 
105
<b>A.</b>&nbsp;
 
106
 mrtg reads the counters maintained by various devices such as routers, using
 
107
   a protocol called 'snmp' (Simple Network Monitoring Protocol).  The
 
108
   management information bases (MIBs) read using snmp, contain incredibly
 
109
   detailed information about the packets the device has seen and what it has
 
110
   done with them.
 
111
</p>
 
112
<p>
 
113
   Again, quoting Tobi:
 
114
</p>
 
115
<p>
 
116
   "MRTG ... uses SNMP to read the traffic counters of your routers and
 
117
</p>
 
118
<pre>
 
119
    ... which logs the traffic data and creates beautiful graphs representing
 
120
    the traffic on the monitored network connection."
 
121
</pre>
 
122
<p>
 
123
   mrtg is focused on 'layer 2' (the tcp/ip and other low level protocol).
 
124
</p>
 
125
<br>
 
126
<p>
 
127
<b>Q.</b>&nbsp;
 
128
 And ntop?
 
129
</p>
 
130
<p>
 
131
<b>A.</b>&nbsp;
 
132
 ntop doesn't use snmp - it's not a device centric view of the network.
 
133
   Instead ntop actually processes the network packets directly.
 
134
</p>
 
135
<br>
 
136
<p>
 
137
<b>Q.</b>&nbsp;
 
138
 What's wrong with snmp?
 
139
</p>
 
140
<p>
 
141
<b>A.</b>&nbsp;
 
142
 Nothing.
 
143
</p>
 
144
<p>
 
145
   snmp is a pull protocol, that is a monitoring tool has to pull the
 
146
   information from the device.  snmp has 'traps' that is alert messages which
 
147
   can be sent out, but the MIB data has to be read by the monitoring tool from
 
148
   the device.
 
149
</p>
 
150
<p>
 
151
   snmp is an older protocol, from the dawn of the network era and it has some
 
152
   minor issues of security and complexity and verbosity.  But it's a critical
 
153
   network protocol, used successfully by 1000s of ISPs to monitor AND CONTROL
 
154
   vast networks.
 
155
</p>
 
156
<p>
 
157
   From our perspective, the problems with snmp are minor -
 
158
</p>
 
159
 
 
160
<pre>
 
161
       It can use a lot of bandwidth - especially if you're reading from devices
 
162
                                       on the far side of slow links.
 
163
</pre>
 
164
 
 
165
<pre>
 
166
       Pulling data out of MIBs is a complex process. MIBs can be specified in
 
167
       an RFC, or be unique to a vendor/device.
 
168
</pre>
 
169
 
 
170
<pre>
 
171
       An snmp-based tool either has to restrict itself to the common MIBs,
 
172
       or (most often for vendor tools) it be updated whenever a new device
 
173
       must be supported or a MIB changes.
 
174
</pre>
 
175
 
 
176
<pre>
 
177
       This makes snmp-based tools complex, because data may be unavailable
 
178
       in certain versions of seemingly similar devices, etc.  For example,
 
179
       http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
 
180
       is a page which links to the specific MIBs supported by various
 
181
       Cisco devices.
 
182
</pre>
 
183
<br>
 
184
<p>
 
185
<b>Q.</b>&nbsp;
 
186
 So why hasn't ntop 'won'?
 
187
</p>
 
188
<p>
 
189
<b>A.</b>&nbsp;
 
190
 mrtg excels at monitoring 100s or 1000s of network devices (routers,
 
191
   switches, etc.) and presenting that information over long periods of time.
 
192
</p>
 
193
<p>
 
194
   ntop doesn't do a good job of showing multiple 'networks' - it's really
 
195
   focused on aggregating a picture of a single network.  And for drilling down
 
196
   into that picture or presenting it over long periods of time.
 
197
</p>
 
198
<p>
 
199
   The processing of packets requires a lot more computer resources than just
 
200
   reading counters from devices.  On the plus side, this gives much more
 
201
   detailed information - for example ntop sees the actual web server request
 
202
   instead of just that there was traffic on port 80.  On the minus side, it's
 
203
   pretty easy to exceed the processing power of the low end machine typically
 
204
   available for ntop.  An ISP using ntop to monitor a couple of T3s needs a
 
205
   FAST computer and A LOT of memory.
 
206
</p>
 
207
<p>
 
208
   ntop also requires access to the physical network (either directly via a
 
209
   network card or indirectly via a netFlow/sFlow probe).  This limits ntop's
 
210
   (usefullness|ability) to work across sites.
 
211
</p>
 
212
<p>
 
213
   Once you learn what they do (mrtg and ntop), you'll probably discover that
 
214
   You need both.
 
215
</p>
 
216
<br>
 
217
<p>
 
218
<b>Q.</b>&nbsp;
 
219
 What's this 'layer' crud?
 
220
</p>
 
221
<p>
 
222
<b>A.</b>&nbsp;
 
223
 Network layers come from a widely cited but never implemented model, the OSI
 
224
   (Open System Interconnect ) networking model from the ISO (International
 
225
   Standards Organization).
 
226
</p>
 
227
<p>
 
228
   Google for it - for example
 
229
</p>
 
230
<pre>
 
231
       http://www.ussg.iu.edu/usail/network/nfs/network_layers.html
 
232
</pre>
 
233
<br>
 
234
<p>
 
235
<b>Q.</b>&nbsp;
 
236
 So ntop is like netFlow (Cisco), sFlow (RFC 3176, http://www.sflow.org) or
 
237
   RMON (HP)?
 
238
</p>
 
239
<p>
 
240
<b>A.</b>&nbsp;
 
241
 Not really, actually those are all protocols for sending and receiving
 
242
   information about the network.
 
243
</p>
 
244
<p>
 
245
   ntop has lots in common with the tools that USE those protocols.
 
246
</p>
 
247
<p>
 
248
   And there are lots of tools - some proprietary, many open source.
 
249
</p>
 
250
<p>
 
251
   The devices/programs that collect the information and send it out in netFlow,
 
252
   sFlow or RMON format are usually called (by me) 'probes'.  The devices and/or
 
253
   programs that receive the netFlow, sFlow or RMON formatted information and do
 
254
   things with it are called 'collectors' (if they process it and forward it on)
 
255
   or called 'displays'.
 
256
</p>
 
257
<p>
 
258
   In fact, ntop can receive netFlow packets and both send and receive sFlow 
 
259
   packets.  It can be a 'probe' or a 'display'. (ntop used to be able to send
 
260
   netFlow packets - that was removed 2004-03 by Luca).
 
261
</p>
 
262
<br>
 
263
<p>
 
264
<b>Q.</b>&nbsp;
 
265
 So ntop is like Nagios or Ipswitch's - WhatsUp Gold?.
 
266
</p>
 
267
<p>
 
268
<b>A.</b>&nbsp;
 
269
 Nope - those are layer 4 and higher (application) monitoring programs.
 
270
</p>
 
271
<br>
 
272
<p>
 
273
<b>Q.</b>&nbsp;
 
274
 So it's like ...
 
275
</p>
 
276
<p>
 
277
<b>A.</b>&nbsp;
 
278
 Enough already - if you search Freshmeat.net,
 
279
   http://freshmeat.net/search/?q=network+monitor&section=projects
 
280
   you will find (as of 18Aug2003):
 
281
</p>
 
282
 
 
283
<pre>
 
284
       Topic :: System :: Networking :: Monitoring (654 projects)
 
285
</pre>
 
286
<p>
 
287
   We'll be here all day.  ntop is ntop.
 
288
</p>
 
289
<br>
 
290
<p>
 
291
<b>Q.</b>&nbsp;
 
292
 Ok, so ntop is a unique TCP/IP analyzer.
 
293
</p>
 
294
<p>
 
295
<b>A.</b>&nbsp;
 
296
 Not exactly.
 
297
</p>
 
298
<p>
 
299
   First off, ntop pretty much doesn't care about the lowest (layer 1 or wire)
 
300
   layer.  It leaves dealing with that to a library, libpcap, which hides most
 
301
   of that.
 
302
</p>
 
303
<p>
 
304
   ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer
 
305
   (layer 2) nor a pure TCP/IP analyzer (layer 3).
 
306
</p>
 
307
<p>
 
308
   ntop gets the data at the layer 2 (frame) level, which could be Ethernet
 
309
   or another protocol.  Beyond Ethernet, ntop has minimal smarts about FDDI,
 
310
   PPP, RAW and TOKEN-RING frames.  That is, at least enough for some basic
 
311
   counts or to extract the (layer 3) TCP/IP data in side.
 
312
</p>
 
313
<p>
 
314
   ntop 3.0 adds TWO (three?) HUGE areas of new protocol support.
 
315
</p>
 
316
<p>
 
317
   ntop 3.0 supports IPv6, thanks to code contributed by Olivier Festor
 
318
   <Olivier.Festor@loria.fr> and Abdelkader Lahmadi <Abdelkader.Lahmadi@loria.fr>
 
319
   of the MADYNES Research Time (Managing DYnamic NEtworks and Services), see
 
320
   http://madynes.loria.fr/.
 
321
</p>
 
322
<p>
 
323
   ntop 3.0 has more than a fair amount of smarts about FibreChannel and SCSI
 
324
   thanks to code contributed by Dinesh G Dutt <ddutt@cisco.com> of Cisco. 
 
325
</p>
 
326
<p>
 
327
   However, since most of ntop's displayed counts are at the TCP/IP level, it
 
328
   confuses people into thinking ntop is purely a TCP/IP analyzer.
 
329
</p>
 
330
<p>
 
331
   ntop is a traffic monitor with it's own network interfaces, which monitors
 
332
   what it sees (or is told about through netFlow or sFlow probes).
 
333
</p>
 
334
<br>
 
335
<p>
 
336
<b>Q.</b>&nbsp;
 
337
 ntop runs under?
 
338
</p>
 
339
<p>
 
340
<b>A.</b>&nbsp;
 
341
 ntop is known to work under Linux, Mac OS X, FreeBSD, OpenBSD (3.4, nothing
 
342
   earlier) NetBSD (with issues) and Win32.
 
343
</p>
 
344
<p>
 
345
   ntop development is done primarily on RedHat Linux and Mac OS.
 
346
</p>
 
347
<p>
 
348
   Luca also does a port to Win32 (MS Visual C++) and works in the Sun
 
349
   Solaris environment.
 
350
</p>
 
351
<p>
 
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.
 
355
</p>
 
356
<p>
 
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:
 
360
</p>
 
361
 
 
362
<pre>
 
363
          count OS      Version        
 
364
        ------- ------- -------------- 
 
365
            492 Linux                  
 
366
             90 Windows WinNT/2K/XP    
 
367
             11 FreeBSD 4.9            
 
368
              9 Solaris 9              
 
369
              7 Darwin  7.2.0          
 
370
              6 FreeBSD 5.2            
 
371
              6 FreeBSD 5.1            
 
372
</pre>
 
373
 
 
374
<pre>
 
375
        and <5 records for FreeBSD 4.6.2, 4.8, 5.0, 5.2.1; OpenBSD 3.4; 
 
376
        and Solaris 8.
 
377
</pre>
 
378
<p>
 
379
   So:
 
380
</p>
 
381
 
 
382
<pre>
 
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
 
385
      OpenBSD 3.4
 
386
</pre>
 
387
<p>
 
388
   NetBSD doesn't seem to have been tested.
 
389
</p>
 
390
<p>
 
391
   Lots of Different Linuxes... of the ones we recognize:
 
392
</p>
 
393
 
 
394
<pre>
 
395
          count Distro    Release
 
396
        ------- --------- --------
 
397
            141 redhat    9
 
398
             42 fedora    1
 
399
             39 slackware 9.1.0
 
400
             38 redhat    7.3
 
401
             26 redhat    8.0
 
402
             15 debian          (probably 3.0)
 
403
             11 mandrake  9.2
 
404
             10 suse      9.0
 
405
             10 slackware 9.0.0
 
406
              9 redhat    7.2
 
407
              8 debian    3.0
 
408
              7 redhat    2.1AS
 
409
              6 mandrake  9.1
 
410
              5 suse      8.2
 
411
              5 redhat    3
 
412
</pre>
 
413
<p>
 
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.
 
418
</p>
 
419
 
 
420
<pre>
 
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.
 
425
</pre>
 
426
 
 
427
<pre>
 
428
 There are sections below about each specific OS.
 
429
</pre>
 
430
<h2>Features</h2>
 
431
<br>
 
432
<p>
 
433
<b>Q.</b>&nbsp;
 
434
 What determines the features of ntop?
 
435
</p>
 
436
<p>
 
437
<b>A.</b>&nbsp;
 
438
 <laugh>Whatever Luca wants</laugh>
 
439
</p>
 
440
<br>
 
441
<p>
 
442
<b>Q.</b>&nbsp;
 
443
 Why did you do this "x" instead of feature "y"?
 
444
</p>
 
445
<p>
 
446
<b>A.</b>&nbsp;
 
447
 Don't know. I could guess...
 
448
</p>
 
449
<p>
 
450
   Imagine you are the network manager for a large University network and have
 
451
   to crack down on users who are illegally exchanging copyrighted files or
 
452
   using University resources to run a business without paying for the resources
 
453
   being consumed.
 
454
</p>
 
455
<p>
 
456
   or
 
457
</p>
 
458
<p>
 
459
   You are a major vendor of infrastructure, whose customers are using networks
 
460
   for new features such as storage area networks and you want to give them
 
461
   the ability to monitor these.
 
462
</p>
 
463
<p>
 
464
   or
 
465
</p>
 
466
<p>
 
467
   You have a really cool technology that you've just donated to the community
 
468
   via an RFC and wish to jump-start adoption of it.
 
469
</p>
 
470
<p>
 
471
   or
 
472
</p>
 
473
<p>
 
474
   You are moving heavily into IPv6 and need to be able to monitor your 'new'
 
475
   network just like you monitored the IPv4 one.
 
476
</p>
 
477
<p>
 
478
   or (my favorite)
 
479
</p>
 
480
<p>
 
481
   You really, really, really hate that ntop generates such lousy html code
 
482
   and you decide to scratch that itch.
 
483
</p>
 
484
<p>
 
485
   or (what should happen)
 
486
</p>
 
487
<p>
 
488
   A major corporation, with out resources, time, skills and/or inclination
 
489
   to do it themselves sponsors the development of a feature that's critical
 
490
   to him/her.
 
491
</p>
 
492
<p>
 
493
   or
 
494
</p>
 
495
<p>
 
496
   Then again, it could just be because it's cool...
 
497
</p>
 
498
<br>
 
499
<p>
 
500
<b>Q.</b>&nbsp;
 
501
 Could ntop do "x"
 
502
</p>
 
503
<p>
 
504
<b>A.</b>&nbsp;
 
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.
 
507
</p>
 
508
<br>
 
509
<p>
 
510
<b>Q.</b>&nbsp;
 
511
 Will you do "x"
 
512
</p>
 
513
<p>
 
514
<b>A.</b>&nbsp;
 
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
 
517
   effort (contact us through http://www.ntop.org/consultancy.html).
 
518
</p>
 
519
<h2>Documentation</h2>
 
520
<br>
 
521
<p>
 
522
<b>Q.</b>&nbsp;
 
523
 Why isn't there (any)(more)(better) documentation.
 
524
</p>
 
525
<p>
 
526
<b>A.</b>&nbsp;
 
527
 (A personal peeve from Burton...)
 
528
</p>
 
529
<p>
 
530
   I get real tired of people complaining that there isn't any documentation
 
531
   and then being unwilling to contribute even the simplest stuff.  I've said
 
532
   I'll edit and assemble whatever people send me... and since I started working
 
533
   with ntop in November 2001, I've received maybe six pages of stuff.
 
534
</p>
 
535
<p>
 
536
   I'm trying to get people - who aren't coders - to contribute to ntop the
 
537
   project.  The contribution that ANYONE can make is "documentation".  A task-
 
538
   specific HOWTO... some sample screen shots... An FAQ entry...
 
539
</p>
 
540
<p>
 
541
   I've tried being nice.
 
542
   I've tried asking.
 
543
   I've tried shaming people into it.
 
544
</p>
 
545
<p>
 
546
   What have I gotten?    Zip.
 
547
</p>
 
548
<p>
 
549
   Nasty is all that's left...  This is your fair warning.  If you show up on
 
550
   the ntop mailing lists and complain about documentation, you will get
 
551
   blasted.
 
552
</p>
 
553
<p>
 
554
   -----Burton
 
555
</p>
 
556
<br>
 
557
<p>
 
558
<b>Q.</b>&nbsp;
 
559
 Ok, where can I find what does exist.
 
560
</p>
 
561
<p>
 
562
<b>A.</b>&nbsp;
 
563
 http://www.ntop.org has pointers and some (dated) documents.
 
564
</p>
 
565
<p>
 
566
   The documentation in the docs/ directory, the Documentation files at SourceForge
 
567
   and some at http://www.ntopsupport.com are basically all that there is.
 
568
</p>
 
569
<p>
 
570
   Search the ntop mailing lists at gmane, http://search.gmane.org. The lists
 
571
   are called gmane.linux.ntop.general and gmane.linux.ntop.devel.
 
572
</p>
 
573
<p>
 
574
   Please contribute to the ntop community by writing things up for inclusion
 
575
   in this FAQ or other documents!
 
576
</p>
 
577
<p>
 
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 
 
581
   contribute)
 
582
</p>
 
583
<br>
 
584
<p>
 
585
<b>Q.</b>&nbsp;
 
586
 I can't find a file at SourceForge!
 
587
</p>
 
588
<p>
 
589
<b>A.</b>&nbsp;
 
590
 You can reach the archives through any SourceForge mirror, e.g.
 
591
</p>
 
592
 
 
593
<pre>
 
594
      http://telia.dl.sourceforge.net/sourceforge/ntop/
 
595
             ^^^^^  change that qualifier to one that's close to you.
 
596
</pre>
 
597
<p>
 
598
   It has ALL the files unless we explicitly delete them...
 
599
</p>
 
600
<h2>Problems</h2>
 
601
<br>
 
602
<p>
 
603
<b>Q.</b>&nbsp;
 
604
 I have a problem...
 
605
</p>
 
606
<p>
 
607
<b>A.</b>&nbsp;
 
608
 Make sure it's a supported release!
 
609
</p>
 
610
<p>
 
611
   We support only the current versions of ntop.  This is either:
 
612
</p>
 
613
 
 
614
<pre>
 
615
       * the last release, e.g. v3.0.
 
616
       * the current cvs (cvs.ntop.org)
 
617
       * the latest development version posted at SourceForge (if one)
 
618
</pre>
 
619
<p>
 
620
   If you use a port/package and the latest version available for your
 
621
   OS is some release candidate from a year ago, sorry.  Contact the
 
622
   packager and ask them to get current.
 
623
</p>
 
624
<p>
 
625
   Luca usually asks people to try the latest cvs (development) version
 
626
   because problems are frequently already fixed in there.
 
627
</p>
 
628
<br>
 
629
<p>
 
630
<b>Q.</b>&nbsp;
 
631
 I'm running something supported and I've tried the latest & greatest.
 
632
   Still, I have a problem.
 
633
</p>
 
634
<p>
 
635
<b>A.</b>&nbsp;
 
636
 Read the ntop mailing lists.
 
637
</p>
 
638
<p>
 
639
   The ntop mailing lists are at
 
640
</p>
 
641
<pre>
 
642
      http://listgateway.unipi.it/mailman/listinfo/ntop
 
643
   and
 
644
      http://listgateway.unipi.it/mailman/listinfo/ntop-dev
 
645
</pre>
 
646
<p>
 
647
   If you're having non-user problems OR you are using the cvs, you should be
 
648
   reading and posting ntop-dev (for example, the cvs commit messages are posted
 
649
   there).
 
650
</p>
 
651
<p>
 
652
   You can read the lists through gmane (or other gateways) if you don't
 
653
   want to subscribe, but only subscribers can post.
 
654
</p>
 
655
<p>
 
656
   You can download the older messages in large chunks from the mailing list
 
657
   subscription pages.  Look for "To see the collection of prior postings to
 
658
   the list".
 
659
</p>
 
660
<br>
 
661
<p>
 
662
<b>Q.</b>&nbsp;
 
663
 I looked and I didn't find my problem.
 
664
</p>
 
665
<p>
 
666
<b>A.</b>&nbsp;
 
667
 Join the mailing list(s) and ask for help.
 
668
</p>
 
669
<p>
 
670
   Before you post, check the "HowTo Ask for Help" at the end of this FAQ.
 
671
</p>
 
672
<p>
 
673
   Please, if at all possible, use the built in PR_ form (the little 'bug' icon
 
674
   on the 'About' tab).
 
675
</p>
 
676
<p>
 
677
   Guidelines for asking questions:
 
678
</p>
 
679
 
 
680
<pre>
 
681
      ONE and only ONE problem / issue / question per message.
 
682
</pre>
 
683
 
 
684
<pre>
 
685
      With a meaningful subject.
 
686
</pre>
 
687
 
 
688
<pre>
 
689
         The goal is that if you're asking a common question, the
 
690
         subject would have allowed you to find it in the back
 
691
         traffic for the mailing list.
 
692
</pre>
 
693
 
 
694
<pre>
 
695
      Post the information about your environment we ask for.
 
696
</pre>
 
697
 
 
698
<pre>
 
699
         We STRONGLY suggest you use the automatically generated "Problem
 
700
         Report" form that since it contains much of the necessary information.
 
701
</pre>
 
702
 
 
703
<pre>
 
704
      Make sure you're in a supported environment (./configure --showoses).
 
705
</pre>
 
706
 
 
707
<pre>
 
708
         If it's an unsupported environment, we're interested in your efforts to
 
709
         make ntop work, but we don't have the time, resources, knowledge and/or
 
710
         interest to do it ourselves.
 
711
</pre>
 
712
 
 
713
<pre>
 
714
      For software 'crashes', please run ntop under the gdb debugger and capture
 
715
      the full failure information.
 
716
</pre>
 
717
 
 
718
<pre>
 
719
         Brief instructions on using gdb are at the end of this file (docs/FAQ).
 
720
</pre>
 
721
<br>
 
722
<p>
 
723
<b>Q.</b>&nbsp;
 
724
 I posted to the list and nobody answered me.
 
725
</p>
 
726
<p>
 
727
<b>A.</b>&nbsp;
 
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
 
730
   wanted to spend THEIR time solving YOUR problem.
 
731
</p>
 
732
<br>
 
733
<p>
 
734
<b>Q.</b>&nbsp;
 
735
 Do you offer paid support?
 
736
</p>
 
737
<p>
 
738
<b>A.</b>&nbsp;
 
739
 Yes - contact us through http://www.ntop.org/consultancy.html
 
740
</p>
 
741
<h2>Configuring ntop</h2>
 
742
<br>
 
743
<p>
 
744
<b>Q.</b>&nbsp;
 
745
 What does ./configure do?
 
746
</p>
 
747
<p>
 
748
<b>A.</b>&nbsp;
 
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
 
751
   to tell you if you're missing something critical).
 
752
</p>
 
753
<br>
 
754
<p>
 
755
<b>Q.</b>&nbsp;
 
756
 Why bother - just compile the code.
 
757
</p>
 
758
<p>
 
759
<b>A.</b>&nbsp;
 
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
 
762
   the files in different ways and put them in different places.  Plus some
 
763
   packages put files into directories with release information in them, etc.
 
764
</p>
 
765
<br>
 
766
<p>
 
767
<b>Q.</b>&nbsp;
 
768
 OK, so ./configure
 
769
</p>
 
770
<p>
 
771
<b>A.</b>&nbsp;
 
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
 
774
   ./configure has switches you use to tell where to find things.
 
775
</p>
 
776
<br>
 
777
<p>
 
778
<b>Q.</b>&nbsp;
 
779
 And the list is?
 
780
</p>
 
781
<p>
 
782
<b>A.</b>&nbsp;
 
783
 ./configure --help shows the whole list. It's a bit confusing because
 
784
   there are standard options and ntop options mixed in there.
 
785
</p>
 
786
<p>
 
787
<b>A.</b>&nbsp;
 
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.
 
790
</p>
 
791
<p>
 
792
   .h files are also called 'includes' and libxxxx files are called libraries
 
793
   or lib files.
 
794
</p>
 
795
<p>
 
796
   .h files are the C source for functions provided by the OS or by libraries.
 
797
   They are typically in a directory named /usr/include, but they can be
 
798
   placed ANYWHERE.
 
799
</p>
 
800
<p>
 
801
   lib files are compiled libraries of these functions (the .h tells ntop
 
802
   how to call something, the lib file is the actual code).  Their names
 
803
   usually begin libxxxx (so the library gd is named libgd).  
 
804
</p>
 
805
<p>
 
806
   By convention, libraries end in .so or .a.  A .so library is a shared
 
807
   library (Windows DLL), where one copy of the library is used by all
 
808
   programs that want it's functions.  A .a library is a non-shared or
 
809
   static library, which must be merged (the technical term is linked)
 
810
   with the code.
 
811
</p>
 
812
<p>
 
813
   ntop uses both - the myrrd library is a static, .a library.  When it
 
814
   comes to things like libpcap or libgd, we use shared (.so) libraries.
 
815
</p>
 
816
<p>
 
817
   Library files are typically placed in /usr/lib, where the gnu linker
 
818
   (ld), 'knows' automatically how to find them.  However, from OS to 
 
819
   OS and distribution to distribution, there are many other common places.
 
820
   Some OSes even have a file telling ld all the places to look.
 
821
</p>
 
822
<br>
 
823
<p>
 
824
<b>Q.</b>&nbsp;
 
825
 So ntop looks for these .h and library thingies in a couple of places.
 
826
   What if it doesn't find them?
 
827
</p>
 
828
<p>
 
829
<b>A.</b>&nbsp;
 
830
 If a basic ./configure can't find something, you'll have to tell ntop
 
831
   where to look.
 
832
</p>
 
833
<p>
 
834
   It's complex and OS/distro dependent. For example, if you install libgd
 
835
   from the Sun Freeware site on to a Solaris machine, the files get put
 
836
   into /usr/local/include and /usr/local/lib, which are not on the lists
 
837
   of 'standard' places for Solaris' versions of gcc (the Gnu c compiler)
 
838
   or ld.  So to compile ntop, you have to tell gcc to look in these
 
839
   additional locations.
 
840
</p>
 
841
<p>
 
842
   The things ntop might be looking for are in this part of the
 
843
   ./configure --help output:
 
844
</p>
 
845
 
 
846
<pre>
 
847
       +-External-source-locations:-------------------------------------------------+
 
848
       --with-pcap-root=DIR        LBNL pcap located in DIR
 
849
       --with-pcap-lib=DIR          or libpcap located in DIR
 
850
       --with-pcap-include=DIR      or pcap.h located in DIR
 
851
       --with-gdbm-root=DIR        gdbm located in DIR
 
852
       --with-gdbm-lib=DIR          or libgdbm located in DIR
 
853
       --with-gdbm-include=DIR      or gdbm.h located in DIR
 
854
       --with-zlib-root=DIR        zlib located in DIR
 
855
       --with-zlib-lib=DIR          or libz located in DIR
 
856
       --with-zlib-include=DIR      or zlib.h located in DIR
 
857
       --with-gd-root=DIR          gd located in DIR
 
858
       --with-gd-lib=DIR            or libgd located in DIR
 
859
       --with-gd-include=DIR        or gd.h located in DIR
 
860
       --with-libpng-root=DIR      libpng located in DIR
 
861
       --with-libpng-lib=DIR        or libpng located in DIR
 
862
       --with-libpng-include=DIR    or png.h located in DIR
 
863
       --with-ossl-root=DIR        openSSL located in DIR
 
864
       --with-ossl-lib=DIR          or libssl located in DIR
 
865
       --with-ossl-include=DIR      or ssl.h located in DIR
 
866
       --with-localedir=DIR        LOCALE files located in DIR (i18n)
 
867
       +-----------------------------------------------------------------------+
 
868
</pre>
 
869
<p>
 
870
   You can see that there is a pattern, pretty much every --with-xxxxx-root
 
871
   has a --with-xxxxx-include and --with-xxxxx-lib option.
 
872
</p>
 
873
<p>
 
874
   So, if ntop tells you it can't find something, do this - first look for the
 
875
   File on your system:
 
876
</p>
 
877
 
 
878
<pre>
 
879
     $ locate pcap.h
 
880
     /usr/include/pcap/pcap.h
 
881
</pre>
 
882
<p>
 
883
   (If you don't have locate, this works too:
 
884
</p>
 
885
<pre>
 
886
     $ find / -type f -name "pcap.h"
 
887
   )
 
888
</pre>
 
889
<p>
 
890
   And then tell ./configure via --with-pcap-include=/usr/include/pcap
 
891
</p>
 
892
<p>
 
893
   (Some OSes are smart enough to look in a subdirectory of the standard
 
894
   location, but others aren't).
 
895
</p>
 
896
<br>
 
897
<p>
 
898
<b>Q.</b>&nbsp;
 
899
 Ok, but why three options?
 
900
</p>
 
901
<p>
 
902
<b>A.</b>&nbsp;
 
903
 You use either the --with-xxxxx-root option OR either/both of the others
 
904
   at a time.  But ntop really only looks at the  --with-xxxxx-include and
 
905
   --with-xxxxx-lib options.
 
906
</p>
 
907
<p>
 
908
   Internally, --with-xxxxx-root=/a/b/c is translated into 
 
909
   --with-xxxxx-lib=/a/b/c/lib and --with-xxxxx-include=/a/b/c/include
 
910
   (that's the usual pattern).
 
911
</p>
 
912
<p>
 
913
   Now sometimes libraries are installed logically - if the pcap.h file is in
 
914
   /usr/local/pcap/include, the library (libpcap.so) is probably in
 
915
   /usr/local/pcap/lib.  Sometimes they are not logical and you will have
 
916
   to use the split options.
 
917
</p>
 
918
<p>
 
919
   The --with-pcap-root=/usr/local/pcap is shorthand for the two options,
 
920
   --with-pcap-include=/usr/local/pcap/include and
 
921
   --with-pcap-lib=/usr/local/pcap/lib.
 
922
</p>
 
923
<br>
 
924
<p>
 
925
<b>Q.</b>&nbsp;
 
926
 Oh Ghu - aren't there any short cuts.
 
927
</p>
 
928
<p>
 
929
<b>A.</b>&nbsp;
 
930
 For the first time you try ./configure, there's a script on SourceForge in
 
931
   The user contributed area that will try to build the ./configure line for
 
932
   you.
 
933
</p>
 
934
<br>
 
935
<p>
 
936
<b>Q.</b>&nbsp;
 
937
 And the OTHER options?
 
938
</p>
 
939
<p>
 
940
<b>A.</b>&nbsp;
 
941
 There is a set that tells ntop where to install stuff. For simplicity,
 
942
   the two you might want to change are:
 
943
</p>
 
944
 
 
945
<pre>
 
946
       --prefix=PREFIX         install architecture-independent files in PREFIX
 
947
                               [/usr/local]
 
948
       --datadir=DIR           read-only architecture-independent data
 
949
                               [PREFIX/share]
 
950
</pre>
 
951
<p>
 
952
   --prefix tells ntop where to install the various files.  The default value
 
953
   is /usr/local, which is where most non-OS software normal goes.
 
954
</p>
 
955
<p>
 
956
   A common choice for libraries (such as pcap) is --prefix=/usr, which puts
 
957
   things like .h files in places easier to automatically find (/usr/include).
 
958
   --prefix=/usr certainly works for ntop.  --prefix=/opt is another choice.
 
959
</p>
 
960
<p>
 
961
   The 'proper' choice turns on which model of file organization the OS and
 
962
   sysadmin prefer.  That's a fight I'm staying out of.
 
963
</p>
 
964
<p>
 
965
   --datadir tells ntop where to put its databases and output files.  The
 
966
   default is /usr/share/ntop, but that will give some sysadmin's agita.
 
967
   Another popular choice is --datadir=/var, which puts all the files in
 
968
   /var/ntop.  That may be attractive especially if you make /var/ntop
 
969
   a separate partition, so the rrd files don't eat all your disk space.
 
970
</p>
 
971
<br>
 
972
<p>
 
973
<b>Q.</b>&nbsp;
 
974
 What's --enable-iknowbetter Override WILLFAIL
 
975
</p>
 
976
<p>
 
977
<b>A.</b>&nbsp;
 
978
 There are some error messages where it's possible that thing work (now)
 
979
   that didn't used to, or you're doing development and don't want ntop
 
980
   to stop you from doing something, or there's an error message that you
 
981
   have skipped before without getting bitten.
 
982
</p>
 
983
<p>
 
984
   --enable-iknowbetter will print the message but not stop ntop from
 
985
   finishing ./configure.
 
986
</p>
 
987
<p>
 
988
   Use it at your own risk.
 
989
</p>
 
990
<br>
 
991
<p>
 
992
<b>Q.</b>&nbsp;
 
993
 What are the --enable and --disable options?
 
994
</p>
 
995
<p>
 
996
<b>A.</b>&nbsp;
 
997
 These (and the with/without options) pretty much do what you think - they
 
998
   enable or disable large chunks of ntop functionality:
 
999
</p>
 
1000
 
 
1001
<pre>
 
1002
       +--ntop-specific:-------------------------------------------------------+
 
1003
       --disable-mt                disable multithread support [default=enabled]
 
1004
       --enable-sslv3              enable ssl v3 support [default=disabled]
 
1005
       --enable-sslwatchdog        enable Watchdog for ssl hang-ups
 
1006
                                   [default=disabled]
 
1007
       --disable-plugins           disable compilation of plugins
 
1008
                                   [default=enabled]
 
1009
       --enable-static-plugins     Enable static linked plugins sntop,
 
1010
                                   default=dynamic]
 
1011
       --enable-ignoresigpipe      Ignore SIGPIPE errors [default=do not ignore]
 
1012
       --enable-i18n               Enable (limited) internationalization
 
1013
                                   [default=disabled]
 
1014
       --enable-showoses           display OS Support information.
 
1015
       --disable-ipv6              use IPv6 [default=enabled]
 
1016
       +-----------------------------------------------------------------------+
 
1017
</pre>
 
1018
 
 
1019
<pre>
 
1020
       +--external-packages:---------------------------------------------------+
 
1021
       --without-ssl               disable HTPPS support [default=enabled]
 
1022
       --without-zlib              disable zlib [default=enabled]
 
1023
       --with-tcpwrap              enable use of TCP Wrapper [default=disabled]
 
1024
</pre>
 
1025
<br>
 
1026
<p>
 
1027
<b>Q.</b>&nbsp;
 
1028
 What ELSE?
 
1029
</p>
 
1030
<p>
 
1031
<b>A.</b>&nbsp;
 
1032
 There are some so called 'environment variables' you can set that change
 
1033
   things too.  The common ones are:
 
1034
</p>
 
1035
<pre>
 
1036
        CC          C compiler command
 
1037
        CFLAGS      C compiler flags
 
1038
        LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
 
1039
                    nonstandard directory <lib dir>
 
1040
        CPPFLAGS    C/C++ preprocessor flags, e.g. -I<include dir> if you have
 
1041
                    headers in a nonstandard directory <include dir>
 
1042
        CPP         C preprocessor
 
1043
</pre>
 
1044
<p>
 
1045
   You would use these variables to override the choices made by ./configure
 
1046
   or to help it to find libraries and programs with truly nonstandard
 
1047
   names/locations.
 
1048
</p>
 
1049
<p>
 
1050
   The best place to look for examples of these environment variables are in
 
1051
   the OS/distribution files in the configureextra directory.  For example,
 
1052
   (again picking on Solaris), we use LDFLAGS to tell ld to look in some
 
1053
   common Solaris locations for libraries via this:
 
1054
</p>
 
1055
 
 
1056
<pre>
 
1057
     LDFLAGS="-L/usr/local/lib -R/usr/local/lib ${LDFLAGS}"
 
1058
</pre>
 
1059
<p>
 
1060
   What that does is add /usr/local/lib to the locations that ld will check.
 
1061
</p>
 
1062
<br>
 
1063
<p>
 
1064
<b>Q.</b>&nbsp;
 
1065
 ./configure dies in some strange horrible way complaining about version
 
1066
   conflicts, lunar phase or whatever.
 
1067
</p>
 
1068
<p>
 
1069
<b>A.</b>&nbsp;
 
1070
 The process of creating portable cross-platform scripts for building
 
1071
   software is ugly and hard and prone to failure.  There are tools
 
1072
   (released by gnu) to help, named automake, autoconf and libtool.
 
1073
   (Collectively the auto* tools).
 
1074
</p>
 
1075
<p>
 
1076
   These tools take basic files and generate more complex files based
 
1077
   on a series of rules, conventions and macros (much of which is poorly
 
1078
   or undocumented).  Other processes (e.g. ./configure) take these files
 
1079
   and generate more complex files based on a different series of rules,
 
1080
   conventions and macros.  This ultimately produces the 'Makefile', which
 
1081
   a program called make uses - based on (...wait for it...) yet another
 
1082
   series of rules, conventions and macros - to actually compile the ntop
 
1083
   source.
 
1084
</p>
 
1085
<p>
 
1086
   There are interdependencies among the tools, partial support for older
 
1087
   versions in some releases, but not in other releases and many more
 
1088
   problems.
 
1089
</p>
 
1090
<p>
 
1091
   Different OSes and different Linux distros ship with wildly different
 
1092
   versions.  Some even have scripts that attempt to analyze the file and
 
1093
   pick the correct version (which just means that trying to code a file
 
1094
   with multiple version support confuses the tool).
 
1095
</p>
 
1096
<p>
 
1097
   So if you have a basic, total failure of ./configure, it's usually
 
1098
   the auto* tools.
 
1099
</p>
 
1100
<p>
 
1101
   ntop used to ship with a manual script that rebuilt the generated files
 
1102
   according to the version(s) of the tools installed on the system you were
 
1103
   using to build ntop.  Thus the standard answer was 'run ./autogen.sh -1'.
 
1104
</p>
 
1105
<p>
 
1106
   But, this meant that you had to have these 'developer' tools installed
 
1107
   and caused much problems and gnashing of teeth.
 
1108
</p>
 
1109
<p>
 
1110
   So we spent 100s of hours rebuilding the scripts to be totally independent
 
1111
   of having the tools installed on your system - only to run into problems
 
1112
   because the xyz 1.6.1 tool installed by default on OS A isn't quite
 
1113
   compatible with the 1.6.3 version on OS B.
 
1114
</p>
 
1115
<p>
 
1116
   So we put technology in place to automatically detect tool versions and
 
1117
   rebuild the generated files if necessary.  That meant you had to have
 
1118
   these 'developer' tools installed and caused much problems.
 
1119
</p>
 
1120
<p>
 
1121
   So we rebuilt the scripts AGAIN and AGAIN, dropped support for old versions
 
1122
   of the tools and finally reached a point where it works for most reasonably
 
1123
   current platforms.  This is a compromise:
 
1124
</p>
 
1125
 
 
1126
<pre>
 
1127
       Systems that don't have the tools installed usually work.
 
1128
       Systems that have bleeding edge versions of these tools may break.
 
1129
       Systems with very old versions also may break.
 
1130
</pre>
 
1131
<p>
 
1132
   The technology to detect versions and rebuild the script files if
 
1133
   appropriate is still in there, but it's disabled from normal use.
 
1134
</p>
 
1135
<p>
 
1136
   If you have the auto* tools installed and have ./configure problems, you
 
1137
   can activate the automatic rebuild feature via:
 
1138
</p>
 
1139
 
 
1140
<pre>
 
1141
      $ export NTOPAUTOREBUILD=yes
 
1142
      $ ./configure ...
 
1143
</pre>
 
1144
<p>
 
1145
   If the rebuild fixes it, that's great.  Regardless, please report the
 
1146
   problem to the ntop mailing list.  Please don't paraphrase the messages
 
1147
   cut & paste the ACTUAL MESSAGES into your report.  Also, please let us
 
1148
   know the version(s) of the tools installed on your system:
 
1149
</p>
 
1150
 
 
1151
<pre>
 
1152
      $ aclocal --version
 
1153
      $ autoheader --version
 
1154
      $ autoconf --version
 
1155
      $ automake --version
 
1156
      $ libtool --version
 
1157
</pre>
 
1158
<br>
 
1159
<p>
 
1160
<b>Q.</b>&nbsp;
 
1161
 But how does it all hang together?
 
1162
</p>
 
1163
<p>
 
1164
<b>A.</b>&nbsp;
 
1165
 There's a vsd (Visio)/pdf in the docs directory - ntop-autotools.pdf.
 
1166
</p>
 
1167
<h2>Compiling ntop</h2>
 
1168
<br>
 
1169
<p>
 
1170
<b>Q.</b>&nbsp;
 
1171
 Which packages/libraries do I need to compile ntop:
 
1172
</p>
 
1173
 
 
1174
<pre>
 
1175
    Note: In some cases the minimal header files for a tool will be in
 
1176
          one "package" and the execution library in another. ntop needs
 
1177
          both so that the ./configure test finds the tool. It's usually
 
1178
          safest to install both the tool and development packages!
 
1179
</pre>
 
1180
 
 
1181
<pre>
 
1182
         (Some packages will have additional packages as pre-requisites)
 
1183
</pre>
 
1184
 
 
1185
<pre>
 
1186
       gdbm (We have people using 1.7.3, 1.8.0, 1.8.2 and 1.8.3)
 
1187
</pre>
 
1188
 
 
1189
<pre>
 
1190
       libpcap
 
1191
          We recommend 0.7.2, but ntop works with most 0.6.x versions. 
 
1192
          The newest version, 0.8.x works too - there are ntop fixes since 
 
1193
          late 2.2.9x releases for this.
 
1194
</pre>
 
1195
 
 
1196
<pre>
 
1197
          STAY AWAY from older versions, especially under Linux.
 
1198
</pre>
 
1199
 
 
1200
<pre>
 
1201
          Note: Building libpcap requires: bison/flex
 
1202
</pre>
 
1203
 
 
1204
<pre>
 
1205
       gd (1.8.x - stay away from 2.x development versions)
 
1206
          http://www.boutell.com/gd/gd.html
 
1207
</pre>
 
1208
 
 
1209
<pre>
 
1210
       libpng (1.2.x - although ntop works with 1.0.x versions, the two libpng
 
1211
              versions are not compatible and will often cause version conflicts
 
1212
              and crashes).
 
1213
</pre>
 
1214
 
 
1215
<pre>
 
1216
       glibc
 
1217
</pre>
 
1218
 
 
1219
<pre>
 
1220
       cpp
 
1221
</pre>
 
1222
 
 
1223
<pre>
 
1224
       gcc
 
1225
          Note: Both gcc 2.95/2.96 and 3.2/3.3 are reported to work.  Across a lot
 
1226
                of software, gcc 3.0 had problems - no clue re ntop.
 
1227
          For you folks still running 2.94, I think I fixed all the compile errors,
 
1228
          but upgrade for ghu's sake!
 
1229
</pre>
 
1230
 
 
1231
<pre>
 
1232
       libtool  1.4+ (distribution with 1.4.2)
 
1233
                     (there are successes reported with 1.3.4 or 1.3.5 -
 
1234
                      use --enable-iknowbetter)
 
1235
</pre>
 
1236
 
 
1237
<pre>
 
1238
       gawk/mawk
 
1239
          Note: If all you have is nawk, then --enable-showoses will not work.
 
1240
                If all you have is original awk, then ./configure will not work.
 
1241
</pre>
 
1242
<br>
 
1243
<p>
 
1244
<b>Q.</b>&nbsp;
 
1245
 Will the "xyz" compiler work instead of gcc?
 
1246
</p>
 
1247
<p>
 
1248
<b>A.</b>&nbsp;
 
1249
 We explicitly REQUIRE gcc.
 
1250
</p>
 
1251
<p>
 
1252
   We know that under many systems, a compiler called cc is available. On some,
 
1253
   it's a symbolic link to gcc, BUT, when invoked as cc, it often triggers 'old'
 
1254
   behaviors for cc compatibility.  On others, cc is a retarded compiler just good
 
1255
   enough for compiling the kernel.
 
1256
</p>
 
1257
<p>
 
1258
   The one exception is Sun's cc, which - since Luca used to do a lot of development
 
1259
   on Solaris - was pretty well supported.
 
1260
</p>
 
1261
<br>
 
1262
<p>
 
1263
<b>Q.</b>&nbsp;
 
1264
 The auto* tools?
 
1265
</p>
 
1266
<p>
 
1267
<b>A.</b>&nbsp;
 
1268
 Only if you are going to rebuild the distributed script files:
 
1269
</p>
 
1270
 
 
1271
<pre>
 
1272
           autoconf 2.5+ (distribution with 2.57)
 
1273
           automake 1.6+ (distribution with 1.6.1)
 
1274
</pre>
 
1275
<br>
 
1276
<p>
 
1277
<b>Q.</b>&nbsp;
 
1278
 Optional libraries?
 
1279
</p>
 
1280
<p>
 
1281
<b>A.</b>&nbsp;
 
1282
 Lots. The most common is:
 
1283
</p>
 
1284
 
 
1285
<pre>
 
1286
       openssl (for https:// support)
 
1287
          Note: For security reasons you should only have the most current
 
1288
                Version of openssl installed.
 
1289
</pre>
 
1290
<br>
 
1291
<p>
 
1292
<b>Q.</b>&nbsp;
 
1293
 ntop doesn't compile.
 
1294
</p>
 
1295
<p>
 
1296
<b>A.</b>&nbsp;
 
1297
 Sure, it does - for me :-)
 
1298
</p>
 
1299
<br>
 
1300
<p>
 
1301
<b>Q.</b>&nbsp;
 
1302
 Right smarty-pants...
 
1303
</p>
 
1304
<p>
 
1305
<b>A.</b>&nbsp;
 
1306
 First, check if you're using a supported OS.
 
1307
</p>
 
1308
<p>
 
1309
   The long and short of it is that ntop works under Linux, Mac OS X and
 
1310
   FreeBSD.
 
1311
</p>
 
1312
<p>
 
1313
   Luca distributes a Win32 version through http://shop.ntop.org but charges a
 
1314
   convenience fee.  Or you can fire up Microsoft's Visual C++ 6.0 and compile
 
1315
   the Win32 version that way.  We don't recommend Visual C++ .Net as the
 
1316
   internals of the memory management caused problems.
 
1317
</p>
 
1318
<p>
 
1319
   It works (albeit with severe limitations) on NetBSD.
 
1320
</p>
 
1321
<p>
 
1322
   It works on OpenBSD 3.4 (only).
 
1323
</p>
 
1324
<p>
 
1325
   It used to work under MinGW, but that broke after 2.1.3 and we need somebody
 
1326
   with some technical skills and an interest in MinGW to fix it.
 
1327
</p>
 
1328
<p>
 
1329
   Anything else, you are in untested waters.  Some cases we know there are
 
1330
   problems, others we just haven't tested.
 
1331
</p>
 
1332
<br>
 
1333
<p>
 
1334
<b>Q.</b>&nbsp;
 
1335
 But that was as of 18Aug2003?
 
1336
</p>
 
1337
<p>
 
1338
<b>A.</b>&nbsp;
 
1339
 Yes. For the latest scoop, run ./configure --enable-showoses
 
1340
</p>
 
1341
<p>
 
1342
   ntop will perform the basic ./configure tests (make sure you have a c
 
1343
   compiler that works, etc.) and then output a table.
 
1344
</p>
 
1345
<p>
 
1346
   This is from a pretty complete 3.0 release (at least as far as OS support
 
1347
   goes):
 
1348
</p>
 
1349
 
 
1350
<pre>
 
1351
     ntop OS Support status extract for version 2.2.91
 
1352
         Run Mon Aug 18 10:00:58 CDT 2003
 
1353
</pre>
 
1354
 
 
1355
<pre>
 
1356
     config.guess value     compiler OS name    Status
 
1357
     ------------------    --------- ---------  ---------------
 
1358
     mingw32*                    gcc MINGW             UNTESTED
 
1359
     cygwin*                       * CYGWIN            WILLFAIL
 
1360
     linux*                     *gcc LINUX      SUPPORTED
 
1361
     solaris2.9*                   * SOLARIS           UNTESTED
 
1362
     solaris2.8*                   * SOLARIS    SUPPORTED
 
1363
     solaris2.5*                   * SOLARIS           UNTESTED
 
1364
     solaris*                      * SOLARIS           UNTESTED
 
1365
     darwin*                       * DARWIN     SUPPORTED
 
1366
     freebsd[45]*               *gcc FREEBSD    SUPPORTED
 
1367
     freebsd*                      * FREEBSD           UNTESTED
 
1368
     openbsd*                      * OPENBSD           WILLFAIL
 
1369
     netbsd*1.5*                 gcc NETBSD
 
1370
     netbsd*                       * NETBSD            UNTESTED
 
1371
     hpux11*                     gcc HPUX              WILLFAIL
 
1372
     hpux10*                     gcc HPUX
 
1373
     aix*                          * AIX               UNTESTED
 
1374
</pre>
 
1375
<p>
 
1376
   Quoting from the ./configure --enable-showoses output:
 
1377
</p>
 
1378
 
 
1379
<pre>
 
1380
     Status of 'SUPPORTED' means you are:
 
1381
</pre>
 
1382
 
 
1383
<pre>
 
1384
          Building ntop for a supported platform
 
1385
          This means we expect ntop to work without major issues
 
1386
</pre>
 
1387
 
 
1388
<pre>
 
1389
     Status of 'UNTESTED' means you are:
 
1390
</pre>
 
1391
 
 
1392
<pre>
 
1393
          Building ntop for an untested platform
 
1394
</pre>
 
1395
 
 
1396
<pre>
 
1397
     Untested means that:
 
1398
</pre>
 
1399
 
 
1400
<pre>
 
1401
          1. A previous version of this OS is supported.
 
1402
          or 2. This version of this OS was supported by a
 
1403
          previous version of ntop.
 
1404
</pre>
 
1405
 
 
1406
<pre>
 
1407
          ./configure applies the same configuration options,
 
1408
          special parameters, etc. as for the prior release.
 
1409
</pre>
 
1410
 
 
1411
<pre>
 
1412
          For OS .0 releases that is probably a bad bet...
 
1413
</pre>
 
1414
 
 
1415
<pre>
 
1416
          It could just be that you are compiling an older version
 
1417
          of ntop on a new OS release - check the http://www.ntop.org
 
1418
          site for an update.
 
1419
</pre>
 
1420
 
 
1421
<pre>
 
1422
     Status of 'WILLFAIL' means you are:
 
1423
</pre>
 
1424
 
 
1425
<pre>
 
1426
          Attempting to build ntop for an unsupported platform
 
1427
</pre>
 
1428
 
 
1429
<pre>
 
1430
          >>> This is unsupported.
 
1431
          >>> It will almost certainly fail
 
1432
          (that is why it is listed as 'unsupported' - doh!)
 
1433
</pre>
 
1434
 
 
1435
<pre>
 
1436
     Status of blank means that the support level depends
 
1437
     upon ntop settings and/or other factors.
 
1438
</pre>
 
1439
<br>
 
1440
<p>
 
1441
<b>Q.</b>&nbsp;
 
1442
 Ok, it's a supported release and it still won't compile.
 
1443
</p>
 
1444
<p>
 
1445
<b>A.</b>&nbsp;
 
1446
 Did you run ./configure? And did it complete successfully?
 
1447
</p>
 
1448
<p>
 
1449
   Usually 'compile' problems for supported platforms are a missing
 
1450
   (critical) library or header file, but the user ignored (didn't see)
 
1451
   the error/warning message and tried running make anyway.
 
1452
</p>
 
1453
<p>
 
1454
   ./configure checks a lot of things.  When it's looking for
 
1455
   headers and libraries, ntop will report KEY information and PROBLEMS
 
1456
   in large, set-off, lines:
 
1457
</p>
 
1458
 
 
1459
<pre>
 
1460
     *******************************************************************
 
1461
     *
 
1462
     * NOTE: Building ntop for a supported platform
 
1463
     *       This means we expect ntop to work without major issues
 
1464
     *
 
1465
     *            'i686-pc-linux-gnu'
 
1466
     *
 
1467
     *    Please keep the ntop-dev mailing list updated with any
 
1468
     *    successes you have or problems you encounter...
 
1469
     *
 
1470
     *   Support for this platform was most recently verified for
 
1471
     *
 
1472
     *     RedHat7.2 w/ updates           ntop 2.1.51   on 2002-10-21
 
1473
     *     Suse i686, 2.4.18-4GB-SMP      ntop 2.1.51   on 2002-10-24
 
1474
     *
 
1475
     *******************************************************************
 
1476
</pre>
 
1477
<p>
 
1478
   READ THESE BOXES.  Even if you don't read the rest of the output, read
 
1479
   the boxes.  ntop can work around a lot of problems (missing libraries)
 
1480
   by disabling features that need them.  If, for example, you don't have
 
1481
   zlib, ntop will compile a version that doesn't output compressed html
 
1482
   pages.  If you don't read the boxes, you will never know.
 
1483
</p>
 
1484
<p>
 
1485
   READ THE MESSAGE BOXES!
 
1486
</p>
 
1487
 
 
1488
<pre>
 
1489
     *******************************************************************
 
1490
     *                                                                 *
 
1491
     * NOTICE:  I know you're used to ignoring output from ./configure *
 
1492
     *                                                                 *
 
1493
     *          ntop has a lot of complexity and interdependences.     *
 
1494
     *                                                                 *
 
1495
     *          Please, please AT LEAST read the stuff in these        *
 
1496
     *          boxes!                                                 *
 
1497
     *                                                                 *
 
1498
     *>>> The ACTION taken is shown prefixed '>>>'                     *
 
1499
     *                                                                 *
 
1500
     *    If the ACTION is unacceptable,                               *
 
1501
     *??? The REMEDIATION plan is shown prefixed with '???'            *
 
1502
     *                                                                 *
 
1503
     *******************************************************************
 
1504
</pre>
 
1505
<p>
 
1506
   The box will tell you what's wrong, what ntop did and often how to fix it
 
1507
   if you don't like ntop's fix.
 
1508
</p>
 
1509
<p>
 
1510
   READ THE MESSAGE BOXES!
 
1511
</p>
 
1512
<p>
 
1513
   Hint: It may sometimes be that you're missing the header files (often those
 
1514
   are in a -devel rpm if you're running RedHat)
 
1515
</p>
 
1516
<p>
 
1517
   If you see a message box and don't understand why ("I'm sure that
 
1518
   header file is present"), then look at a file called config.log.  Search
 
1519
   for the specific header or library reported in the message box and you will
 
1520
   see the detailed compiler/linker error messages.
 
1521
</p>
 
1522
<p>
 
1523
   For example, ./configure reports:
 
1524
</p>
 
1525
 
 
1526
<pre>
 
1527
        checking for linux/if_pppox.h... no
 
1528
</pre>
 
1529
<p>
 
1530
   The first thing to so is check if it's on your system:
 
1531
</p>
 
1532
 
 
1533
<pre>
 
1534
     $ locate linux/if_pppox.h
 
1535
     /usr/include/linux/if_pppox.h
 
1536
</pre>
 
1537
<p>
 
1538
   (If you don't have locate, this works too:
 
1539
</p>
 
1540
<pre>
 
1541
     $ find / -type f -name "ethertype.h"
 
1542
   )
 
1543
</pre>
 
1544
<p>
 
1545
   Open up config.log and look for if_pppox.h:
 
1546
</p>
 
1547
 
 
1548
<pre>
 
1549
     configure:13086: checking for linux/if_pppox.h
 
1550
     configure:13103: gcc -c -g -O2 -Wshadow -Wpointer-arith
 
1551
      -Wmissing-prototypes -Wmissing-declarations -Wnested-externs  -fPIC
 
1552
      -DLINUX conftest.c >&5
 
1553
     configure:13158: parse error before '/' token
 
1554
     In file included from configure:13160:
 
1555
     /usr/include/linux/if_pppox.h:38: `ETH_ALEN' undeclared here (not in a
 
1556
         function)
 
1557
     /usr/include/linux/if_pppox.h:39: `IFNAMSIZ' undeclared here (not in a
 
1558
         function)
 
1559
     /usr/include/linux/if_pppox.h:40: confused by earlier errors, bailing out
 
1560
     configure:13106: $? = 1
 
1561
     configure: failed program was:
 
1562
     | #line 13091 "configure"
 
1563
     | /* confdefs.h.  */
 
1564
     |
 
1565
     | #define PACKAGE_NAME "ntop"
 
1566
     | #define PACKAGE_TARNAME "ntop"
 
1567
     | #define PACKAGE_VERSION "2.2.91"
 
1568
     | #define PACKAGE_STRING "ntop 2.2.91"
 
1569
     | #define PACKAGE_BUGREPORT ""
 
1570
     | #define PACKAGE "ntop"
 
1571
     | #define VERSION "2.2.91"
 
1572
     | #define STDC_HEADERS 1
 
1573
     ...
 
1574
     | #define HAVE_NETINET_UDP_H 1
 
1575
     | /* end confdefs.h.  */
 
1576
     | net/if.h netinet/if_ether.h
 
1577
     |
 
1578
     | #include <linux/if_pppox.h>
 
1579
     configure:13123: result: no
 
1580
</pre>
 
1581
<p>
 
1582
   You see the actual test program, the actual compile line and the error
 
1583
   messages.
 
1584
</p>
 
1585
<p>
 
1586
   Before reporting it to us, chase down where those missing items are declared:
 
1587
</p>
 
1588
 
 
1589
<pre>
 
1590
     $ grep -R 'ETH_ALEN' /usr/include/* | grep '#define'
 
1591
     /usr/include/linux/if_ether.h:#define ETH_ALEN  6
 
1592
     /usr/include/net/ethernet.h:#define     ETHER_ADDR_LEN  ETH_ALEN
 
1593
</pre>
 
1594
<p>
 
1595
   And post that information with your error report.  The reason is that these
 
1596
   field definitions are often placed in very different places in different
 
1597
   OSes and even in different distributions.
 
1598
</p>
 
1599
<p>
 
1600
   FWIW, if you look in the older configure.in:
 
1601
</p>
 
1602
 
 
1603
<pre>
 
1604
      AC_CHECK_HEADERS([linux/if_pppox.h], [], [], [net/if.h
 
1605
         netinet/if_ether.h])
 
1606
</pre>
 
1607
<p>
 
1608
   should have been
 
1609
</p>
 
1610
 
 
1611
<pre>
 
1612
      AC_CHECK_HEADERS([linux/if_pppox.h], [], [], [#include <net/if.h>
 
1613
      #include <netinet/if_ether.h>])
 
1614
</pre>
 
1615
<p>
 
1616
   because the macro doesn't do the #include automatically.
 
1617
</p>
 
1618
<br>
 
1619
<p>
 
1620
<b>Q.</b>&nbsp;
 
1621
 Nope, it's not ./configure...
 
1622
</p>
 
1623
<p>
 
1624
<b>A.</b>&nbsp;
 
1625
 If it's not the configuration, then it's usually a problem with your specific
 
1626
   system, either:
 
1627
</p>
 
1628
 
 
1629
<pre>
 
1630
        - A new release of a supported OS.
 
1631
        - An uncommon option/configuration of a supported OS.
 
1632
</pre>
 
1633
<p>
 
1634
   In other words, something is different from what we've seen or expected.
 
1635
</p>
 
1636
<p>
 
1637
   Review the output from make.  The error message will usually give you a
 
1638
   Somewhat cryptic description of what's wrong and where.  Look for messages
 
1639
   about missing files.  Post as much information as you can - do locates for
 
1640
   the missing files, etc.  The more you give us the less we will have to ask
 
1641
   you to provide.
 
1642
</p>
 
1643
<p>
 
1644
   Remember, we can't see your box - all that the people on the list see is the
 
1645
   information you give in your message.
 
1646
</p>
 
1647
<br>
 
1648
<p>
 
1649
<b>Q.</b>&nbsp;
 
1650
 Compile dies because it's missing depcomp
 
1651
</p>
 
1652
<p>
 
1653
<b>A.</b>&nbsp;
 
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
 
1656
   directory.
 
1657
</p>
 
1658
<p>
 
1659
   It's in /usr/share/automake on my Linux boxes.  Another user reports it is in
 
1660
   /usr/local/share/automake in sun8.
 
1661
</p>
 
1662
<p>
 
1663
   If you have automake installed, this will do it automatically:
 
1664
</p>
 
1665
 
 
1666
<pre>
 
1667
       $ automake --add-missing --gnu -c
 
1668
</pre>
 
1669
<br>
 
1670
<p>
 
1671
<b>Q.</b>&nbsp;
 
1672
 Make fails with a message about being unable to create a .deps file.
 
1673
</p>
 
1674
<p>
 
1675
<b>A.</b>&nbsp;
 
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.
 
1678
</p>
 
1679
<br>
 
1680
<p>
 
1681
<b>Q.</b>&nbsp;
 
1682
 Make fails with a message about a missing .deps file
 
1683
</p>
 
1684
<p>
 
1685
<b>A.</b>&nbsp;
 
1686
 Basically, it's a automake 1.5 bug, related to dependency tracking.
 
1687
</p>
 
1688
<p>
 
1689
   If you don't have automake installed, you shouldn't see this problem.
 
1690
</p>
 
1691
<p>
 
1692
   ntop requires automake 1.6+ - that dependency is EXPLICT in the Makefile.am!
 
1693
</p>
 
1694
<p>
 
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.
 
1699
</p>
 
1700
<p>
 
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.
 
1703
</p>
 
1704
<p>
 
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
 
1708
   fails.
 
1709
</p>
 
1710
<p>
 
1711
   The problem should be trapped and worked around, however, so report the
 
1712
   problem to the list.
 
1713
</p>
 
1714
<br>
 
1715
<p>
 
1716
<b>Q.</b>&nbsp;
 
1717
 Why is the .deps problem mostly happening under FreeBSD?
 
1718
</p>
 
1719
<p>
 
1720
<b>A.</b>&nbsp;
 
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:
 
1725
</p>
 
1726
 
 
1727
<pre>
 
1728
     ./devel/automake
 
1729
        -- which is 1.5
 
1730
     ./devel/automake14
 
1731
     ./devel/automake17
 
1732
        -- which does NOT work
 
1733
</pre>
 
1734
<br>
 
1735
<p>
 
1736
<b>Q.</b>&nbsp;
 
1737
 So how do I work around the problem?
 
1738
</p>
 
1739
<p>
 
1740
<b>A.</b>&nbsp;
 
1741
 Install 1.6.3. It's quite easy, does NOT require root. The steps are listed
 
1742
   in the ./configure message, repeated below:
 
1743
</p>
 
1744
 
 
1745
<pre>
 
1746
      Download automake 1.6.3 from gnu
 
1747
          $ wget http://ftp.gnu.org/gnu/automake/automake-1.6.3.tar.gz
 
1748
</pre>
 
1749
 
 
1750
<pre>
 
1751
      Untar it
 
1752
          $ tar xfvz automake-1.6.3.tar.gz
 
1753
</pre>
 
1754
 
 
1755
<pre>
 
1756
      Make it
 
1757
          $ cd automake-1.6.3
 
1758
          $ ./configure --prefix=/home/<whatever>/automake163
 
1759
          $ make
 
1760
          $ make install
 
1761
</pre>
 
1762
 
 
1763
<pre>
 
1764
      Add it to your path (this is bash, but other shells, can do it too)
 
1765
</pre>
 
1766
 
 
1767
<pre>
 
1768
          $ PATH=/home/<whatever>automake163/bin:$PATH
 
1769
          $ export PATH
 
1770
</pre>
 
1771
 
 
1772
<pre>
 
1773
      And then untar, ./configure and make ntop.
 
1774
</pre>
 
1775
<br>
 
1776
<p>
 
1777
<b>Q.</b>&nbsp;
 
1778
 Make fails with a message like this:
 
1779
</p>
 
1780
<pre>
 
1781
     /bin/ld: Warning: size of symbol `pcap_open_dead' changed from 100 to 67
 
1782
         in pcap.o
 
1783
     collect2: ld returned 1 exit status
 
1784
     make[2]: *** [libntop.la] Error 1
 
1785
     make[2]: Leaving directory `/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3'
 
1786
     make[1]: *** [all-recursive] Error 1
 
1787
     make[1]: Leaving directory `/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3'
 
1788
     make: *** [all] Error 2
 
1789
</pre>
 
1790
<p>
 
1791
<b>A.</b>&nbsp;
 
1792
 Ah yes, size of symbol...changed. It means you have a conflict between
 
1793
   the version of the shared library (be it libpcap, libgd, whatever) that
 
1794
   was used to compile ntop with the version that was used to link ntop.
 
1795
</p>
 
1796
<br>
 
1797
<p>
 
1798
<b>Q.</b>&nbsp;
 
1799
 'splain please...
 
1800
</p>
 
1801
<p>
 
1802
<b>A.</b>&nbsp;
 
1803
 If you break down a typical link line:
 
1804
</p>
 
1805
 
 
1806
<pre>
 
1807
      gcc -shared  address.lo ... ntop_darwin.lo
 
1808
          -L/usr/local/include
 
1809
          -L/usr/local/lib
 
1810
          -L/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3/myrrd
 
1811
          -lpthread -lresolv -lnsl -lz -lc -lssl
 
1812
          -lcrypto -lgd -lpng -lpcap /usr/lib/libgdbm.so
 
1813
          -lmyrrd
 
1814
          -Wl,-soname -Wl,libntop-2.2.3.so
 
1815
          -o .libs/libntop-2.2.3.so
 
1816
</pre>
 
1817
<p>
 
1818
   You see the mix of -L and -l parameters.  The -L parameters ADD 
 
1819
   additional places to look for the shared libraries, which are in 
 
1820
   addition to the 'standard locations' for the system.  The -l
 
1821
   parameters tell which libraries to include.
 
1822
</p>
 
1823
<p>
 
1824
   Read the man pages (man ld, man ld.so, etc.)
 
1825
</p>
 
1826
<p>
 
1827
   The 'standard locations' are very system dependent, but usually
 
1828
   include /usr/lib and /lib.  PLUS whatever is (under Linux) in the
 
1829
   ld.so.conf file, for example
 
1830
</p>
 
1831
 
 
1832
<pre>
 
1833
      $ cat /etc/ld.so.conf
 
1834
      /usr/kerberos/lib
 
1835
      /usr/X11R6/lib
 
1836
      /usr/lib/qt-3.0.5/lib
 
1837
      /usr/local/lib
 
1838
</pre>
 
1839
<p>
 
1840
   So, on this system, to resolve a library, ld looks in the -L values:
 
1841
</p>
 
1842
 
 
1843
<pre>
 
1844
      1. /usr/local/include
 
1845
      2. /usr/local/lib
 
1846
      3. /linuxadmin/ntop/ntop2.2.3/ntop-2.2.3/myrrd
 
1847
</pre>
 
1848
 
 
1849
<pre>
 
1850
      And then the 'standard' places:
 
1851
</pre>
 
1852
 
 
1853
<pre>
 
1854
      4. /usr/kerberos/lib
 
1855
      5. /usr/X11R6/lib
 
1856
      6. /usr/lib/qt-3.0.5/lib
 
1857
      7. /usr/local/lib
 
1858
      8. /lib
 
1859
      9. /usr/lib
 
1860
</pre>
 
1861
<p>
 
1862
   Similarly, if you break apart the gcc COMPILE line and scrap the dups,
 
1863
   you'll have a different set of places where gcc looks for the .h files.
 
1864
   For those, it's the -I parameters plus whatever is 'standard' on your
 
1865
   system, which is dependent on the specific gcc port:
 
1866
</p>
 
1867
<p>
 
1868
   /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H  -DLINUX
 
1869
</p>
 
1870
<pre>
 
1871
       -I. -I/linuxadmin/ntop/ntop2.2.3/ntop-2.2.3/myrrd 
 
1872
       -I/usr/local/include
 
1873
      -g -O2 -fPIC -g -O2 -c
 
1874
      -Wshadow ... -Wnested-externs
 
1875
       -o ntop_darwin.lo
 
1876
</pre>
 
1877
<p>
 
1878
   Again, read the gcc man page.
 
1879
</p>
 
1880
<p>
 
1881
   A big problem is that - unlike .so files, it's not real clear what
 
1882
   directories ARE searched for .h files, only that there is a set.
 
1883
</p>
 
1884
<p>
 
1885
   With me so far?  Go back to the message... what it means is that:
 
1886
</p>
 
1887
 
 
1888
<pre>
 
1889
      * From one set of locations, at compile time, the size of 
 
1890
        the parameter list for pcap_open_dead was 100 bytes.
 
1891
      * From the other set of locations, at link (ld) time, the
 
1892
        library expects the parameter list to be of size 67.
 
1893
</pre>
 
1894
<p>
 
1895
   Danger, Will Robinson...
 
1896
</p>
 
1897
<p>
 
1898
   The most likely cause of this problem is when you tell ntop to look at
 
1899
   one location to resolve either the .h or .so and it finds the other,
 
1900
   'automatically' in a 'standard' location, but the two are actually from
 
1901
   incompatible versions.
 
1902
</p>
 
1903
<p>
 
1904
   Say you have libpcap 0.6.2 installed by the os in /usr/lib and 
 
1905
   /usr/include, but you also install libpcap 0.7.2 in /usr/local/lib and 
 
1906
   /usr/local/include.
 
1907
</p>
 
1908
 
 
1909
<pre>
 
1910
      $ locate pcap.h
 
1911
      /usr/include/pcap.h
 
1912
      /usr/local/include/pcap.h
 
1913
</pre>
 
1914
<p>
 
1915
   and
 
1916
</p>
 
1917
 
 
1918
<pre>
 
1919
      $ locate libpcap.so
 
1920
      /usr/lib/libpcap.so.0
 
1921
      /usr/lib/libpcap.so
 
1922
      /usr/lib/libpcap.so.0.6.2
 
1923
      /usr/lib/libpcap.so.0.6
 
1924
      /usr/local/lib/libpcap.so.0
 
1925
      /usr/local/lib/libpcap.so
 
1926
      /usr/local/lib/libpcap.so.0.7.2
 
1927
      /usr/local/lib/libpcap.so.0.7
 
1928
</pre>
 
1929
<p>
 
1930
   If all you give ./configure is --with-pcap-header=/usr/local/lib
 
1931
</p>
 
1932
 
 
1933
<pre>
 
1934
      * At compile time, it finds the pcap.h in /usr/local/lib (0.7.2)
 
1935
      * At link time, it finds the libpcap.so in the 'default', 
 
1936
        /usr/lib/libpcap.so which is actually libpcap.so.0.6.2
 
1937
</pre>
 
1938
<p>
 
1939
   ntop did EXACTLY what you told it to do.  The fact that it makes no
 
1940
   sense is a problem, so you get the error message.
 
1941
</p>
 
1942
<br>
 
1943
<p>
 
1944
<b>Q.</b>&nbsp;
 
1945
 So the real solution is?
 
1946
</p>
 
1947
<p>
 
1948
<b>A.</b>&nbsp;
 
1949
 Give ntop pointers to consistent sets of header and library files, and maybe
 
1950
   don't have multiple versions of the same library installed at once.
 
1951
</p>
 
1952
<br>
 
1953
<p>
 
1954
<b>Q.</b>&nbsp;
 
1955
 I'm done compiling and it works/doesn't work, what do I do?
 
1956
</p>
 
1957
<p>
 
1958
<b>A.</b>&nbsp;
 
1959
 make install (You'll typically need to be root for this to work)
 
1960
</p>
 
1961
<br>
 
1962
<p>
 
1963
<b>Q.</b>&nbsp;
 
1964
 Anything else?
 
1965
</p>
 
1966
<p>
 
1967
<b>A.</b>&nbsp;
 
1968
 Yes. Run the "census" - this will send us an email telling us what's
 
1969
   working and what's not working.  The census sends me the basics - uname 
 
1970
   information, autotool versions, version.c.  The domain name is blinded, 
 
1971
   and the script will show you the file before it's sent (you'll have 10 
 
1972
   seconds to press control-c to abort).
 
1973
</p>
 
1974
<p>
 
1975
   If things work ok, then send the census information via
 
1976
</p>
 
1977
 
 
1978
<pre>
 
1979
    make census-ok
 
1980
</pre>
 
1981
<p>
 
1982
   If you have problems, the create the census information via
 
1983
</p>
 
1984
 
 
1985
<pre>
 
1986
    make census-fail
 
1987
</pre>
 
1988
<p>
 
1989
   Edit it to describe the problem and send it to census@ntopsupport.com
 
1990
</p>
 
1991
<br>
 
1992
<p>
 
1993
<b>Q.</b>&nbsp;
 
1994
 I'm seeing a lot of "changing search order for system directory" messages?
 
1995
</p>
 
1996
<p>
 
1997
<b>A.</b>&nbsp;
 
1998
 It's not a problem, just confusing. This warning, which appears if you
 
1999
   redefine the system include directory, causes lots of confusion.  Supposedly,
 
2000
   according to this http://gcc.gnu.org/ml/gcc-bugs/2002-10/msg01080.html,
 
2001
   it wasn't fixed in gcc 3.2.0, but should be fixed in gcc 3.2.1.
 
2002
</p>
 
2003
<p>
 
2004
   According to this: http://gcc.gnu.org/onlinedocs/cpp/Invocation.html,
 
2005
   it's truly harmless on systems which already have /usr/local/include as
 
2006
   a standard system library:
 
2007
</p>
 
2008
 
 
2009
<pre>
 
2010
      -I dir 
 
2011
      Add the directory dir to the list of directories to be searched for
 
2012
      header files. See Search Path. Directories named by -I are searched
 
2013
      before the standard system include directories. If the directory dir
 
2014
      is a standard system include directory, the option is ignored to ensure
 
2015
      that the default search order for system directories and the special
 
2016
      treatment of system headers are not defeated (see System Headers) . 
 
2017
</pre>
 
2018
<h2>Other ./configure features</h2>
 
2019
<br>
 
2020
<p>
 
2021
<b>Q.</b>&nbsp;
 
2022
 How do I update the Vendor Table (MAC address prefixes)?
 
2023
</p>
 
2024
<p>
 
2025
<b>A.</b>&nbsp;
 
2026
 ntop has (in Makefile), a rule to automatically download the latest vendor
 
2027
   information table from the IEEE, the oui.txt file ntop reads.
 
2028
</p>
 
2029
<p>
 
2030
   If you are seeing unknown MAC address prefixes (the 1st three units), try
 
2031
   the full IEEE table.  To rebuild it:
 
2032
</p>
 
2033
 
 
2034
<pre>
 
2035
     # make dnvt
 
2036
</pre>
 
2037
<p>
 
2038
   and then copy the new oui.txt over the one installed by ntop originally.
 
2039
</p>
 
2040
<p>
 
2041
   Also note that the table changes over time - there are almost 600
 
2042
   Modifications and/or new assignments between the version shipped with
 
2043
   ntop 2.0 and the version on the IEEE site in February 2002.
 
2044
</p>
 
2045
<br>
 
2046
<p>
 
2047
<b>Q.</b>&nbsp;
 
2048
 How do I update the passive ethernet fingerprint database?
 
2049
</p>
 
2050
<p>
 
2051
<b>A.</b>&nbsp;
 
2052
 ntop has (in Makefile), a rule to automatically download the latest
 
2053
   ettercap file from SourceForge:
 
2054
</p>
 
2055
 
 
2056
<pre>
 
2057
     # make dnetter
 
2058
</pre>
 
2059
<p>
 
2060
   It will also compress the file and tell you how big the old and new files
 
2061
   were.
 
2062
</p>
 
2063
<br>
 
2064
<p>
 
2065
<b>Q.</b>&nbsp;
 
2066
 How do I update the IP to Country Code table?
 
2067
</p>
 
2068
<p>
 
2069
<b>A.</b>&nbsp;
 
2070
 Again, ntop has (in Makefile), a rule to automatically download the
 
2071
   latest data and build the file.
 
2072
</p>
 
2073
 
 
2074
<pre>
 
2075
     # make p2c
 
2076
</pre>
 
2077
<p>
 
2078
   Note that this is actually a fairly complex script (utils/p2c) and is
 
2079
   dependent upon data posted to supposedly well known locations by the various
 
2080
   internet number authorities (APNIC, RIPE, etc.)
 
2081
</p>
 
2082
<p>
 
2083
   It's a LOT of data to download so don't do this on a site with a slow
 
2084
   link to the internet.  Also, read the output carefully and DO NOT apply a
 
2085
   file if there are messages you don't understand.
 
2086
</p>
 
2087
<br>
 
2088
<p>
 
2089
<b>Q.</b>&nbsp;
 
2090
 But the IP -> CC data is wrong.
 
2091
</p>
 
2092
<p>
 
2093
<b>A.</b>&nbsp;
 
2094
 Yeah. Most people don't care :-(... it's enough to see various pretty
 
2095
   flags.
 
2096
</p>
 
2097
<p>
 
2098
   Sadly, the registries often post files with errors in them.  Some Tier
 
2099
   1 ISPs post their own data to elaborate on the registry data.  Most ISPs
 
2100
   don't post data.  Some entries in the files make 'logical' sense, but not
 
2101
   physical sense.
 
2102
</p>
 
2103
<p>
 
2104
   If you find another set of data, let us know - the shell script is pretty
 
2105
   easy to follow to add another data source.
 
2106
</p>
 
2107
<p>
 
2108
   The user who used to care about this (Mr. Anon E. Mouse) used to send me
 
2109
   a file of corrections to apply to the file we posted with ntop.
 
2110
</p>
 
2111
<p>
 
2112
   If such a file exists, it would be posted @ SourceForge in the user
 
2113
   contributed area.
 
2114
</p>
 
2115
<h2>Running - Startup</h2>
 
2116
<br>
 
2117
<p>
 
2118
<b>Q.</b>&nbsp;
 
2119
 ntop won't start - I get this message:
 
2120
</p>
 
2121
<pre>
 
2122
  ** FATAL ERROR** ... open of /var/ntop/addressQueue.db failed:
 
2123
       File open error
 
2124
</pre>
 
2125
<p>
 
2126
<b>A.</b>&nbsp;
 
2127
 It's either permissions (the ntop -u userid doesn't have read/write access
 
2128
   to that file - common if you're upgrading from 2.2 to 3.0).
 
2129
</p>
 
2130
<p>
 
2131
   The other cause is that there's still an instance of ntop running. Make
 
2132
   sure you shutdown ntop before starting it.
 
2133
</p>
 
2134
<br>
 
2135
<p>
 
2136
<b>Q.</b>&nbsp;
 
2137
 What is the function of the 'ntop' script in the build directory - should I
 
2138
   call it or /usr/local/bin/ntop ?
 
2139
</p>
 
2140
<p>
 
2141
<b>A.</b>&nbsp;
 
2142
 (from the comments in the script):
 
2143
</p>
 
2144
 
 
2145
<pre>
 
2146
    # ntop - temporary wrapper script for .libs/ntop
 
2147
    # Generated by ltmain.sh - GNU libtool 1.4 (1.920 2001/04/24 23:26:18)
 
2148
    #
 
2149
    # The ntop program cannot be directly executed until all the libtool
 
2150
    # libraries that it depends on are installed.
 
2151
    #
 
2152
    # This wrapper script should never be moved out of the build directory.
 
2153
    # If it is, it will not operate correctly.
 
2154
</pre>
 
2155
<p>
 
2156
   It allows you to run ntop out of the build directory before doing a "make
 
2157
   install" by doing all the necessary linkage magic - such as forcing a relink
 
2158
   if it didn't succeed originally - to the files in .libs.
 
2159
</p>
 
2160
<p>
 
2161
   Think of it as simulating make install, but not moving stuff to /usr/local
 
2162
   or wherever.
 
2163
</p>
 
2164
<p>
 
2165
   Don't use it - it just causes problems...
 
2166
</p>
 
2167
<br>
 
2168
<p>
 
2169
<b>Q.</b>&nbsp;
 
2170
 Which libraries do I need?
 
2171
</p>
 
2172
<p>
 
2173
<b>A.</b>&nbsp;
 
2174
 To run ntop: glibc, gdbm, libpcap
 
2175
</p>
 
2176
<pre>
 
2177
      For https://, add openssl.
 
2178
      For other tools and compile options, add the appropriate libraries.
 
2179
</pre>
 
2180
<br>
 
2181
<p>
 
2182
<b>Q.</b>&nbsp;
 
2183
 ntop seems to run, but the web server isn't up.
 
2184
</p>
 
2185
<p>
 
2186
<b>A.</b>&nbsp;
 
2187
 Set the password - see docs/1STRUN.TXT
 
2188
</p>
 
2189
<br>
 
2190
<p>
 
2191
<b>Q.</b>&nbsp;
 
2192
 How do you reset Admin password if we lost it?
 
2193
</p>
 
2194
<p>
 
2195
<b>A.</b>&nbsp;
 
2196
 Delete ntop_pw.db and follow the procedure in docs/1STRUN.txt
 
2197
</p>
 
2198
<br>
 
2199
<p>
 
2200
<b>Q.</b>&nbsp;
 
2201
 I'm being prompted to set a password, what do I enter.
 
2202
</p>
 
2203
<p>
 
2204
<b>A.</b>&nbsp;
 
2205
 Anything you want, of 5 or more characters. If ntop can't find the value
 
2206
   in it's database, it will prompt you to set on.  If this happens every
 
2207
   time you start ntop, check the permissions on the ntop_pw.db file.
 
2208
</p>
 
2209
<br>
 
2210
<p>
 
2211
<b>Q.</b>&nbsp;
 
2212
 How does the @filename option work e.g. /usr/bin/ntop ... @filename ...
 
2213
</p>
 
2214
<p>
 
2215
<b>A.</b>&nbsp;
 
2216
 The text of 'filename', is copied - ignoring line breaks and
 
2217
   comments (anything following a #) - into the command line.
 
2218
</p>
 
2219
<p>
 
2220
   ntop behaves as if all of the text had simply been typed directly 
 
2221
   on the command line.  Multiple @s are permitted in the command
 
2222
   line, nesting is not.  @s in the file will cause an error.
 
2223
</p>
 
2224
<p>
 
2225
   Both are displayed on the info.html report, the "Started as"
 
2226
   shows the actual command line ntop was given and the 
 
2227
   "Resolved to" shows what ntop processed.
 
2228
</p>
 
2229
<p>
 
2230
   Started as /usr/bin/ntop -i eth0,eth1 @/root/ntop_parms -d -L
 
2231
</p>
 
2232
<p>
 
2233
   with /root/ntop_parms containing:
 
2234
</p>
 
2235
 
 
2236
<pre>
 
2237
      -p /usr/share/ntop/protocol.list
 
2238
      -P /usr/share/ntop
 
2239
      -w 192.168.42.38:3000
 
2240
      # -W 192.168.42.38:3001
 
2241
      -u ntop
 
2242
      --trace-level 3
 
2243
      -m 12.239.0.0/16,10.113.0.0/16
 
2244
      -E
 
2245
      -K
 
2246
</pre>
 
2247
<p>
 
2248
   becomes:
 
2249
</p>
 
2250
<p>
 
2251
   Resolved to /usr/bin/ntop -i eth0,eth1 -p /usr/share/ntop/protocol.list
 
2252
</p>
 
2253
<pre>
 
2254
               -P /usr/share/ntop -w 192.168.42.38 -u ntop --trace-level 3
 
2255
               -m 12.239.0.0/16,10.113.0.0/16 -E -K -d -L
 
2256
</pre>
 
2257
<p>
 
2258
   Remember, most ntop options are "sticky", that is they just set an
 
2259
   internal flag. Invoking them multiple times doesn't change ntop's
 
2260
   behavior. However, options that set a value, such as --trace-level,
 
2261
   will use the LAST value given: --trace-level 2 --trace-level 3 will
 
2262
   run as --trace-level 3.
 
2263
</p>
 
2264
<p>
 
2265
   It is recommended that you use FULL pathnames for @filename, since
 
2266
   ntop may have different effective directories when run in different
 
2267
   ways.  However, you may wish to use relative pathnames to take
 
2268
   advantage of the different effective directories (say cron vs.
 
2269
   command line).  Just know where you're starting.
 
2270
</p>
 
2271
<br>
 
2272
<p>
 
2273
<b>Q.</b>&nbsp;
 
2274
 ntop seems to run but I don't see any traffic.
 
2275
</p>
 
2276
<p>
 
2277
<b>A.</b>&nbsp;
 
2278
 Make sure you aren't running against the loopback (127.0.0.1) interface.
 
2279
   lo shouldn't see much traffic, only that originating on the host destined
 
2280
   for it (e.g. ping 127.0.0.1).
 
2281
</p>
 
2282
<br>
 
2283
<p>
 
2284
<b>Q.</b>&nbsp;
 
2285
 ntop is unable to open its database file. Specifically:
 
2286
   I have following messages while running ntop
 
2287
</p>
 
2288
 
 
2289
<pre>
 
2290
     wait please: ntop is coming up...
 
2291
     24/Jul/2003 15:15:23 Initializing IP services...
 
2292
     <snip />
 
2293
     24/Jul/2003 15:15:23 Initializing GDBM...
 
2294
     24/Jul/2003 15:15:23 Database '/var/ntop/addressCache.db' open failed: File
 
2295
         open error
 
2296
     24/Jul/2003 15:15:23 Possible solution: please use '-P <directory>'
 
2297
</pre>
 
2298
<p>
 
2299
<b>A.</b>&nbsp;
 
2300
 Multiple possible choices...
 
2301
</p>
 
2302
<pre>
 
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
 
2308
       and locked.
 
2309
</pre>
 
2310
<br>
 
2311
<p>
 
2312
<b>Q.</b>&nbsp;
 
2313
 What's inside the .db files and what's their format?
 
2314
</p>
 
2315
<p>
 
2316
<b>A.</b>&nbsp;
 
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
 
2319
   interested in the file content as they are temporary caches and contain the
 
2320
   configuration as well as the MD5 hash of the web passwords.
 
2321
</p>
 
2322
<p>
 
2323
   I posted a trivial dumpgdbm.c to gmane - search for it.
 
2324
</p>
 
2325
<br>
 
2326
<p>
 
2327
<b>Q.</b>&nbsp;
 
2328
 ntop starts up with this:
 
2329
   WARNING: Discarded network 172.20.0.0/16: this is the local network.
 
2330
</p>
 
2331
<p>
 
2332
<b>A.</b>&nbsp;
 
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
 
2335
   local networks are always local, ntop doesn't need to make them pseudo-local.
 
2336
</p>
 
2337
<br>
 
2338
<p>
 
2339
<b>Q.</b>&nbsp;
 
2340
 What are ntop's options?
 
2341
</p>
 
2342
<p>
 
2343
<b>A.</b>&nbsp;
 
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.
 
2346
</p>
 
2347
<p>
 
2348
   The best way to see what is actually available is to run ntop with the -h or
 
2349
   --help options and see.   Also read man ntop.
 
2350
</p>
 
2351
<p>
 
2352
   Here is the FULL set of real, working options as of February 2004
 
2353
</p>
 
2354
 
 
2355
<pre>
 
2356
    -4             | --ipv4
 
2357
                             Use IPv4 connections (for the ntop web server)
 
2358
    -6             | --ipv6
 
2359
                             Use IPv6 connections (for the ntop web server)
 
2360
</pre>
 
2361
 
 
2362
<pre>
 
2363
    -a <file>      | --access-log-file <file>
 
2364
                             File for ntop web server access log
 
2365
</pre>
 
2366
 
 
2367
<pre>
 
2368
    -b             | --disable-decoders
 
2369
                             Disable protocol decoders
 
2370
</pre>
 
2371
 
 
2372
<pre>
 
2373
    -c             | --sticky-hosts
 
2374
                             Idle hosts are not purged from memory
 
2375
</pre>
 
2376
 
 
2377
<pre>
 
2378
    -d             | --daemon
 
2379
                             Run ntop in daemon mode
 
2380
</pre>
 
2381
 
 
2382
<pre>
 
2383
    -e <number>    | --max-table-rows <number>
 
2384
                             Maximum number of table rows to report
 
2385
</pre>
 
2386
 
 
2387
<pre>
 
2388
    -f <file>      | --traffic-dump-file <file>
 
2389
                             Traffic dump file (see tcpdump)
 
2390
</pre>
 
2391
 
 
2392
<pre>
 
2393
    -g             | --track-local-hosts
 
2394
                             Track only local hosts
 
2395
</pre>
 
2396
 
 
2397
<pre>
 
2398
    -h             | --help
 
2399
                             Display help and exit
 
2400
</pre>
 
2401
 
 
2402
<pre>
 
2403
    -i <name>      | --interface <name>
 
2404
                             Interface name or names to monitor
 
2405
</pre>
 
2406
 
 
2407
<pre>
 
2408
    -j             | --create-other-packets
 
2409
                             Create file ntop-other-pkts.XXX.pcap file
 
2410
</pre>
 
2411
 
 
2412
<pre>
 
2413
    -o             | --no-mac
 
2414
                             ntop will trust just IP addresses (no MACs)
 
2415
</pre>
 
2416
 
 
2417
<pre>
 
2418
    -k             | --filter-expression-in-extra-frame
 
2419
                             Show kernel filter expression in extra frame
 
2420
</pre>
 
2421
 
 
2422
<pre>
 
2423
    -l <path>      | --pcap-log <path>
 
2424
                             Dump packets captured to a file (debug only!)
 
2425
</pre>
 
2426
 
 
2427
<pre>
 
2428
    -m <addresses> | --local-subnets <addresses>
 
2429
                             Local subnetwork(s) (see man page)
 
2430
</pre>
 
2431
 
 
2432
<pre>
 
2433
    -n             | --numeric-ip-addresses
 
2434
                             Numeric IP addresses - no DNS resolution
 
2435
</pre>
 
2436
 
 
2437
<pre>
 
2438
    -p <list>      | --protocols <list>
 
2439
                             List of IP protocols to monitor (see man page)
 
2440
</pre>
 
2441
 
 
2442
<pre>
 
2443
    -q             | --create-suspicious-packets
 
2444
                             Create file ntop-suspicious-pkts.XXX.pcap file
 
2445
</pre>
 
2446
 
 
2447
<pre>
 
2448
    -r <number>    | --refresh-time <number>
 
2449
                             Refresh time in seconds, default is 120
 
2450
</pre>
 
2451
 
 
2452
<pre>
 
2453
    -s             | --no-promiscuous
 
2454
                             Disable promiscuous mode
 
2455
</pre>
 
2456
 
 
2457
<pre>
 
2458
    -t <number>    | --trace-level <number>
 
2459
                             Trace level 0-6
 
2460
</pre>
 
2461
 
 
2462
<pre>
 
2463
    -u <user>      | --user <user>
 
2464
                             Userid/name to run ntop under (see man page)
 
2465
</pre>
 
2466
 
 
2467
<pre>
 
2468
    -x <max num hash entries>
 
2469
                             Max num. hash entries ntop can handle (default 4294967295)
 
2470
</pre>
 
2471
 
 
2472
<pre>
 
2473
    -w <port>      | --http-server <port>
 
2474
                             Web server (http:) port (or address:port) to listen on
 
2475
</pre>
 
2476
 
 
2477
<pre>
 
2478
    -z             | --disable-sessions
 
2479
                             Disable TCP session tracking
 
2480
</pre>
 
2481
 
 
2482
<pre>
 
2483
    -A
 
2484
                             Ask admin user password and exit
 
2485
</pre>
 
2486
 
 
2487
<pre>
 
2488
    --set-admin-password=<pass>
 
2489
                             Set password for the admin user to <pass>
 
2490
</pre>
 
2491
 
 
2492
<pre>
 
2493
    --w3c
 
2494
                             Add extra headers to make better html
 
2495
</pre>
 
2496
 
 
2497
<pre>
 
2498
    -B <filter>    | --filter-expression
 
2499
                             Packet filter expression, like tcpdump
 
2500
</pre>
 
2501
 
 
2502
<pre>
 
2503
    -D <name>      | --domain <name>
 
2504
                             Internet domain name
 
2505
</pre>
 
2506
 
 
2507
<pre>
 
2508
    -F <spec>      | --flow-spec <specs>
 
2509
                             Flow specs (see man page)
 
2510
</pre>
 
2511
 
 
2512
<pre>
 
2513
    -K             | --enable-debug
 
2514
                             Enable debug mode
 
2515
</pre>
 
2516
 
 
2517
<pre>
 
2518
    -L
 
2519
                             Do logging via syslog
 
2520
</pre>
 
2521
 
 
2522
<pre>
 
2523
    --use-syslog=<facility>
 
2524
                             Do logging via syslog, facility ('=' is REQUIRED)
 
2525
</pre>
 
2526
 
 
2527
<pre>
 
2528
    -M             | --no-interface-merge
 
2529
                             Don't merge network interfaces (see man page)
 
2530
</pre>
 
2531
 
 
2532
<pre>
 
2533
    -N             | --wwn-map
 
2534
                             Map file providing map of WWN to FCID/VSAN
 
2535
</pre>
 
2536
 
 
2537
<pre>
 
2538
    -O <path>      | --pcap-file-path <path>
 
2539
                             Path for log files in pcap format
 
2540
</pre>
 
2541
 
 
2542
<pre>
 
2543
    -P <path>      | --db-file-path <path>
 
2544
                             Path for ntop internal database files
 
2545
</pre>
 
2546
 
 
2547
<pre>
 
2548
    -U <URL>       | --mapper <URL>
 
2549
                             URL (mapper.pl) for displaying host location
 
2550
</pre>
 
2551
 
 
2552
<pre>
 
2553
    -V             | --version
 
2554
                             Output version information and exit
 
2555
</pre>
 
2556
 
 
2557
<pre>
 
2558
    -X <max num TCP sessions>
 
2559
                             Max num. TCP sessions ntop can handle (default 4294967295)
 
2560
</pre>
 
2561
 
 
2562
<pre>
 
2563
    -W <port>      | --https-server <port>
 
2564
                             Web server (https:) port (or address:port) to listen on
 
2565
</pre>
 
2566
 
 
2567
<pre>
 
2568
    --disable-instantsessionpurge
 
2569
                             Disable instant FIN session purge
 
2570
</pre>
 
2571
 
 
2572
<pre>
 
2573
    --disable-mutexextrainfo
 
2574
                             Disable extra mutex info
 
2575
</pre>
 
2576
 
 
2577
<pre>
 
2578
    --disable-schedyield
 
2579
                             Turn off sched_yield() calls, if ntop is deadlocking on them
 
2580
</pre>
 
2581
 
 
2582
<pre>
 
2583
    --disable-stopcap
 
2584
                             Capture packets even if there's no memory left
 
2585
</pre>
 
2586
 
 
2587
<pre>
 
2588
    --fc-only
 
2589
                             Display only Fibre Channel statistics
 
2590
</pre>
 
2591
 
 
2592
<pre>
 
2593
    --no-fc
 
2594
                             Disable processing & Display of Fibre Channel
 
2595
</pre>
 
2596
 
 
2597
<pre>
 
2598
    --no-invalid-lun
 
2599
                             Don't display Invalid LUN information
 
2600
</pre>
 
2601
 
 
2602
<pre>
 
2603
    --p3p-cp
 
2604
                             Set return value for p3p compact policy, header
 
2605
</pre>
 
2606
 
 
2607
<pre>
 
2608
    --p3p-uri
 
2609
                             Set return value for p3p policyref header
 
2610
</pre>
 
2611
 
 
2612
<pre>
 
2613
    --set-pcap-nonblocking
 
2614
                             Call pcap_setnonblock
 
2615
</pre>
 
2616
 
 
2617
<pre>
 
2618
    --skip-version-check
 
2619
                             Skip ntop version check
 
2620
</pre>
 
2621
 
 
2622
<pre>
 
2623
    --ssl-watchdog
 
2624
                             Use ssl watchdog (NS6 problem)
 
2625
</pre>
 
2626
<br>
 
2627
<p>
 
2628
<b>Q.</b>&nbsp;
 
2629
 -4 and -6?
 
2630
</p>
 
2631
<p>
 
2632
<b>A.</b>&nbsp;
 
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 
 
2635
   to both.  Use these to restrict the web server.
 
2636
</p>
 
2637
<br>
 
2638
<p>
 
2639
<b>Q.</b>&nbsp;
 
2640
 --trace-level?
 
2641
</p>
 
2642
<p>
 
2643
<b>A.</b>&nbsp;
 
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.
 
2647
</p>
 
2648
<p>
 
2649
   -t 5:
 
2650
</p>
 
2651
<pre>
 
2652
      [MSGID8757584] OSFP: scanFingerprintLoop() checked 1, resolved 1
 
2653
</pre>
 
2654
<p>
 
2655
   -t 6:
 
2656
</p>
 
2657
<pre>
 
2658
      [MSGID8757584] [ntop:698] OSFP: scanFingerprintLoop() checked 1, resolved 1
 
2659
</pre>
 
2660
<br>
 
2661
<p>
 
2662
<b>Q.</b>&nbsp;
 
2663
 ntop starts up find and then seems to die.
 
2664
</p>
 
2665
<p>
 
2666
<b>A.</b>&nbsp;
 
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"
 
2669
</p>
 
2670
 
 
2671
<pre>
 
2672
     UID   PID  PPID STAT     TIME COMMAND
 
2673
     501 18327     1 S    00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2674
     501 18330 18327 S    00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2675
     501 18331 18330 S    00:00:05 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2676
     501 18332 18330 S    00:00:45 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2677
     501 18333 18330 S    00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2678
     501 18334 18330 S    00:00:06 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2679
     501 18335 18330 S    00:00:00 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2680
     501 18336 18330 R    00:00:32 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2681
     501 18337 18330 S    00:00:41 /usr/bin/ntop -i eth1,eth2 @/etc/ntop.conf...
 
2682
</pre>
 
2683
<p>
 
2684
   The 'PID' numbers match the THREADMGMT: numbers in the log:
 
2685
</p>
 
2686
 
 
2687
<pre>
 
2688
      ntop[18326]:   INIT: Parent process is exiting (this is normal)
 
2689
           ^^^^^ is the thread that issued the message
 
2690
</pre>
 
2691
 
 
2692
<pre>
 
2693
      ntop[18327]:   INIT: Bye bye: I'm becoming a daemon...
 
2694
               (18327 is the 'master' thread created as ntop becomes a daemon)
 
2695
</pre>
 
2696
 
 
2697
<pre>
 
2698
      ntop[18327]: THREADMGMT: Started thread (16386) for network packet analyser 
 
2699
               A message is issued for each thread started.
 
2700
                                               ^^^^^ is the 'internal' thread #.
 
2701
                                                     Ignore it
 
2702
      ntop[18331]: THREADMGMT: Packet processor thread running... 
 
2703
           ^^^^^ is the child thread.  Each one issues a message as it starts up
 
2704
</pre>
 
2705
 
 
2706
<pre>
 
2707
      ntop[18327]: THREADMGMT: Started thread (32771) for idle hosts detection 
 
2708
      ntop[18332]: THREADMGMT: Idle host scan thread running... 
 
2709
      ntop[18327]: THREADMGMT: Started thread (49156) for DNS address resolution 
 
2710
      ntop[18333]: THREADMGMT: Address resolution thread running... 
 
2711
      ntop[18334]: THREADMGMT: rrd thread (65541) started 
 
2712
      ntop[18327]: THREADMGMT: Started thread (81926) for web server 
 
2713
      ntop[18335]: THREADMGMT: web connections thread (18335) started... 
 
2714
      ntop[18327]: THREADMGMT: Started thread (98311) for network packet sniffing on eth1 
 
2715
      ntop[18336]: THREADMGMT: pcap dispatch thread running... 
 
2716
      ntop[18327]: THREADMGMT: Started thread (114696) for network packet sniffing on eth2 
 
2717
      ntop[18337]: THREADMGMT: pcap dispatch thread running... 
 
2718
</pre>
 
2719
<p>
 
2720
   So:
 
2721
</p>
 
2722
 
 
2723
<pre>
 
2724
     UID   PID  PPID STAT     TIME is
 
2725
     501 18327     1 S    00:00:00 Master
 
2726
     501 18330 18327 S    00:00:00 (internal used by POSIX)
 
2727
     501 18331 18330 S    00:00:05 Packet processor
 
2728
     501 18332 18330 S    00:00:45 Idle Host Scan
 
2729
     501 18333 18330 S    00:00:00 Address Resolution
 
2730
     501 18334 18330 S    00:00:06 rrd
 
2731
     501 18335 18330 S    00:00:00 Web Server
 
2732
     501 18336 18330 R    00:00:32 eth1
 
2733
     501 18337 18330 S    00:00:41 eth2
 
2734
i
 
2735
   If you connect to the running ntop via gdb, you can see this:
 
2736
</pre>
 
2737
<p>
 
2738
   $ gdb /usr/bin/ntop 18327
 
2739
   (gdb) info threads
 
2740
</p>
 
2741
<pre>
 
2742
         ^^^^^^^^^^^^ Shows all the threads and their current state
 
2743
</pre>
 
2744
 
 
2745
<pre>
 
2746
     9 Thread 114696 (LWP 18337)  0x40255c68 in recvfrom () from
 
2747
            /lib/i686/libpthread.so.0
 
2748
     8 Thread 98311 (LWP 18336)  0x40255c68 in recvfrom () from
 
2749
            /lib/i686/libpthread.so.0
 
2750
     7 Thread 81926 (LWP 18335)  0x420dcc31 in select () from
 
2751
            /lib/i686/libc.so.6
 
2752
     6 Thread 65541 (LWP 18334)  0x420b0226 in nanosleep () from
 
2753
            /lib/i686/libc.so.6
 
2754
     5 Thread 49156 (LWP 18333)  0x40252a35 in __pthread_sigsuspend ()
 
2755
            from /lib/i686/libpthread.so.0
 
2756
     4 Thread 32771 (LWP 18332)  0x420b0226 in nanosleep () from
 
2757
            /lib/i686/libc.so.6
 
2758
     3 Thread 16386 (LWP 18331)  0x40252a35 in __pthread_sigsuspend ()
 
2759
            from /lib/i686/libpthread.so.0
 
2760
     2 Thread 32769 (LWP 18330)  0x420db1a7 in poll () from
 
2761
            /lib/i686/libc.so.6
 
2762
     1 Thread 16384 (LWP 18327)  0x420b0226 in nanosleep () from
 
2763
            /lib/i686/libc.so.6
 
2764
</pre>
 
2765
<p>
 
2766
   (gdb) thread 2
 
2767
</p>
 
2768
<pre>
 
2769
         ^^^^^^^^ switch to thread 2 and see it's state
 
2770
</pre>
 
2771
<p>
 
2772
   [Switching to thread 2 (Thread 32769 (LWP 18330))]#0  0x420db1a7 in
 
2773
</p>
 
2774
<pre>
 
2775
            poll () from /lib/i686/libc.so.6
 
2776
</pre>
 
2777
<p>
 
2778
   (gdb) info stack
 
2779
</p>
 
2780
<pre>
 
2781
         ^^^^^^^^^^ check the call stack
 
2782
</pre>
 
2783
<p>
 
2784
   #0  0x420db1a7 in poll () from /lib/i686/libc.so.6
 
2785
   #1  0x4024f9de in __pthread_manager () from /lib/i686/libpthread.so.0
 
2786
</p>
 
2787
<pre>
 
2788
                     ^^^^^^^^^^^^^^^^^ running __pthread_manager
 
2789
</pre>
 
2790
<br>
 
2791
<p>
 
2792
<b>Q.</b>&nbsp;
 
2793
 All the threads seem to be running ok.
 
2794
</p>
 
2795
<p>
 
2796
<b>A.</b>&nbsp;
 
2797
 Check if there's one that looks like this:
 
2798
</p>
 
2799
 
 
2800
<pre>
 
2801
     4 Thread 32771 (LWP 27295)  0x420cd207 in sched_yield () from
 
2802
            /lib/i686/libc.so.6
 
2803
</pre>
 
2804
<p>
 
2805
   Let ntop run a few more seconds (cont command), then check again.
 
2806
</p>
 
2807
<p>
 
2808
   If it's frozen in the sched_yield, you're probably tripping a deadlock 
 
2809
   situation that we've seen but don't understand - There's a lot of
 
2810
   stuff on the 'net, including what seems to be the same problem with
 
2811
   other resource intensive tools but no clear answers.  
 
2812
</p>
 
2813
<p>
 
2814
   This happens most often on RedHat Linux 8.0 (9 uses a different
 
2815
   threading library and the issue hasn't been reported there).  
 
2816
</p>
 
2817
<p>
 
2818
   Regardless, if you see the deadlock or just have a hung ntop, there is a
 
2819
   run time option to try: --disable-schedyield.  This option disables the
 
2820
   calls at a slight penalty to ntop's interactivness.  If you're experiencing
 
2821
   the deadlocks, try it.
 
2822
</p>
 
2823
<p>
 
2824
   And, especially if you're running something other than RedHat 8, please
 
2825
   let the ntop-dev list know about it.
 
2826
</p>
 
2827
<br>
 
2828
<p>
 
2829
<b>Q.</b>&nbsp;
 
2830
 But what about SQL and mySQL
 
2831
</p>
 
2832
<p>
 
2833
<b>A.</b>&nbsp;
 
2834
 Removed in 2.1.50+ versions - use rrd
 
2835
</p>
 
2836
<br>
 
2837
<p>
 
2838
<b>Q.</b>&nbsp;
 
2839
 But I really, really, need the data in an sql database.
 
2840
</p>
 
2841
<p>
 
2842
<b>A.</b>&nbsp;
 
2843
 If you are only interested in saving your netflow data in MySQL, use the
 
2844
   script ntop/NetFlow/netFlowClient.pl (netflow v5).  With few additional lines
 
2845
   you could save your data in flat files, forward the netflow data or whatever.
 
2846
</p>
 
2847
<p>
 
2848
   What this script does it set itself up as a netflow collector and sql
 
2849
   inserter. The main loop just accepts a netflow packet and inserts the flow(s)
 
2850
   into sql.
 
2851
</p>
 
2852
<p>
 
2853
   To use this with a single instance of ntop, just set ntop up as a netflow
 
2854
   sender, directed at the script (e.g. 127.0.0.1 on any port you like).
 
2855
   Configure the script with the port # and run it.
 
2856
</p>
 
2857
<p>
 
2858
   The same idea would work with sFlow, you would just have to change the packet
 
2859
   decoding part of the script.
 
2860
</p>
 
2861
 
 
2862
<pre>
 
2863
Q: How does ntop use lsof? nmap?
 
2864
</pre>
 
2865
<p>
 
2866
<b>A.</b>&nbsp;
 
2867
 ntop no longer uses these external tools.
 
2868
</p>
 
2869
<p>
 
2870
   OS fingerprinting was replaced by ettercap.
 
2871
</p>
 
2872
<p>
 
2873
   If you need lsof data, you should ssh to the host and run it locally (this
 
2874
   allows the sysadmin to put appropriate security on lsof).
 
2875
</p>
 
2876
<br>
 
2877
<p>
 
2878
<b>Q.</b>&nbsp;
 
2879
 Can I set the admin password from a script?
 
2880
</p>
 
2881
<p>
 
2882
<b>A.</b>&nbsp;
 
2883
 Yes, you can call ntop with the option:
 
2884
</p>
 
2885
<pre>
 
2886
      ntop --set-admin-password=password        
 
2887
</pre>
 
2888
<br>
 
2889
<p>
 
2890
<b>Q.</b>&nbsp;
 
2891
 What's this warning about ownership?
 
2892
</p>
 
2893
<p>
 
2894
<b>A.</b>&nbsp;
 
2895
 The first time you run make install and ntop creates a new
 
2896
   directory for ntop's files, there's a problem.  So you'll
 
2897
   see this warning box:
 
2898
</p>
 
2899
 
 
2900
<pre>
 
2901
      ************************************************************
 
2902
      ************************************************************
 
2903
</pre>
 
2904
 
 
2905
<pre>
 
2906
        WARNING: This install created a directory for the ntop
 
2907
                 files and databases:
 
2908
</pre>
 
2909
 
 
2910
<pre>
 
2911
                   some directory...
 
2912
</pre>
 
2913
 
 
2914
<pre>
 
2915
                 This directory MUST be owned by the user
 
2916
                 which you are going to use to run ntop.
 
2917
</pre>
 
2918
 
 
2919
<pre>
 
2920
                 The command you must issue is something like:
 
2921
</pre>
 
2922
 
 
2923
<pre>
 
2924
                 chown -R ntop.ntop <directory>
 
2925
           or    chown -R ntop:users <directory>
 
2926
</pre>
 
2927
 
 
2928
<pre>
 
2929
                 man chown to check the syntax for YOUR system
 
2930
</pre>
 
2931
 
 
2932
<pre>
 
2933
      ************************************************************
 
2934
      ************************************************************
 
2935
</pre>
 
2936
<p>
 
2937
   Since root created the directory, root is the owner.  And since we don't
 
2938
   know - yet - what user ntop is going to be run as, we can't issue the
 
2939
   chown (CHange OWNership) command for you.
 
2940
</p>
 
2941
<br>
 
2942
<p>
 
2943
<b>Q.</b>&nbsp;
 
2944
 And if I don't do this?
 
2945
</p>
 
2946
<p>
 
2947
<b>A.</b>&nbsp;
 
2948
 ntop won't run. Typically you get a message about a bad -P file or
 
2949
   endless prompts for the admin password.
 
2950
</p>
 
2951
<br>
 
2952
<p>
 
2953
<b>Q.</b>&nbsp;
 
2954
 I can't merge interfaces (-M option)?
 
2955
</p>
 
2956
<p>
 
2957
<b>A.</b>&nbsp;
 
2958
 Check your plugins and see if either netFlow or sFlow is active.
 
2959
   Regardless of whether you're using them, if they're active, they
 
2960
   (silently) force the -M switch on.
 
2961
</p>
 
2962
<br>
 
2963
<p>
 
2964
<b>Q.</b>&nbsp;
 
2965
 Explain -u.
 
2966
</p>
 
2967
<p>
 
2968
<b>A.</b>&nbsp;
 
2969
 -u root means that you are running ntop as root. It means you don't drop
 
2970
   root's superuser privledges, so pretty much you can read/write any file.
 
2971
   It's not a good idea.  While we're not aware of any security problems with
 
2972
   ntop, programs that run as root are targets.
 
2973
</p>
 
2974
<p>
 
2975
   -u ntop (or -u whatever) means you run as a normal user and can be assigned
 
2976
   only the privledges necessary to run ntop.  It also means you can only read/
 
2977
   write files as ntop.  So less is exposed.
 
2978
</p>
 
2979
<p>
 
2980
   For even better security, the -u userid should not have a valid shell, so
 
2981
   people can't use it to login.
 
2982
</p>
 
2983
<br>
 
2984
<p>
 
2985
<b>Q.</b>&nbsp;
 
2986
 What are the options that reduce ntop's workload?
 
2987
</p>
 
2988
<p>
 
2989
<b>A.</b>&nbsp;
 
2990
 These options turn off certain processing (and thus limit ntop's
 
2991
   functionality), and may be appropriate for high volume installations.
 
2992
</p>
 
2993
<p>
 
2994
   -b | --disable-decoders
 
2995
</p>
 
2996
 
 
2997
<pre>
 
2998
     This flag disables protocol decoders. Use it for better performance
 
2999
     or if you feel ntop has problems handling these protocols in your
 
3000
     environment.
 
3001
</pre>
 
3002
 
 
3003
<pre>
 
3004
     This switch disables code in a number of places throughout ntop, code
 
3005
     which analyzes specific protocols, but can place additional load on the
 
3006
     host.  This switch could be used to run ntop on low-end CPUs or where
 
3007
     ntop is acting as a collector (netFlow or sFlow) and the GUI is not
 
3008
     required.
 
3009
</pre>
 
3010
 
 
3011
<pre>
 
3012
     Disabled is the analysis of:
 
3013
</pre>
 
3014
 
 
3015
<pre>
 
3016
        DNS Sniffing - where ntop captures DNS information from other hosts'
 
3017
                       requests to reduce the # of DNS requests ntop must -
 
3018
                       itself - make.
 
3019
</pre>
 
3020
 
 
3021
<pre>
 
3022
        NetBIOS   \
 
3023
        NetWare    \
 
3024
        AppleTalk   -- resource intensive protocol analysis of less
 
3025
        bootp/dhcp /   common protocols.
 
3026
        OSI       /
 
3027
</pre>
 
3028
 
 
3029
<pre>
 
3030
        http (80) - Request success/failure counting on port 80 and other
 
3031
                    analysis, including "Virtual Host".
 
3032
</pre>
 
3033
 
 
3034
<pre>
 
3035
        ftp passive session tracking.
 
3036
</pre>
 
3037
 
 
3038
<pre>
 
3039
        "Wrong Port" monitoring for: http, ftp and smtp (used with the
 
3040
              -q | --create-suspicious-packets option to dump "suspicious"
 
3041
              packets to an analysis file)  With this option, ntop checks
 
3042
              the payload for each new connection, looking for text usually
 
3043
              present in http, ftp or smtp requests.  If these are not on the
 
3044
              "normal" ports (http's 80, ntop's 3000 or squid's 3128, ftp's
 
3045
              21 or smtp's 25) (or there is a non-ftp or smtp request on the
 
3046
              standard ports), the packet is logged.
 
3047
</pre>
 
3048
<p>
 
3049
   -g | --track-local-hosts
 
3050
</p>
 
3051
 
 
3052
<pre>
 
3053
     Use this flag to tell ntop that you care only about local hosts (use
 
3054
     -m | -- local-subnets to specify local nets).  This flag is useful when
 
3055
     ntop sees many hosts (e.g. border gateway) but only the local ones need
 
3056
     to be tracked.
 
3057
</pre>
 
3058
 
 
3059
<pre>
 
3060
     This switch disables code in a number of places throughout ntop, code
 
3061
     which allows ntop to track "foreign" hosts (that is ones not local
 
3062
     according to the IP address(es) of ntop's interfaces or set pseudo-local
 
3063
     by -m | -- local-subnets).
 
3064
</pre>
 
3065
 
 
3066
<pre>
 
3067
     Basically, ntop doesn't bother to do DNS resolution on these addresses
 
3068
     and, for purposes of various counts, uses the "other" bucket instead of
 
3069
     creating a unique hash table bucket for the specific host.
 
3070
</pre>
 
3071
 
 
3072
<pre>
 
3073
     This switch could be used to run ntop on low-end CPUs or where ntop is
 
3074
     acting as a collector (netFlow or sFlow) and the GUI is not required.
 
3075
</pre>
 
3076
<p>
 
3077
   -o | --no-mac
 
3078
</p>
 
3079
 
 
3080
<pre>
 
3081
     Specifies that ntop should not trust MAC addresses but just IP addresses.
 
3082
     This option is useful whenever ntop is started on an interface where MAC
 
3083
     (Media Access Controller - the low-level Ethernet address) addresses can
 
3084
     not really be trusted (e.g. port/VLAN mirror in Switched Ethernet
 
3085
     environments).
 
3086
</pre>
 
3087
 
 
3088
<pre>
 
3089
     Certain processing is performed differently:
 
3090
</pre>
 
3091
 
 
3092
<pre>
 
3093
          Hash search is via IP not MAC
 
3094
</pre>
 
3095
 
 
3096
<pre>
 
3097
     Certain capabilities are disabled:
 
3098
</pre>
 
3099
 
 
3100
<pre>
 
3101
          Analysis of bootp/dhcp requests
 
3102
          localRoutersList.html report
 
3103
          Wrong net mask log message and flag
 
3104
          Analysis of non-tcp/udp protocols like NetWare and Spanning Tree
 
3105
          Router listing on Host Detailed report.
 
3106
          Traffic Matrix report
 
3107
</pre>
 
3108
 
 
3109
<pre>
 
3110
     (Note that this list is subject to change as we learn more about protocols
 
3111
      that do/do not depend on the MAC address)
 
3112
</pre>
 
3113
 
 
3114
<pre>
 
3115
     See also -z | --disable-sessions
 
3116
</pre>
 
3117
<p>
 
3118
   -z | --disable-sessions
 
3119
</p>
 
3120
 
 
3121
<pre>
 
3122
     This flag disables tcp session tracking. Use it for better performance or
 
3123
     when you don't really need the tracking of sessions.
 
3124
</pre>
 
3125
 
 
3126
<pre>
 
3127
     Also, in situations where the MAC addresses cannot be trusted, ntop may
 
3128
     - or may not - be able to accurately track tcp sessions.  There is no easy
 
3129
     way to tell, so this switch puts control back into the users' hands.
 
3130
</pre>
 
3131
 
 
3132
<pre>
 
3133
     In versions after 2.0 up to & including 2.1.2, the -j | 
 
3134
     --border-sniffer-mode flag (predecessor of -o | --no-mac) always turned
 
3135
     this off.  Many users wanted to try turning session tracking back on, and
 
3136
     did via code patches with mixed results.
 
3137
</pre>
 
3138
 
 
3139
<pre>
 
3140
     Suggested usage:  If you enable -o | --no-mac, try running ntop with
 
3141
     sessions enabled.  If the data looks reasonable, congratulations - your
 
3142
     network allows session tracking.  If the data does not look reasonable,
 
3143
     then you will also need to disable session tracking with this switch.
 
3144
</pre>
 
3145
<br>
 
3146
<p>
 
3147
<b>Q.</b>&nbsp;
 
3148
 -s | --no-promiscuous doesn't work
 
3149
</p>
 
3150
<p>
 
3151
<b>A.</b>&nbsp;
 
3152
 It should work - it's passed to pcap_open_live. Understand that it does mean
 
3153
   ntop sees a lot less comprehensive view of the traffic.  You won't see
 
3154
   anything different unless you do an ifconfig on the interface.  Note that
 
3155
   while the parameter specifies if the interface is to be put into promiscuous
 
3156
   mode, even if this parameter is false, the interface could well be in
 
3157
   promiscuous mode for some other reason.
 
3158
</p>
 
3159
<p>
 
3160
   If it fails, you'll see a message and ntop will refuse to startup
 
3161
</p>
 
3162
<br>
 
3163
<p>
 
3164
<b>Q.</b>&nbsp;
 
3165
 How does -m | --local-subnets work?
 
3166
</p>
 
3167
<p>
 
3168
<b>A.</b>&nbsp;
 
3169
 This flag allows users to specify the subnets whose traffic is considered
 
3170
   local (called "pseudoLocal" internally).  
 
3171
</p>
 
3172
<p>
 
3173
   The format is
 
3174
</p>
 
3175
<pre>
 
3176
        <network address>/<# subnet mask bits>[,<network address>/<#  subnet 
 
3177
         mask bits>
 
3178
</pre>
 
3179
<p>
 
3180
   For instance "131.114.21.0/24,10.0.0.0/255.0.0.0".
 
3181
</p>
 
3182
<br>
 
3183
<p>
 
3184
<b>Q.</b>&nbsp;
 
3185
 (followup) but what does it MEAN?
 
3186
</p>
 
3187
<p>
 
3188
<b>A.</b>&nbsp;
 
3189
 Surprisingly, it means EXACTLY what it says. Treat traffic on the listed
 
3190
   subnet(s) as local.
 
3191
</p>
 
3192
<p>
 
3193
   -m relates to the traffic you see on the wire at the TCP/IP level.
 
3194
   -m tells ntop something it can't determine by itself.  And that is to 
 
3195
   treat a range of addresses EXACTLY like it was local.
 
3196
</p>
 
3197
<p>
 
3198
   For example, on my Cable Modem, I see broadcasts for a number of subnets
 
3199
   that AT&T (now Comcast) has assigned to this area (I don't see the 
 
3200
   traffic just the broadcasts).
 
3201
</p>
 
3202
<p>
 
3203
   If you have VLANs or simply network overlays (two or more networks on the
 
3204
   same wire, but with separate address spaces).  etc.
 
3205
</p>
 
3206
<p>
 
3207
   Those are the cases where you use -m.  To tell ntop to treat that traffic
 
3208
   as local.
 
3209
</p>
 
3210
<br>
 
3211
<p>
 
3212
<b>Q.</b>&nbsp;
 
3213
 Why
 
3214
</p>
 
3215
<pre>
 
3216
A  ntop differentiates between local traffic and remote traffic.  There are
 
3217
   actually four classes (although only three are routinely reported) L->L L->R
 
3218
   R->L and R->R.  Some additional processing is done and some additional 
 
3219
   reporting is available for L traffic.
 
3220
</pre>
 
3221
<br>
 
3222
<p>
 
3223
<b>Q.</b>&nbsp;
 
3224
 I'm confused. Explain, please!
 
3225
</p>
 
3226
<p>
 
3227
<b>A.</b>&nbsp;
 
3228
 Suppose your IP is 1.2.3.4 with a 255.255.255.0 netmask (a/k/a 1.2.3.4/24)
 
3229
</p>
 
3230
<p>
 
3231
   Under the TCP/IP protocol, traffic with any address 1.2.3.1 -> 1.2.3.254 does
 
3232
   not get routed.  It's "local".
 
3233
</p>
 
3234
<p>
 
3235
   Your buddy is at 1.2.3.9 and the router is 1.2.3.1, so your network looks
 
3236
   like this:
 
3237
</p>
 
3238
<p>
 
3239
   the       +--------+
 
3240
   world-----+ Router +--1.2.3.1--------------------------------------
 
3241
   +dog      +--------+                | 1.2.3.4             | 1.2.3.9
 
3242
</p>
 
3243
<pre>
 
3244
                                  +--------+            +--------+
 
3245
                                  |  You   |            |  Buddy |
 
3246
                                  +--------+            +--------+
 
3247
</pre>
 
3248
<p>
 
3249
   Say you send a packet to your buddy at 1.2.3.9. You build a packet with
 
3250
   SRC=1.2.3.4 DST=1.2.3.9 and your data and cast it out the wire.   (For
 
3251
   purposes of this illustration, ignore the fact the your TCP stack would
 
3252
   recognize the "local" nature of the packet and actually use another, lower
 
3253
   level protocol, called Ethernet to deliver it.)
 
3254
</p>
 
3255
<p>
 
3256
   The router (1.2.3.1) looks at it, does the math and ignores it - it's local
 
3257
   Your buddy (1.2.3.9) looks at it, says - gee, that's me and reads it
 
3258
</p>
 
3259
<p>
 
3260
   This is L->L traffic.
 
3261
</p>
 
3262
<p>
 
3263
   Now you send a packet to ntop.org at 131.114.21.9.  Again, SRC=1.2.3.4 and
 
3264
   Now DST=131.114.21.9.
 
3265
</p>
 
3266
<p>
 
3267
   The router (1.2.3.1) looks at it, does the math and says - oops, I have to
 
3268
   send it out to the world. Your buddy (1.2.3.9) looks at it, says - gee that's
 
3269
   NOT me and ignores it
 
3270
</p>
 
3271
<p>
 
3272
   This is L->R traffic.
 
3273
</p>
 
3274
<p>
 
3275
   Now it's perfectly possible to have multiple (physical) networks on the same
 
3276
   physical wire.  Say that your ISP chooses to put 1.2.4.1-1.2.4.254
 
3277
   (1.2.4.0/24) on the same wire. (Why would they do this? - maybe it's a big
 
3278
   pipe and only a few users or whatever).
 
3279
</p>
 
3280
<p>
 
3281
   A packet from 1.2.4.4 -> 1.2.4.9 is seen by
 
3282
</p>
 
3283
<p>
 
3284
   The router - no, that too is local, ignore it
 
3285
   You (1.2.3.4): (1.2.4.9) - not me - ignore it
 
3286
   Buddy (1.2.3.9) - um... 1.2.4.9 - not me - ignore it
 
3287
</p>
 
3288
<p>
 
3289
   And that's perfectly legal.
 
3290
</p>
 
3291
<p>
 
3292
   But what if you are the ISP and you want ntop to see ALL the traffic on that
 
3293
   wire? ntop will figure out from it's own IP address that the 1.2.3.0/24
 
3294
   traffic is local, but it will classify the 1.2.4.0/24 as REMOTE.
 
3295
</p>
 
3296
<p>
 
3297
   And that is what the --local-subnets switch does.  It tells ntop to treat
 
3298
   that 1.2.4.0/24 traffic as local.
 
3299
</p>
 
3300
<p>
 
3301
   If there isn't any other traffic on the wire, then telling ntop to treat it
 
3302
   as local won't change a thing.
 
3303
</p>
 
3304
<p>
 
3305
   You can always use a packet sniffer, such as tcpdump to scan the traffic on
 
3306
   the wire and see what's really there...
 
3307
</p>
 
3308
<br>
 
3309
<p>
 
3310
<b>Q.</b>&nbsp;
 
3311
 And internally?
 
3312
</p>
 
3313
<p>
 
3314
<b>A.</b>&nbsp;
 
3315
 ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer
 
3316
   (layer 2) nor a pure TCP/IP analyzer (layer 3).  Most of ntop's displayed
 
3317
   counts are at the TCP/IP level, and that's what confuses people.  Internally,
 
3318
   ntop works both at the level of the Ethernet frame and the TCP/IP packet.
 
3319
</p>
 
3320
<p>
 
3321
   A single MAC address can be associated with multiple TCP/IP addresses.  The
 
3322
   MAC address -- unless something is horribly wrong on the network or with the
 
3323
   hardware or somebody is deliberately spoofing it -- is guaranteed to be
 
3324
   unique and refers to a physical host or network interface.  For many reports,
 
3325
   ntop displays the information using the MAC address to separate physical
 
3326
   devices.  Other data is accumulated and displayed at the TCP/IP (level 3)
 
3327
   layer.
 
3328
</p>
 
3329
<p>
 
3330
   -m relates to the traffic you see on the wire at the TCP/IP level.
 
3331
   -m tells ntop something it can't determine by itself.  And that is to treat
 
3332
   that range of addresses EXACTLY like it was local.
 
3333
</p>
 
3334
<p>
 
3335
   For example, on my Cable Modem, I see broadcasts for a number of subnets
 
3336
   that AT&T has assigned to this area (I don't see the traffic, but you get
 
3337
   the picture) in an overlay structure (two or more networks on the
 
3338
   same wire, but with separate address spaces).
 
3339
</p>
 
3340
<br>
 
3341
<p>
 
3342
<b>Q.</b>&nbsp;
 
3343
 What about multicast traffic?
 
3344
</p>
 
3345
<p>
 
3346
<b>A.</b>&nbsp;
 
3347
 Multicast traffic uses the 224.0.0.0/4 address range (that is all addresses
 
3348
   between 224.0.0.0 and 239.255.255.255 - see RFC 1112).  By default then,
 
3349
   all multicast traffic is treated as 'Remote' by ntop.  
 
3350
</p>
 
3351
<p>
 
3352
   Your actual network topology may be such that multicast traffic could
 
3353
   all be local, all be remote or a mixture.  You can use the -m | 
 
3354
   --local-subnets parameter to force some (or all) multicast groups
 
3355
   to be counted as 'Local' traffic.
 
3356
</p>
 
3357
<br>
 
3358
<p>
 
3359
<b>Q.</b>&nbsp;
 
3360
 What about VLANs?
 
3361
</p>
 
3362
<p>
 
3363
<b>A.</b>&nbsp;
 
3364
 VLAN traffic is also a special case. ntop treats all traffic within your
 
3365
   machine's netmask definition as 'Local'.  For instance, you may have a /16
 
3366
   network (netmask of 255.255.0.0), and you are using VLANs to distribute
 
3367
   the traffic.  In this case ntop will see the a.b.c.d/16 address and classify
 
3368
   all traffic within this /16 network as 'Local'.
 
3369
</p>
 
3370
<p>
 
3371
   Don't design your network that way.
 
3372
</p>
 
3373
<br>
 
3374
<p>
 
3375
<b>Q.</b>&nbsp;
 
3376
 But they did!
 
3377
</p>
 
3378
<p>
 
3379
<b>A.</b>&nbsp;
 
3380
 This MIGHT work:
 
3381
</p>
 
3382
<p>
 
3383
   Use an un-numbered interface, so that ntop doesn't assign any implicit
 
3384
   'Local' addresses.  Then use the -m | --local-subnets parameter to 
 
3385
   define what is truly 'Local'.  As long as there aren't too many
 
3386
   'Local' networks, this should work.  I run something sort of like this
 
3387
   (but using /24s not subdividing a /16) for my development network.
 
3388
</p>
 
3389
<br>
 
3390
<p>
 
3391
<b>Q.</b>&nbsp;
 
3392
 What are the default protocols ntop monitors?
 
3393
</p>
 
3394
<p>
 
3395
<b>A.</b>&nbsp;
 
3396
 (These are the ones ntop monitors if the user does not supply a -p parameter)
 
3397
   Check addDefaultProtocols() in ntop.c around line 520.
 
3398
   The current list (August 2003) is
 
3399
</p>
 
3400
 
 
3401
<pre>
 
3402
     Protocol   Ports
 
3403
     --------   -----
 
3404
</pre>
 
3405
 
 
3406
<pre>
 
3407
     FTP        ftp ftp-data
 
3408
     HTTP       http www https 3128      /* 3128 is HTTP cache */
 
3409
     DNS        name domain
 
3410
     Telnet     telnet login
 
3411
     NBios-IP   netbios-ns netbios-dgm netbios-ssn
 
3412
     Mail       pop-2 pop-3 pop3 kpop smtp imap imap2
 
3413
     DHCP/BOOTP 67-68
 
3414
     SNMP       snmp snmp-trap
 
3415
     NNTP       nntp
 
3416
     NFS        mount pcnfs bwnfs nfsd nfsd-status
 
3417
     X11        6000-6010
 
3418
     SSH        22
 
3419
     Gnutella   6346 6347 6348
 
3420
     Morpheus   1214
 
3421
     WinMX      6699 7730
 
3422
     eDonkey    4661-4665
 
3423
     Messenger  1863 5000 5001 5190-5193
 
3424
</pre>
 
3425
<p>
 
3426
   Note that the names come from /etc/services (or your system's equivalent).
 
3427
   If you add protocols to /etc/services, you can refer to them by name on the
 
3428
   -p parameter.
 
3429
</p>
 
3430
<p>
 
3431
   The list changes over time as P2P protocols appear and disappear.  Check the
 
3432
   cvs and diff ntop.c (around line 550 in void addDefaultProtocols() if you
 
3433
   want the history.
 
3434
</p>
 
3435
<br>
 
3436
<p>
 
3437
<b>Q.</b>&nbsp;
 
3438
 What about protocol XYZZY?
 
3439
</p>
 
3440
<p>
 
3441
<b>A.</b>&nbsp;
 
3442
 The analysis of protocols is very limited and unsophisticated. But,
 
3443
   theoretically, if it's there in plain text, we could report on it.
 
3444
   The more work you can do up front in identifying the protocol (e.g. port #s,
 
3445
   header structure, etc.), the easier it would be to add.
 
3446
</p>
 
3447
<br>
 
3448
<p>
 
3449
<b>Q.</b>&nbsp;
 
3450
 How can I run ntop without being root?
 
3451
</p>
 
3452
<p>
 
3453
<b>A.</b>&nbsp;
 
3454
 A very simple way of doing this is:
 
3455
   > su
 
3456
   > chown root ntop
 
3457
   > chgrp root ntop
 
3458
   > chmod 6111 ntop
 
3459
   > exit
 
3460
</p>
 
3461
<p>
 
3462
   This makes ntop read-only for everyone and sets the setuid and setguid bits.
 
3463
</p>
 
3464
<p>
 
3465
   Do not forget to use the -u flag so that ntop changes user as soon as it
 
3466
   is started.
 
3467
</p>
 
3468
<p>
 
3469
   Understand that setting the Setuid and Setguid bits allows ANY user to run
 
3470
   ntop and it will run with ROOT privileges.  This is very powerful, and often
 
3471
   a source of security exposure - many system hardening scripts and
 
3472
   recommendations tell you to look for and remove the setuid and setguid bits.
 
3473
</p>
 
3474
<p>
 
3475
   DO NOT suid UNLESS YOU UNDERSTAND THE RISKS!
 
3476
</p>
 
3477
<p>
 
3478
   REPEAT: DO NOT DO THIS, IT IS A BAD IDEA!
 
3479
</p>
 
3480
<p>
 
3481
   Also, there are unconfirmed reports of this method problems, causing a
 
3482
</p>
 
3483
<pre>
 
3484
      "socket: operation not permitted"
 
3485
   message.  Probably related to something in the OS checking for real root
 
3486
   not suid to open the interface in promiscuous mode.
 
3487
</pre>
 
3488
<br>
 
3489
<p>
 
3490
<b>Q.</b>&nbsp;
 
3491
 I am using a /16 (/25 or whatever) mask and I get this message:
 
3492
</p>
 
3493
<pre>
 
3494
      Truncated network size to 1024 hosts (real netmask 255.255.255.0)
 
3495
</pre>
 
3496
<p>
 
3497
<b>A.</b>&nbsp;
 
3498
 Yes. ntop limits each network to 1024 hosts (a /24). If you need more, alter
 
3499
   the #define for MAX_SUBNET_HOSTS in globals-defines.h and recompile.  Space
 
3500
   has to be reserved for this many hosts for each network, so the limit exists
 
3501
   to keep memory usage from growing to absurd levels on people with "class A"
 
3502
   (/8) interfaces (e.g. 10. or Cable Modems, etc.).
 
3503
</p>
 
3504
<h2>Running - On-going</h2>
 
3505
<br>
 
3506
<p>
 
3507
<b>Q.</b>&nbsp;
 
3508
 Explain L and R - why doesn't ntop double count?
 
3509
</p>
 
3510
<p>
 
3511
<b>A.</b>&nbsp;
 
3512
 Classification is all based on what ntop SEES in the packets. ntop sees
 
3513
   packets and ONLY packets.  Packets have a FROM and a TO address.  Which 
 
3514
   packets ntop sees is determined by the interfaces it is monitoring.
 
3515
</p>
 
3516
<p>
 
3517
   Traffic (packets) is classified based on the joint classification of the
 
3518
   FROM address (L or R) and the TO address (L or R).
 
3519
</p>
 
3520
<p>
 
3521
   Only in L->L traffic will ntop see sent=rcvd and 'double count'.
 
3522
</p>
 
3523
 
 
3524
<pre>
 
3525
                            Host: 192.168.1.x  www.yahoo.com
 
3526
                                  L->R  R->L   L->R  R->L
 
3527
                                  S  R  S  R   S  R  S  R
 
3528
      192.168.1.x>www.yahoo.com
 
3529
        HTTP GET ...             30  .  .  .   .  .  . 30
 
3530
</pre>
 
3531
 
 
3532
<pre>
 
3533
      www.yahoo.com>192.168.1.x
 
3534
        HTTP 200                  .  .  .  8   8  .  .  .
 
3535
</pre>
 
3536
 
 
3537
<pre>
 
3538
      www.yahoo.com>192.168.1.x   .  .  .200 200  .  .  .
 
3539
        <html>...</html>
 
3540
</pre>
 
3541
 
 
3542
<pre>
 
3543
      etc.
 
3544
</pre>
 
3545
<br>
 
3546
<p>
 
3547
<b>Q.</b>&nbsp;
 
3548
 Why does ntop use so much memory ?
 
3549
</p>
 
3550
<p>
 
3551
<b>A.</b>&nbsp;
 
3552
 ntop holds a lot of information about each host it has seen in an in-memory
 
3553
   table. Periodically, it looks at all the entries in the table and flushes any
 
3554
   which have been idle for a period of time.
 
3555
</p>
 
3556
<p>
 
3557
   You can change the sizing of the table and the flushing interval via #define
 
3558
   statements in globals-defines.h.
 
3559
</p>
 
3560
<p>
 
3561
   But realistically, ntop needs enough memory to hold information about what's
 
3562
   active on YOUR network.
 
3563
</p>
 
3564
<p>
 
3565
   To reduce memory, monitor fewer protocols or use the filter (-B "bpf filter")
 
3566
   option to monitor only parts of the network.
 
3567
</p>
 
3568
<p>
 
3569
   There have been a couple of discussions on the ntop mailing list about ntop's
 
3570
   memory usage - you might read them (search on gmane).
 
3571
</p>
 
3572
<br>
 
3573
<p>
 
3574
<b>Q.</b>&nbsp;
 
3575
 So ntop's memory usage is dependent upon?
 
3576
</p>
 
3577
<p>
 
3578
<b>A.</b>&nbsp;
 
3579
 ntop's memory usage for host tables depends on the # of hosts it sees in
 
3580
   packet traffic.  This is NOT, repeat NOT controllable by ntop in ANY way.
 
3581
   If a user kicks off a port scan, 100s of hosts appear.  If somebody does a
 
3582
   DOS attack against you, 1000s of hosts 'appear'.  If a user searches Kazza
 
3583
   for an obscure song, it can probe 4K hosts. etc.
 
3584
</p>
 
3585
<p>
 
3586
   Lots of those hosts appear, have a few bytes of traffic and then disappear.
 
3587
   Each host has a variable amount of memory - there's a base structure, some
 
3588
   optional counter structures and a large # of pointer fields, which may or
 
3589
   may not be valued for any given host.  It depends on the # of active
 
3590
   sessions and a lot of other things, but 8-20K is a good guess - I usually
 
3591
   use 12K as an guestimating size.  Similarly, sessions may appear and
 
3592
   disappear (http: opens a lot, does a small retrieval and closes them), ssh
 
3593
   may last for days.  etc.   Memory is consumed tracking them too.
 
3594
</p>
 
3595
<br>
 
3596
<p>
 
3597
<b>Q.</b>&nbsp;
 
3598
 So what does the purge do?
 
3599
</p>
 
3600
<p>
 
3601
<b>A.</b>&nbsp;
 
3602
 ntop purges idle hosts. Period.
 
3603
</p>
 
3604
<p>
 
3605
   Idle being defined as having not had packet traffic for a #define able
 
3606
   period, 5 minutes by default.
 
3607
</p>
 
3608
<p>
 
3609
   Because of the amount of linked data, these purges take time (lots of 
 
3610
   free() calls on all those char* values), so we don't purge in 'real time'.
 
3611
   First we build a list of idle hosts, then we purge from that list.
 
3612
   Any idle host is eligible for purge (unless you tell ntop not to purge idle
 
3613
   hosts, which is usable only on small networks).
 
3614
</p>
 
3615
<p>
 
3616
   Over time, all idle hosts are purged.  Only to be perturbed by the 
 
3617
   next burst of activity - say a port scan or everybody logging in back
 
3618
   in after lunch.  Eventually, there's some form of steady state, but it's
 
3619
   HIGHLY dependent upon network activity.  Which, remember, is external to 
 
3620
   ntop and can't be predicted.
 
3621
</p>
 
3622
<br>
 
3623
<p>
 
3624
<b>Q.</b>&nbsp;
 
3625
 Why?
 
3626
</p>
 
3627
<p>
 
3628
<b>A.</b>&nbsp;
 
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
 
3631
   time to sort (let alone free).   During which time, on that busy network,
 
3632
   a couple of dozen packets are processed...  Meaning maybe your list of idle
 
3633
   hosts is wrong.
 
3634
</p>
 
3635
<br>
 
3636
<p>
 
3637
<b>Q.</b>&nbsp;
 
3638
 So how about a hard memory limit?
 
3639
</p>
 
3640
<p>
 
3641
<b>A.</b>&nbsp;
 
3642
 There's no way to make a hard limit without purging ACTIVE hosts (or
 
3643
   non-IDLE given ntop's definition of idle).
 
3644
</p>
 
3645
<p>
 
3646
   Think about it ... you're at that 1GB limit and you find a new host.
 
3647
   Do you kick off an interim purge (with it's huge overhead?)  And wait
 
3648
   2 or 3 s for an available slot??  While 1000s of other packets appear??
 
3649
</p>
 
3650
<br>
 
3651
<p>
 
3652
<b>Q.</b>&nbsp;
 
3653
 Soft limit?
 
3654
</p>
 
3655
<p>
 
3656
<b>A.</b>&nbsp;
 
3657
 It might, might, be possible as a soft limit - but it's got a lot of
 
3658
   issues.
 
3659
</p>
 
3660
<p>
 
3661
   First off, tracking memory usage of the hosts tables is itself a huge
 
3662
   job. There are multiple places were stuff is purged, added to the 
 
3663
   structures as pointers, etc. and there's a queue of purged entries 
 
3664
   for reuse to cut down on the malloc() calls.
 
3665
</p>
 
3666
<p>
 
3667
   Secondly, the purge is resource intensive, and has been the cause of
 
3668
   deadlocks before - you don't dare lock the structures for too long - 
 
3669
   packets keep arriving, and FAST on the busy network that has the memory
 
3670
   issues in the first place.  Since you can't lock for long, you can only
 
3671
   purge a small # of entries.
 
3672
</p>
 
3673
<br>
 
3674
<p>
 
3675
<b>Q.</b>&nbsp;
 
3676
 Why does ntop drop packets?
 
3677
</p>
 
3678
<p>
 
3679
<b>A.</b>&nbsp;
 
3680
 Short Answer: You need a faster processor. Maybe.
 
3681
</p>
 
3682
<p>
 
3683
<b>A.</b>&nbsp;
 
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 
 
3686
   actually in ntop.
 
3687
</p>
 
3688
<p>
 
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:
 
3692
</p>
 
3693
 
 
3694
<pre>
 
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 
 
3700
       pcap_geterr()."
 
3701
</pre>
 
3702
<p>
 
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.
 
3706
</p>
 
3707
<p>
 
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.
 
3710
</p>
 
3711
<p>
 
3712
   It looks great, but the reality is that the stats provided by libpcap
 
3713
   aren't very good!
 
3714
</p>
 
3715
<br>
 
3716
<p>
 
3717
<b>Q.</b>&nbsp;
 
3718
 Not good? Why...
 
3719
</p>
 
3720
<p>
 
3721
<b>A.</b>&nbsp;
 
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.
 
3726
</p>
 
3727
<p>
 
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.
 
3730
</p>
 
3731
<br>
 
3732
<p>
 
3733
<b>Q.</b>&nbsp;
 
3734
 How can packets be lost in the NIC?
 
3735
</p>
 
3736
<p>
 
3737
<b>A.</b>&nbsp;
 
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.
 
3742
</p>
 
3743
<p>
 
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
 
3748
   boost performance.
 
3749
</p>
 
3750
<p>
 
3751
   Check ifconfig for this:
 
3752
</p>
 
3753
 
 
3754
<pre>
 
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
 
3759
                                             ^^^^^^^^^
 
3760
                TX packets:473009 errors:0 dropped:0 overruns:0 carrier:0
 
3761
                                           ^^^^^^^^^
 
3762
                collisions:1073 txqueuelen:100
 
3763
                RX bytes:2606704447 (2485.9 Mb)  TX bytes:70474880 (67.2 Mb)
 
3764
                Interrupt:11 Base address:0xc000
 
3765
</pre>
 
3766
<p>
 
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?  
 
3771
</p>
 
3772
 
 
3773
<pre>
 
3774
       You're toast...
 
3775
</pre>
 
3776
<p>
 
3777
   Upgrade the Processor or NIC. Maybe.
 
3778
</p>
 
3779
<br>
 
3780
<p>
 
3781
<b>Q.</b>&nbsp;
 
3782
 Can you tell if the NIC is the bottleneck?
 
3783
</p>
 
3784
<p>
 
3785
<b>A.</b>&nbsp;
 
3786
 Probably not. Different NIC cards (and NIC card drivers) record different
 
3787
   information.  Different tools present pieces and parts of it differently.
 
3788
</p>
 
3789
<p>
 
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??
 
3793
</p>
 
3794
<p>
 
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.
 
3799
</p>
 
3800
<p>
 
3801
   For example - eth1 is an Intel Ethernet Pro/100, eth2 a 3c905...
 
3802
</p>
 
3803
<p>
 
3804
   # netstat -i --all
 
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
 
3809
</p>
 
3810
<p>
 
3811
   No errors - great, right?  But look at ifconfig, a few seconds earlier:
 
3812
</p>
 
3813
<p>
 
3814
   # ifconfig
 
3815
   eth1      Link encap:Ethernet  HWaddr 00:03:47:B1:62:27  
 
3816
</p>
 
3817
<pre>
 
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 
 
3824
</pre>
 
3825
<p>
 
3826
   eth2      Link encap:Ethernet  HWaddr 00:60:97:04:30:33  
 
3827
</p>
 
3828
<pre>
 
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 
 
3835
</pre>
 
3836
<p>
 
3837
   If I'm reading the code right, then the frame:nnnn count is set here:
 
3838
</p>
 
3839
 
 
3840
<pre>
 
3841
     sp->stats.rx_frame_errors += le32_to_cpu(sp->lstats->rx_align_errs);
 
3842
</pre>
 
3843
<p>
 
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.
 
3847
</p>
 
3848
<br>
 
3849
<p>
 
3850
<b>Q.</b>&nbsp;
 
3851
 How can packets can be lost in the kernel?
 
3852
</p>
 
3853
<p>
 
3854
<b>A.</b>&nbsp;
 
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.
 
3857
</p>
 
3858
<p>
 
3859
   Not really.
 
3860
</p>
 
3861
<p>
 
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 
 
3868
   time critical.
 
3869
</p>
 
3870
<p>
 
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).
 
3876
</p>
 
3877
<p>
 
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.
 
3881
</p>
 
3882
<p>
 
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.
 
3886
</p>
 
3887
<br>
 
3888
<p>
 
3889
<b>Q.</b>&nbsp;
 
3890
 But at least I can trust the libpcap reported counts, right?
 
3891
</p>
 
3892
<p>
 
3893
<b>A.</b>&nbsp;
 
3894
 Nope. You need to treat the pcap reported drops with more than a few
 
3895
   grains of salt.  See this thread, for example:
 
3896
</p>
 
3897
<pre>
 
3898
      http://www.tcpdump.org/lists/workers/2001/07/msg00018.html
 
3899
   and this msg:
 
3900
      http://www.mcabee.org/lists/snort-users/Jan-02/msg00771.html
 
3901
</pre>
 
3902
<p>
 
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".
 
3906
</p>
 
3907
<p>
 
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.
 
3913
</p>
 
3914
<p>
 
3915
   Ultimately, some piece of hardware or software SHOULD be counting packets
 
3916
   and dropped packets.
 
3917
</p>
 
3918
<p>
 
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).
 
3921
</p>
 
3922
<p>
 
3923
   Put the two together and I wouldn't trust 'em.
 
3924
</p>
 
3925
<p>
 
3926
   Want more fear?  Read the comments through out the libpcap code.  Like 
 
3927
   this gem from pcap-linux.c:
 
3928
</p>
 
3929
 
 
3930
<pre>
 
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.
 
3937
</pre>
 
3938
<p>
 
3939
   And this from pcap-bpf.c:
 
3940
</p>
 
3941
 
 
3942
<pre>
 
3943
    /*
 
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.
 
3947
     *
 
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.
 
3952
     *
 
3953
     * Both statistics include packets not yet read from the kernel
 
3954
     * by libpcap, and thus not yet seen by the application.
 
3955
     */
 
3956
</pre>
 
3957
<p>
 
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.  
 
3963
</p>
 
3964
<p>
 
3965
   If a BPF filter (-B option) is in place, the differences between OSes are
 
3966
   more significant.
 
3967
</p>
 
3968
<p>
 
3969
   etc.
 
3970
</p>
 
3971
<p>
 
3972
   Trust nobody...
 
3973
</p>
 
3974
<br>
 
3975
<p>
 
3976
<b>Q.</b>&nbsp;
 
3977
 ntop drops packets?
 
3978
</p>
 
3979
<p>
 
3980
<b>A.</b>&nbsp;
 
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.
 
3985
</p>
 
3986
<p>
 
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.
 
3990
</p>
 
3991
<p>
 
3992
   Now, you can increase PACKET_QUEUE_LENGTH
 
3993
</p>
 
3994
 
 
3995
<pre>
 
3996
      ntop.h:   693   #define PACKET_QUEUE_LENGTH     2048
 
3997
</pre>
 
3998
<p>
 
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).
 
4004
</p>
 
4005
<p>
 
4006
   The instantaneous and maximum value for the queue are reported in
 
4007
   the configuration report:
 
4008
</p>
 
4009
 
 
4010
<pre>
 
4011
      # Queued Pkts to Process 0
 
4012
      # Max Queued Pkts 0
 
4013
</pre>
 
4014
<p>
 
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.)
 
4021
</p>
 
4022
<br>
 
4023
<p>
 
4024
<b>Q.</b>&nbsp;
 
4025
 So what do you show?
 
4026
</p>
 
4027
<p>
 
4028
<b>A.</b>&nbsp;
 
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.
 
4031
</p>
 
4032
<p>
 
4033
   The counts that ARE available in a system-independent way are what is 
 
4034
   reported in the statistics on the Stats | Traffic page.
 
4035
</p>
 
4036
<br>
 
4037
<p>
 
4038
<b>Q.</b>&nbsp;
 
4039
 So what is reported?
 
4040
</p>
 
4041
<p>
 
4042
<b>A.</b>&nbsp;
 
4043
 ntop reports the packet and dropped counts as reported by libpcap and the
 
4044
   received, dropped and processed counts it maintains internally.
 
4045
</p>
 
4046
<br>
 
4047
<p>
 
4048
<b>Q.</b>&nbsp;
 
4049
 So what does ntop do with what it does receive?
 
4050
</p>
 
4051
<p>
 
4052
<b>A.</b>&nbsp;
 
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 
 
4056
   'bug'.
 
4057
</p>
 
4058
<p>
 
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).  
 
4062
</p>
 
4063
<br>
 
4064
<p>
 
4065
<b>Q.</b>&nbsp;
 
4066
 How do I tell?
 
4067
</p>
 
4068
<p>
 
4069
<b>A.</b>&nbsp;
 
4070
 You can monitor the queue size on the 'Configuration' (info.html) page.
 
4071
</p>
 
4072
<br>
 
4073
<p>
 
4074
<b>Q.</b>&nbsp;
 
4075
 What about the other dropped items?
 
4076
</p>
 
4077
<p>
 
4078
<b>A.</b>&nbsp;
 
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.
 
4081
</p>
 
4082
<p>
 
4083
   The best suggestion is to try another NIC or a faster machine.  
 
4084
</p>
 
4085
<br>
 
4086
<p>
 
4087
<b>Q.</b>&nbsp;
 
4088
 Why?
 
4089
</p>
 
4090
<p>
 
4091
<b>A.</b>&nbsp;
 
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.
 
4096
</p>
 
4097
<p>
 
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.
 
4100
</p>
 
4101
<br>
 
4102
<p>
 
4103
<b>Q.</b>&nbsp;
 
4104
 Won't a faster CPU help?
 
4105
</p>
 
4106
<p>
 
4107
<b>A.</b>&nbsp;
 
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.
 
4111
</p>
 
4112
<p>
 
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'.
 
4117
</p>
 
4118
<p>
 
4119
   As we say, YMMV...
 
4120
</p>
 
4121
<br>
 
4122
<p>
 
4123
<b>Q.</b>&nbsp;
 
4124
 So?
 
4125
</p>
 
4126
<p>
 
4127
<b>A.</b>&nbsp;
 
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.
 
4132
</p>
 
4133
<p>
 
4134
   Still it's not all gloom and doom!
 
4135
</p>
 
4136
<p>
 
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.
 
4140
</p>
 
4141
<br>
 
4142
<p>
 
4143
<b>Q.</b>&nbsp;
 
4144
 ntop stops capturing packets, except ARP and other broadcasts. Why?
 
4145
</p>
 
4146
<p>
 
4147
<b>A.</b>&nbsp;
 
4148
 Check if you have a daemon running that periodically checks for and
 
4149
   resets interfaces in promiscuous mode?  If that happens, all you
 
4150
   would see were broadcast packets like ARPs...
 
4151
</p>
 
4152
<p>
 
4153
   Check back in the log and see if there is a message about the interface
 
4154
   changing status.  Determine why.
 
4155
</p>
 
4156
<br>
 
4157
<p>
 
4158
<b>Q.</b>&nbsp;
 
4159
 How much horsepower do I need to run ntop on a network of size x?
 
4160
</p>
 
4161
<p>
 
4162
<b>A.</b>&nbsp;
 
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
 
4165
   buffer will handle the occasional peak, but if you see frequent
 
4166
   lost packets, you're in trouble.
 
4167
</p>
 
4168
<p>
 
4169
   Note that a few packets occasionally lost isn't a big deal for most
 
4170
   users.  After all, the network itself has losses - I've seen my AT&T
 
4171
   Broadband connection have spurts of 30% packet loss.  Ideally in a
 
4172
   LAN environment, the packet loss should be down in the small #s...
 
4173
   the Ethernet standard allows 1  error in 100,000,000(10^8), but most
 
4174
   vendors beat that by a long margin (even as high as 1 in 10^12).
 
4175
</p>
 
4176
<p>
 
4177
   Of course, those are lab measurements.  In the real world?  Not that good.
 
4178
   Electrical noise can be a real bugaboo. Remember, at a certain point, if
 
4179
   the NIC doesn't understand what it's seeing, it throws it away and
 
4180
   declares an error.  The key is to keep up with the traffic.
 
4181
</p>
 
4182
<p>
 
4183
   Similarly, the OS kernel does the same thing in it's interrupt handling
 
4184
   (throw away packets).  Last resort, but better than hanging up the whole
 
4185
   machine.
 
4186
</p>
 
4187
<p>
 
4188
   ntop drops packets when the queue gets longer than the permitted length.
 
4189
   You can see this in the configuration page as # Queued Pkts to Process
 
4190
   and # Max Queued Pkts.
 
4191
</p>
 
4192
<p>
 
4193
   One or two or a small number (you pick your tolerance) is ok, but constant
 
4194
   losses isn't.  What I'm saying is that as long as ntop can keep up with the
 
4195
   NIC, then the data is as good as it gets...  if ntop can't keep up, then the
 
4196
   data isn't very good.
 
4197
</p>
 
4198
<p>
 
4199
   If you have measurements - network size, traffic flow and %CPU used (with
 
4200
   the hardware info, of course), shoot them over to us on ntop and someday
 
4201
   maybe we'll be able to give better #s.
 
4202
</p>
 
4203
<br>
 
4204
<p>
 
4205
<b>Q.</b>&nbsp;
 
4206
 What about my Frobozz Model xx Magic Network card? Is it good enough?
 
4207
</p>
 
4208
<p>
 
4209
<b>A.</b>&nbsp;
 
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,
 
4212
   anything will do.  For a busy network, buy a decent PCI NIC.
 
4213
</p>
 
4214
<br>
 
4215
<p>
 
4216
<b>Q.</b>&nbsp;
 
4217
 Gigabit Ethernet?
 
4218
</p>
 
4219
<p>
 
4220
<b>A.</b>&nbsp;
 
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
 
4223
   of 32bit PCI and PC100/133 RAM, heck even PC2700 DDR).  
 
4224
</p>
 
4225
<br>
 
4226
<p>
 
4227
<b>Q.</b>&nbsp;
 
4228
 Do "zero copy" drivers help?
 
4229
</p>
 
4230
<p>
 
4231
<b>A.</b>&nbsp;
 
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:
 
4234
</p>
 
4235
 
 
4236
<pre>
 
4237
      "What is "zero copy"?
 
4238
</pre>
 
4239
 
 
4240
<pre>
 
4241
      Zero copy is a misnomer, or an accurate description, depending on how
 
4242
      you look at things.
 
4243
</pre>
 
4244
 
 
4245
<pre>
 
4246
      In the normal case, with network I/O, buffers are copied from the user
 
4247
      process into the kernel on the send side, and from the kernel into 
 
4248
      the user process on the receiving side.
 
4249
</pre>
 
4250
 
 
4251
<pre>
 
4252
      That is the copy that is being eliminated in this case. The DMA or 
 
4253
      copy from the kernel into the NIC, or from the NIC into the kernel is 
 
4254
      not the copy that is being eliminated. In fact you can't eliminate 
 
4255
      that copy without taking packet processing out of the kernel altogether.
 
4256
      (i.e. the kernel has to see the packet headers in order to determine 
 
4257
      what to do with the payload)
 
4258
</pre>
 
4259
 
 
4260
<pre>
 
4261
      Memory copies from userland into the kernel are one of the 
 
4262
      largest bottlenecks in network performance on a BSD system, so 
 
4263
      eliminating them can greatly increase network throughput, and 
 
4264
      decrease system load when CPU or memory bandwidth isn't the 
 
4265
      limiting factor."
 
4266
</pre>
 
4267
<p>
 
4268
   What's that mean?  It means that BEST CASE, you have to copy the data 
 
4269
   NIC->Kernel and without zero copy, it happens TWICE.  Then, once you're
 
4270
   in the kernel, it has to hand the data off to libpcap (another copy) 
 
4271
   and from libpcap to ntop.  So we're moving the data 3 or 4 times... 
 
4272
   best case!
 
4273
</p>
 
4274
<p>
 
4275
   Let's do some off the cuff math.  Looking here
 
4276
</p>
 
4277
<pre>
 
4278
      http://www6.tomshardware.com/mainboard/20020501/ddr400vsrambus-05.html
 
4279
   shows a table of memory types and max bandwidth (picking a few):
 
4280
</pre>
 
4281
 
 
4282
<pre>
 
4283
      Label  Name  Effective Clock  Data Bus Bandwidth
 
4284
      PC100  SDRAM       100 MHz     64 Bit  0,8 GB/s
 
4285
      PC133  SDRAM       133 MHz     64 Bit  1,06 GBb/s
 
4286
      PC2700 DDR333      166 MHz     64 Bit  2,7 GB/s
 
4287
</pre>
 
4288
<p>
 
4289
   See the problem?  A fully loaded GigE link is 1 Gb/s.  4x that is 0.5 
 
4290
   GB/s - so if ALL that's going on is the capture of packets from the network,
 
4291
   the CPU can keep up.  Maybe.  Those bandwidth numbers are theoretical, best
 
4292
   case (nice sequential access).  Throw in some other system activity, cache 
 
4293
   misses and CAS/RAS issues... and um...
 
4294
</p>
 
4295
<p>
 
4296
   The moral is that if you're going to use ntop to monitor big fat links,
 
4297
   you need screaming fast iron.
 
4298
</p>
 
4299
<br>
 
4300
<p>
 
4301
<b>Q.</b>&nbsp;
 
4302
 Can I disable logging? Totally?
 
4303
</p>
 
4304
<p>
 
4305
<b>A.</b>&nbsp;
 
4306
 Sort of - if you run single threaded, without the -d or -L options.
 
4307
   Multithreaded?  No.  If ntop creates child threads, they don't have
 
4308
   terminal access and have to have some way of reporting things.
 
4309
</p>
 
4310
<br>
 
4311
<p>
 
4312
<b>Q.</b>&nbsp;
 
4313
 I'm seeing weird "hosts" on my network with names like
 
4314
   "Bridge Sp. Tree/OSI Route".
 
4315
   What are they?
 
4316
</p>
 
4317
<p>
 
4318
<b>A.</b>&nbsp;
 
4319
 There is a list of "special" MAC address prefixes in vendor.c,
 
4320
   specialMacInfo[].  There are blocks of MAC addresses reserved (sometimes not
 
4321
   formally) for special uses, such as sharing information about Spanning Tree
 
4322
   for bridges.  These do not have an IP address - they operate at a lower
 
4323
   level - so nothing gets displayed in some of ntop's fields.
 
4324
</p>
 
4325
<p>
 
4326
   A reference about protocols at the wire level is here:
 
4327
</p>
 
4328
<pre>
 
4329
      http://www.oreillynet.com/pub/a/network/2001/03/02/net_2nd_lang.html
 
4330
</pre>
 
4331
<p>
 
4332
   If you only want to see TCP/IP, then I suggest you use -B "ip" to filter
 
4333
   only TCP/IP protocol on your ntop line...
 
4334
</p>
 
4335
<br>
 
4336
<p>
 
4337
<b>Q.</b>&nbsp;
 
4338
 How do I see fully qualified names for all my hosts? Some are netbios
 
4339
   names!
 
4340
</p>
 
4341
<p>
 
4342
<b>A.</b>&nbsp;
 
4343
 ntop doesn't SEND NetBIOS queries, it sniffs them off the traffic already on
 
4344
   the network.
 
4345
</p>
 
4346
<p>
 
4347
   There is only ONE case where ntop uses the NetBIOS names, which is if
 
4348
   it can't resolve them via DNS (both it's own queries and from sniffing
 
4349
   responses to other's queries off the network).
 
4350
</p>
 
4351
<p>
 
4352
   So, if you have a properly functioning DNS, you'll see DNS names.  If
 
4353
   these are (for example) internal names, unknown to the DNS server, you'll
 
4354
   see NetBIOS names if they are available.  Lastly, you'll get IP addresses...
 
4355
</p>
 
4356
<p>
 
4357
   If you do have a DNS, and the name is resolved as part of the default
 
4358
   domain, you won't see a fully qualified name back from the DNS, so ntop
 
4359
   won't have that information.
 
4360
</p>
 
4361
<p>
 
4362
   So, on a real network you'll often get a mix of name resolution types:
 
4363
</p>
 
4364
 
 
4365
<pre>
 
4366
    Host                            IP Address      MAC Address
 
4367
                                                                   Other Name(s)
 
4368
    netnews.attbi.com               63.240.76.16
 
4369
    tigger.homeportal.2wire.net     192.168.0.xx   00:D0:09:xx:xx:xx
 
4370
    homeportal.homeportal.2wire.net 192.168.0.1    00:D0:9E:xx:xx:xx
 
4371
    swallowtail                     192.168.0.XX   00:A0:CC:xx:xx:xx SWTL [DMN]
 
4372
    12-xxx-xxx-xxx.client.attbi.com 12.xxx.xxx.xxx 00:D0:9E:xx:xx:xx
 
4373
    12-xxx-xxx-yyy.client.attbi.com 12.xxx.xxx.yyy
 
4374
</pre>
 
4375
<br>
 
4376
<p>
 
4377
<b>Q.</b>&nbsp;
 
4378
 What does this log message (and others like it) mean?
 
4379
   **WARNING** releaseMutex() call with an UN-LOCKED mutex [hash.c:559] last
 
4380
</p>
 
4381
<pre>
 
4382
               unlock [pid 22176, pbuf.c:2598]
 
4383
</pre>
 
4384
<p>
 
4385
<b>A.</b>&nbsp;
 
4386
 Those messages are part of an error check in our mutex handling routines.
 
4387
</p>
 
4388
<p>
 
4389
   Actually they pretty much mean what they say.
 
4390
</p>
 
4391
<p>
 
4392
   releaseMutex() call with an UN-LOCKED mutex means that the corresponding
 
4393
   accessMutex() call never occured.
 
4394
</p>
 
4395
<p>
 
4396
   releaseMutex() call with an UN-INITIALIZED mutex means that the 
 
4397
   access/release occured before the createMutex().
 
4398
</p>
 
4399
<p>
 
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.
 
4403
</p>
 
4404
<p>
 
4405
   There are others, look in leaks.c for the entire set.
 
4406
</p>
 
4407
<br>
 
4408
<p>
 
4409
<b>Q.</b>&nbsp;
 
4410
 How serious are they?
 
4411
</p>
 
4412
<p>
 
4413
<b>A.</b>&nbsp;
 
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.
 
4416
</p>
 
4417
<p>
 
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.  
 
4422
   Those are spurious.
 
4423
</p>
 
4424
<p>
 
4425
   But for most users, these warning messages shouldn't be ignored if they occur
 
4426
   often.
 
4427
</p>
 
4428
<p>
 
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').
 
4434
</p>
 
4435
<p>
 
4436
   So we use this pattern instead:
 
4437
</p>
 
4438
 
 
4439
<pre>
 
4440
      access(stateChangeMutex)
 
4441
        set state data
 
4442
      release(stateChangeMutex)
 
4443
</pre>
 
4444
 
 
4445
<pre>
 
4446
      access(mutex) or release(mutex)
 
4447
</pre>
 
4448
 
 
4449
<pre>
 
4450
      access(stateChangeMutex)
 
4451
        set state data
 
4452
      release(stateChangeMutex)
 
4453
</pre>
 
4454
<p>
 
4455
   The problem is that these updates aren't atomic, so it's possible to have
 
4456
   the state data updated by another thread:
 
4457
</p>
 
4458
 
 
4459
<pre>
 
4460
      ---------thread A---------         ---------thread B---------
 
4461
      access(stateChangeMutex)
 
4462
        set state data
 
4463
                                         access(stateChangeMutex)
 
4464
                                         *****blocked****
 
4465
      release(stateChangeMutex)
 
4466
                                         (resumes)
 
4467
                                           set state data
 
4468
                                         release(stateChangeMutex)
 
4469
      access(mutex)
 
4470
      ****blocked****
 
4471
                                         release(mutex)
 
4472
      (resumes)
 
4473
                                         access(stateChangeMutex)
 
4474
                                           set state data
 
4475
                                         release(stateChangeMutex)
 
4476
</pre>
 
4477
 
 
4478
<pre>
 
4479
      access(stateChangeMutex)
 
4480
        set state data
 
4481
      release(stateChangeMutex)
 
4482
</pre>
 
4483
 
 
4484
<pre>
 
4485
      Unfortunately, this is equally likely:
 
4486
</pre>
 
4487
 
 
4488
<pre>
 
4489
      ---------thread A---------         ---------thread B---------
 
4490
      access(stateChangeMutex)
 
4491
        set state data
 
4492
                                         access(stateChangeMutex)
 
4493
                                         *****blocked****
 
4494
      release(stateChangeMutex)
 
4495
                                         (resumes)
 
4496
                                           set state data
 
4497
                                         release(stateChangeMutex)
 
4498
      access(mutex)
 
4499
      ****blocked****
 
4500
                                         release(mutex)
 
4501
      (resumes)
 
4502
      access(stateChangeMutex)
 
4503
        set state data
 
4504
      release(stateChangeMutex)
 
4505
                                         access(stateChangeMutex)
 
4506
                                           set state data
 
4507
                                         release(stateChangeMutex)
 
4508
</pre>
 
4509
<p>
 
4510
   So at the end, you have an inaccurate picture in the state table.
 
4511
</p>
 
4512
<br>
 
4513
<p>
 
4514
<b>Q.</b>&nbsp;
 
4515
 Threads. ugh...
 
4516
</p>
 
4517
<p>
 
4518
<b>A.</b>&nbsp;
 
4519
 There's a good set of articles on POSIX threads at
 
4520
</p>
 
4521
<pre>
 
4522
      http://www-106.ibm.com/developerworks/library/l-posix1/,
 
4523
      http://www-106.ibm.com/developerworks/library/l-posix2/ and
 
4524
      http://www-106.ibm.com/developerworks/library/l-posix3/.
 
4525
</pre>
 
4526
<br>
 
4527
<p>
 
4528
<b>Q.</b>&nbsp;
 
4529
 What does the message "URL security(1): ERROR: Found percent in
 
4530
   URL...DANGER... rejecting request" mean?
 
4531
</p>
 
4532
<p>
 
4533
<b>A.</b>&nbsp;
 
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
 
4536
   no situation where ntop should process this, we reject it.
 
4537
   URLsecurity in http.c is the place where these tests occur.
 
4538
</p>
 
4539
<br>
 
4540
<p>
 
4541
<b>Q.</b>&nbsp;
 
4542
 What does the message "Rejected request from address x.y.z.t (it previously
 
4543
   sent ntop a bad request)" mean?
 
4544
</p>
 
4545
<p>
 
4546
<b>A.</b>&nbsp;
 
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
 
4549
   requests...  rather than waste cycles ignoring an attack...
 
4550
</p>
 
4551
<br>
 
4552
<p>
 
4553
<b>Q.</b>&nbsp;
 
4554
 What are the other URL security(#) codes?
 
4555
</p>
 
4556
<p>
 
4557
<b>A.</b>&nbsp;
 
4558
 1. Found a % in the request (Unicode problems)
 
4559
   2.  Found a parameter type code (//, &&, ??)
 
4560
   3.  Found a directory transversal code (..)
 
4561
   4.  Found a prohibited (RFC1945) character
 
4562
   5.  Found a bad extension
 
4563
</p>
 
4564
<br>
 
4565
<p>
 
4566
<b>Q.</b>&nbsp;
 
4567
 ntop doesn't report any traffic at all.
 
4568
</p>
 
4569
<p>
 
4570
<b>A.</b>&nbsp;
 
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
 
4573
   doesn't count things.
 
4574
</p>
 
4575
<p>
 
4576
   ntop does not sample.  It processes every packet it sees and counts them.
 
4577
   Only if there is more traffic than ntop can handle for a long period of time
 
4578
   will the packet queue hit it's limit and packets be lost.  But this is still
 
4579
   not sampling.
 
4580
</p>
 
4581
<p>
 
4582
   Make sure that there's traffic on the interface(s) you are using. You can
 
4583
   use tcpdump or a similar network sniffer tool to check.
 
4584
</p>
 
4585
<p>
 
4586
   If you are on a segmented network (i.e. switched), you may not see traffic
 
4587
   that isn't destined for the ntop machine unless you configure the switch to
 
4588
   set the port for the ntop host into "mirror" or "management" mode (different
 
4589
   vendors call it different things, but it's a mode where ALL traffic is copied
 
4590
   to a specific port, regardless of which port the destination host is on).
 
4591
</p>
 
4592
<p>
 
4593
   If there is more than one interface in the ntop host, perhaps you aren't
 
4594
   listening on the one that has traffic?  Check using ifconfig:
 
4595
</p>
 
4596
<p>
 
4597
   eth0      Link encap:Ethernet  HWaddr 00:D0:09:77:85:B9
 
4598
</p>
 
4599
<pre>
 
4600
             inet addr:192.168.0.34  Bcast:192.168.0.255  Mask:255.255.255.0
 
4601
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
4602
             RX packets:1105906 errors:0 dropped:0 overruns:0 frame:0
 
4603
             TX packets:601935 errors:0 dropped:0 overruns:0 carrier:0
 
4604
             collisions:0 txqueuelen:100
 
4605
             RX bytes:119869887 (114.3 Mb)  TX bytes:112203781 (107.0 Mb)
 
4606
             Interrupt:11 Base address:0xc000
 
4607
</pre>
 
4608
<p>
 
4609
   If the RX and TX numbers are increasing, this shows that traffic IS
 
4610
   flowing...
 
4611
</p>
 
4612
<p>
 
4613
   If you have an unnumbered interface (listening only), remember you need to
 
4614
   use -m to tell ntop what is local and what isn't:
 
4615
</p>
 
4616
<p>
 
4617
   eth1      Link encap:Ethernet  HWaddr 00:30:F1:54:55:00
 
4618
</p>
 
4619
<pre>
 
4620
             UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
 
4621
             RX packets:1596612 errors:0 dropped:0 overruns:0 frame:0
 
4622
             TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 
4623
             collisions:0 txqueuelen:100
 
4624
             RX bytes:566953031 (540.6 Mb)  TX bytes:0 (0.0 b)
 
4625
</pre>
 
4626
<p>
 
4627
   You can select an interface using the '-i' flag, e.g. -i eth1 or
 
4628
   -i eth0,eth1.
 
4629
</p>
 
4630
<br>
 
4631
<p>
 
4632
<b>Q.</b>&nbsp;
 
4633
 ntop doesn't understand xxxxx?
 
4634
</p>
 
4635
<p>
 
4636
<b>A.</b>&nbsp;
 
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
 
4639
   that simple concept.
 
4640
</p>
 
4641
<p>
 
4642
   How does Apache handle virtual hosts? It analyzes the flow at the
 
4643
   application level (layer 4) not the wire/packet/protocol (layers 1, 2 and
 
4644
   3).  It does this by re-assembling packets into a layer 4 message (e.g. GET
 
4645
   http://virtual.host.name.com/page.html)...
 
4646
</p>
 
4647
<p>
 
4648
   Now there are some layer 4 analysis routines - virtual hosts was added in
 
4649
   2.2 (and the folks who have virtual hosts have been pretty pleased), ftp, 
 
4650
   http, and some others - mostly looking for traffic on non-standard
 
4651
   ports, etc.
 
4652
</p>
 
4653
<p>
 
4654
   So, since ntop works at the packet level, it doesn't understand virtual
 
4655
   hosts. Unless it's SPECIFICALLY coded for.  ntop is a NETWORK analyzer, not 
 
4656
   an application level one.
 
4657
</p>
 
4658
<br>
 
4659
<p>
 
4660
<b>Q.</b>&nbsp;
 
4661
 tcpwrappers doesn't work
 
4662
</p>
 
4663
<p>
 
4664
<b>A.</b>&nbsp;
 
4665
 Oh yes it does... for http: connections
 
4666
</p>
 
4667
<p>
 
4668
   1) You have to configure it this way before compiling ntop:
 
4669
</p>
 
4670
<pre>
 
4671
        ./configure --enable-tcpwrap
 
4672
</pre>
 
4673
<p>
 
4674
   2) You must have the headers and libraries installed on the build machine
 
4675
</p>
 
4676
<pre>
 
4677
      (and on the execution machine if they aren't the same).
 
4678
</pre>
 
4679
<p>
 
4680
   Remember to make the appropriate entries in hosts.allow (e.g. 
 
4681
   ntop:192.168.0.) and hosts.deny (e.g. ntop:ALL)
 
4682
</p>
 
4683
<p>
 
4684
   However, tcpwrappers and https:// is known not to work - see docs/KNOWN_BUGS
 
4685
</p>
 
4686
<br>
 
4687
<p>
 
4688
<b>Q.</b>&nbsp;
 
4689
 My filter doesn't work! I'm running ntop like this:
 
4690
</p>
 
4691
<pre>
 
4692
      /usr/local/bin/ntop -u nobody -L -d -E -w 3000 -S 2 \
 
4693
                      -m 192.168.10.0/24,xxx.xxx.xxx.xxx/32 \
 
4694
                      -M -i eth0,eth1 \
 
4695
                      (src net 192.168.10.0/24 or src host xxx.xxx.xxx.xxx ) \
 
4696
                       and not dst net 192.168.10.0/24
 
4697
</pre>
 
4698
<p>
 
4699
<b>A.</b>&nbsp;
 
4700
 Yup, it doesn't work. Use the -B option and put the filter in quotes:
 
4701
</p>
 
4702
<pre>
 
4703
      -B "(src net 192.168.10.0/24 or src host xxx.xxx.xxx.xxx ) and 
 
4704
           not dst net 192.168.10.0/24"
 
4705
</pre>
 
4706
<p>
 
4707
   ntop used to assume anything it didn't recognize was a filter.  But not since 
 
4708
   2.1.3.  If you try this now, you should see a log warning that says maybe you
 
4709
   forgot the quotes
 
4710
</p>
 
4711
<br>
 
4712
<p>
 
4713
<b>Q.</b>&nbsp;
 
4714
 I have experienced problems defining multiple filters: ntop reports 'syntax
 
4715
   error'
 
4716
</p>
 
4717
<p>
 
4718
<b>A.</b>&nbsp;
 
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
 
4721
   flex.  Please make sure you're using version 2.5.4 or above.
 
4722
</p>
 
4723
<br>
 
4724
<p>
 
4725
<b>Q.</b>&nbsp;
 
4726
 Can you give some additional examples of filters?
 
4727
</p>
 
4728
<p>
 
4729
<b>A.</b>&nbsp;
 
4730
 man tcpdump -- see "expression"
 
4731
</p>
 
4732
<p>
 
4733
   A couple of simple examples, courtesy of B. Loic:
 
4734
</p>
 
4735
 
 
4736
<pre>
 
4737
       -B "host not 192.168.1.100 and not 192.168.1.101"
 
4738
</pre>
 
4739
<p>
 
4740
   to exclude hosts 192.168.1.100 and 192.168.1.101 from tracking (FQDN 
 
4741
   such as www.yahoo.com will work too). 
 
4742
</p>
 
4743
<p>
 
4744
   If you need to exclude a full IP range, you will want to use something like
 
4745
</p>
 
4746
 
 
4747
<pre>
 
4748
        -B "net not 192.168.1.0/24" 
 
4749
</pre>
 
4750
<h2>Running - Web Server</h2>
 
4751
<br>
 
4752
<p>
 
4753
<b>Q.</b>&nbsp;
 
4754
 ntop shows an older, single menu interface
 
4755
</p>
 
4756
<p>
 
4757
<b>A.</b>&nbsp;
 
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.
 
4761
</p>
 
4762
<p>
 
4763
   To find the html files, ntop looks in the html subdirectory in two places:
 
4764
</p>
 
4765
 
 
4766
<pre>
 
4767
      1. In the current directory (i.e. ./html),
 
4768
   and
 
4769
      2. In '[prefix]/share/ntop/html'
 
4770
         (where [prefix] is set by the --prefix option of your ./configure
 
4771
          step).
 
4772
</pre>
 
4773
<p>
 
4774
   Common causes:
 
4775
</p>
 
4776
 
 
4777
<pre>
 
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.
 
4781
</pre>
 
4782
 
 
4783
<pre>
 
4784
      2. Forgetting to run './autogen.sh -1' first and 'make install' last when
 
4785
         first building ntop from source.
 
4786
</pre>
 
4787
 
 
4788
<pre>
 
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:
 
4792
</pre>
 
4793
 
 
4794
<pre>
 
4795
            cd /usr/bin
 
4796
            /root/ntop/ntop
 
4797
</pre>
 
4798
 
 
4799
<pre>
 
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!
 
4802
</pre>
 
4803
<p>
 
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!
 
4806
</p>
 
4807
<br>
 
4808
<p>
 
4809
<b>Q.</b>&nbsp;
 
4810
 Why does ntop display bits of my web site, instead of its own pages?
 
4811
</p>
 
4812
<p>
 
4813
<b>A.</b>&nbsp;
 
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.
 
4816
</p>
 
4817
<p>
 
4818
   This is a feature.
 
4819
</p>
 
4820
<p>
 
4821
   You are one of those rare souls who happen to have had an unrelated
 
4822
   subdirectory 'html' with a file named 'index.html' as a subdirectory 
 
4823
   of the current working directory at the time that you launched ntop. 
 
4824
   cd to an acceptable directory, such as /usr/share/ntop, before 
 
4825
   launching ntop.  
 
4826
</p>
 
4827
<br>
 
4828
<p>
 
4829
<b>Q.</b>&nbsp;
 
4830
 What are High/Medium/Low risk flags
 
4831
</p>
 
4832
<p>
 
4833
<b>A.</b>&nbsp;
 
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
 
4836
   the problem descriptions or via http://127.0.0.1:3000/help.html
 
4837
</p>
 
4838
<p>
 
4839
   Often seen if you are monitoring a backbone or common network (high)
 
4840
   or if you have cloned MAC addresses for, say, a home Firewall box.
 
4841
</p>
 
4842
<br>
 
4843
<p>
 
4844
<b>Q.</b>&nbsp;
 
4845
 What does the "Users" flag mean on a host?
 
4846
</p>
 
4847
<p>
 
4848
<b>A.</b>&nbsp;
 
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
 
4851
   protocols.
 
4852
</p>
 
4853
<p>
 
4854
   In sessions.c, the function updateHostUsers() is used to maintain the list
 
4855
   of "users" of a host.  In handleSession(), as part of the protocol level
 
4856
   analysis, the "user" information for various protocols is pulled out of the
 
4857
   packets.  Stuff like the "X-Kazaa-Username" header, the "MAIL FROM:" header,
 
4858
   etc.
 
4859
</p>
 
4860
<p>
 
4861
   We tag users as one or more of the following types:
 
4862
</p>
 
4863
<pre>
 
4864
        P2P_USER, SMTP_USER, FTP_USER, POP_USER, IMAP_USER
 
4865
</pre>
 
4866
<p>
 
4867
   Note that for P2P, we also record - where possible - whether this user is
 
4868
   in P2P_UPLOAD_MODE and/or P2P_DOWNLOAD_MODE.
 
4869
</p>
 
4870
<br>
 
4871
<p>
 
4872
<b>Q.</b>&nbsp;
 
4873
 Why are some of the host names in different colors?
 
4874
</p>
 
4875
<p>
 
4876
<b>A.</b>&nbsp;
 
4877
 Colors are used on several of the ntop pages to convey extra
 
4878
   information to the user.  (in particular the ACTIVE TCP SESSIONS
 
4879
   and the LOCAL HOST STATS pages). There are five colors used to
 
4880
   depict how long ago the host was first seen by ntop.
 
4881
</p>
 
4882
<p>
 
4883
   The pages which display these colors use a html style sheet called
 
4884
   style.css located in the normal html subdirectory (where ntop is
 
4885
   installed). This happens by setting the 'class=' parameter of
 
4886
   the html 'A' (Anchor or hyper-link) tag.  The style sheet defines
 
4887
   the following:
 
4888
</p>
 
4889
 
 
4890
<pre>
 
4891
      Age of host  'class' name  Color code         Color description
 
4892
      (minutes)
 
4893
      -------------------------------------------------------------------
 
4894
      0-5          A.age0min    { color:#FF0000 }   Red
 
4895
      5-15         A.age5min    { color:#FF00FF }   Fuchsia/Magenta
 
4896
      15-30        A.age15min   { color:#FF7F00 }   Coral (lt orange)
 
4897
      30-60        A.age30min   { color:#007FFF }   Slate blue
 
4898
      60+          A.age60min   { color:#0000FF }   Blue
 
4899
</pre>
 
4900
<p>
 
4901
   The color legend is displayed on the About | Configuration page
 
4902
   (info.html).
 
4903
</p>
 
4904
<br>
 
4905
<p>
 
4906
<b>Q.</b>&nbsp;
 
4907
 What does the P2P flag mean on a host?
 
4908
</p>
 
4909
<p>
 
4910
<b>A.</b>&nbsp;
 
4911
 If ntop knows enough to tag you as a P2P user, it's also looking at the
 
4912
   other headers to see if it can track what files you're exchanging.  If a host
 
4913
   (i.e. a workstation) downloads a file from another host ("server"), the file
 
4914
   name is recorded in the list ntop maintains for both of them.
 
4915
</p>
 
4916
<p>
 
4917
   If a host has at least one file name recorded, it's tagged with the "P2P"
 
4918
   flag.
 
4919
</p>
 
4920
<br>
 
4921
<p>
 
4922
<b>Q.</b>&nbsp;
 
4923
 What does a "Virtual Host" mean.
 
4924
</p>
 
4925
<p>
 
4926
<b>A.</b>&nbsp;
 
4927
 If a single instance of a web server handles many web sites, all of the
 
4928
   references resolve to the same name.  The web server uses the "Host:"
 
4929
   header to determine which "index.html" page to serve up.
 
4930
</p>
 
4931
<p>
 
4932
   ntop monitors port 80 (http:) exchanges and looks for the Host: which allows
 
4933
   it to build a list of virtual hosts being handled by the web server.
 
4934
</p>
 
4935
<h2>Running - Web Server (https:)</h2>
 
4936
<br>
 
4937
<p>
 
4938
<b>Q.</b>&nbsp;
 
4939
 SSL is not working! I have the following error in the log/terminal:
 
4940
</p>
 
4941
<pre>
 
4942
     10/Jun/2002 22:58:17 Started thread (6151) for network packet sniffing on
 
4943
          eth0.1700:error:140EC0AF:SSL routines:SSL2_READ_INTERNAL:non sslv2
 
4944
          initial packet:s2_pkt.c:187:
 
4945
</pre>
 
4946
<p>
 
4947
<b>A.</b>&nbsp;
 
4948
 You forgot to put https:// instead of http:// in the URL you put in your
 
4949
   browser!
 
4950
</p>
 
4951
<br>
 
4952
<p>
 
4953
<b>Q.</b>&nbsp;
 
4954
 Unable to find SSL certificate 'ntop-cert.pem'
 
4955
</p>
 
4956
<p>
 
4957
<b>A.</b>&nbsp;
 
4958
 ntop looks such file under the current working directory, then /etc or in
 
4959
   Whatever directory you configured with ./configure.
 
4960
</p>
 
4961
<p>
 
4962
   If you want a personal certificate, you need to create it by:
 
4963
</p>
 
4964
 
 
4965
<pre>
 
4966
      >make ntop-cert.pem
 
4967
</pre>
 
4968
<p>
 
4969
   It should be installed as part of "make install".  If you have a special
 
4970
   Certificate or it's not present, do it (one-time) manually:
 
4971
</p>
 
4972
<p>
 
4973
   For example to install it under /usr/local/etc, do:
 
4974
</p>
 
4975
<p>
 
4976
   mkdir /usr/local/etc
 
4977
   cp /usr/local/bin/ntop-cert.pem /usr/local/etc/ntop
 
4978
</p>
 
4979
<p>
 
4980
   See docs/README.SSL
 
4981
</p>
 
4982
 
 
4983
<pre>
 
4984
Q: What is the ssl watchdog?
 
4985
A: Short answer: There are reported problems w/ the ntop web server hanging when
 
4986
                 accessed via ssl (https://) from Netscape 6.2.2 (Win2K) (and
 
4987
                 others).
 
4988
</pre>
 
4989
 
 
4990
<pre>
 
4991
                 The ssl "watchdog" keeps an eye on the web server - it waits
 
4992
                 for 3 seconds and then if the SSL_accept call (openSSL) hasn't
 
4993
                 finished, it aborts it. This leaves the user with nothing on
 
4994
                 their web browser, but at least ntop's web server continues on.
 
4995
</pre>
 
4996
 
 
4997
<pre>
 
4998
                 There is no known way to send something back to the user. DON'T
 
4999
                 EVEN ASK. It's not in ntop, it's the browser-server handshake
 
5000
                 that's hung.  So, it looks - to the user - like a failed 
 
5001
                 connection.  S'be'it...
 
5002
</pre>
 
5003
<p>
 
5004
   If you are using https:// and seem to have the problem, run ntop with the 
 
5005
   --ssl-watchdog command line parameter... The item to look for on the
 
5006
   configuration page (info.html) is:
 
5007
</p>
 
5008
 
 
5009
<pre>
 
5010
       # HTTPS Request Timeouts
 
5011
</pre>
 
5012
<p>
 
5013
   Or messages in the log:
 
5014
</p>
 
5015
<p>
 
5016
   ...: SSLWDERROR: Watchdog timer has expired. Aborting request, but ntop
 
5017
</p>
 
5018
<pre>
 
5019
        processing continues!
 
5020
</pre>
 
5021
<p>
 
5022
   You can also enable it via a ./configure parameter (./configure --help |
 
5023
   less) if it's something you're going to always require.
 
5024
</p>
 
5025
<br>
 
5026
<p>
 
5027
<b>Q.</b>&nbsp;
 
5028
 Tell me more
 
5029
</p>
 
5030
<p>
 
5031
<b>A.</b>&nbsp;
 
5032
 The problem is that ntop's web server is single threaded until we determine
 
5033
   that the request is simply one that will be reading data.  At that point we
 
5034
   fork to generate the page.  But the basic "accept a request" code is single
 
5035
   threaded.  This happens all but instantaneously and hasn't been a problem
 
5036
   previously.
 
5037
</p>
 
5038
<p>
 
5039
   The code is pretty basic and pretty common:
 
5040
</p>
 
5041
 
 
5042
<pre>
 
5043
       select() to wait for a connection, then
 
5044
       ssl_accept() to fire up a "server", meaning the ssl handshake.
 
5045
</pre>
 
5046
 
 
5047
<pre>
 
5048
       Then process the http request (i.e. the GET and associated headers).
 
5049
</pre>
 
5050
<p>
 
5051
   With Netscape 6.2.2 (and others), there seems to be a bug in the Netscape
 
5052
   code (ntop's is identical to other projects like sshd).
 
5053
</p>
 
5054
<p>
 
5055
   According to something I read - but now can't find again - Netscape doesn't
 
5056
   accept a legal combination of options on the handshake back from openSSL and
 
5057
   hangs in a deadly embrace.  Supposedly openSSL 0.9.6c (or was it d - it's not
 
5058
   in the changelog) built in a patch.  However, I didn't find the new version
 
5059
   changed the behavior.
 
5060
</p>
 
5061
<p>
 
5062
   There is stuff about a bug w/ Netscape 4.x on the openSSL website, but I'm
 
5063
   not having trouble with Netscape 4.x.
 
5064
</p>
 
5065
<p>
 
5066
   I don't understand the details and really don't care to find out.  It boils
 
5067
   down to a hang in a call, SSL_accept() that doesn't have a timeout parameter.
 
5068
   Argh
 
5069
</p>
 
5070
<p>
 
5071
   Because the code is invasive, I built it (like the SIGPIPE stuff) so you can
 
5072
   turn it on at ./configure time:
 
5073
</p>
 
5074
 
 
5075
<pre>
 
5076
      --enable-sslwatchdog    Watchdog for ssl hangups (Netscape 6.2.2)
 
5077
                              [default=disabled]
 
5078
</pre>
 
5079
<p>
 
5080
   or via a command line option:
 
5081
</p>
 
5082
 
 
5083
<pre>
 
5084
      --ssl-watchdog          Use ssl watchdog (NS6 problem)
 
5085
</pre>
 
5086
<p>
 
5087
   With the "fix", ntop's web server hangs for at most 3 seconds, then continues
 
5088
   on.  The user gets nada - and I don't know a way to send them anything,
 
5089
   because we haven't retrieved the request yet nor done the handshake (so there
 
5090
   isn't a TCP connection!)
 
5091
</p>
 
5092
<p>
 
5093
   It only affects https:// requests and I've coded the watchdog so it doesn't
 
5094
   activate unless we have openSSL and either the compile or runtime parameter
 
5095
   set.  If you don't get https:// requests, it's just another idle thread.
 
5096
</p>
 
5097
<p>
 
5098
   The fix is working for me... What I've tested (and the results with and
 
5099
   without the watchdog):
 
5100
</p>
 
5101
 
 
5102
<pre>
 
5103
    Win2k
 
5104
      MS Internet Explorer 5.5 - ok
 
5105
      Netscape 4.61 - ok
 
5106
      Netscape 4.79 - ok
 
5107
      Netscape 6.2.2 - user gets no response
 
5108
                     - old: ntop webserver hung and must restart ntop!!
 
5109
      Opera 6.03 - user gets a partial response
 
5110
                 - old: browser says "setting up secure connection" and
 
5111
                        never continues, but ntop's webserver is ok
 
5112
                        (SOMETIMES you get SSL errors in log, esp.
 
5113
                        if you cancel the browser)
 
5114
</pre>
 
5115
 
 
5116
<pre>
 
5117
    Linux
 
5118
      Konqueror 2.2.2 - ok
 
5119
      Mozilla - 1.0 - ok
 
5120
      Netscape 4.78 - ok
 
5121
      Galeon 1.2.5 - almost complete response, browser session is toast
 
5122
                     (must restart)
 
5123
                   - old: user gets nothing, but the ntop webserver is ok
 
5124
      Opera 6.0B1 - user gets a partial response, but browser session is ok
 
5125
                  - old: browser says "setting up secure connection" and never
 
5126
                         continues, but ntop's webserver is ok.
 
5127
</pre>
 
5128
<h2>Running - Web Server - Security</h2>
 
5129
<br>
 
5130
<p>
 
5131
<b>Q.</b>&nbsp;
 
5132
 I'm being prompted for a userid/password, what do I enter.
 
5133
</p>
 
5134
<p>
 
5135
<b>A.</b>&nbsp;
 
5136
 The default admin userid is 'Admin' (without the quotes) and the password
 
5137
   is whatever you set on the 1st run of ntop (look in this FAQ for
 
5138
   --set-admin-password).
 
5139
</p>
 
5140
<br>
 
5141
<p>
 
5142
<b>Q.</b>&nbsp;
 
5143
 Why create Userids (beyond the Admin id created by --set-admin-password)
 
5144
</p>
 
5145
<p>
 
5146
<b>A.</b>&nbsp;
 
5147
 Multiple users allow you to control who can alter ntop's performance and/or
 
5148
   view specific information. If you look on the "Admin" tab, you will see that
 
5149
   you can create additional users and also control which URLs can be executed
 
5150
   by whom.
 
5151
</p>
 
5152
<p>
 
5153
   Userids could allow, for example, an ISP to allow users to access SOME
 
5154
   network performance statistics, but not the proprietary stuff...
 
5155
</p>
 
5156
<p>
 
5157
   Suppose you want to restrict who accesses the Multicast statistics page,
 
5158
   multicastStats.html.
 
5159
</p>
 
5160
<p>
 
5161
   ntop uses terminal wildcards matching the names, so multicast is treated as
 
5162
   multicast* and matches multicastStats.html plus any other name beginning
 
5163
   multicast...
 
5164
</p>
 
5165
<p>
 
5166
   howto:
 
5167
</p>
 
5168
<p>
 
5169
   1st add a new user
 
5170
   2nd add "multicast" to the list of controlled screens and allow admin
 
5171
</p>
 
5172
<pre>
 
5173
       and the new user to access it (note the * wildcard is automatically
 
5174
       added)
 
5175
</pre>
 
5176
<p>
 
5177
   Try and access the screen and you are prompted for a userid/password...
 
5178
</p>
 
5179
<p>
 
5180
   Look in http.c for all the names and #defines used...
 
5181
</p>
 
5182
<br>
 
5183
<p>
 
5184
<b>Q.</b>&nbsp;
 
5185
 So, How do I restrict access to the main http or https ntop web page?
 
5186
</p>
 
5187
<p>
 
5188
<b>A.</b>&nbsp;
 
5189
 To stop everyone from logging into ntop, do the following:
 
5190
   Select ADMIN tab
 
5191
   Select URL's then "Add Url"
 
5192
   Don't fill in anything (the wildcard * is implied)
 
5193
   Select only the users who you want to authorize (hold control key and
 
5194
   click on user to add more users if you added users)
 
5195
</p>
 
5196
<p>
 
5197
   and click on "Add Url"
 
5198
</p>
 
5199
<p>
 
5200
   You will see URL '*' is added, e.g.
 
5201
</p>
 
5202
 
 
5203
<pre>
 
5204
     'showU*'
 
5205
     '*'
 
5206
     'shutdown*'
 
5207
     'deleteU*'
 
5208
     'modifyU*'
 
5209
</pre>
 
5210
<p>
 
5211
   Then only users who know the user id and password (remember to keep the .db
 
5212
   file secure!) will have access.
 
5213
</p>
 
5214
<br>
 
5215
<p>
 
5216
<b>Q.</b>&nbsp;
 
5217
 How good is the default security ntop provides through the web server.
 
5218
</p>
 
5219
<p>
 
5220
<b>A.</b>&nbsp;
 
5221
 Good question...
 
5222
</p>
 
5223
<p>
 
5224
   The default ntop configuration is not appropriate if you put ntop in a
 
5225
   publicly reachable location.  We assume that ntop is either running in a
 
5226
   small, trusted, LAN or that you've used other tools such as firewalls to
 
5227
   protect the ntop web server.
 
5228
</p>
 
5229
<p>
 
5230
   The userid/password scheme is good enough to prevent you from accidentally
 
5231
   shutting down ntop or getting into 'dangerous' places.  But that's really
 
5232
   all it does.
 
5233
</p>
 
5234
<p>
 
5235
   Also, the security of the ntop web server is only as good as the security of
 
5236
   the passwords file, ntop_pw.db - only the ntop -u userid should be able to
 
5237
   read from or write to it.
 
5238
</p>
 
5239
<p>
 
5240
   Read man crypt for information on the security of the encrypted password.
 
5241
</p>
 
5242
<br>
 
5243
<p>
 
5244
<b>Q.</b>&nbsp;
 
5245
 The plugins aren't very secure.
 
5246
</p>
 
5247
<p>
 
5248
<b>A.</b>&nbsp;
 
5249
 True.
 
5250
</p>
 
5251
<br>
 
5252
<p>
 
5253
<b>Q.</b>&nbsp;
 
5254
 How do I prevent users from turning plugins on/off?
 
5255
</p>
 
5256
<p>
 
5257
<b>A.</b>&nbsp;
 
5258
 The default configuration of ntop does not protect the plugin pages - no
 
5259
   password is required to access showPlugins.html.
 
5260
</p>
 
5261
<p>
 
5262
   This allows any user who can connect to the ntop web server to view reports
 
5263
   FROM the plugins, but also allows them to make plugin configuration changes.
 
5264
</p>
 
5265
<p>
 
5266
   This may not be desirable.  You may wish to add additional URLs to the
 
5267
   Default list of those which require entry of a userid/password.
 
5268
</p>
 
5269
<p>
 
5270
   You can prevent unauthorized individuals from turning plugins on/off by
 
5271
   adding this URL: "showPlugins.html?" to the list via Add URL.
 
5272
</p>
 
5273
<br>
 
5274
<p>
 
5275
<b>Q.</b>&nbsp;
 
5276
 Ok, but they can still get into the configuration pages and change things.
 
5277
</p>
 
5278
<p>
 
5279
<b>A.</b>&nbsp;
 
5280
 Yes. Add the following URLs to the controlled list:
 
5281
</p>
 
5282
 
 
5283
<pre>
 
5284
        plugins/sFlow*
 
5285
        plugins/netFlow*
 
5286
        plugins/rrdPlugin*
 
5287
</pre>
 
5288
 
 
5289
<pre>
 
5290
    This will keep everybody who doesn't know the userid/password out of the
 
5291
    configurable plugins.  Unfortunately, it will also prevent them from seeing
 
5292
    the rrd graphs, because those are created out of the rrd plugin.
 
5293
</pre>
 
5294
<p>
 
5295
<b>A.</b>&nbsp;
 
5296
 Instead of plugins/rrdPlugin*, create these:
 
5297
</p>
 
5298
 
 
5299
<pre>
 
5300
        plugins/rrdPlugin?d*
 
5301
        plugins/rrdPlugin?h*
 
5302
        plugins/rrdPlugin?i*
 
5303
        plugins/rrdPlugin?r*
 
5304
</pre>
 
5305
<p>
 
5306
   It's still not perfect, the reasons why are left as an exercise for the
 
5307
   user.
 
5308
</p>
 
5309
<br>
 
5310
<p>
 
5311
<b>Q.</b>&nbsp;
 
5312
 I created a new user, adminp for administering the plugins and ntop is
 
5313
   also accepting the admin userid/password.
 
5314
</p>
 
5315
<p>
 
5316
<b>A.</b>&nbsp;
 
5317
 Yes, the matching of userid's isn't too swift. It's better to make sure
 
5318
   that there are NO common initial substrings among ANY of the userids.
 
5319
</p>
 
5320
 
 
5321
<pre>
 
5322
Q: How can I use Apache (with it's security, etc.) to serve up ntop pages?
 
5323
A: (Toby Johnson [public@tobiasly.com], Sun 10Nov2002)
 
5324
</pre>
 
5325
<p>
 
5326
   A while back, I had written about the possibility of configuring ntop to use
 
5327
   only relative URL's, in order to facilitate proxying ntop's web interface
 
5328
   through Apache. I have decided it's easier to simply use Apache's ability to
 
5329
   rewrite ntop's URL's when necessary. So, based on my experience, here is a
 
5330
   mini-HOWTO on how to proxy ntop through Apache.
 
5331
</p>
 
5332
<p>
 
5333
   ------
 
5334
</p>
 
5335
<p>
 
5336
   Proxying ntop's web interface through a secure Apache virtual host is a
 
5337
   convenient way to make use of any existing security measures you may already
 
5338
   have. In my case, I wanted to be able to access ntop from anywhere outside
 
5339
   my LAN, but opening another port on my server for ntop's dedicated web
 
5340
   server wasn't an option.
 
5341
</p>
 
5342
<p>
 
5343
   I already had a password-protected, secure web server that I use for admin
 
5344
   purposes -- I'll call it https://admin.tobiasly.com. I wanted ntop's web
 
5345
   interface to appear as a subdirectory under this host:
 
5346
   https://admin.tobiasly.com/ntop/ .
 
5347
</p>
 
5348
<p>
 
5349
   Here's how to configure such a setup. Change the server names and ports to
 
5350
   match your own. I'm assuming that you already have a working, secure Apache
 
5351
   virtual host (using HTTPS).
 
5352
</p>
 
5353
<p>
 
5354
   First, pick a port for ntop's HTTP server. I'll use 15123. You won't need
 
5355
   ntop's built-in HTTPS server, since you're proxying its content through a
 
5356
   pre-existing Apache HTTPS server. Configure ntop to start with the correct
 
5357
   HTTP port, and with HTTPS disabled. Something like "ntop -d -w 15123 -W 0".
 
5358
   (See the ntop man page for more startup options.)
 
5359
</p>
 
5360
<p>
 
5361
   Now, you need to tell Apache that anything under the /ntop/ URL should be
 
5362
   proxied to the ntop web server. In my case, the Apache server is running on
 
5363
   the same machine as ntop, so it's just a proxy to a different port on
 
5364
   localhost. In your Apache secure host configuration, add a line like this:
 
5365
</p>
 
5366
 
 
5367
<pre>
 
5368
      ProxyPass /ntop/ http://localhost:15123/
 
5369
</pre>
 
5370
<p>
 
5371
   Now, whenever Apache receives a request for something like
 
5372
   "https://secure.tobiasly.com/ntop/home.html", it will proxy this request to
 
5373
   the location "http://localhost:15123/home.html". Ntop will take it from
 
5374
   there, generate the web content, and pass the result back to Apache. Then
 
5375
   Apache passes that result back to the original client.
 
5376
</p>
 
5377
<p>
 
5378
   It's important to note that you don't need to open port 15123 to the
 
5379
   outside, since the connection actually goes through your existing Apache
 
5380
   port, and then is transparently proxied by Apache on the server itself. Of
 
5381
   course, you don't even have to run ntop on the same machine; as long as the
 
5382
   Apache server can connect to ntop's port, it'll work.
 
5383
</p>
 
5384
<p>
 
5385
   This is not the same as URL redirection. As far as your web browser knows,
 
5386
   everything is going through https://secure.tobiasly.com/ntop/. The Apache
 
5387
   server does all the proxy work behind the scenes, and simply serves up the
 
5388
   results to the requesting client. And since the "outward-facing" server is
 
5389
   Apache instead of ntop, you'll be using your existing Apache secure server
 
5390
   certificate, instead of ntop's ntop-cert.pem.
 
5391
</p>
 
5392
<p>
 
5393
   Everything appears to work OK at first, but we quickly run into a problem:
 
5394
   some of the URL's that ntop generates are absolute. For example, to draw bar
 
5395
   graphs, ntop's web pages will request the image "/gauge.jpg". This would
 
5396
   translate into "https://secure.tobiasly.com/gauge.jpg". Also, host info
 
5397
   pages are absolute. If I click on the host "10.1.2.3", it tries to take me
 
5398
   to the page "https://secure.tobiasly.com/10.1.2.3.html".
 
5399
</p>
 
5400
<p>
 
5401
   This is a big problem, because unless the URL is underneath the /ntop/
 
5402
   directory, Apache doesn't know that it needs to proxy the request to ntop,
 
5403
   and you get broken links. Luckily, Apache has the Rewrite module that lets
 
5404
   us fool with requested URL's. In order to get the required URL's rewritten,
 
5405
   add the following to your Apache secure virtual host configuration:
 
5406
</p>
 
5407
 
 
5408
<pre>
 
5409
      RewriteEngine On
 
5410
      RewriteCond %{HTTP_REFERER} tobiasly.com/ntop
 
5411
      RewriteCond %{REQUEST_URI} !^/ntop
 
5412
      RewriteRule ^/(.*)$ http://secure.tobiasly.com/ntop/$1 [L,P]
 
5413
</pre>
 
5414
<p>
 
5415
   In English, this basically says "If I get a URL request that comes from a
 
5416
   page that has tobiasly.com/ntop in it, and that request doesn't begin with
 
5417
   /ntop, rewrute the URL to begin with http://secure.tobiasly.com/ntop/, and
 
5418
   pass this rewritten URL to the Proxy engine." At this point, the Proxy
 
5419
   engine will see that it is getting a URL that begins with /ntop/, and
 
5420
   correctly pass it to the ntop web server. Rewriting the request to begin
 
5421
   with HTTP instead of HTTPS may seem incorrect, but since that URL will be
 
5422
   handed directly to the Proxy engine, it can't be HTTPS or ntop's web server
 
5423
   will not recognize it.
 
5424
</p>
 
5425
<p>
 
5426
   Now, you should be able to simply connect to
 
5427
   https://secure.tobiasly.com/ntop/ , and you're ready to go!
 
5428
</p>
 
5429
<h2>Running - Web Server - i18n</h2>
 
5430
<br>
 
5431
<p>
 
5432
<b>Q.</b>&nbsp;
 
5433
 Is ntop localized for language x? (i18n)
 
5434
</p>
 
5435
<p>
 
5436
<b>A.</b>&nbsp;
 
5437
 No. ntop wasn't really written with i18n in mind.
 
5438
</p>
 
5439
<p>
 
5440
   Most of the text is generated in-line, on the fly.  Plus ntop must
 
5441
   dynamically support multiple locales simultaneously.
 
5442
</p>
 
5443
<p>
 
5444
   However, beginning with v2.1.56 (2.2 development release), there is limited,
 
5445
   optional, i18n support in ntop.
 
5446
</p>
 
5447
<br>
 
5448
<p>
 
5449
<b>Q.</b>&nbsp;
 
5450
 So, what internationalization (i18n) support does ntop provide.
 
5451
</p>
 
5452
<p>
 
5453
<b>A.</b>&nbsp;
 
5454
 The key word is LIMITED
 
5455
</p>
 
5456
<p>
 
5457
   This only applies to the pages that are pulled from .html files, NOT those
 
5458
   created internally.  This includes the menus and the few static text pages,
 
5459
   but none of the pages with interesting data on them.
 
5460
</p>
 
5461
<p>
 
5462
   The localized pages must be placed in parallel directories to the existing
 
5463
   html ones.
 
5464
</p>
 
5465
<p>
 
5466
   For example, if ntop is installed in /usr/share/ntop, the html files are in
 
5467
   /usr/share/ntop/html.
 
5468
</p>
 
5469
<p>
 
5470
   To support them Canadians, then, you would need to create a
 
5471
   /usr/share/ntop/html_en_CA AND that locale would need to be installed on the
 
5472
   ntop host system.
 
5473
</p>
 
5474
<p>
 
5475
   Note that there are NO i18n files distributed with ntop (yet!)
 
5476
</p>
 
5477
<p>
 
5478
   At ./configure time, you enable support via --enable-i18n.  ntop MUST be told
 
5479
   how to find the locale files.  In ./configure, a "standard" location is
 
5480
   defined per OS.
 
5481
</p>
 
5482
<p>
 
5483
   (Initially only the value for FreeBSD is populated).  All others assume the
 
5484
   "default", /usr/lib/locale.  If that isn't right for your OS, then you MUST
 
5485
   use the optional parameter --with-localedir= to tell ntop where to find the
 
5486
   files.
 
5487
</p>
 
5488
<p>
 
5489
   At run time, ntop scans the host for the installed locales (locale -a should
 
5490
   - on most systems give you a list) and checks if a comparable html_cc_XX
 
5491
   directory exists.
 
5492
</p>
 
5493
<p>
 
5494
   This builds a list of supported languages, which (along with i18n status) is
 
5495
   shown on the configuration pages, info.html and textinfo.html.
 
5496
</p>
 
5497
<p>
 
5498
   When an http request is made, your browser sends a list of languages it is
 
5499
   willing to accept in the http Accept-Language: header.
 
5500
</p>
 
5501
<p>
 
5502
   (check View | Internet Options | Languages in IE to see what you're sending)
 
5503
</p>
 
5504
<p>
 
5505
   For example,
 
5506
</p>
 
5507
 
 
5508
<pre>
 
5509
       Accept-Languages: en_US, en
 
5510
</pre>
 
5511
<p>
 
5512
   Means that you prefer US English, but will accept any English dialect if US
 
5513
   English isn't available.
 
5514
</p>
 
5515
<p>
 
5516
   Be aware that the locale settings and Accept-Language settings are not well
 
5517
   standardized, nor common and may not necessarily map very cleanly.  You
 
5518
   should see what's defined (perhaps it's locale 'german' instead of 'gr') and
 
5519
   make or link directories as necessary.  You can always create the directory
 
5520
   you tell ntop to use via --with-localedir= in the /usr/share/ntop structure
 
5521
   and create links from there to the real locale directories!
 
5522
</p>
 
5523
<p>
 
5524
   Limits in the per-request and total # of languages to support are in
 
5525
   globals-defines.h
 
5526
</p>
 
5527
<p>
 
5528
   Because of directory structure limits, a lack of interest in multiple
 
5529
   character sets, etc. the locale and accept-language headers are coerced into
 
5530
   a common format:
 
5531
</p>
 
5532
<p>
 
5533
   locales are                  ll[_XX][.char][@modifier]
 
5534
</p>
 
5535
 
 
5536
<pre>
 
5537
       ll - language, usually the 2 character ISO abrev., such as us, it.
 
5538
       XX - dialect (often a country), such as CA or US (en_US != en_CA)
 
5539
       char - character set (we sort of assume UTF-8)
 
5540
       modifier - euro
 
5541
</pre>
 
5542
<p>
 
5543
   Accept-Language: values are  ll-XX or ll or ll-*
 
5544
</p>
 
5545
<p>
 
5546
   Once the user makes a request, each page pulled is checked:
 
5547
</p>
 
5548
 
 
5549
<pre>
 
5550
       1. For each of the Accept-Language values.
 
5551
       2. For the ntop host locale value.
 
5552
       3. In the ntop default (English) set.
 
5553
</pre>
 
5554
<p>
 
5555
   These checks are performed for each of the libraries specified in the config
 
5556
   value (CFG_DATAFILE_DIR).
 
5557
</p>
 
5558
<br>
 
5559
<p>
 
5560
<b>Q.</b>&nbsp;
 
5561
 What about the country flags.
 
5562
</p>
 
5563
<p>
 
5564
<b>A.</b>&nbsp;
 
5565
 There are other sets available on the web, of different quality and size.
 
5566
   Rather than chase down permissions and rights, we'll stick with what we have
 
5567
   but let you know here of other options.
 
5568
</p>
 
5569
<p>
 
5570
   If you find a set you like, just download them and replace the xx.gif files 
 
5571
   in .../html/statsicons/flags
 
5572
</p>
 
5573
<p>
 
5574
   Much better, but about 4x larger:
 
5575
</p>
 
5576
<pre>
 
5577
      http://users.skynet.be/hermandw/fl/smalgifs.html
 
5578
</pre>
 
5579
<p>
 
5580
   Same height, but wider (so they look better):
 
5581
</p>
 
5582
<pre>
 
5583
      http://www.kidlink.org/www/miniflags.html
 
5584
</pre>
 
5585
<br>
 
5586
<p>
 
5587
<b>Q.</b>&nbsp;
 
5588
 What pages can be customized?
 
5589
</p>
 
5590
<p>
 
5591
<b>A.</b>&nbsp;
 
5592
 ls /usr/share/ntop/html/*.html (or wherever the ntop pages are installed):
 
5593
</p>
 
5594
<p>
 
5595
   frameset
 
5596
   --------
 
5597
</p>
 
5598
 
 
5599
<pre>
 
5600
       Note: There is no real benefit, except maybe the title in index.html so
 
5601
             you can see that it really does work!
 
5602
</pre>
 
5603
<p>
 
5604
   index.html
 
5605
   index_inner.html
 
5606
   index_left.html
 
5607
   index_top.html
 
5608
   top.html
 
5609
</p>
 
5610
<p>
 
5611
   Navigation
 
5612
   ----------
 
5613
   About.html
 
5614
   Admin.html
 
5615
   All.html
 
5616
   FibreChannel.html
 
5617
   IP.html
 
5618
   Local.html
 
5619
   SCSI.html
 
5620
   Summary.html
 
5621
</p>
 
5622
<p>
 
5623
   Misc data
 
5624
   ---------
 
5625
   Copyright.html
 
5626
   dump.html
 
5627
   faq.html - lots of work
 
5628
   help.html - good candidate
 
5629
   ntop.html - splash page
 
5630
   ntophelp.html
 
5631
   privacyNotice.html
 
5632
</p>
 
5633
<p>
 
5634
   Also, remember that a file overrides ntop's internal page generation, so you
 
5635
   can also use this facility to override ANY of ntop's pages and return a
 
5636
   customized page (perhaps you don't want users seeing them?).
 
5637
</p>
 
5638
<h2>Running - Web Server - p3p</h2>
 
5639
<br>
 
5640
<p>
 
5641
<b>Q.</b>&nbsp;
 
5642
 What's up with P3P?
 
5643
</p>
 
5644
<p>
 
5645
<b>A.</b>&nbsp;
 
5646
 P3P is a W3C recommendation - http://www.w3.org/TR/P3P/ - for specifying how
 
5647
   an application(typically a web site) handles personally identifiably
 
5648
   information.  What information the site collects and what it does with the
 
5649
   information.
 
5650
</p>
 
5651
<p>
 
5652
   p3p is pretty complex!  There are basically two ways to enable an application
 
5653
   for p3p. One is to add another HTTP header, P3P:.  The second is to support a
 
5654
   well-known file location, /w3c/p3p.xml (like robots.txt).
 
5655
</p>
 
5656
<p>
 
5657
   Browser support is pretty spotty, as is web site adoption.
 
5658
</p>
 
5659
<p>
 
5660
   Some 3rd party browsers have some support...  up to CrazyBrowser which claims
 
5661
   "full support", whatever that means...
 
5662
</p>
 
5663
<br>
 
5664
<p>
 
5665
<b>Q.</b>&nbsp;
 
5666
 So why put P3P into ntop?
 
5667
</p>
 
5668
<p>
 
5669
<b>A.</b>&nbsp;
 
5670
 It's coming. P3P is gradually making it's way into the top web sites -
 
5671
   right now (Dec2002), for example dell.com supports it and yahoo.com doesn't.
 
5672
</p>
 
5673
<br>
 
5674
<p>
 
5675
<b>Q.</b>&nbsp;
 
5676
 Ok, but what's that got to do with ntop?
 
5677
</p>
 
5678
<p>
 
5679
<b>A.</b>&nbsp;
 
5680
 Since ntop collects personally identifiable data in it's access log (-a
 
5681
   option) and it's various reports and makes those available to pretty much
 
5682
   anyone in the default configuration, it's probably not a bad idea to OFFER
 
5683
   some support.  Especially if you're running ntop at a site that has started
 
5684
   to support P3P, if you don't have a mechanism for your own policies
 
5685
   you'll have to adhere to corporate ones.  And that could require massive
 
5686
   changes to ntop.
 
5687
</p>
 
5688
<br>
 
5689
<p>
 
5690
<b>Q.</b>&nbsp;
 
5691
 IE6?
 
5692
</p>
 
5693
<p>
 
5694
<b>A.</b>&nbsp;
 
5695
 Since ntop doesn't send the P3P: header, IE6 ignores ntop wrt p3p. Besides,
 
5696
   IE6 uses p3p to block 3rd party cookies.  If you want to see the p3p stuff,
 
5697
   it's view | privacy report in the menus.  If the site's policies don't match
 
5698
   your settings, there will be a red "do not enter" icon in the third box on
 
5699
   the bottom right of the IE6 window - double click on it to see the report.
 
5700
   See http://support.microsoft.com/default.aspx?scid=KB;en-us;q293513
 
5701
</p>
 
5702
<br>
 
5703
<p>
 
5704
<b>Q.</b>&nbsp;
 
5705
 Mozilla
 
5706
</p>
 
5707
<p>
 
5708
<b>A.</b>&nbsp;
 
5709
 Unknown if it's enabled by default. Mozilla had support, ripped it out in
 
5710
   Feb 2002 and put a new version back in.
 
5711
</p>
 
5712
<br>
 
5713
<p>
 
5714
<b>Q.</b>&nbsp;
 
5715
 Other browsers
 
5716
</p>
 
5717
<p>
 
5718
<b>A.</b>&nbsp;
 
5719
 See their home pages or search the web. One that I know that claims "full
 
5720
   support" (whatever that means) is at http://www.crazybrowser.com/
 
5721
</p>
 
5722
<br>
 
5723
<p>
 
5724
<b>Q.</b>&nbsp;
 
5725
 Privacy Bird?
 
5726
</p>
 
5727
<p>
 
5728
<b>A.</b>&nbsp;
 
5729
 A browser-add-on, AT&T's privacy bird (http://www.privacybird.com/), that I'm
 
5730
   playing with is a lot more aggressive in supporting p3p.  If Privacy bird
 
5731
   doesn't see the P3P: header, it then requests the "well known" file,
 
5732
   /w3c/p3p.xml file and gets nailed by ntop as a hostile application, since we
 
5733
   don't have support for returning .xml files (yet).
 
5734
</p>
 
5735
<br>
 
5736
<p>
 
5737
<b>Q.</b>&nbsp;
 
5738
 So when & how does ntop support p3p?
 
5739
</p>
 
5740
<p>
 
5741
<b>A.</b>&nbsp;
 
5742
 A patch in the cvs on 4Dec2002 adds minimal support for p3p -- specifically:
 
5743
</p>
 
5744
 
 
5745
<pre>
 
5746
      1) ntop will respond to queries for /w3c/p3p.xml and ntop.p3p -- returning
 
5747
         the ntop.p3p file, IF ONE EXISTS.
 
5748
</pre>
 
5749
 
 
5750
<pre>
 
5751
         If the file does not exist, a 404 error is generated (vs. pre 4Dec2002
 
5752
         behavior of adding the address to the myGlobals.weDontWantToTalkWithYou
 
5753
         list).
 
5754
</pre>
 
5755
 
 
5756
<pre>
 
5757
      2) New parameters, --p3p-cp and --p3p-uri allow you to return the P3P:
 
5758
         header with either or both of the parameters (cp="" or policyref="")
 
5759
         set.
 
5760
</pre>
 
5761
 
 
5762
<pre>
 
5763
         ntop doesn't validate the text in any way other than the usual
 
5764
         stringSanityCheck().
 
5765
</pre>
 
5766
<p>
 
5767
   This allows me to run the Privacy Bird and still talk to ntop.  I'll admit
 
5768
   that option #2 is speculative, since I really don't have much of a way to
 
5769
   test it.
 
5770
</p>
 
5771
<br>
 
5772
<p>
 
5773
<b>Q.</b>&nbsp;
 
5774
 But there isn't a sample .p3p file provided.
 
5775
</p>
 
5776
<p>
 
5777
<b>A.</b>&nbsp;
 
5778
 Right.
 
5779
</p>
 
5780
<p>
 
5781
   Please note that there is no sample file provided.  This is not an oversight.
 
5782
</p>
 
5783
<p>
 
5784
   After careful consideration, I am not providing one.  The reason is that a
 
5785
   .p3p file is intended to be a legal contract between your site and your users.
 
5786
   While I could provide a default file that has the right tags - as I
 
5787
   understand p3p - for the data ntop collects and stores, I don't want the
 
5788
   responsibility and/or liability.
 
5789
</p>
 
5790
<p>
 
5791
   If anyone wants this "sample p3p file", I will make it available for a fee,
 
5792
   Provided your organization - through an appropriate officer, in writing:
 
5793
</p>
 
5794
 
 
5795
<pre>
 
5796
      1) Acknowledges that Luca Deri, Burton Strauss and other developers of
 
5797
         ntop have no liability for any use(s) you make of the sample p3p file
 
5798
         or anything you derive from it.
 
5799
</pre>
 
5800
 
 
5801
<pre>
 
5802
      2) You will defend us - at your expense - from any lawsuit, arbitration
 
5803
         proceeding, etc. filed in conjunction with your use of the sample p3p
 
5804
         file.
 
5805
</pre>
 
5806
 
 
5807
<pre>
 
5808
      3) You will pay any judgments, legal expenses, etc. related to any
 
5809
         lawsuit, arbitration proceeding, etc. in conjunction with your use of
 
5810
         the sample p3p file.
 
5811
</pre>
 
5812
<p>
 
5813
   Since your legal department would be nuts to agree to that I doubt it will
 
5814
   come up.
 
5815
</p>
 
5816
<br>
 
5817
<p>
 
5818
<b>Q.</b>&nbsp;
 
5819
 So How do I create a .p3p file?
 
5820
</p>
 
5821
<p>
 
5822
<b>A.</b>&nbsp;
 
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
 
5825
   from IBM (http://www.alphaworks.ibm.com/tech/p3peditor).
 
5826
</p>
 
5827
<h2>Networks, Network cards and Networking</h2>
 
5828
<br>
 
5829
<p>
 
5830
<b>Q.</b>&nbsp;
 
5831
 My security people won't let me run in promiscuous mode.
 
5832
</p>
 
5833
<p>
 
5834
<b>A.</b>&nbsp;
 
5835
 Tough...
 
5836
</p>
 
5837
<p>
 
5838
   Or, use the -s option and accept the limitations...
 
5839
</p>
 
5840
<p>
 
5841
   Ask them "honestly, what is the problem" - other than having an interface
 
5842
   in promiscuous mode is a signature of a sniffer and security folks look for
 
5843
   unauthorized sniffers?
 
5844
</p>
 
5845
<p>
 
5846
   ntop needs promiscuous mode so that it sees the full range of traffic.  Any
 
5847
   similar product will do the same thing.
 
5848
</p>
 
5849
<p>
 
5850
   If the security people think traffic on the wire is secure, they're wrong!
 
5851
   Face facts - just about every Windows user, except for 2K/XP Pro (and then
 
5852
   only if TBTP have especially locked them down) can install the windows
 
5853
   version of tcpdump...
 
5854
</p>
 
5855
<p>
 
5856
   If it's a checklist item, just gen up a form to "authorize" it, have the
 
5857
   boss and VP/CIO sign it and give it to them.
 
5858
</p>
 
5859
<br>
 
5860
<p>
 
5861
<b>Q.</b>&nbsp;
 
5862
 What is Ethernet and TCP/IP and how do they differ?
 
5863
</p>
 
5864
<p>
 
5865
<b>A.</b>&nbsp;
 
5866
 Both are protocols - that is the definition of how
 
5867
   to interpret bits on wires (or in packets) into
 
5868
   meaningful conversations.
 
5869
</p>
 
5870
<p>
 
5871
   Ethernet is the lower level, wire (or wireless) protocol,
 
5872
   concerned with moving the physical bits of data.
 
5873
</p>
 
5874
<p>
 
5875
   TCP/IP is the higher-level protocol, which explains
 
5876
   how to interpret the block of bits (frame).
 
5877
</p>
 
5878
<p>
 
5879
   TCP/IP uses a familiar 32-bit "IP" address, e.g.
 
5880
   192.168.0.1.
 
5881
</p>
 
5882
<p>
 
5883
   Ethernet uses a less familiar, 48 bit unique to the NIC
 
5884
   (some times called "burned in") address, e.g.
 
5885
   00:40:05:DE:AD:00.  This is called the MAC (Media
 
5886
   Access Control) address.
 
5887
</p>
 
5888
<p>
 
5889
   FYI: The official IEEE MAC address lookup is at
 
5890
</p>
 
5891
<pre>
 
5892
       http://standards.ieee.org/regauth/oui/index.shtml
 
5893
   (Look up the first six digits, separated by -s, e.g. 00-40-05)
 
5894
</pre>
 
5895
<br>
 
5896
<p>
 
5897
<b>Q.</b>&nbsp;
 
5898
 OK, but how is stuff sent from my computer to, say, Yahoo!?
 
5899
</p>
 
5900
<p>
 
5901
<b>A.</b>&nbsp;
 
5902
 First off, your computer does a lookup - using a service
 
5903
   called DNS (Domain Name Service) to convert www.yahoo.com
 
5904
   to a numeric value, such as 66.218.71.80.
 
5905
</p>
 
5906
<p>
 
5907
   Then it builds a collection of characters that says send
 
5908
   this data from me, 192.168.0.1 to Yahoo at 66.218.71.80.
 
5909
   This is called a packet.  That gets wrapped in an Ethernet
 
5910
   frame (addressed from 00:40:05:DE:AD:00 to the MAC address
 
5911
   of the local gateway router, 0:d0:9e:6:38:00 and squirts it
 
5912
   out the router.
 
5913
</p>
 
5914
<p>
 
5915
   Packets are forwarded step by step along a path from you
 
5916
   to Yahoo by computers called routers.  This is done based
 
5917
   on the 32 bit IP address and the router's knowledge of the
 
5918
   network.
 
5919
</p>
 
5920
<p>
 
5921
   Each router sees a Ethernet frame addressed to it (by
 
5922
   MAC address), checks the TCP/IP address to figure out
 
5923
   where to send it next, re-wraps the TCP/IP packet in a new
 
5924
   Ethernet frame (with the from MAC as it's own and the to
 
5925
   MAC as the next hop).
 
5926
</p>
 
5927
<p>
 
5928
   This happens until the TCP/IP packet reaches the final
 
5929
   segment (the last router).  Once it reaches a router that
 
5930
   knows it has addresses 66.218.71.0-66.218.71.255 on one
 
5931
   of it's interface, the routing stops using the TCP/IP
 
5932
   address.
 
5933
</p>
 
5934
<p>
 
5935
   The last hop is done (like each intermediate hop - at the
 
5936
   lowest level) based on the MAC address!  Specifically, the
 
5937
   last router does an "ARP" (Address Resolution Protocol") query,
 
5938
   to find out "Who Has" address 66.218.71.80.  The NIC responds
 
5939
   with it's MAC address:
 
5940
</p>
 
5941
 
 
5942
<pre>
 
5943
      arp who-has www.yahoo.com tell router
 
5944
      arp reply www.yahoo.com is-at 0:d0:9e:6:38:00
 
5945
</pre>
 
5946
<p>
 
5947
   And the packet is routed to that address.
 
5948
</p>
 
5949
<p>
 
5950
   Alright, that's a bit simplified, but see Douglas Comer,
 
5951
   "Internetworking with TCP/IP, volume I", page 25 and 73ff.
 
5952
</p>
 
5953
<br>
 
5954
<p>
 
5955
<b>Q.</b>&nbsp;
 
5956
 Tell me more.
 
5957
</p>
 
5958
<p>
 
5959
<b>A.</b>&nbsp;
 
5960
 OK, gang time to teach Ethernet & TCP/IP basics one more time.
 
5961
   With pictures...
 
5962
</p>
 
5963
<p>
 
5964
   Suppose you have a network that looks like this (we'll use 
 
5965
   impossible addresses 288 - just pretend it's ok):
 
5966
</p>
 
5967
 
 
5968
<pre>
 
5969
              (ext) 288.1.1.1     (int) 288.2.2.1
 
5970
                            +-----+
 
5971
     World+Dog ------------ + ISA + ------- LAN ----- WS 288.2.2.2
 
5972
         |                  +-----+
 
5973
         |                     |(dmz) 277.1.1.1
 
5974
        me 299.0.0.1           \----------- DMZ ----- MAIL 277.1.1.2
 
5975
                                                  \-- WEB  277.1.1.3
 
5976
</pre>
 
5977
<p>
 
5978
   ISA can be acting solely as a router or it can be acting as a NAT device.
 
5979
   That's irrelevant, so we assume it's not.
 
5980
</p>
 
5981
<p>
 
5982
   I send you a packet.  It travels the Internet and arrives at your 288.1.1.1
 
5983
   the ISA(router) with src=299.0.0.1, dst=288.2.2.2.
 
5984
</p>
 
5985
<p>
 
5986
   Like every router along the way, ISA(router) looks at the destination
 
5987
   address and realizes it has to route the packet on to 288.2.2.2.  So the
 
5988
   ISA(router) sends the packet on, out the best interface to reach 288.2.2.2.
 
5989
</p>
 
5990
<p>
 
5991
   Remember, however, the TCP/IP packet is wrapped in a lower level (Ethernet)
 
5992
   packet at the wire level.  Read your TCP/IP and Ethernet standards - the
 
5993
   actual delivery of packets over links is this Ethernet level and it uses the
 
5994
   48 bit MAC address.
 
5995
</p>
 
5996
<p>
 
5997
   This "Ethernet" packet is actually what travels hop to hop to hop (you can
 
5998
   even see these headers if you have visibility to the traffic - it's called
 
5999
   the link level header by tcpdump and you'll see the 48 bit MAC addresses if
 
6000
   you use the -e parameter).
 
6001
</p>
 
6002
<p>
 
6003
   In order to be able to handle the Ethernet level signaling, each router
 
6004
   rewrites the packet so that the 48 bit source MAC address it it's own
 
6005
   (from-router that is) and the destination MAC address is the one that
 
6006
   from-router has in it's tables for to-router (the next hop).
 
6007
</p>
 
6008
<p>
 
6009
   So the packet looks like this, where the srcMAC and dstMAC get rewritten
 
6010
   each hop, so that the routers on both ends of the link know whom it's
 
6011
   addressed to:
 
6012
</p>
 
6013
<p>
 
6014
   Hop1 (srcMAC=00:00:00:aa:aa:aa dstMAC=00:00:00:bbbbb:bb frame=IP
 
6015
   data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!")
 
6016
   Hop2 (srcMAC=00:00:00:bb:bb:bb dstMAC=00:00:00:cc:cc:cc frame=IP
 
6017
   data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!")
 
6018
   Hop3 (srcMAC=00:00:00:cc:cc:cc dstMAC=00:00:00:dd:dd:dd frame=IP
 
6019
   data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!")
 
6020
</p>
 
6021
<p>
 
6022
   Notice how the TCP/IP stuff isn't changed.  But the MAC address is.
 
6023
</p>
 
6024
<p>
 
6025
   At each hop, the NIC card, operating at the Ethernet level, sees its own MAC
 
6026
   address and knows to accept the packet. It passes it up the protocol stack,
 
6027
   where the next layer (TCP/IP) realizes it needs to be routed further on...
 
6028
</p>
 
6029
<p>
 
6030
   Ultimately, the packet gets delivered to some service listening on your WS.
 
6031
</p>
 
6032
<p>
 
6033
   Here's a packet capture to show you:
 
6034
</p>
 
6035
<p>
 
6036
   # tcpdump -Xx -c1 -i eth0 -e
 
6037
   tcpdump: listening on eth0
 
6038
   11:49:10.809890 0:3:47:b1:xx:xx 0:e0:18:b4:yy:yy ip 118:
 
6039
   tigger.ssh > zebra.2714:
 
6040
   P 1824243567:1824243631(64) ack 2328789523 win 11792 (DF) [tos 0x10]
 
6041
   0x0000   4510 0068 b305 4000 4006 b1e4 c0a8 2a24        E..h..@.@.....*$
 
6042
   0x0010   c0a8 2a21 0016 0a9a 6cbb bf6f 8ace 8213        ..*!....l..o....
 
6043
   0x0020   5018 2e10 ee1a 0000 469a 3e34 eda7 549e        P.......F.>4..T.
 
6044
   0x0030   0ec4 4847 8983 fb4f 65ea 5c3e 0bbe c325        ..HG...Oe.\>...%
 
6045
   0x0040   7db8 9954 dae1 55b6 54f9 cdfd ac07 a2b5        }..T..U.T.......
 
6046
   0x0050   ce4f
 
6047
</p>
 
6048
<p>
 
6049
   So this says, the packet came from tigger (MAC address 0:3:47:b1:xx:xx) ->
 
6050
   zebra (MAC address 0:e0:18:b4:yy:yy)
 
6051
</p>
 
6052
<pre>
 
6053
     Within that is the tcp/ip packet, from c0a82a24 -> c0ae2a21
 
6054
   (192.168.42.36 -> 192.168.42.33)
 
6055
</pre>
 
6056
<p>
 
6057
   Here's another one, from tigger -> router.
 
6058
</p>
 
6059
<p>
 
6060
   # tcpdump -Xx -c1 -i eth0 -e host 192.168.42.1
 
6061
   tcpdump: listening on eth0
 
6062
   11:52:48.712750 0:3:47:b1:aa:aa 0:d0:9e:6:bb:bb ip 72:
 
6063
   tigger.32782 > homeportal.gateway.2wire.net.domain:
 
6064
   41356+ A? cvs.ntop.org. (30) (DF)
 
6065
   0x0000   4500 003a bf7e 4000 4011 a5be c0a8 2a24        E..:.~@.@.....*$
 
6066
   0x0010   c0a8 2a01 800e 0035 0026 ce2e a18c 0100        ..*....5.&......
 
6067
   0x0020   0001 0000 0000 0000 0363 7673 046e 746f        .........cvs.nto
 
6068
   0x0030   7003 6f72 6700 0001 0001                       p.org.....
 
6069
</p>
 
6070
<p>
 
6071
   (0035 = port 53, so it's a dns query)
 
6072
</p>
 
6073
<p>
 
6074
   And one more, from cvs.ntop.org -> tigger (which has to have passed through
 
6075
   the router)
 
6076
</p>
 
6077
<p>
 
6078
   # tcpdump -Xx -c1 -i eth0 -e "not src net 192.168.42.0/24"
 
6079
   tcpdump: listening on eth0
 
6080
   11:53:39.688806 0:d0:9e:6:bb:bb 0:3:47:b1:aa:aa ip 69:
 
6081
   195.31.151.66.cvspserver > tigger.42964:
 
6082
   P 2566885448:2566885451(3) ack 2903504154 win 24616 <nop,nop,timestamp
 
6083
   389837493 85533859> (DF)
 
6084
   0x0000   4500 0037 5f3c 4000 2906 ad56 c31f 9742        E..7_<@.)..V...B
 
6085
   0x0010   c0a8 2a24 0961 a7d4 98ff 9048 ad0f f51a        ..*$.a.....H....
 
6086
   0x0020   8018 6028 279a 0000 0101 080a 173c 72b5        ..`('........<r.
 
6087
   0x0030   0519 24a3 6f6b 0a                              ..$.ok.
 
6088
</p>
 
6089
<p>
 
6090
   See the MAC address?  It's the routers, not cvs.ntop.org's
 
6091
</p>
 
6092
<br>
 
6093
<p>
 
6094
<b>Q.</b>&nbsp;
 
6095
 Why do I care?
 
6096
</p>
 
6097
<p>
 
6098
<b>A.</b>&nbsp;
 
6099
 Because that's sometimes a problem you'll have with ntop. See ntop is
 
6100
   nosy, so it puts the interface into promiscuous mode, where every 
 
6101
   packet - addressed to the ntop host or not - is processed.  Now the 
 
6102
   next layer up, the tcp/ip layer will throw away any 'junk' (You can 
 
6103
   just hear it going tisk, tisk, tisk).  But libpcap can intercept them 
 
6104
   at the Ethernet level and feed them to ntop...
 
6105
</p>
 
6106
<p>
 
6107
   For REMOTE hosts, ntop uses the IP address as it's the only valid data.
 
6108
   But for LOCAL hosts, ntop prefers to use the MAC address as a way of
 
6109
   resolving multi-homed or multiply addressed hosts.
 
6110
</p>
 
6111
<p>
 
6112
   See if you have two IP addresses assigned to the same host on your local
 
6113
   network, say 192.168.42.42 and 192.168.42.43, how is ntop to tell they're
 
6114
   the same host?  Well, the MAC addresses are the same...  (for some
 
6115
   manufacturers, e.g. Sun, ALL of the interfaces on a host use the same MAC
 
6116
   address).
 
6117
</p>
 
6118
<p>
 
6119
   read getHostInfo() in hash.c.
 
6120
</p>
 
6121
 
 
6122
<pre>
 
6123
      /* This is a local address hence this is a potential
 
6124
         multihomed host. */
 
6125
</pre>
 
6126
 
 
6127
<pre>
 
6128
      if((el->hostIpAddress.s_addr != 0x0)
 
6129
         && (el->hostIpAddress.s_addr != hostIpAddress->s_addr)) {
 
6130
         isMultihomed = 1;
 
6131
         FD_SET(FLAG_HOST_TYPE_MULTIHOMED, &el->flags);
 
6132
      }
 
6133
</pre>
 
6134
<p>
 
6135
   i.e. if the address we've stored for this host doesn't match this one, 
 
6136
   it's multihomed.
 
6137
</p>
 
6138
 
 
6139
<pre>
 
6140
      } else if((hostIpAddress != NULL)
 
6141
                && (el->hostIpAddress.s_addr == hostIpAddress->s_addr)) {
 
6142
         /* Spoofing or duplicated MAC address:
 
6143
            two hosts with the same IP address and different MAC
 
6144
            addresses
 
6145
          */
 
6146
</pre>
 
6147
 
 
6148
<pre>
 
6149
         if(!hasDuplicatedMac(el)) {
 
6150
            FD_SET(FLAG_HOST_DUPLICATED_MAC, &el->flags);
 
6151
            ...
 
6152
         }
 
6153
</pre>
 
6154
 
 
6155
<pre>
 
6156
         setSpoofingFlag = 1;
 
6157
         hostFound = 1;
 
6158
         break;
 
6159
      }
 
6160
</pre>
 
6161
<p>
 
6162
   If the addresses DO match, we've had two MAC addresses, so this is being
 
6163
   spoofed.
 
6164
</p>
 
6165
<p>
 
6166
   etc.
 
6167
</p>
 
6168
<br>
 
6169
<p>
 
6170
<b>Q.</b>&nbsp;
 
6171
 So why do I get bad output?
 
6172
</p>
 
6173
<p>
 
6174
<b>A.</b>&nbsp;
 
6175
 If, somehow, you've confused ntop - for example telling it that
 
6176
   277.1.1.0/24 in the ascii art example (above) is local, then ntop 
 
6177
   is going to believe you.  And it will see a packet with the 
 
6178
   277.1.1.1 IP and a MAC address. And use that.  Only it's not the MAC 
 
6179
   address of the MAIL host, it's really the MAC address of ISA.
 
6180
</p>
 
6181
<p>
 
6182
   No matter, ntop doesn't know this -- all it sees is the packets and 
 
6183
   the data you gave it.  So later on, when it sees a packet with the 
 
6184
   same MAC address, but a different IP, well, it will assume that it's 
 
6185
   the same host... and the data will all be lumped together.
 
6186
</p>
 
6187
<br>
 
6188
<p>
 
6189
<b>Q.</b>&nbsp;
 
6190
 Does that explain why I'm seeing xxxx as multihomed?
 
6191
</p>
 
6192
<p>
 
6193
<b>A.</b>&nbsp;
 
6194
 Maybe. Remember - it only takes one packet, not even an ack, for
 
6195
   ntop to create a host record.  If that's wrong, it will carry 
 
6196
   forward - and you'll probably see the host tagged as 'Multihomed'
 
6197
   when correct packets show up.  Say:
 
6198
</p>
 
6199
 
 
6200
<pre>
 
6201
      Host 1: IP 192.168.1.1 MAC 00:00:00:aa:aa:aa
 
6202
      Host 3: IP 192.168.1.3 MAC 00:00:00:cc:cc:cc
 
6203
</pre>
 
6204
<p>
 
6205
   If somebody has the incorrect hosts table, dns, cached, whatever 
 
6206
   but has the info that Host 1 is 192.168.1.3 and is on the same 
 
6207
   subnet, then it will send a packet where the Ethernet layer and
 
6208
   the ip are nonsense.  But because it's on the same wire, the ip 
 
6209
   is ignored:
 
6210
</p>
 
6211
<p>
 
6212
   (Ethernet from:00:00:00:dd:dd:dd to:00:00:00:aa:aa:aa)
 
6213
</p>
 
6214
<pre>
 
6215
       (tcp s=192.168.1.4 d=192.168.1.3)
 
6216
</pre>
 
6217
<p>
 
6218
   ntop will read both out of the packet and create the association
 
6219
</p>
 
6220
 
 
6221
<pre>
 
6222
      192.168.1.3=00:00:00:aa:aa:aa
 
6223
</pre>
 
6224
<p>
 
6225
   Since it doesn't know better.
 
6226
</p>
 
6227
<p>
 
6228
   Then when it sees
 
6229
</p>
 
6230
<p>
 
6231
   (Ethernet from:00:00:00:ee:ee:ee to:00:00:00:cc:cc:cc)
 
6232
</p>
 
6233
<pre>
 
6234
      (tcp s=192.168.1.5 d=192.168.1.3)
 
6235
</pre>
 
6236
<p>
 
6237
   It will create the multihomed association...
 
6238
</p>
 
6239
<br>
 
6240
<p>
 
6241
<b>Q.</b>&nbsp;
 
6242
 So what's a hub vs. a Switch
 
6243
</p>
 
6244
<p>
 
6245
<b>A.</b>&nbsp;
 
6246
 A hub is a device that links a bunch of computers together
 
6247
   at the wire (Ethernet) level.  Logically, Ethernet is a bus,
 
6248
   that is everybody sees all the traffic, just like cars crossing
 
6249
   under a highway bridge.   Physically, Ethernet is wired like
 
6250
   a star - with all the wires coming back to a central "hub".
 
6251
   The hub is just the device that makes the electric star look
 
6252
   like a shared bus.
 
6253
</p>
 
6254
<p>
 
6255
   Switches and Hubs operate at the Ethernet level, not TCP/IP.
 
6256
</p>
 
6257
<p>
 
6258
<b>A.</b>&nbsp;
 
6259
 Watch out for 'Switched hubs', which are hubs that include an
 
6260
   internal switch between 2 or more segments (for example, BUT
 
6261
   NOT LIMITED TO a 10BaseT and 100BaseT) segment.  These are hubs
 
6262
   within a segment, but switches across segments.  ntop may not
 
6263
   see the traffic you expect if you have a 'switched hubs' and
 
6264
   manufacturers are pretty bad about marking them. See
 
6265
   http://article.gmane.org/gmane.linux.ntop.general/5081
 
6266
</p>
 
6267
<p>
 
6268
<b>A.</b>&nbsp;
 
6269
 A switch is a smart hub.
 
6270
</p>
 
6271
<p>
 
6272
   Switches improve performance by creating a virtual Ethernet
 
6273
   bus for the duration of the packet that joins JUST the source
 
6274
   and destination ports.
 
6275
</p>
 
6276
<p>
 
6277
   A switch operates via an internal table of MAC addresses.
 
6278
   It learns (or is programmed) that 0:d0:9e:6:38:00 is on
 
6279
   port 1, while 00:40:05:DE:AD:00 is on port 3.
 
6280
</p>
 
6281
<p>
 
6282
   A packet coming in port 1, destined for 00:40:05:DE:AD:00
 
6283
   is sent out ONLY port 3.
 
6284
</p>
 
6285
<p>
 
6286
   If the switch doesn't know (or the packet is a broadcast),
 
6287
   it gets sent out all ports.
 
6288
</p>
 
6289
<p>
 
6290
   This doesn't make for MORE bandwidth, but it does use it
 
6291
   more efficiently.  That is in addition to the session between
 
6292
   ports 1 and 3 at 100Mbps, a second, simultaneous 100Mbps
 
6293
   session can occur between ports 2 and 4.
 
6294
</p>
 
6295
<br>
 
6296
<p>
 
6297
<b>Q.</b>&nbsp;
 
6298
 How do I use ntop in a switched network?
 
6299
</p>
 
6300
<p>
 
6301
<b>A.</b>&nbsp;
 
6302
 First off, you need to be or have the support of
 
6303
   your network administrator.  (Yes, you can do something
 
6304
   called "ARP poisoning" to - maybe - get the switch to send
 
6305
   you all the traffic, but that's beyond this FAQ... STFW)
 
6306
</p>
 
6307
<p>
 
6308
   Many switches (although not the USD$50 cheap "workgroup" units)
 
6309
   have a special port or mode, where by all the traffic for the
 
6310
   entire network gets copied out that port, in addition to the
 
6311
   normal switch action.
 
6312
</p>
 
6313
<p>
 
6314
   When you invoke the monitoring mode (called span, mirror, monitor,
 
6315
   analysis, etc.), you are forcing the entire switch bandwidth out one
 
6316
   port.  This may exceed the bandwidth of the port.  100Mbps+100Mbps
 
6317
   >> 100Mbps!
 
6318
</p>
 
6319
<p>
 
6320
   Traffic that is being sent to the monitoring port in excess of the
 
6321
   capacity of that port is usually dropped.  It should NOT slow down
 
6322
   the switch on other ports.
 
6323
</p>
 
6324
<p>
 
6325
   Some switches have some buffering capability and it *may* be able to
 
6326
   keep up with an occasional burst of traffic, as long as the average
 
6327
   is below the port capacity and the buffer isn't exceeded.
 
6328
</p>
 
6329
<p>
 
6330
   See, for example, http://www.cisco.com/warp/public/473/41.html#archXL.
 
6331
</p>
 
6332
<p>
 
6333
   One list of switch manufacturers is the document is titled "REFERENCE:
 
6334
   Configuring a Switch to Monitor All Traffic" from Elron Software. (The
 
6335
   URL is long, do a Google search for "site:elronsoftware.com wi6038").
 
6336
</p>
 
6337
<h2>Dumping data</h2>
 
6338
<br>
 
6339
<p>
 
6340
<b>Q.</b>&nbsp;
 
6341
 Can I use ntop from php/perl?
 
6342
</p>
 
6343
<p>
 
6344
<b>A.</b>&nbsp;
 
6345
 Yes you can. Please see the www directory under the ntop source tree.
 
6346
</p>
 
6347
<p>
 
6348
<b>A.</b>&nbsp;
 
6349
 Look at the Admin | Dump Data page.
 
6350
</p>
 
6351
<h2>rrd (myrrd)</h2>
 
6352
<br>
 
6353
<p>
 
6354
<b>Q.</b>&nbsp;
 
6355
 How do I save data between runs?
 
6356
</p>
 
6357
<p>
 
6358
<b>A.</b>&nbsp;
 
6359
 Use rrd.
 
6360
</p>
 
6361
<br>
 
6362
<p>
 
6363
<b>Q.</b>&nbsp;
 
6364
 What's rrd?
 
6365
</p>
 
6366
<p>
 
6367
<b>A.</b>&nbsp;
 
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.
 
6370
   Download it and read it.
 
6371
</p>
 
6372
<br>
 
6373
<p>
 
6374
<b>Q.</b>&nbsp;
 
6375
 Do I gotta?
 
6376
</p>
 
6377
<p>
 
6378
<b>A.</b>&nbsp;
 
6379
 Yup - the pretty pictures won't work in this FAQ.
 
6380
</p>
 
6381
<br>
 
6382
<p>
 
6383
<b>Q.</b>&nbsp;
 
6384
 What's myrrd?
 
6385
</p>
 
6386
<p>
 
6387
<b>A.</b>&nbsp;
 
6388
 ntop includes a frozen and slightly patched version of rrd 1.0.42 in the
 
6389
   ntop source tree.  This is called myrrd.
 
6390
</p>
 
6391
<p>
 
6392
   As of rrdtool 1.0.46 was released 04-Jan-2004.
 
6393
</p>
 
6394
<br>
 
6395
<p>
 
6396
<b>Q.</b>&nbsp;
 
6397
 Where do I get rrd?
 
6398
</p>
 
6399
<p>
 
6400
<b>A.</b>&nbsp;
 
6401
 You should not need to do anything to get rrd (see myrrd, above).
 
6402
</p>
 
6403
<p>
 
6404
   The home page for rrd is
 
6405
   http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
 
6406
</p>
 
6407
<p>
 
6408
   rpm's are available at
 
6409
   http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub
 
6410
</p>
 
6411
<br>
 
6412
<p>
 
6413
<b>Q.</b>&nbsp;
 
6414
 What about the multi-threaded development version?
 
6415
</p>
 
6416
<p>
 
6417
<b>A.</b>&nbsp;
 
6418
 Stay away. I only experimented with it a little bit, but it was not
 
6419
   stable.  Use 1.0.42.
 
6420
</p>
 
6421
 
 
6422
<pre>
 
6423
Q: I've enabled the rrd plugin and there's no data ... there are messages in the log:
 
6424
</pre>
 
6425
 
 
6426
<pre>
 
6427
        RRD call stack:
 
6428
        argv[0]: rrd_update
 
6429
        argv[1]: ...rrd/matrix/12.239.98.199/12.239.181.175/pkts.rrd
 
6430
        argv[2]: 1037289548:1
 
6431
        rrd_create(...) error: creating '...': No such file or directory
 
6432
        rrd_update(...) error: opening '...': No such file or directory
 
6433
</pre>
 
6434
 
 
6435
<pre>
 
6436
A: Create the rrd directory and make sure that the -u userid has read/write
 
6437
   access to it (typically /usr/share/ntop/rrd).
 
6438
</pre>
 
6439
<br>
 
6440
<p>
 
6441
<b>Q.</b>&nbsp;
 
6442
 rrdPlugin - problem with rrd/myrrd?
 
6443
</p>
 
6444
<p>
 
6445
<b>A.</b>&nbsp;
 
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
 
6448
   and not some other version of rrd that's installed somewhere else on your system.
 
6449
</p>
 
6450
<p>
 
6451
   Sometimes this causes problems, where there are special tricks required to tell
 
6452
   (a non gnu ld) loader about static (.a) libraries, which ntop doesn't have in
 
6453
   the Makefile nor the configureextra files.
 
6454
</p>
 
6455
<p>
 
6456
   As a SHORT TERM WORK-AROUND, you can TRY this:
 
6457
</p>
 
6458
 
 
6459
<pre>
 
6460
      $ cd myrrd
 
6461
</pre>
 
6462
<p>
 
6463
   Edit Makefile --
 
6464
</p>
 
6465
 
 
6466
<pre>
 
6467
       all: $(LIBRRD) libmyrrd.so
 
6468
                      ^^^^^^^^^^^ add this 
 
6469
</pre>
 
6470
<p>
 
6471
   Add these lines:
 
6472
</p>
 
6473
 
 
6474
<pre>
 
6475
       libmyrrd.so: $(OBJECTS)
 
6476
       <tab>ld -shared -o libmyrrd.so $(OBJECTS)
 
6477
</pre>
 
6478
<p>
 
6479
   Now do make.  You should see a libmyrrd.so file.
 
6480
</p>
 
6481
<p>
 
6482
   The main 'make' should now complete.  Copy that libmyrrd.so file where the other
 
6483
   ntop library files are, and it MIGHT work.
 
6484
</p>
 
6485
<p>
 
6486
   However, the whole idea behind having a static libmyrrd.a is to prevent version
 
6487
   conflicts and use a stable version of rrd.
 
6488
</p>
 
6489
<p>
 
6490
   The right fix is to get the configureextra/<whatever> file changed.
 
6491
</p>
 
6492
<h2>netFlow and sFlow</h2>
 
6493
<br>
 
6494
<p>
 
6495
<b>Q.</b>&nbsp;
 
6496
 How do I access netFlow or sFlow data from ntop?
 
6497
</p>
 
6498
<p>
 
6499
<b>A.</b>&nbsp;
 
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).
 
6502
</p>
 
6503
<p>
 
6504
   First, use the appropriate plugin to set the parameters - basically the port
 
6505
   you want ntop to listen on.  Then, using the Admin | Set Interface menu item,
 
6506
   switch ntop to report on the sFlow/netFlow pseudo-device (NetFlow-device or
 
6507
   sFlow-device).
 
6508
</p>
 
6509
<br>
 
6510
<p>
 
6511
<b>Q.</b>&nbsp;
 
6512
 Is there any parameter to set to tell sFlow which interface/ip address
 
6513
   to use when exporting the flows?
 
6514
</p>
 
6515
<p>
 
6516
<b>A.</b>&nbsp;
 
6517
 No. All ntop does is send a packet to the network addressed to the
 
6518
   destination you request.
 
6519
</p>
 
6520
<p>
 
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:
 
6524
</p>
 
6525
<p>
 
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
 
6534
</p>
 
6535
<p>
 
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)
 
6538
</p>
 
6539
<p>
 
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)
 
6542
</p>
 
6543
<p>
 
6544
   A packet to 192.168.2.46 goes via eth0
 
6545
</p>
 
6546
<p>
 
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)
 
6549
</p>
 
6550
<p>
 
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.
 
6554
</p>
 
6555
<h2>netFlow</h2>
 
6556
<br>
 
6557
<p>
 
6558
<b>Q.</b>&nbsp;
 
6559
 Which versions of netFlow.
 
6560
</p>
 
6561
<p>
 
6562
<b>A.</b>&nbsp;
 
6563
 v5
 
6564
   And v1/v7/v9 - in that internally a v1/v7/v9 flow is copied to a v5 buffer and then
 
6565
   processed.  We default/ignore fields that are different.
 
6566
   And nFlow - similar conversion.
 
6567
</p>
 
6568
<br>
 
6569
<p>
 
6570
<b>Q.</b>&nbsp;
 
6571
 netFlow doesn't work.
 
6572
</p>
 
6573
<p>
 
6574
<b>A.</b>&nbsp;
 
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.  
 
6577
   If you don't activate the plugin, you'll still have the netflow-device, but
 
6578
   no data on it...
 
6579
</p>
 
6580
<br>
 
6581
<p>
 
6582
<b>Q.</b>&nbsp;
 
6583
 What's Virtual NetFlow Interface?
 
6584
</p>
 
6585
<p>
 
6586
<b>A.</b>&nbsp;
 
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 
 
6589
   the netFlow collector.  So ntop knows 'where' the data is coming from.
 
6590
</p>
 
6591
<br>
 
6592
<p>
 
6593
<b>Q.</b>&nbsp;
 
6594
 'splain some more, Lucy...
 
6595
</p>
 
6596
<p>
 
6597
<b>A.</b>&nbsp;
 
6598
 OK.
 
6599
</p>
 
6600
<p>
 
6601
   It's best to think of netFlow like this:
 
6602
</p>
 
6603
<p>
 
6604
   The physical interface which is monitoring the packets is like a
 
6605
   temperature probe you stick into a roast.
 
6606
</p>
 
6607
<p>
 
6608
   Even though the display of the data can be right there at the probe, or
 
6609
   the other end of a (long) wire, or somewhere entirely elsewhere via a 
 
6610
   wireless connection, the probe is monitoring at the tip.  If it says 145F,
 
6611
   that's the temperature of the meat - not the oven and not the kitchen.
 
6612
</p>
 
6613
<p>
 
6614
   Similarly, the netFlow data ntop is receiving is based on the probe
 
6615
   location.
 
6616
</p>
 
6617
<p>
 
6618
   So, if you have a router and are monitoring a single interface to collect
 
6619
   netFlow data, then the ip address you want to give to ntop is that of
 
6620
   the router interface.
 
6621
</p>
 
6622
<p>
 
6623
   If you are monitoring a router with more than one interface, you will 
 
6624
   need to give ntop ONE of those addresses and use the -m | --local-subnets
 
6625
   option to tell it that the other addresses are also local.
 
6626
</p>
 
6627
<br>
 
6628
<p>
 
6629
<b>Q.</b>&nbsp;
 
6630
 Where is info about netflow?
 
6631
</p>
 
6632
<p>
 
6633
<b>A.</b>&nbsp;
 
6634
 Dale Reed pointed out a good tech doc (no flak, just the formats) for netflow
 
6635
</p>
 
6636
<pre>
 
6637
    V1/5/7:
 
6638
</pre>
 
6639
 
 
6640
<pre>
 
6641
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/nfc_2_0/nfc_ug/nfcform.htm
 
6642
</pre>
 
6643
<p>
 
6644
   (As of Oct2003, it includes v8 and is here:)
 
6645
</p>
 
6646
<pre>
 
6647
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/nfc_3_0/nfc_ug/nfcform.htm
 
6648
</pre>
 
6649
<br>
 
6650
<p>
 
6651
<b>Q.</b>&nbsp;
 
6652
 How Do I Enable NetFlow Data Export on a Cisco Device?
 
6653
</p>
 
6654
<p>
 
6655
<b>A.</b>&nbsp;
 
6656
 To enable netFlow Data Export (NDE) from a Cisco device to an ntop netFlow
 
6657
   receiver on port 2055 (default) at address 10.1.1.1:
 
6658
</p>
 
6659
 
 
6660
<pre>
 
6661
     ip flow-export destination 10.1.1.1 2055
 
6662
     ip flow-export version 5
 
6663
</pre>
 
6664
<p>
 
6665
   You may want to designate the source interface, e.g.:
 
6666
</p>
 
6667
 
 
6668
<pre>
 
6669
     ip flow-export source Ethernet0
 
6670
</pre>
 
6671
<p>
 
6672
   Enable netFlow on each interface to be monitored. netFlow normally only
 
6673
   captures data from each incoming packet, so to see traffic in both directions
 
6674
   netFlow must be enabled on both the incoming and outgoing interfaces. As an
 
6675
   example, for an Internet access router this would mean enabling netFlow on
 
6676
   both the internal (e.g. Ethernet) and the external (e.g. ISDN / Frame Relay
 
6677
   etc) interfaces:
 
6678
</p>
 
6679
 
 
6680
<pre>
 
6681
     interface Ethernet0
 
6682
     ip route-cache flow
 
6683
</pre>
 
6684
 
 
6685
<pre>
 
6686
     interface Dialer1
 
6687
     ip route-cache flow
 
6688
</pre>
 
6689
<p>
 
6690
   By default netFlow will only export flow statistics shortly after the flow
 
6691
   Terminates or when 30 minutes have elapsed. In many environments, you want
 
6692
   ntop to be a bit more up to date. To change the timeout to five minutes:
 
6693
</p>
 
6694
 
 
6695
<pre>
 
6696
     ip flow-cache timeout active 5
 
6697
</pre>
 
6698
<p>
 
6699
   The following 'show' commands are useful for examining netFlow statistics
 
6700
   directly on the Cisco box and may assist when setting up ntop:
 
6701
</p>
 
6702
 
 
6703
<pre>
 
6704
     show ip flow export
 
6705
     show ip cache flow
 
6706
     show ip cache verbose flow
 
6707
</pre>
 
6708
<p>
 
6709
   Obviously, there is a lot more to it than this, for more information, see the
 
6710
   Cisco web site: http://www.cisco.com/go/netflow
 
6711
</p>
 
6712
<pre>
 
6713
                                     (Created by sholmes at snapshot, 02Feb2003)
 
6714
</pre>
 
6715
<h2>sFlow</h2>
 
6716
<br>
 
6717
<p>
 
6718
<b>Q.</b>&nbsp;
 
6719
 What is sFlow
 
6720
</p>
 
6721
<p>
 
6722
<b>A.</b>&nbsp;
 
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
 
6725
   for detailed packet tracing and analysis, NetFlow compatible collectors for
 
6726
   IP flow accounting, and provides text based output that can be used in
 
6727
   scripts to provide customized analysis and reporting and for integrating with
 
6728
   other tools such as MRTG or rrdtool.
 
6729
</p>
 
6730
<p>
 
6731
   Some info:
 
6732
</p>
 
6733
<p>
 
6734
   http://www.inmon.com/sflowTools.htm
 
6735
   http://www.faqs.org/rfcs/rfc3176.html
 
6736
</p>
 
6737
<br>
 
6738
<p>
 
6739
<b>Q.</b>&nbsp;
 
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.
 
6742
</p>
 
6743
<p>
 
6744
<b>A.</b>&nbsp;
 
6745
 sFlow can be a collector or a receiver or both, depending on the
 
6746
   settings configured via the plugin.
 
6747
</p>
 
6748
<p>
 
6749
   If you configure ntop as an sFlow collector, it will use sFlow data
 
6750
   for generating reports, treating the remote collector(s) as another
 
6751
   network interface - see Admin | Switch NIC.
 
6752
</p>
 
6753
<h2>snapshot, cvs and the Wiki</h2>
 
6754
<br>
 
6755
<p>
 
6756
<b>Q.</b>&nbsp;
 
6757
 What was "snapshot"?
 
6758
</p>
 
6759
<p>
 
6760
<b>A.</b>&nbsp;
 
6761
 Snapshot was a community FAQ and documentation resource at
 
6762
   http://snapshot.ntop.org. It's was also the site of "the snapshots".
 
6763
</p>
 
6764
<p>
 
6765
   Unfortunately, snapshot seems to have 'Gone to Atlanta' (404), with
 
6766
   the web server no longer responding in February 2004.
 
6767
</p>
 
6768
<p>
 
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 
 
6771
   some time.
 
6772
</p>
 
6773
<br>
 
6774
<p>
 
6775
<b>Q.</b>&nbsp;
 
6776
 Is there a community resource that replaces (enhances) snapshot.
 
6777
</p>
 
6778
<p>
 
6779
<b>A.</b>&nbsp;
 
6780
 Yes. There is now an ntop Wiki at
 
6781
</p>
 
6782
<pre>
 
6783
     http://www.burtonstrauss.com/pmwiki/pmwiki.php?pagename=Ntop.HomePage
 
6784
   Whether it remains available depends on whether people contribute.
 
6785
</pre>
 
6786
<br>
 
6787
<p>
 
6788
<b>Q.</b>&nbsp;
 
6789
 What was "a snapshot" or "the snapshots"?
 
6790
</p>
 
6791
<p>
 
6792
<b>A.</b>&nbsp;
 
6793
 A snapshot was a dump of the ntop cvs structure, automatically generated
 
6794
   every day at 5 minutes after midnight (Pisa time).
 
6795
</p>
 
6796
<p>
 
6797
   Snapshots were named with their creation date, in the form of
 
6798
   ntop-yy-mm-dd.tgz.
 
6799
</p>
 
6800
<p>
 
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.
 
6803
</p>
 
6804
<p>
 
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.
 
6810
</p>
 
6811
<p>
 
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. 
 
6816
</p>
 
6817
<p>
 
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.
 
6821
</p>
 
6822
<p>
 
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.).
 
6825
</p>
 
6826
<p>
 
6827
   Note that the ntop_2_2_patches branch broke the snapshot extract script, so
 
6828
   snapshots ARE NO LONGER RECOMENDED OR SUPPORTED.
 
6829
</p>
 
6830
<h2>Old answers, but goodies</h2>
 
6831
<br>
 
6832
<p>
 
6833
<b>Q.</b>&nbsp;
 
6834
 What is "obsolete/"
 
6835
</p>
 
6836
<p>
 
6837
<b>A.</b>&nbsp;
 
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
 
6841
   it...
 
6842
</p>
 
6843
<p>
 
6844
   Code in obsolete/ IS NOT MAINTAINED, even minimally.
 
6845
</p>
 
6846
<p>
 
6847
   Specifics?  (As of June 2002)
 
6848
</p>
 
6849
 
 
6850
<pre>
 
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.
 
6855
               ntop-rules.8
 
6856
               event.c
 
6857
               rules.c
 
6858
               rules.h
 
6859
               rules.sample
 
6860
</pre>
 
6861
 
 
6862
<pre>
 
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.
 
6866
               wapPlugin.c
 
6867
               rmon.h
 
6868
               rmonPlugin.c
 
6869
</pre>
 
6870
 
 
6871
<pre>
 
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.  
 
6876
</pre>
 
6877
<br>
 
6878
<p>
 
6879
<b>Q.</b>&nbsp;
 
6880
 I get an error, libtool: link: CURRENT `-release' is not a nonnegative
 
6881
   integer
 
6882
</p>
 
6883
<p>
 
6884
<b>A.</b>&nbsp;
 
6885
 This is an autoconf problem. It should be fixed.
 
6886
   The whole set of messages is typically:
 
6887
</p>
 
6888
<p>
 
6889
   [...]
 
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
 
6897
</p>
 
6898
<p>
 
6899
   From Luca:
 
6900
</p>
 
6901
 
 
6902
<pre>
 
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."
 
6906
</pre>
 
6907
 
 
6908
<pre>
 
6909
       Workarounds:
 
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
 
6913
         "-release".
 
6914
</pre>
 
6915
<p>
 
6916
   Other Solutions:
 
6917
</p>
 
6918
<p>
 
6919
   1) Burton posted a personal patch to do the above for Makefile.am on
 
6920
</p>
 
6921
<pre>
 
6922
      Thu Dec 20 2001 - "Compile problems with -release". Check the ntop-dev
 
6923
      archive.
 
6924
</pre>
 
6925
<p>
 
6926
   2) Older versions (e.g. Slackware 7.xx) of Linux installations have older
 
6927
</p>
 
6928
<pre>
 
6929
      versions of automake, which don't exhibit the bug.
 
6930
</pre>
 
6931
<p>
 
6932
   3) (Sean O'Neill) "I cheated a bit and hacked libtool by changing the
 
6933
</p>
 
6934
<pre>
 
6935
      following"
 
6936
</pre>
 
6937
 
 
6938
<pre>
 
6939
        current="$2"
 
6940
          to
 
6941
        current=0
 
6942
</pre>
 
6943
 
 
6944
<pre>
 
6945
    4) The new ./configure scripts - call it versions after Nov2002 - fix this.
 
6946
</pre>
 
6947
 
 
6948
<pre>
 
6949
Q, How to Build the (obsolete) RMON plugin
 
6950
</pre>
 
6951
<p>
 
6952
<b>A.</b>&nbsp;
 
6953
 Without any guarantees...
 
6954
</p>
 
6955
 
 
6956
<pre>
 
6957
    0) Please do NOT use a precompiled UCD package unless you know what you're
 
6958
       doing.
 
6959
</pre>
 
6960
 
 
6961
<pre>
 
6962
    1) Fetch UCD-SNMP [See http://net-snmp.sourceforge.net/developer.html]
 
6963
</pre>
 
6964
 
 
6965
<pre>
 
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"
 
6969
    > make
 
6970
    > make install
 
6971
</pre>
 
6972
 
 
6973
<pre>
 
6974
    3) Once you this stuff ready you can build the ntop/RMON plugins.
 
6975
</pre>
 
6976
 
 
6977
<pre>
 
6978
    4) Now start ntop.
 
6979
</pre>
 
6980
 
 
6981
<pre>
 
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].
 
6985
</pre>
 
6986
<p>
 
6987
   NOTE: If you use tkMib do not forget to do "setenv MIBS ALL" (csh shells),
 
6988
</p>
 
6989
<pre>
 
6990
         otherwise you won't see the RMON MIB.
 
6991
</pre>
 
6992
<p>
 
6993
   How to Build the RMON plugin (bis) created 04/03 2002 by pierlo
 
6994
</p>
 
6995
<p>
 
6996
   The following works with :
 
6997
</p>
 
6998
<pre>
 
6999
     - ntop v.2.0.1
 
7000
     - UCD-SNMP v.4.2.3
 
7001
     - openSSL v.0.9.6c
 
7002
</pre>
 
7003
 
 
7004
<pre>
 
7005
     0. Requirements
 
7006
     * Make sure that ntop works properly
 
7007
</pre>
 
7008
 
 
7009
<pre>
 
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)
 
7013
</pre>
 
7014
 
 
7015
<pre>
 
7016
     * fetch & install UCD-SNMP :
 
7017
     tar -xvzf XXXXX.tar.gz
 
7018
     ./configure --enable-shared
 
7019
     make
 
7020
     umask 022
 
7021
     make install
 
7022
</pre>
 
7023
 
 
7024
<pre>
 
7025
     1. uncomment lines around 474 and 1035 in configure.in file :
 
7026
</pre>
 
7027
 
 
7028
<pre>
 
7029
     dnl>OPTIONAL UCD-SNMP
 
7030
     dnl>AC_HAVE_HEADERS(ucd-snmp/ucd-snmp-agent-includes.h)
 
7031
     (...)
 
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)
 
7037
</pre>
 
7038
 
 
7039
<pre>
 
7040
     (remove the dnl> from the AC_ lines)
 
7041
</pre>
 
7042
 
 
7043
<pre>
 
7044
     * in /ntop/plugins/rmonPlugin.c file, replace :
 
7045
</pre>
 
7046
 
 
7047
<pre>
 
7048
     line 702 approx. : droppedPackets with droppedPkts
 
7049
     (there is only one occurence, so it may not be difficult to find)
 
7050
</pre>
 
7051
 
 
7052
<pre>
 
7053
     line 676 approx. :
 
7054
     if (header_simple_table (vp,name,length,exact,var_len,
 
7055
          write_method,numDevices)
 
7056
</pre>
 
7057
 
 
7058
<pre>
 
7059
     with :
 
7060
</pre>
 
7061
 
 
7062
<pre>
 
7063
     if (header_simple_table(vp,name,length,exact,var_len,
 
7064
          write_method,myGlobals.numDevices)
 
7065
</pre>
 
7066
 
 
7067
<pre>
 
7068
     and :
 
7069
</pre>
 
7070
 
 
7071
<pre>
 
7072
     long_ret = (long)(device[ifNum]
 
7073
</pre>
 
7074
 
 
7075
<pre>
 
7076
     with
 
7077
</pre>
 
7078
 
 
7079
<pre>
 
7080
     long_ret = (long)(myGlobals.device[ifNum]
 
7081
</pre>
 
7082
 
 
7083
<pre>
 
7084
     (lines 690 to 782 approx., about 13 occurences to change)
 
7085
</pre>
 
7086
 
 
7087
<pre>
 
7088
     2. launch /ntop/autogen.sh -1
 
7089
</pre>
 
7090
 
 
7091
<pre>
 
7092
     3. launch /ntop/configure
 
7093
</pre>
 
7094
 
 
7095
<pre>
 
7096
     Be sure that :
 
7097
</pre>
 
7098
 
 
7099
<pre>
 
7100
     * there is no warning about openSSL libraries !
 
7101
</pre>
 
7102
 
 
7103
<pre>
 
7104
     * the following checks are successful :
 
7105
     " Step 4. Looking for both required and optional system headers....
 
7106
     (...)
 
7107
     checking for ucd-snmp/ucd-snmp-agent-includes.h... yes"
 
7108
     (...)
 
7109
</pre>
 
7110
 
 
7111
<pre>
 
7112
     "Step 7. Looking for optional GPLed libraries....
 
7113
     (...)
 
7114
     checking for register_mib in -lucdagent... yes"
 
7115
</pre>
 
7116
 
 
7117
<pre>
 
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
 
7121
     helpful.
 
7122
</pre>
 
7123
 
 
7124
<pre>
 
7125
     3. edit /ntop/plugins/Makefile : replace every ocurence of "icmpPlugin"
 
7126
        with "rmonPlugin".
 
7127
</pre>
 
7128
 
 
7129
<pre>
 
7130
     4. Launch /ntop/plugins/make
 
7131
</pre>
 
7132
 
 
7133
<pre>
 
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.
 
7137
</pre>
 
7138
 
 
7139
<pre>
 
7140
     Hope I didn't forget anything... Have fun !
 
7141
</pre>
 
7142
 
 
7143
<pre>
 
7144
     P-L.
 
7145
</pre>
 
7146
<br>
 
7147
<p>
 
7148
<b>Q.</b>&nbsp;
 
7149
 I don't understand -j | --border-sniffer-mode
 
7150
</p>
 
7151
<p>
 
7152
<b>A.</b>&nbsp;
 
7153
 Welcome to the club <grin />
 
7154
</p>
 
7155
<p>
 
7156
   Quoting from Luca's comment:
 
7157
</p>
 
7158
<p>
 
7159
   "-j is used when you are starting ntop on a mirrored interface where you
 
7160
   cannot trust MAC addresses."
 
7161
</p>
 
7162
<p>
 
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.
 
7168
</p>
 
7169
<p>
 
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
 
7173
   ports.
 
7174
</p>
 
7175
<p>
 
7176
   So an ntop instance, sniffer, whatever only sees a fraction of the traffic.
 
7177
</p>
 
7178
<p>
 
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
 
7181
   be performed there.
 
7182
</p>
 
7183
<p>
 
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.
 
7187
</p>
 
7188
<p>
 
7189
   Note that:
 
7190
</p>
 
7191
<p>
 
7192
   1. -j usually requires you to specify the local network (-m) as a mirrored
 
7193
</p>
 
7194
<pre>
 
7195
      interface might have a wrong/ip-less/privare IP address.
 
7196
</pre>
 
7197
<p>
 
7198
   2. -j disables some features as TCP session tracking etc.
 
7199
</p>
 
7200
<p>
 
7201
   In future versions -j will disappear and it will be replaced with more flags
 
7202
   for better controlling all these options.
 
7203
</p>
 
7204
<p>
 
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.
 
7207
</p>
 
7208
<p>
 
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.
 
7215
</p>
 
7216
<p>
 
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)
 
7221
</p>
 
7222
<br>
 
7223
<p>
 
7224
<b>Q.</b>&nbsp;
 
7225
 When I run with -j | --border-sniffer-mode, there are different menus.
 
7226
</p>
 
7227
<p>
 
7228
<b>A.</b>&nbsp;
 
7229
 Yes.
 
7230
</p>
 
7231
<p>
 
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.
 
7236
</p>
 
7237
<br>
 
7238
<p>
 
7239
<b>Q.</b>&nbsp;
 
7240
 OK, but it changed after 2.1.2 (i.e. in 2.1.50) what are the NEW parameters?
 
7241
</p>
 
7242
<p>
 
7243
<b>A.</b>&nbsp;
 
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!
 
7248
</p>
 
7249
<br>
 
7250
<p>
 
7251
<b>Q.</b>&nbsp;
 
7252
 What was the -S option?
 
7253
</p>
 
7254
<p>
 
7255
<b>A.</b>&nbsp;
 
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
 
7259
   device.
 
7260
</p>
 
7261
<p>
 
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].
 
7266
</p>
 
7267
<p>
 
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).
 
7270
</p>
 
7271
<p>
 
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.
 
7275
</p>
 
7276
<p>
 
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...)
 
7280
</p>
 
7281
<p>
 
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.
 
7284
</p>
 
7285
<p>
 
7286
   But if you're looking for device throughput to be preserved... nope...
 
7287
</p>
 
7288
<p>
 
7289
   Also, ntop stores the information during 1) reset and 2) shutdown. So if ntop
 
7290
   crashes, the persistent data will be lost.
 
7291
</p>
 
7292
<p>
 
7293
   This option was removed from ntop in the 2.1.52 development version.
 
7294
</p>
 
7295
<br>
 
7296
<p>
 
7297
<b>Q.</b>&nbsp;
 
7298
 What was the -A option, a/k/a --accuracy-level?
 
7299
</p>
 
7300
<p>
 
7301
<b>A.</b>&nbsp;
 
7302
 This option was used to set ntop into various modes which performed less
 
7303
   processing, in order to handle higher traffic volumes.
 
7304
</p>
 
7305
<p>
 
7306
   It was added on 14Dec2001 (just before v2.0) and was removed on 11Mar2002,
 
7307
   although traces survived in usage() until April 2002.
 
7308
</p>
 
7309
<p>
 
7310
   Note that the CODE remains in initialize.c for use by EXPERTS if necessary.
 
7311
</p>
 
7312
<br>
 
7313
<p>
 
7314
<b>Q.</b>&nbsp;
 
7315
 What was the --no-admin-password-hint option?
 
7316
</p>
 
7317
<p>
 
7318
<b>A.</b>&nbsp;
 
7319
 This option was used to remove the hint text from the administrative password
 
7320
   entry message box.
 
7321
</p>
 
7322
<p>
 
7323
   It was added 4Feb2002 and removed 8Mar2002 (the last traces, in usage(), were
 
7324
   removed on 4Apr2002).
 
7325
</p>
 
7326
<h2>Solaris</h2>
 
7327
 
 
7328
<pre>
 
7329
                                        During the ntop 2.2 development cycle,
 
7330
                                        we did development/testing under:
 
7331
                                           Solaris 2.5, 7 and 8 (i86)
 
7332
</pre>
 
7333
 
 
7334
<pre>
 
7335
                                        During the ntop 3.0 development cycle,
 
7336
                                        we did development/testing under:
 
7337
                                           Solaris 8 (i86) and 9
 
7338
</pre>
 
7339
<br>
 
7340
<p>
 
7341
<b>Q.</b>&nbsp;
 
7342
 How do I install the ntop package on Solaris?
 
7343
</p>
 
7344
<p>
 
7345
<b>A.</b>&nbsp;
 
7346
 For instance do 'pkgadd -d ntop-2.2-solaris.i386'
 
7347
</p>
 
7348
<br>
 
7349
<p>
 
7350
<b>Q.</b>&nbsp;
 
7351
 What c compiler do I need?
 
7352
</p>
 
7353
<p>
 
7354
<b>A.</b>&nbsp;
 
7355
 Sun's cc or gnu's gcc.
 
7356
</p>
 
7357
<br>
 
7358
<p>
 
7359
<b>Q.</b>&nbsp;
 
7360
 What about /usr/ucb/cc is that the one?
 
7361
</p>
 
7362
<p>
 
7363
<b>A.</b>&nbsp;
 
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.
 
7366
</p>
 
7367
<p>
 
7368
   The cc I mean is Sun's Commercial Compiler.
 
7369
</p>
 
7370
<h2>xxxxBSD</h2>
 
7371
<br>
 
7372
<p>
 
7373
<b>Q.</b>&nbsp;
 
7374
 When I type 'make' it complains about a makefile error.
 
7375
</p>
 
7376
<p>
 
7377
<b>A.</b>&nbsp;
 
7378
 Always remember to use gnu make.
 
7379
</p>
 
7380
<p>
 
7381
   On many *BSD systems which have other 'make's, gnu make is called gmake.
 
7382
   Try make --version -- if it shows a Gnu version stamp you're ok, otherwise
 
7383
   try gmake.
 
7384
</p>
 
7385
<h2>BSD - FreeBSD</h2>
 
7386
 
 
7387
<pre>
 
7388
                                        During the ntop 2.2 development cycle,
 
7389
                                        we did development/testing under:
 
7390
                                           4.6.3
 
7391
                                           5.0
 
7392
</pre>
 
7393
 
 
7394
<pre>
 
7395
                                        Users reported success with:
 
7396
                                           4.7
 
7397
                                           4.8
 
7398
</pre>
 
7399
 
 
7400
<pre>
 
7401
                                        During the ntop 3.0 development cycle,
 
7402
                                        we did development/testing under:
 
7403
                                           4.8 and 4.9
 
7404
                                           5.1 and 5.2
 
7405
</pre>
 
7406
 
 
7407
<pre>
 
7408
                                        Users reported success with:
 
7409
                                           4.6.2
 
7410
                                           4.5.1
 
7411
</pre>
 
7412
<br>
 
7413
<p>
 
7414
<b>Q.</b>&nbsp;
 
7415
 I can't compile ntop under FreeBSD 5.0 or 5.1.
 
7416
</p>
 
7417
<p>
 
7418
<b>A.</b>&nbsp;
 
7419
 In some situations, we produce gcc link lines which expose a conflict 'tween
 
7420
   FreeBSD 5.x and libtool.
 
7421
</p>
 
7422
<p>
 
7423
   You will see the following error messages:
 
7424
</p>
 
7425
 
 
7426
<pre>
 
7427
       expr: illegal option -- l
 
7428
       usage: expr [-e] expression
 
7429
       etc.
 
7430
</pre>
 
7431
<p>
 
7432
   See the release notes for FreeBSD 5.0 and the expr(1) man page:
 
7433
</p>
 
7434
 
 
7435
<pre>
 
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
 
7438
</pre>
 
7439
<p>
 
7440
   Solve this by setting the compatibility flag before running make.
 
7441
</p>
 
7442
 
 
7443
<pre>
 
7444
       $ export EXPR_COMPAT=Y
 
7445
</pre>
 
7446
<p>
 
7447
   configure.in and configure have been updated to do warn you to do this.
 
7448
</p>
 
7449
<br>
 
7450
<p>
 
7451
<b>Q.</b>&nbsp;
 
7452
 I get "ntop: /dev/bpf0: Device not configured", what's wrong?
 
7453
</p>
 
7454
<p>
 
7455
<b>A.</b>&nbsp;
 
7456
 This is because bfpX has not been configured inside the generic bsd-kernel
 
7457
   config file.
 
7458
</p>
 
7459
<p>
 
7460
   If you use generic kernel config file put "pseudo-device bpfilter 16" in
 
7461
   kernel config file and rebuild the kernel.
 
7462
</p>
 
7463
<br>
 
7464
<p>
 
7465
<b>Q.</b>&nbsp;
 
7466
 I remember rumors about something not being right under FreeBSD with
 
7467
   threads?
 
7468
</p>
 
7469
<p>
 
7470
<b>A.</b>&nbsp;
 
7471
 Yes. See FreeBSD bug bin/17437 at
 
7472
   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17437
 
7473
</p>
 
7474
<p>
 
7475
   Basically, due to limits in FreeBSD, there is no pthread_atfork() function.
 
7476
   So, when ntop does it's fork() call to create http pages, it can't fixup
 
7477
   the Mutexes.  It wrong and could conceivably cause problems.
 
7478
</p>
 
7479
<p>
 
7480
   However - ntop ran for years without the pthread_atfork() code, so we're
 
7481
   no worse off in 3.0 under FreeBSD than in 2.2 or 2.1...
 
7482
</p>
 
7483
<p>
 
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,
 
7486
   just walking at about 0.001KPH).
 
7487
</p>
 
7488
<p>
 
7489
   Thanks to Yeoman efforts by Stanley Hopcroft, Michal Meloun and, well, me,
 
7490
   we have a work-around.  
 
7491
</p>
 
7492
<p>
 
7493
   If you're running under FreeBSD, use the flag, --set-pcap-nonblocking.
 
7494
</p>
 
7495
<p>
 
7496
   For more on this, read the threads at gmane - look for "FreeBSD and pthreads" - 
 
7497
   that's probably the best summary.  But there's stuff on this back at least to 
 
7498
   October 2003 - look for Stanley's problems with CPU usage.
 
7499
</p>
 
7500
<br>
 
7501
<p>
 
7502
<b>Q.</b>&nbsp;
 
7503
 Um... something about bad fds?
 
7504
</p>
 
7505
<p>
 
7506
<b>A.</b>&nbsp;
 
7507
 Oh yes, see bug bin/51535: uthreads bug: new opened files may get stale fcntl flags
 
7508
</p>
 
7509
<p>
 
7510
   They fixed the code, sort of:
 
7511
</p>
 
7512
 
 
7513
<pre>
 
7514
         OS      Version
 
7515
         ------- --------------
 
7516
         FreeBSD 4.9    FIXED
 
7517
         FreeBSD 5.1    BUGGY
 
7518
         FreeBSD 5.2    FIXED
 
7519
         FreeBSD 4.8    BUGGY
 
7520
         FreeBSD 4.6.2  BUGGY
 
7521
</pre>
 
7522
<p>
 
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.
 
7526
</p>
 
7527
<h2>BSD - OpenBSD</h2>
 
7528
 
 
7529
<pre>
 
7530
                                        During the ntop 3.0 development cycle,
 
7531
                                        we tried development/testing under:
 
7532
                                           3.1 and 3.4
 
7533
</pre>
 
7534
<br>
 
7535
<p>
 
7536
<b>Q.</b>&nbsp;
 
7537
 So?
 
7538
</p>
 
7539
<p>
 
7540
<b>A.</b>&nbsp;
 
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.
 
7543
</p>
 
7544
<p>
 
7545
<b>A.</b>&nbsp;
 
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.
 
7548
</p>
 
7549
<h2>BSD - NetBSD</h2>
 
7550
 
 
7551
<pre>
 
7552
                                        During the ntop 2.3 development cycle,
 
7553
                                        we tried development/testing under:
 
7554
                                           1.5.3
 
7555
                                           1.6
 
7556
                                           1.6.1
 
7557
</pre>
 
7558
<br>
 
7559
<p>
 
7560
<b>Q.</b>&nbsp;
 
7561
 So?
 
7562
</p>
 
7563
<p>
 
7564
<b>A.</b>&nbsp;
 
7565
 Some testing was done using - ntop works only in SINGLE THREADED mode and so
 
7566
   is fragile.
 
7567
</p>
 
7568
<br>
 
7569
<p>
 
7570
<b>Q.</b>&nbsp;
 
7571
 And Multithreaded?
 
7572
</p>
 
7573
<p>
 
7574
<b>A.</b>&nbsp;
 
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
 
7578
   far...
 
7579
</p>
 
7580
<br>
 
7581
<p>
 
7582
<b>Q.</b>&nbsp;
 
7583
 But there IS a POSIX threads...
 
7584
</p>
 
7585
<p>
 
7586
<b>A.</b>&nbsp;
 
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.
 
7589
</p>
 
7590
<h2>Linux - all</h2>
 
7591
 
 
7592
<pre>
 
7593
                                        During the ntop 2.2 development cycle,
 
7594
                                        we did development and/or testing under:
 
7595
                                           Debian
 
7596
                                           LinuxFromScratch 3.0pre3
 
7597
                                           RedHat AS2.1, 7.2, 7.3, 8.0
 
7598
</pre>
 
7599
 
 
7600
<pre>
 
7601
                                        During the ntop 3.0 development cycle,
 
7602
                                        we did development and/or testing under:
 
7603
                                           Debian 3.0 (Woody)
 
7604
                                           Gentoo 1.4 (rc5 and released)
 
7605
                                           LinuxFromScratch 3.0pre3
 
7606
                                           Mandrake 9.1
 
7607
                                           RedHat AS2.1, 7.3, 8.0 and 9
 
7608
                                           Slackware 9.0
 
7609
                                           SuSE 8.2
 
7610
</pre>
 
7611
 
 
7612
<pre>
 
7613
                                        And loads more - see the list above.
 
7614
</pre>
 
7615
 
 
7616
<pre>
 
7617
                                        Others should certainly work and there
 
7618
                                        are many user reports of success.
 
7619
</pre>
 
7620
<h2>Linux - RedHat</h2>
 
7621
<br>
 
7622
<p>
 
7623
<b>Q.</b>&nbsp;
 
7624
 NPTL?
 
7625
</p>
 
7626
<p>
 
7627
<b>A.</b>&nbsp;
 
7628
 When RH9 came out with NPTL, we had lots of problems. NPTL is much closer
 
7629
   to POSIX threads, but very different from the old linuxthreads.  At the same
 
7630
   time, we had problems with the glibc 2.3.x (vs. 2.2.x) update.
 
7631
</p>
 
7632
<p>
 
7633
   By the end of the development cycle, a couple of memory management fixes
 
7634
   seem to have made the NPTL/glibc problems go away.  But if they're still out
 
7635
   there, they are quite nasty.  Random unexplained BOMBs and such.
 
7636
</p>
 
7637
<p>
 
7638
   If you hit these problems, you can try disabling NPTL via this flag.
 
7639
   Before both ./configure AND make, set the following:
 
7640
</p>
 
7641
 
 
7642
<pre>
 
7643
        export LD_ASSUME_KERNEL=2.4.1"
 
7644
</pre>
 
7645
<p>
 
7646
   This forces the use of the old linuxthreads library.
 
7647
</p>
 
7648
<p>
 
7649
   This flag may also do something to glibc, but it's undocumented and we
 
7650
   never could really figure it out.  For that run time behavior change
 
7651
   to happen, you would also have to have the LD_ASSUME_KERNAL flag set
 
7652
   at run time too.
 
7653
</p>
 
7654
<br>
 
7655
<p>
 
7656
<b>Q.</b>&nbsp;
 
7657
 The cause?
 
7658
</p>
 
7659
<p>
 
7660
<b>A.</b>&nbsp;
 
7661
 Unknown.
 
7662
</p>
 
7663
<p>
 
7664
   A lot of them seemed to go away when we fixed a free() that occurs in
 
7665
   a fork()ed child of memory malloc()ed in the parent.  Under Linux, the
 
7666
   fork() gets a copy of memory, but a technique called copy-on-write is used
 
7667
   to reduce the time the fork() takes.
 
7668
</p>
 
7669
<p>
 
7670
   We suspected that the free() was corrupting the parent's memory structures,
 
7671
   but this isn't supposed to be possible and we couldn't nail it down enough
 
7672
   to report it to the glibc people.
 
7673
</p>
 
7674
<br>
 
7675
<p>
 
7676
<b>Q.</b>&nbsp;
 
7677
 What can I do to help?
 
7678
</p>
 
7679
<p>
 
7680
<b>A.</b>&nbsp;
 
7681
 There is code in leaks.c tagged "DIAGNOSTIC". Turn it on, collect a set of
 
7682
   potential problems and report them.  However, this code isn't that bright.
 
7683
   It will report all the free() calls in fork()ed children, even those that
 
7684
   are legit (i.e. the malloc() was also in for fork()ed child).
 
7685
</p>
 
7686
<br>
 
7687
<p>
 
7688
<b>Q.</b>&nbsp;
 
7689
 "application bug: ntop(...) has SIGCHLD set to SIG_IGN but calls wait().
 
7690
   (See the NOTES section of 'man 2 wait'). Workaround activated."
 
7691
</p>
 
7692
<p>
 
7693
   This message and the NOTES section of the man page lead me to believe
 
7694
   that the problem is handled but the kernel feels the need to report it
 
7695
   from time to time.
 
7696
</p>
 
7697
<p>
 
7698
<b>A.</b>&nbsp;
 
7699
 Read the NOTES section. The problem has been handled, but the kernel
 
7700
   feels the need to report it from time to time.  See the article at
 
7701
   http://article.gmane.org/gmane.linux.ntop.general/5304
 
7702
</p>
 
7703
<br>
 
7704
<p>
 
7705
<b>Q.</b>&nbsp;
 
7706
 libpng version conflicts?
 
7707
</p>
 
7708
<p>
 
7709
<b>A.</b>&nbsp;
 
7710
 See libpng, below.
 
7711
</p>
 
7712
<h2>Win32 - Common</h2>
 
7713
<br>
 
7714
<p>
 
7715
<b>Q.</b>&nbsp;
 
7716
 Where can I find GDBM for Windows?
 
7717
</p>
 
7718
<p>
 
7719
<b>A.</b>&nbsp;
 
7720
 GDBM for windows can be found at http://www.roth.net/libs/gdbm/
 
7721
</p>
 
7722
<br>
 
7723
<p>
 
7724
<b>Q.</b>&nbsp;
 
7725
 ntop -i1 ... doesn't work
 
7726
</p>
 
7727
<p>
 
7728
<b>A.</b>&nbsp;
 
7729
 ntop has special parameters under Win32
 
7730
</p>
 
7731
 
 
7732
<pre>
 
7733
         Under win32 there are TWO COMPLETELY SEPARATE TYPES OF PARAMETERS.
 
7734
</pre>
 
7735
 
 
7736
<pre>
 
7737
     There are the parameters to the win32 stub AND there are parameters to ntop
 
7738
     itself.
 
7739
</pre>
 
7740
 
 
7741
<pre>
 
7742
     AFTER THE win32 parameters are the ntop parameters in the standard (Unix)
 
7743
     -xxx format.
 
7744
</pre>
 
7745
 
 
7746
<pre>
 
7747
         ntop /c <normal parms>  runs ntop INTERACTIVELY with the specified ntop
 
7748
         parameters
 
7749
</pre>
 
7750
 
 
7751
<pre>
 
7752
         ntop /i <parameters> installs ntop as a service to run with the specified parameters
 
7753
</pre>
 
7754
 
 
7755
<pre>
 
7756
         ntop /d deletes the ntop service
 
7757
</pre>
 
7758
<p>
 
7759
   Remember, ntop /i and ntop /d don't actually run the service - you need to
 
7760
   start it.
 
7761
</p>
 
7762
<br>
 
7763
<p>
 
7764
<b>Q.</b>&nbsp;
 
7765
 How do I figure out what my network interface numbers are for the -I
 
7766
   parameter?
 
7767
</p>
 
7768
<p>
 
7769
<b>A.</b>&nbsp;
 
7770
 (Thanks to jac engel [jacengel@home.nl] for the example)
 
7771
</p>
 
7772
<p>
 
7773
   If you only have ONE network interface, it doesn't matter as the default is
 
7774
   fine.  However, that's the RARE case.  Most people have multiple network
 
7775
   interfaces (NICs), with virtual ones for VPNs, Dialup Networking, etc.
 
7776
</p>
 
7777
<p>
 
7778
   The Windows tools ipconfig, winipcfg and the Device Manager (depending on
 
7779
   which version of Windows you have) will probably show you them.  However,
 
7780
   it's easier and better to use ntop to show you how ntop sees the network
 
7781
   interfaces.
 
7782
</p>
 
7783
<p>
 
7784
   If you start  ntop /c (interactive mode, with only the default parameters) it
 
7785
   Will display all your network interfaces (NICs), like this:
 
7786
</p>
 
7787
 
 
7788
<pre>
 
7789
    Running ntop for Win32.
 
7790
    Wait please: ntop is coming up...
 
7791
    23/Aug/2002 20:43:55 Initializing IP services...
 
7792
    23/Aug/2002 20:43:55 Initializing GDBM...
 
7793
    23/Aug/2002 20:43:55 Initializing network devices...
 
7794
    23/Aug/2002 20:43:55 Found interface [index=0] '\Device\Packet_{14...1C}'
 
7795
    23/Aug/2002 20:43:55 Found interface [index=1] '\Device\Packet_{86...B4}'
 
7796
    23/Aug/2002 20:43:55 Found interface [index=2] '\Device\Packet_NdisWanIp'
 
7797
    23/Aug/2002 20:43:57 ntop v.2.1 MT [WinNT/2K/XP] (11/07/2002 build)
 
7798
    23/Aug/2002 20:43:57 Listening on [3F1C}\Device\Packet_{14...1C}
 
7799
</pre>
 
7800
 
 
7801
<pre>
 
7802
  By default, ntop will use the lowest numbered interface.  Because #s are
 
7803
  assigned based on the sequence cards are discovered, and this is altered if
 
7804
  cards are removed and added, this is often not what you want.
 
7805
</pre>
 
7806
 
 
7807
<pre>
 
7808
  After you figure out which NIC you want, start ntop /c -i1 or -i2 or
 
7809
  whatever...
 
7810
</pre>
 
7811
<br>
 
7812
<p>
 
7813
<b>Q.</b>&nbsp;
 
7814
 OK, but how to I translate \Device\Packet_xxxxx to my Froboz ModelT network
 
7815
   card and not the Fubar27 that's on the motherboard.
 
7816
</p>
 
7817
<p>
 
7818
<b>A.</b>&nbsp;
 
7819
 ntop should report both the index and the human readable information.
 
7820
</p>
 
7821
<p>
 
7822
<b>A.</b>&nbsp;
 
7823
 A Google search on script "CurrentVersion\NetworkCards" finds a couple of
 
7824
   scripts/utilities that might work in various environments.
 
7825
</p>
 
7826
<p>
 
7827
<b>A.</b>&nbsp;
 
7828
 Otherwise...
 
7829
</p>
 
7830
<p>
 
7831
   You're going to need to view the registry.  All the usual warnings - back up
 
7832
   your pc, etc.
 
7833
</p>
 
7834
<p>
 
7835
   If you damage the registry, you may not be able to reboot the computer.
 
7836
</p>
 
7837
<p>
 
7838
   You're not going to CHANGE anything, but an inadvertent keystroke could be
 
7839
   disaster ... BE CAREFUL!
 
7840
</p>
 
7841
<p>
 
7842
   Under WinNT/2K, to find the interface name of your NIC look in the registry
 
7843
   at the keys in 
 
7844
</p>
 
7845
<pre>
 
7846
     HKLM\Software\Microsoft\Windows NT\Currentversion\NetworkCards\
 
7847
   The two subkeys, Servicename and the Description tells you which id maps to
 
7848
   which NIC.
 
7849
</pre>
 
7850
<br>
 
7851
<p>
 
7852
<b>Q.</b>&nbsp;
 
7853
 Where does ntop look for html (and gif) files under Win32?
 
7854
</p>
 
7855
<p>
 
7856
<b>A.</b>&nbsp;
 
7857
 ntop looks in two places. The first is the current directory and the second
 
7858
   is configurable through a constant in ntop_win32.h, #define DATAFILE_DIR "."
 
7859
</p>
 
7860
<p>
 
7861
   Note that the current directory, or ".", may not be what you expect.
 
7862
</p>
 
7863
<p>
 
7864
   When running ntop as a Win32 service, "." is %SystemRoot%\system32, meaning
 
7865
   that ntop looks in %SystemRoot%\system32\html for the .html and .gif files.
 
7866
</p>
 
7867
<p>
 
7868
   When running ntop from the command line,
 
7869
</p>
 
7870
 
 
7871
<pre>
 
7872
       ntop /c parameters...
 
7873
</pre>
 
7874
<p>
 
7875
   "." is whatever directory is current.  This means that if you run ntop with a
 
7876
   full, explicit path (c:\ntopnew\ntop /c ...) there may be an unexpected
 
7877
   difference between what ntop finds for "." and what you THINK "." is!  This
 
7878
   will lead to missing .html and .gif files.
 
7879
</p>
 
7880
<p>
 
7881
   If you wish to have ntop look in a specific place for the files, the best
 
7882
   choices are:
 
7883
</p>
 
7884
 
 
7885
<pre>
 
7886
     1) Create a .bat file to run ntop which does a cd to the expected directory
 
7887
        first.
 
7888
     2) Edit ntop_win32.c and then recompile.
 
7889
</pre>
 
7890
<p>
 
7891
   Note that the settings for DATAFILE_DIR (and other constants) are reported on
 
7892
   the text version of the configuration page, textinfo.html.
 
7893
</p>
 
7894
<h2>Win32 (MinGW) (Windows)</h2>
 
7895
<br>
 
7896
<p>
 
7897
<b>Q.</b>&nbsp;
 
7898
 What's the scoop with ntop on Windows?
 
7899
</p>
 
7900
<p>
 
7901
<b>A.</b>&nbsp;
 
7902
 Semi-officially,
 
7903
</p>
 
7904
<p>
 
7905
   ntop for Windows 95/98/ME/NT/2K is also provided as a binary application with
 
7906
   limited capture capability (1000 packets). This is intended to allow 
 
7907
   demonstration of ntop for people without access to a Unix system.
 
7908
</p>
 
7909
<p>
 
7910
   We call this version Win32 after the old official name of the Windows library.
 
7911
</p>
 
7912
<p>
 
7913
   If you want to use the full version with unlimited packet capture you can
 
7914
   either:
 
7915
</p>
 
7916
 
 
7917
<pre>
 
7918
       * Recompile ntop from the source by yourself (Luca says just open the
 
7919
         files in MS Visual C++ 6.0 and press compile)
 
7920
       * Register your ntop for Windows 95/98/NT/2K copy by paying a 
 
7921
         convenience fee to receive the prebuilt executable.
 
7922
</pre>
 
7923
<p>
 
7924
   If you decide to register your copy, Luca will send you an URL from which
 
7925
   you  can download the full version periodically.
 
7926
</p>
 
7927
<br>
 
7928
<p>
 
7929
<b>Q.</b>&nbsp;
 
7930
 So where did MinGW come in?
 
7931
</p>
 
7932
<p>
 
7933
<b>A.</b>&nbsp;
 
7934
 All of the necessary open software tools have been ported to run under
 
7935
   windows (sort of), so it is theoretically possible to build and run ntop
 
7936
   under Windows.  
 
7937
</p>
 
7938
<p>
 
7939
   However, Windows and *nix are very, very different internally.  So we have
 
7940
   to use special versions of the packet capture library (winpcap instead of
 
7941
   libpcap).  And we needed our standard tools (gcc et al), plus some 'glue'
 
7942
   so we could make *nix calls and have Windows things happen.
 
7943
</p>
 
7944
<p>
 
7945
   For the tools and glue, there are three choices: native, Cygwin and MinGW.
 
7946
</p>
 
7947
<p>
 
7948
   Native means you put lots of #ifdefs in to make Windows calls where you
 
7949
   had *nix calls.
 
7950
</p>
 
7951
<p>
 
7952
   Cygwin is a shim - it's a Windows dll (Dynamic Link Library) that pretends
 
7953
   to support the *nix calls and then does the right Windows things for you.
 
7954
</p>
 
7955
<p>
 
7956
   MinGW is a project to create native Windows tools and executables from
 
7957
   *nix code.
 
7958
</p>
 
7959
<p>
 
7960
   Each of these have limits, pluses and minuses.  For example, Cygwin's dll
 
7961
   has caused all sorts of problems (dlls and their *nix equivalent, shared
 
7962
   libraries, usually do).  MinGW has some limits.  As MinGW grew, ntop for
 
7963
   Win32(MinGW) got closer to ntop under *nix.  Native means supporting two
 
7964
   'separate' code bases.
 
7965
</p>
 
7966
<p>
 
7967
   Luca actually picked a hybrid - he uses Microsoft Visual C++ 6.0 - which
 
7968
   has it's own (albeit incomplete) shim layer.  As long as you stay within
 
7969
   the limits of the shim, the same code works across platforms.  In other
 
7970
   places you have to make thinks like Windows wants them.  How close are
 
7971
   we?  grep for WIN32.
 
7972
</p>
 
7973
<p>
 
7974
   The advantage of the hybrid was that is was also pretty close to working
 
7975
   under MinGW - creating native executables from the base code using free
 
7976
   tools.  So people sent in patches and it pretty much worked.  Up until
 
7977
   2.1.3, that is.  But it was never officially more than an 'it also runs'.
 
7978
</p>
 
7979
<p>
 
7980
   After 2.1.3, Luca embarked on a process of bringing the WIN32 and *nix
 
7981
   code closer together.  Surprisingly, this actually broke MinGW!
 
7982
</p>
 
7983
<br>
 
7984
<p>
 
7985
<b>Q.</b>&nbsp;
 
7986
 Where do I get MinGW?
 
7987
</p>
 
7988
<p>
 
7989
<b>A.</b>&nbsp;
 
7990
 The MinGW home page is http://www.mingw.org. Quoting:
 
7991
</p>
 
7992
 
 
7993
<pre>
 
7994
      "MinGW is a collection of header files and import libraries that 
 
7995
      allow one to use GCC and produce native Windows32 programs that do
 
7996
      not rely on any 3rd-party DLLs. The current set of tools include 
 
7997
      GNU Compiler Collection (GCC), GNU Binary Utilities (Binutils), 
 
7998
      GNU debugger (Gdb) , GNU make, and a assorted other utilities. We
 
7999
      are currently working on creating a complete set of Mingw-hosted
 
8000
      GNU toolchain, and looking for volunteers."
 
8001
</pre>
 
8002
<br>
 
8003
<p>
 
8004
<b>Q.</b>&nbsp;
 
8005
 Does ntop work under Cygwin?
 
8006
</p>
 
8007
<p>
 
8008
<b>A.</b>&nbsp;
 
8009
 The .exe distributed through ntop.org is built with Visual C++ 6.0.
 
8010
   It proved just barely possible to use the same code under MinGW.
 
8011
   Forget about cygwin.
 
8012
</p>
 
8013
<br>
 
8014
<p>
 
8015
<b>Q.</b>&nbsp;
 
8016
 Does ntop (v3.0) work under MinGW?
 
8017
</p>
 
8018
<p>
 
8019
<b>A.</b>&nbsp;
 
8020
 No - There are problems with versions of ntop after 2.1.3 under MinGW -
 
8021
   it won't build.
 
8022
</p>
 
8023
<br>
 
8024
<p>
 
8025
<b>Q.</b>&nbsp;
 
8026
 When I type 'make' it complains about a makefile error.
 
8027
</p>
 
8028
<pre>
 
8029
A: Remember to use -f Makefile.MinGW or whatever is appropriate - see
 
8030
   BUILD-MinGW.txt.
 
8031
</pre>
 
8032
<br>
 
8033
<p>
 
8034
<b>Q.</b>&nbsp;
 
8035
 Mingw make of Ntop fails when using the single-file distribution
 
8036
   MinGW-1.1.tar.gz with make errors about version.c like :
 
8037
</p>
 
8038
<pre>
 
8039
    zsh: no matches found: *version
 
8040
    make: *** [version.c] Error 1
 
8041
</pre>
 
8042
<p>
 
8043
<b>A.</b>&nbsp;
 
8044
 Be sure that your PATH setting in the DOS command box of the Mingw bin
 
8045
   directory ends with a backslash.
 
8046
</p>
 
8047
<pre>
 
8048
    This is OK:
 
8049
        set path=C:\Mingw\bin\;%path%
 
8050
    This is wrong:
 
8051
        set path=C:\Mingw\bin;%path%
 
8052
                             ^
 
8053
</pre>
 
8054
<h2>Win32 (MS Visual C++)</h2>
 
8055
<h2>Other platforms</h2>
 
8056
 
 
8057
<pre>
 
8058
-UX
 
8059
=-=-=
 
8060
During the 2.2 development cycle, some work was done to make ntop work under
 
8061
-UX 11 without breaking the HP-UX 10.20 support (limited as it was). During
 
8062
the 3.0 development cycle, HP-UX was not considered.
 
8063
</pre>
 
8064
 
 
8065
<pre>
 
8066
It will almost certainly fail.
 
8067
</pre>
 
8068
 
 
8069
<pre>
 
8070
IRIX (v1.3 information)
 
8071
=-=-=-=-=-=-=-=-=-=-=-=-
 
8072
During the ntop 2.2 and 3.0 development cycles, IRIX was not considered.
 
8073
</pre>
 
8074
 
 
8075
<pre>
 
8076
It will almost certainly fail.
 
8077
</pre>
 
8078
 
 
8079
<pre>
 
8080
Digital UNIX (v1.3)
 
8081
During the ntop 2.2 and 3.0 development cycles, Digital UNIX was not considered.
 
8082
</pre>
 
8083
 
 
8084
<pre>
 
8085
It will almost certainly fail.
 
8086
</pre>
 
8087
 
 
8088
<pre>
 
8089
AIX (v1.3)
 
8090
During the ntop 2.2 and 3.0 development cycles, AIX was not considered.
 
8091
</pre>
 
8092
 
 
8093
<pre>
 
8094
It will almost certainly fail.
 
8095
</pre>
 
8096
<h2>Libpng</h2>
 
8097
<br>
 
8098
<p>
 
8099
<b>Q.</b>&nbsp;
 
8100
 Bad things - I see the following messages:
 
8101
</p>
 
8102
<pre>
 
8103
        libpng warning: Application was compiled with png.h from libpng-1.0.x
 
8104
        libpng warning: Application is running with png.c from libpng-1.2.x 
 
8105
        gd-png: fatal libpng error: Incompatible libpng version in application
 
8106
              and library
 
8107
</pre>
 
8108
<p>
 
8109
<b>A.</b>&nbsp;
 
8110
 You have a version problem with libpng.
 
8111
</p>
 
8112
<p>
 
8113
   First off, following the instructions in BUILD-NTOP.txt should work just
 
8114
   fine. These problems come about when you have libpng installed (i.e. using
 
8115
   shared libraries).
 
8116
</p>
 
8117
<p>
 
8118
   1. If you are compiling from source, you may have png.h left over from the
 
8119
</p>
 
8120
<pre>
 
8121
      earlier version of libpng. Remove it.
 
8122
</pre>
 
8123
<p>
 
8124
   2. (Most common under RedHat). RedHat 7.2 installs a libgd.so.1.8.4 library,
 
8125
</p>
 
8126
<pre>
 
8127
       which was compiled against 1.0.x series of libpng (which is fine, because
 
8128
       RedHat 7.2 includes libpng-1.0.12).
 
8129
</pre>
 
8130
<p>
 
8131
   Updating RedHat to newer (RawHide) packages for libpng,
 
8132
   http://www.rpmfind.net//linux/RPM/rawhide/1.0/i386/RedHat/RPMS/libpng-1.2.2-5.i386.html,
 
8133
   should work. However, there are reports of version conflicts and required
 
8134
   updates to multiple packages. Proceed with caution (especially if you decide
 
8135
   to uninstall 1.2.2-5).
 
8136
   Also, do not use --nodeps or --force, as this can leave you with two
 
8137
   partially installed versions (see item #1, above).
 
8138
</p>
 
8139
<p>
 
8140
   3. (Slackware) Users have reported this error from an older header file in
 
8141
</p>
 
8142
<pre>
 
8143
      /usr/include.
 
8144
   Make sure to run "make install" in the libpng directory so that the latest
 
8145
   files are in the common library locations. You can do this with buildAll.sh,
 
8146
   just navigate back down to the libpng-1.2.x directory first.
 
8147
</pre>
 
8148
<p>
 
8149
   4. If you are building ntop on one machine and running on another, they may
 
8150
</p>
 
8151
<pre>
 
8152
      have different libpng.so versions.  Even if you think you are using the
 
8153
      static linked version (buildAll.sh), be careful - see the entry (above) on
 
8154
      "make install" for libpng.
 
8155
</pre>
 
8156
<br>
 
8157
<p>
 
8158
<b>Q.</b>&nbsp;
 
8159
 When I run ./configure, it finds png.h but not libpng:
 
8160
</p>
 
8161
<pre>
 
8162
      *******************************************************************
 
8163
      *
 
8164
      * ERROR: libpng header or library routines are missing
 
8165
      *           (yes means it was found, no means it was not found)
 
8166
      *
 
8167
      *              png.h...yes
 
8168
      *              png_read_info() in -lpng...
 
8169
      *
 
8170
      *>>> No way to proceed.
 
8171
      *
 
8172
      *???        Install libpng (and/or libpng-devel), check www.libpng.org
 
8173
      *???    and Rerun ./configure
 
8174
      *
 
8175
      *******************************************************************
 
8176
</pre>
 
8177
<p>
 
8178
<b>A.</b>&nbsp;
 
8179
 You're missing libpng.so. Look for it (locate libpng) and tell ntop
 
8180
   where it is via the --with-png-lib= parameter.
 
8181
</p>
 
8182
<br>
 
8183
<p>
 
8184
<b>Q.</b>&nbsp;
 
8185
 I seem to be missing libpng.so - when I do locate libpng, it finds:
 
8186
</p>
 
8187
<pre>
 
8188
      /usr/lib/libpng.so.3
 
8189
      /usr/lib/libpng.so.3.1.2.2
 
8190
      /usr/lib/libpng12.so.0
 
8191
      /usr/lib/libpng12.so.0.1.2.2
 
8192
      /usr/lib/libpng.so.2.1.0.13
 
8193
   but no libpng.so...
 
8194
</pre>
 
8195
<p>
 
8196
<b>A.</b>&nbsp;
 
8197
 Yeah. Send RedHat a nasty gram.
 
8198
</p>
 
8199
<br>
 
8200
<p>
 
8201
<b>Q.</b>&nbsp;
 
8202
 I don't understand...
 
8203
</p>
 
8204
<p>
 
8205
<b>A.</b>&nbsp;
 
8206
 In a normal libpng install, say from the source, you would have - in
 
8207
   addition to the .so.n.n.n.n files - a symlink named libpng.so, like this:
 
8208
</p>
 
8209
 
 
8210
<pre>
 
8211
      lrwxrwxrwx 1 root  root   19 Apr 23 15:46 libpng.so -> libpng12.so.0.1.2.2
 
8212
</pre>
 
8213
<p>
 
8214
   But, that link seems to be missing.  Without it, -lpng doesn't properly
 
8215
   resolve and you get the ./configure error.
 
8216
</p>
 
8217
<br>
 
8218
<p>
 
8219
<b>Q.</b>&nbsp;
 
8220
 Why?
 
8221
</p>
 
8222
<p>
 
8223
<b>A.</b>&nbsp;
 
8224
 RedHat ships Linux with both versions of libpng, a 1.0.x and a 1.2.x version.
 
8225
</p>
 
8226
<p>
 
8227
   Do this:
 
8228
</p>
 
8229
 
 
8230
<pre>
 
8231
      $ rpm -qa | grep libpng
 
8232
</pre>
 
8233
<p>
 
8234
   And you'll see the libpng 1.0.x run time:
 
8235
</p>
 
8236
 
 
8237
<pre>
 
8238
      libpng-1.2.2-8
 
8239
      libpng-devel-1.2.2-8
 
8240
      libpng10-1.0.13-6
 
8241
</pre>
 
8242
<p>
 
8243
   Dig into the files installed by them and you'll not find libpng.so.
 
8244
</p>
 
8245
<p>
 
8246
   Since they're incompatible RedHat doesn't create the libpng.so link.
 
8247
   Instead they patch the makefiles to point the various packages at one or the
 
8248
   other .so file they install.  This allows them to ship packages that require
 
8249
   one or the other.
 
8250
</p>
 
8251
<p>
 
8252
   It works fine unless you try and install something other than via an rpm.
 
8253
   Then you're missing the libpng.so file that normal packages look for...
 
8254
</p>
 
8255
<p>
 
8256
   Best bet is to create a symbolic link from the libpng.so.xxxx installed 
 
8257
   by the package which matches the -devel (because that's where png.h is 
 
8258
   found), e.g.:
 
8259
</p>
 
8260
<p>
 
8261
   ln -s /usr/lib/libpng.so.3.1.2.2 /usr/lib/libpng.so
 
8262
</p>
 
8263
<p>
 
8264
   And remember this in case you update the libpng rpm's in the future.
 
8265
</p>
 
8266
<h2>Silly Season</h2>
 
8267
<br>
 
8268
<p>
 
8269
<b>Q.</b>&nbsp;
 
8270
 Who is Pixel
 
8271
</p>
 
8272
<p>
 
8273
<b>A.</b>&nbsp;
 
8274
 My cat.
 
8275
</p>
 
8276
<h2>HowTo Ask For Help (ntop mailing lists)</h2>
 
8277
 
 
8278
<pre>
 
8279
WTO ask for help on the ntop or ntop-dev mailing lists:
 
8280
</pre>
 
8281
 
 
8282
<pre>
 
8283
WHERE TO POST
 
8284
</pre>
 
8285
 
 
8286
<pre>
 
8287
ntop is for user questions - "How to I install", "data isn't being recorded",
 
8288
etc.
 
8289
</pre>
 
8290
 
 
8291
<pre>
 
8292
ntop-dev is for code and development questions.  The ntop-dev list goes to fewer
 
8293
people, those who have self-selected themselves to be interested in ntop at the
 
8294
code level.
 
8295
</pre>
 
8296
 
 
8297
<pre>
 
8298
Discussions about the current cvs version belong in ntop-dev.
 
8299
</pre>
 
8300
 
 
8301
<pre>
 
8302
If a discussion gets too technical, you may be asked to "move it to ntop-dev".
 
8303
Please honor that request (even if you have to subscribe for a while - ntop-dev
 
8304
is fairly low traffic).
 
8305
</pre>
 
8306
 
 
8307
<pre>
 
8308
There used to be mailing lists and trackers at SourceForge, which were rarely
 
8309
looked at and have been discontinued. Use the ntop and ntop-dev lists (go to
 
8310
http://www.ntop.org to signup for them).
 
8311
</pre>
 
8312
 
 
8313
<pre>
 
8314
OFFICIAL vs UNOFFICIAL
 
8315
</pre>
 
8316
 
 
8317
<pre>
 
8318
A response from Luca Deri should be considered official.  He is the author of
 
8319
ntop and controls the project and it's destiny.
 
8320
</pre>
 
8321
 
 
8322
<pre>
 
8323
***Please understand that the mailing lists are a community support effort***
 
8324
</pre>
 
8325
 
 
8326
<pre>
 
8327
Besides Luca Deri, a number of people answer questions to the best of our
 
8328
ability. None of the rest of the people who may respond to your question on ntop
 
8329
or ntop-dev are able to respond "officially".
 
8330
</pre>
 
8331
 
 
8332
<pre>
 
8333
Likewise, this HOWTO is unofficial.
 
8334
</pre>
 
8335
 
 
8336
<pre>
 
8337
Everyone is welcome to help with the evolution of ntop - that is to find
 
8338
problems, create and test patches and send them in to patches@ntop.org for
 
8339
inclusion.  There are a small number of people with write access to the cvs,
 
8340
but anything we commit is subject to being ripped out by Luca for any reason...
 
8341
or no reason at all...
 
8342
</pre>
 
8343
 
 
8344
<pre>
 
8345
QUESTION FORMATS
 
8346
</pre>
 
8347
 
 
8348
<pre>
 
8349
ONE QUESTION per message, and you MUST use meaningful message subjects - one's
 
8350
that would have helped YOU find the prior discussion of this or a similar
 
8351
problem in the archives.  Titles such as "urgent" or "ntop problem" will often
 
8352
not get a response - it may be urgent to you but it's probably not an issue
 
8353
for others.
 
8354
</pre>
 
8355
 
 
8356
<pre>
 
8357
WE STRONGLY SUGGEST YOU USE THE BUILT IN AUTOMATICALLY GENERATED PROBLEM
 
8358
REPORT (About | "bug icon").  This includes most of the internal configuration
 
8359
data we ask for (and more) and has blank spots for you to fill it.
 
8360
</pre>
 
8361
 
 
8362
<pre>
 
8363
Generate one, cut & paste into your mail client, edit the data and sent it.
 
8364
</pre>
 
8365
 
 
8366
<pre>
 
8367
Beyond that, don't worry -- it's about information, not format.
 
8368
</pre>
 
8369
 
 
8370
<pre>
 
8371
RESPONSES
 
8372
</pre>
 
8373
 
 
8374
<pre>
 
8375
Despite any individual's frequent postings, nobody is "responsible" for
 
8376
answering your question. It's all on a "best efforts" basis. This is equally
 
8377
true of the entries in ntop's Wiki. Our responses may be incomplete, inaccurate,
 
8378
even dead wrong. Caveat Emptor! The only "guarantee" is that free support will 
 
8379
be worth what you've paid for it.  It may be worth MORE, it won't be worth
 
8380
LESS.
 
8381
</pre>
 
8382
 
 
8383
<pre>
 
8384
Just because you post a question does NOT mean that you are OWED an answer.
 
8385
</pre>
 
8386
 
 
8387
<pre>
 
8388
If nobody answers, then maybe it's because:
 
8389
</pre>
 
8390
<p>
 
8391
   * Nobody knows.
 
8392
   * People are busy.
 
8393
   * You've asked the same question multiple times and it's already been
 
8394
</p>
 
8395
<pre>
 
8396
     answered.
 
8397
   * You have been asked for additional information and are unable/unwilling
 
8398
     to supply it.
 
8399
</pre>
 
8400
 
 
8401
<pre>
 
8402
or, well, any one of a dozen other reasons.
 
8403
</pre>
 
8404
 
 
8405
<pre>
 
8406
Asking the same question multiple times - or asking it again because you don't
 
8407
like the answer you received - is a slap in the face of the person who took the
 
8408
time to answer you in the first place and will more than likely not get a
 
8409
different response.  If you're not sure that your message posted, check the
 
8410
archives to see if your message is there -- please don't just keep reposting it.
 
8411
</pre>
 
8412
 
 
8413
<pre>
 
8414
You can always use gmane (http://www.gmane.org) to see the last 600 or so
 
8415
postings to the lists.
 
8416
</pre>
 
8417
 
 
8418
<pre>
 
8419
Please direct all original postings and subsequent replies to the list, not to
 
8420
someone privately.  Most of us will reply solely to the mailing list, unless
 
8421
you specifically request otherwise.  If you do request otherwise, the individual
 
8422
you sent it to may choose not to respond.  Our posting here is NOT a public
 
8423
invitation to invade our e-mail boxes for your free private support.
 
8424
</pre>
 
8425
 
 
8426
<pre>
 
8427
THE BACK AND FORTH PROCESS
 
8428
</pre>
 
8429
 
 
8430
<pre>
 
8431
"Why don't you just fix my problem instead of asking for more information?"
 
8432
</pre>
 
8433
 
 
8434
<pre>
 
8435
Understand that we can't see your machine (and wouldn't want the
 
8436
responsibility of sshing into somebody else's box as root).  The only
 
8437
information we have is what you post and the responses to our questions.  Few
 
8438
failures in ntop are related to the core processing routines - so if you're
 
8439
having a problem, it's most likely because of some combination of your network
 
8440
and your ntop configuration.  It may be unique to you -- and only with YOUR help
 
8441
can it be resolved.
 
8442
</pre>
 
8443
 
 
8444
<pre>
 
8445
WHAT IS SUPPORTED?
 
8446
</pre>
 
8447
 
 
8448
<pre>
 
8449
Releases are hosted at SourceForge.
 
8450
</pre>
 
8451
 
 
8452
<pre>
 
8453
At the time of this writing the stable version is 3.0. What support is available
 
8454
is for the development version ("the cvs").  All support is in the form of
 
8455
fixing things in the cvs.
 
8456
</pre>
 
8457
 
 
8458
<pre>
 
8459
However we also attempt to support the current "stable" release (3.0).
 
8460
</pre>
 
8461
 
 
8462
<pre>
 
8463
Older versions are not supported -- especially 1.3 and the 2.0.99 series of
 
8464
2.1 release candidates.  If you have a problem with them, please obtain the
 
8465
current cvs version and see if it's still a problem.  Unlike certain much larger
 
8466
projects, we don't fix things in older versions - there simply aren't enough
 
8467
resources available.
 
8468
</pre>
 
8469
 
 
8470
<pre>
 
8471
intop is not supported.  It's gone and no longer in the cvs.  For a look at
 
8472
Rocco's new, work-in-progress, download ntcsh, the ntop enabled tcsh shell.
 
8473
</pre>
 
8474
 
 
8475
<pre>
 
8476
Please understand that the only way to fix your problem may be a source patch,
 
8477
which you will have to apply, compile, install and test against the cvs version
 
8478
prior to it's inclusion in the cvs.
 
8479
</pre>
 
8480
 
 
8481
<pre>
 
8482
If you aren't capable of or willing to do these steps -- for whatever reason --
 
8483
then you should not be compiling from the cvs.
 
8484
</pre>
 
8485
 
 
8486
<pre>
 
8487
CVS
 
8488
</pre>
 
8489
 
 
8490
<pre>
 
8491
The cvs is at http://cvs.ntop.org, userid is anonymous, password ntop.
 
8492
</pre>
 
8493
 
 
8494
<pre>
 
8495
The cvs is a DEVELOPMENT version.  The code in the cvs is subject to rapid
 
8496
change.  At any point in time, it may not compile.  It may not compile with
 
8497
certain options or on some platforms. s'be'it -- it's a DEVELOPMENT version.
 
8498
</pre>
 
8499
 
 
8500
<pre>
 
8501
2.1.3
 
8502
</pre>
 
8503
 
 
8504
<pre>
 
8505
The actual flow of ntop development was 
 
8506
    2.1 -> 2.1.1 -> 2.1.2 -> 2.1.50 -> 2.1.51...
 
8507
</pre>
 
8508
 
 
8509
<pre>
 
8510
Version 2.1.3 was provided by Dennis Schoen [ds@teuto.net] as part of the Debian
 
8511
project.  Dennis (manually) maintains a bitkeeper tree, based on 2.1.2 with
 
8512
various patches which - in HIS opinion - were important enough to be back
 
8513
ported.  Releases in this tree are identified as 2.1.2-n.  Dennis reports you
 
8514
can obtain his current version via:
 
8515
</pre>
 
8516
 
 
8517
<pre>
 
8518
bk clone bk://ntop.teuto.net:ntop-debian ntop-stable
 
8519
</pre>
 
8520
 
 
8521
<pre>
 
8522
Version 2.1.3 is an export from Dennis' tree with the version number changed and
 
8523
is equivalent to 2.1.2-1.  Dennis' graciously provided the extract and we
 
8524
accepted with thanks!
 
8525
</pre>
 
8526
 
 
8527
<pre>
 
8528
2.2
 
8529
</pre>
 
8530
 
 
8531
<pre>
 
8532
The actual flow of ntop development was 2.1 -> 2.1.1 -> 2.1.2 -> 2.1.50
 
8533
                                     -> 2.1.51..59 -> 2.1.90..92 -> 2.2
 
8534
</pre>
 
8535
<p>
 
8536
   after 2.2, came 2.2a/2.2b (Win32 only), then 2.2c.  These were branches,
 
8537
   containing unique 2.2 fixes and back-ports of some critical items.
 
8538
</p>
 
8539
 
 
8540
<pre>
 
8541
3.0
 
8542
</pre>
 
8543
 
 
8544
<pre>
 
8545
The actual flow of ntop development was 2.2.1..4 ->
 
8546
                                    -> 2.2.90..99 -> 3.0pre1 -> 3.0
 
8547
</pre>
 
8548
 
 
8549
<pre>
 
8550
FEE-BASED SUPPORT
 
8551
</pre>
 
8552
 
 
8553
<pre>
 
8554
If you want better than "best-efforts" support, contact the individual you
 
8555
Desire support from off-list to make financial arrangements.  Please understand
 
8556
that people are doing development in areas that are of personal interest to
 
8557
them, to improve ntop.
 
8558
If you want to discuss payment for support or a specific change that is of
 
8559
Interest to you, feel free to email the individual off-list - some of us are
 
8560
Computer consultants and can be bought, with the understanding that the work
 
8561
product is offered back to the community in the spirit of the open source
 
8562
movement and the strictures of the GPL.
 
8563
</pre>
 
8564
 
 
8565
<pre>
 
8566
SO WHAT INFORMATION SHOULD I POST?
 
8567
</pre>
 
8568
 
 
8569
<pre>
 
8570
BEFORE POSTING:
 
8571
</pre>
 
8572
 
 
8573
<pre>
 
8574
1. Please review the output from ./configure.
 
8575
</pre>
 
8576
 
 
8577
<pre>
 
8578
    We all have the bad habit of skipping over this, but there are often
 
8579
    warnings which explain why things don't work.  ntop tries to build itself by
 
8580
    turning off features where the required libraries and/or headers aren't
 
8581
    available.
 
8582
    The minimum required set is just that - minimal.  This is often the source
 
8583
    of "feature x or switch y doesn't work" reports.
 
8584
</pre>
 
8585
 
 
8586
<pre>
 
8587
2. Please review the docs/FAQ file.
 
8588
</pre>
 
8589
 
 
8590
<pre>
 
8591
3. Please review back message traffic from the mailing lists.
 
8592
</pre>
 
8593
 
 
8594
<pre>
 
8595
     Yes, we know that there isn't a search function at ntop.org.  Did you know
 
8596
     that the lists are spidered every couple of months or so and can be
 
8597
     searched through Google??  For example, "site:lists.ntop.org rpm" will find
 
8598
     mail list messages with the word "rpm" in them.
 
8599
</pre>
 
8600
 
 
8601
<pre>
 
8602
     Do you know about gmane (http://www.gmane.org) has archives (searchable) of
 
8603
     the ntop lists going back into late 2001.  The lists are called
 
8604
</pre>
 
8605
 
 
8606
<pre>
 
8607
          gmane.linux.ntop.devel
 
8608
          gmane.linux.ntop.general
 
8609
</pre>
 
8610
 
 
8611
<pre>
 
8612
     You can read these online (the last 600 messages or so) or through the nntp
 
8613
     server.
 
8614
</pre>
 
8615
 
 
8616
<pre>
 
8617
POSTING:
 
8618
</pre>
 
8619
 
 
8620
<pre>
 
8621
Do not worry about posting TOO much information - we're pretty good at filtering
 
8622
out the noise.
 
8623
</pre>
 
8624
 
 
8625
<pre>
 
8626
WE STRONGLY SUGGEST YOU USE THE BUILT IN AUTOMATICALLY GENERATED PROBLEM
 
8627
REPORT (About | "bug icon").  This includes most of the internal configuration
 
8628
data we ask for (and more) and has blank spots for you to fill it.
 
8629
</pre>
 
8630
 
 
8631
<pre>
 
8632
Generate one, cut & paste into your mail client, edit the data and sent it.
 
8633
</pre>
 
8634
 
 
8635
<pre>
 
8636
If you can't or won't use the automated problem report (say, for example you
 
8637
can't get ntop up to generate it) - don't worry -- it's about information, not
 
8638
format.  Send us what you can, organized this way:
 
8639
</pre>
 
8640
 
 
8641
<pre>
 
8642
1. A brief summary of the problem.
 
8643
</pre>
 
8644
 
 
8645
<pre>
 
8646
2. Operations
 
8647
     The EXACT command line you use to invoke ntop.
 
8648
          If it's in a script, cut & paste it and
 
8649
          resolve all the variables!
 
8650
</pre>
 
8651
 
 
8652
<pre>
 
8653
     Error Messages:  Cut & paste the exact text.
 
8654
          If it's in the log, give us 15 or 20 lines before.
 
8655
</pre>
 
8656
 
 
8657
<pre>
 
8658
     The exact URL you used from the browser.
 
8659
</pre>
 
8660
 
 
8661
<pre>
 
8662
3.  Software
 
8663
     ntop version, source and any applied patches
 
8664
</pre>
 
8665
 
 
8666
<pre>
 
8667
            If you've compiled from the source, say so!
 
8668
</pre>
 
8669
 
 
8670
<pre>
 
8671
            If you're using a package (such as an .rpm), where
 
8672
                did you get it from and what is the EXACT name,
 
8673
                version information and date? (for example, post
 
8674
                the output from rpm -q ntop -i)
 
8675
</pre>
 
8676
 
 
8677
<pre>
 
8678
     OS vendor & version
 
8679
</pre>
 
8680
 
 
8681
<pre>
 
8682
     gcc version (e.g. gcc --version)
 
8683
       (For ./configure problems, the versions for autoconf, automake and
 
8684
        libtool too)
 
8685
</pre>
 
8686
 
 
8687
<pre>
 
8688
     glibc version
 
8689
</pre>
 
8690
 
 
8691
<pre>
 
8692
     Any major upgrades (kernel, networking, etc.)
 
8693
</pre>
 
8694
 
 
8695
<pre>
 
8696
     What else is running
 
8697
</pre>
 
8698
 
 
8699
<pre>
 
8700
4. Hardware
 
8701
     Type & # of processors
 
8702
</pre>
 
8703
 
 
8704
<pre>
 
8705
     Amount of memory
 
8706
</pre>
 
8707
 
 
8708
<pre>
 
8709
     # network interfaces and types (vendor, bus, etc.)
 
8710
</pre>
 
8711
 
 
8712
<pre>
 
8713
5.  Network
 
8714
     Roughly where are the interface(s) you're monitoring
 
8715
          (Public Internet, Private LAN, what?)
 
8716
</pre>
 
8717
 
 
8718
<pre>
 
8719
     What's the bandwidth (e.g. 10 Mbps University internet,
 
8720
           1.5 Mbps T1, Cable Modem capped at 1.5Mbps, 56K dialup)
 
8721
</pre>
 
8722
 
 
8723
<pre>
 
8724
     How many machines (traffic sources/destinations) and users
 
8725
</pre>
 
8726
 
 
8727
<pre>
 
8728
(If you're uncomfortable giving specifics, then leave it generic, but the
 
8729
information is necessary to allow efficient use of the community's time helping
 
8730
YOU with YOUR problem)
 
8731
</pre>
 
8732
 
 
8733
<pre>
 
8734
AFTER POSTING:
 
8735
</pre>
 
8736
 
 
8737
<pre>
 
8738
Please let us know if our help fixed the problem, didn't solve it or enabled you
 
8739
to solve it yourself and what the result was.  The historical record of the ntop
 
8740
and ntop-dev archives is the complete chain from problem to resolution.
 
8741
</pre>
 
8742
 
 
8743
<pre>
 
8744
(Originally posted on 07Jan2002 to ntop and ntop-dev, updated.  This is version 12April2003)
 
8745
</pre>
 
8746
<h2>GDB ultraMini-tutorial - Running ntop under gdb (debugger)</h2>
 
8747
 
 
8748
<pre>
 
8749
The very best way to debug a segmentation fault in ntop is to use gdb. The
 
8750
Standard ntop compile already has the flags necessary to do this set.
 
8751
</pre>
 
8752
 
 
8753
<pre>
 
8754
(Note - if you don't have gdb, or aren't compiling yourself, this won't work)
 
8755
</pre>
 
8756
 
 
8757
<pre>
 
8758
> gdb /usr/bin/ntop (or wherever ntop is installed)
 
8759
...
 
8760
(gdb) set args (your usual arg string) -K
 
8761
</pre>
 
8762
 
 
8763
<pre>
 
8764
[That is, add the -K argument. While you are at it, don't give it the -d
 
8765
argument and add -u root (replace any existing -u value) - yes, it's insecure
 
8766
running as root, but you're not planning on doing this in production nor as a
 
8767
routine situation!]
 
8768
</pre>
 
8769
 
 
8770
<pre>
 
8771
it will run... when it bombs...
 
8772
</pre>
 
8773
 
 
8774
<pre>
 
8775
(gdb) list [this shows where in the code it died]
 
8776
</pre>
 
8777
 
 
8778
<pre>
 
8779
(gdb) info stack [this shows the call stack]
 
8780
</pre>
 
8781
 
 
8782
<pre>
 
8783
if there are any variables involved, you can print them:
 
8784
</pre>
 
8785
 
 
8786
<pre>
 
8787
(gdb) print deviceId
 
8788
</pre>
 
8789
 
 
8790
<pre>
 
8791
[gdb can handle pretty complex arguments in the print command, so you can say
 
8792
"print myGlobals.device[0].hash_hostTraffic[myGlobals.broadcastEntryIdx]"
 
8793
if that's what it bombed on.]
 
8794
</pre>
 
8795
 
 
8796
<pre>
 
8797
"bt full" does a decent job of printing the stack and the back trace and the
 
8798
local variables at each level. Just make sure you are in the thread you are
 
8799
interested in:
 
8800
</pre>
 
8801
 
 
8802
<pre>
 
8803
(gdb) bt full
 
8804
#0 0x40592557 in __libc_pause () from /lib/i686/libc.so.6
 
8805
No locals.
 
8806
#1 0x4046b5a3 in pause () at wrapsyscall.c:123
 
8807
result = -1073743680
 
8808
oldtype = 0
 
8809
#2 0x0804ac1b in main (argc=22, argv=0xbffffa44) at main.c:928
 
8810
argc = -1073743680
 
8811
argv = (char **) 0x0
 
8812
i = 0
 
8813
userSpecified = 1
 
8814
ifStr = "eth0,eth1", '\000' 
 
8815
lastTime = 1025633918
 
8816
#3 0x404f3647 in __libc_start_main (main=0x804a74c , argc=22, ubp_av=0xbffffa44,
 
8817
init=0x8049600 <_init>, fini=0x804d000 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
 
8818
stack_end=0xbffffa3c) at ../sysdeps/generic/libc-start.c:129
 
8819
ubp_av = (char **) 0xbffffa44
 
8820
fini = (void (*)()) 0x40016b4c <_dl_debug_mask>
 
8821
rtld_fini = (void (*)()) 0xbffff87c
 
8822
ubp_ev = (char **) 0xbffffaa0
 
8823
(gdb)
 
8824
</pre>
 
8825
 
 
8826
<pre>
 
8827
gdb has all kinds of included help, and frankly that's all I know...
 
8828
Here are some extracts and examples:
 
8829
</pre>
 
8830
 
 
8831
<pre>
 
8832
(gdb) help info thread
 
8833
IDs of currently known threads.
 
8834
</pre>
 
8835
 
 
8836
<pre>
 
8837
(gdb) info thread
 
8838
  13 Thread 11276 (LWP 8967)  0x405f651e in __select () from
 
8839
/lib/i686/libc.so.6
 
8840
  12 Thread 10251 (LWP 8966)  0x405f651e in __select () from
 
8841
/lib/i686/libc.so.6
 
8842
  11 Thread 9226 (LWP 8965)  0x405f651e in __select () from
 
8843
/lib/i686/libc.so.6
 
8844
  10 Thread 8201 (LWP 8964)  0x405f651e in __select () from
 
8845
/lib/i686/libc.so.6
 
8846
  9 Thread 7176 (LWP 8963)  0x405f651e in __select () from
 
8847
/lib/i686/libc.so.6
 
8848
  8 Thread 6151 (LWP 8962)  0x405ca071 in __libc_nanosleep () from
 
8849
/lib/i686/libc.so.6
 
8850
  7 Thread 5126 (LWP 8961)  0x4053db85 in __sigsuspend (set=0x4300998c)
 
8851
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
 
8852
  6 Thread 4101 (LWP 8960)  0x405ca071 in __libc_nanosleep () from
 
8853
/lib/i686/libc.so.6
 
8854
  5 Thread 3076 (LWP 8959)  0x405ca071 in __libc_nanosleep () from
 
8855
/lib/i686/libc.so.6
 
8856
  4 Thread 2051 (LWP 8958)  0x405ca071 in __libc_nanosleep () from
 
8857
/lib/i686/libc.so.6
 
8858
  3 Thread 1026 (LWP 8957)  0x4053db85 in __sigsuspend (set=0x4100967c)
 
8859
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
 
8860
  2 Thread 2049 (LWP 8956)  0x405f4e17 in __poll (fds=0x823dbec, nfds=1,
 
8861
timeout=2000)
 
8862
    at ../sysdeps/unix/sysv/linux/poll.c:63
 
8863
* 1 Thread 1024 (LWP 8952)  0x405ca027 in __libc_pause () from
 
8864
/lib/i686/libc.so.6
 
8865
</pre>
 
8866
 
 
8867
<pre>
 
8868
The * indicates the current thread.  Switch with this:
 
8869
</pre>
 
8870
 
 
8871
<pre>
 
8872
(gdb) thread 7
 
8873
</pre>
 
8874
 
 
8875
<pre>
 
8876
Once you have a thread selected, you can look at the call stack:
 
8877
</pre>
 
8878
 
 
8879
<pre>
 
8880
(gdb) help stack
 
8881
Examining the stack.
 
8882
The stack is made up of stack frames.  Gdb assigns numbers to stack frames
 
8883
counting from zero for the innermost (currently executing) frame.
 
8884
</pre>
 
8885
 
 
8886
<pre>
 
8887
At any time gdb identifies one frame as the "selected" frame.
 
8888
Variable lookups are done with respect to the selected frame.
 
8889
When the program being debugged stops, gdb selects the innermost frame.
 
8890
The commands below can be used to select other frames by number or address.
 
8891
</pre>
 
8892
 
 
8893
<pre>
 
8894
List of commands:
 
8895
</pre>
 
8896
 
 
8897
<pre>
 
8898
backtrace -- Print backtrace of all stack frames
 
8899
bt -- Print backtrace of all stack frames
 
8900
down -- Select and print stack frame called by this one
 
8901
frame -- Select and print a stack frame
 
8902
return -- Make selected stack frame return to its caller
 
8903
select-frame -- Select a stack frame without printing anything
 
8904
up -- Select and print stack frame that called this one
 
8905
</pre>
 
8906
 
 
8907
<pre>
 
8908
Type "help" followed by command name for full documentation.
 
8909
Command name abbreviations are allowed if unambiguous.
 
8910
(gdb) info stack
 
8911
#0  0x4053db85 in __sigsuspend (set=0x4300998c) at
 
8912
../sysdeps/unix/sysv/linux/sigsuspend.c:45
 
8913
#1  0x404db1c9 in __pthread_wait_for_restart_signal (self=0x43009be0) at
 
8914
pthread.c:969
 
8915
#2  0x404dc1ec in __new_sem_wait (sem=0x804d5c8) at restart.h:34
 
8916
#3  0x402960e0 in waitSem (semId=0x804d5c8) at util.c:1126
 
8917
#4  0x4027ae0f in dequeueAddress (notUsed=0x0) at address.c:425
 
8918
#5  0x404d8c6f in pthread_start_thread (arg=0x43009be0) at manager.c:284
 
8919
</pre>
 
8920
 
 
8921
<pre>
 
8922
And select a specific frame via:
 
8923
</pre>
 
8924
 
 
8925
<pre>
 
8926
(gdb) select-frame 4
 
8927
</pre>
 
8928
 
 
8929
<pre>
 
8930
(gdb) help list
 
8931
List specified function or line.
 
8932
With no argument, lists ten more lines after or around previous listing.
 
8933
"list -" lists the ten lines before a previous ten-line listing.
 
8934
One argument specifies a line, and ten lines are listed around that line.
 
8935
Two arguments with comma between specify starting and ending lines to list.
 
8936
Lines can be specified in these ways:
 
8937
  LINENUM, to list around that line in current file,
 
8938
  FILE:LINENUM, to list around that line in that file,
 
8939
  FUNCTION, to list around beginning of that function,
 
8940
  FILE:FUNCTION, to distinguish among like-named static functions.
 
8941
  *ADDRESS, to list around the line containing that address.
 
8942
With two args if one is empty it stands for ten lines away from the other
 
8943
arg.
 
8944
(gdb) list address.c:425
 
8945
420
 
8946
421         while((myGlobals.addressQueueLen == 0)
 
8947
422               && (myGlobals.capturePackets) /* Courtesy of Wies-Software
 
8948
<wies@wiessoft.de> */
 
8949
423               ) {
 
8950
424     #ifdef USE_SEMAPHORES
 
8951
425           waitSem(&myGlobals.queueAddressSem);
 
8952
426     #else
 
8953
427           waitCondvar(&myGlobals.queueAddressCondvar);
 
8954
428     #endif
 
8955
429           key_data.dptr = data_data.dptr = NULL;
 
8956
</pre>
 
8957
 
 
8958
<pre>
 
8959
(gdb) help print
 
8960
Print value of expression EXP.
 
8961
Variables accessible are those of the lexical environment of the selected
 
8962
stack frame, plus all those whose scope is global or an entire file.
 
8963
</pre>
 
8964
 
 
8965
<pre>
 
8966
$NUM gets previous value number NUM.  $ and $$ are the last two values.
 
8967
$$NUM refers to NUM'th value back from the last one.
 
8968
Names starting with $ refer to registers (with the values they would have
 
8969
if the program were to return to the stack frame now selected, restoring
 
8970
all registers saved by frames farther in) or else to debugger
 
8971
"convenience" variables (any such name not a known register).
 
8972
Use assignment expressions to give values to convenience variables.
 
8973
</pre>
 
8974
 
 
8975
<pre>
 
8976
{TYPE}ADREXP refers to a datum of data type TYPE, located at address ADREXP.
 
8977
@ is a binary operator for treating consecutive data objects
 
8978
anywhere in memory as an array.  FOO@NUM gives an array whose first
 
8979
element is FOO, whose second element is stored in the space following
 
8980
where FOO is stored, etc.  FOO must be an expression whose value
 
8981
resides in memory.
 
8982
</pre>
 
8983
 
 
8984
<pre>
 
8985
EXP may be preceded with /FMT, where FMT is a format letter
 
8986
but no count or size letter (see "x" command).
 
8987
</pre>
 
8988
 
 
8989
<pre>
 
8990
(gdb) print key_data
 
8991
$3 = {dptr = 0x0, dsize = 1076452514}
 
8992
(gdb) print data_data
 
8993
$4 = {dptr = 0x0, dsize = 4}
 
8994
</pre>
 
8995
 
 
8996
<pre>
 
8997
Original version Luca Deri, 1999-2001
 
8998
Updated Burton M. Strauss III 2002, 2003, 2004
 
8999
</pre>
 
9000
<!-- Total Lines........  6121 -->
 
9001
 
 
9002
<!-- (skipped) --s......    75 -->
 
9003
<!-- (skipped) ==s......    16 -->
 
9004
<!-- (skipped) header...    50 -->
 
9005
<!-- empty ("").........  1697 -->
 
9006
<!-- empty (//).........     6 -->
 
9007
<!-- Sections...........     0 -->
 
9008
<!-- Q:.................   248 -->
 
9009
<!-- A:.................   256 -->
 
9010
<!-- Normal text........  2044 -->
 
9011
<!-- Preformatted text..  1693 -->
 
9012
<!-- Updated.xxmmmyyyy..     0 -->
 
9013
<!-- Added.xxmmmyyyy....     0 -->
 
9014
<!-- ...........TOTAL...  6085 -->
 
9015
</body>
 
9016
</html>