On Jul 31, 2011, at 11:50 AM, enrico wrote: > Hello Luca, > thank you for your reply. > i have found the problem.... > Since we are using ntop in a complex environment, many instances, many > interfaces, mirroring ports, many 'custom protocol', i have tried to do > the same test you did on /tmp. > > I worked with all the 3 versions and with different users (root, nobody, > ntop) > So i have tried to disable each option (one by one) in @filename > and try to read the dump files. > It works every time except when i'm using > (-d | --daemon) > > we were always starting/stopping ntop with a script and put it in > background, logging in syslog, and killing it with "killall ntop" or > simply by killing the father process. > > Do you recommend running ntop in a dedicated machine not as daemon? It's not really necessary unless you want to insulate ntop from the outside environment > > we are using this script > http://www.slackers.it/repository/ntop/src/rc.ntop > and we put in line 39 our parameters @filename and -p @protocols.list > it looks fine to me
> > oh, another thing, but it is offtopic... > why the ./configure script in dev. versions cannot recognize many options > like --disable-ipv6 --disable-mysql --enable-snmp --enable-fc --enable- > sslv3 --enable-jumbo-frames....?? My goal is actually to remove options. In 4.1 SVN I have already harvested some of them. This is to simplify the code. Luca > > thank you! > > > On Wed, 27 Jul 2011 07:48:39 +0200, Luca Deri wrote: > >> Enrico >> I have just done a test using the SVN code with/without PF_RING. THis is >> the outcome >> >> root@i7:/home/deri/ntop# ./ntop -q -P /tmp -O /tmp -t 6 -i eth1 Wed Jul >> 27 07:45:29 2011 NOTE: Interface merge enabled by default Wed Jul 27 >> 07:45:29 2011 [globals-core.c:83] Initializing gdbm databases Wed Jul >> 27 07:45:29 2011 [initialize.c:557] Opening database >> '/tmp/prefsCache.db' Wed Jul 27 07:45:29 2011 [initialize.c:557] >> Opening database '/tmp/ntop_pw.db' Wed Jul 27 07:45:29 2011 >> [prefs.c:239] NOTE: Reading preferences file entries Wed Jul 27 07:45:29 >> 2011 [prefs.c:345] NOTE: Processing parameters (pass2) Wed Jul 27 >> 07:45:29 2011 [prefs.c:828] ntop will be started as user nobody Wed Jul >> 27 07:45:29 2011 [main.c:578] ntop v.4.1.0 (64 bit) Wed Jul 27 07:45:29 >> 2011 [main.c:579] Configured on Jul 20 2011 12:40:18, built on Jul 20 >> 2011 12:40:52. Wed Jul 27 07:45:29 2011 [main.c:580] Copyright >> 1998-2011 by Luca Deri <[email protected]> Wed Jul 27 07:45:29 2011 >> [main.c:581] Get the freshest ntop from http://www.ntop.org/ Wed Jul 27 >> 07:45:29 2011 [main.c:585] NOTE: ntop is running from >> '/home/deri/ntop/.libs' Wed Jul 27 07:45:29 2011 [main.c:586] NOTE: >> (but see warning on man page for the --instance parameter) Wed Jul 27 >> 07:45:29 2011 [main.c:594] Initializing ntop Wed Jul 27 07:45:29 2011 >> [initialize.c:114] Initializing IP services Wed Jul 27 07:45:29 2011 >> [initialize.c:1078] Initializing network devices [eth1] Wed Jul 27 >> 07:45:30 2011 [initialize.c:1128] Found interface [index=0] 'eth0' Wed >> Jul 27 07:45:30 2011 [initialize.c:1128] Found interface [index=1] >> 'eth1' Wed Jul 27 07:45:30 2011 [initialize.c:1128] Found interface >> [index=2] 'usbmon1' Wed Jul 27 07:45:30 2011 [initialize.c:1128] Found >> interface [index=3] 'usbmon2' Wed Jul 27 07:45:30 2011 >> [initialize.c:1128] Found interface [index=4] 'any' Wed Jul 27 07:45:30 >> 2011 [initialize.c:1128] Found interface [index=5] 'lo' Wed Jul 27 >> 07:45:30 2011 [initialize.c:1184] Checking requested device 'eth1' Wed >> Jul 27 07:45:30 2011 [initialize.c:742] Adding network device eth1 Wed >> Jul 27 07:45:30 2011 [initialize.c:880] Saving packets into file >> /tmp/ntop-suspicious-pkts.deveth1.pcap ... >> root@i7:/home/deri/ntop# tcpdump -n -r >> /tmp/ntop-suspicious-pkts.deveth1.pcap reading from file >> /tmp/ntop-suspicious-pkts.deveth1.pcap, link-type EN10MB (Ethernet) >> 07:45:30.689929 IP 146.48.125.130 > 146.48.125.125: ICMP 146.48.125.130 >> udp port 514 unreachable, length 405 07:45:30.689929 IP 146.48.125.130 > >> 146.48.125.125: ICMP 146.48.125.130 udp port 514 unreachable, length 405 >> 07:45:31.697153 IP 146.48.125.130 > 146.48.125.125: ICMP 146.48.125.130 >> udp port 514 unreachable, length 407 07:45:31.697153 IP 146.48.125.130 > >> 146.48.125.125: ICMP 146.48.125.130 udp port 514 unreachable, length 407 >> 07:45:32.693054 IP 146.48.125.130 > 146.48.125.125: ICMP 146.48.125.130 >> udp port 514 unreachable, length 409 07:45:32.693054 IP 146.48.125.130 > >> 146.48.125.125: ICMP 146.48.125.130 udp port 514 unreachable, length 409 >> >> I am not sure I understand your problem >> >> Luca >> >> >> On Jul 25, 2011, at 12:41 PM, Enrico Papi wrote: >> >>> i just want to specify that in my case i am not using 'pf_ring' >>> >>> thank you in advance for your support. >>> >>> Enrico. >>> >>> >>> On 07/25/2011 11:44 AM, Enrico Papi wrote: >>>> Hello, >>>> >>>> i'm using 3 versions of Ntop (4.0.3, svn-4735, svn-4742) and my libcap >>>> version is 1.1.1 >>>> >>>> I have the same problem reported in this topic when i try to open with >>>> tcpdump or wireshark the files saved with ntop (suspicious and >>>> 'other') >>>> >>>> >>>> "reading from file ntop-other-pkts.vlan.pcap, link-type EN10MB >>>> (Ethernet) -11:-46:-20.262 [|ether] >>>> tcpdump: pcap_loop: bogus savefile header " >>>> >>>> this problem happens in all the 3 versions. i have tried also to open >>>> the files after shutting down properly ntop but i have the same error >>>> in all the 3 versions. all the other features of ntop are working very >>>> well but i can't debug this error since i nothing related is written >>>> on the syslog. >>>> >>>> i think it could be related to the size of these pcap files, that >>>> should be lower than a max value. but it happens also with files < >>>> 1000K >>>> >>>> anyone who have some suggestions? >>>> >>>> >>>> >>>> >>>> On Tue, 08 Mar 2011 00:45:09 -0800, M. V. wrote: >>>> >>>>> hi, >>>>> >>>>> in order to boost capturing performance, i installed PF-Ring for >>>>> libpcap on Debian-6.0 using the link below. i got latest version of >>>>> pf-ring from svn, and recompiled my intel-card's driver to support >>>>> pf_ring. i didn't get any error or problem during the process. >>>>> >>>>> http://www.ntop.org/blog/?p=125 >>>>> >>>>> now, when i use tcpdump which is compiled with libpcap-pf_ring to >>>>> capture traffic, it captures with no error or warning and it seems >>>>> that my capturing performance got better (based on capture-file >>>>> size), but the problem is: >>>>> >>>>> when i open captured file with wireshark or tcpdump itself, i got a >>>>> weird error about bad packets size. >>>>> >>>>> wireshark error: >>>>> ---------------------- >>>>> The capture file appears to be damaged or corrupt. (pcap: File has >>>>> 3014350264-byte packet, bigger than maximum of 65535) >>>>> >>>>> tcpdump error: >>>>> -------------------- >>>>> tcpdump: pcap_loop: bogus savefile header >>>>> >>>>> i don't know what is the problem, so i wanted to ask if anyone has >>>>> experienced this before or has any idea about it. >>>>> >>>>> thank you. >>>>> >>>>> >>>>> >>>>> <html><head><style type="text/css"><!-- DIV {margin:0px;} >>>>> --></style></head><body><div style="font-family:times new roman,new >>>>> york,times,serif;font-size:12pt"><div><div>hi,<br> <br> >>>>> in order to boost capturing performance, i installed PF-Ring for >>>>> libpcap on Debian-6.0 using the link below. i got latest version of >>>>> pf-ring from svn, and recompiled my intel-card's driver to support >>>>> pf_ring. i didn't get any error or problem during the >>>>> process.<br><br> <a >>>>> href="http://www.ntop.org/blog/?p=125";>http://www.ntop.org/blog/? > p=125</ >>>> a><br><br> >>>>> now, when i use tcpdump which is compiled with libpcap-pf_ring to >>>>> capture traffic, it captures with no error or warning and it seems >>>>> that my capturing performance got better (based on capture-file >>>>> size), but the problem is:<br> >>>>> <br> >>>>> when i open captured file with wireshark or tcpdump itself, i got a >>>>> weird error about bad packets size.<br> <br> wireshark error:<br> >>>>> ----------------------<br> >>>>> The capture file appears to be damaged or corrupt.<br> (pcap: File >>>>> has 3014350264-byte packet, bigger than maximum of 65535)<br> <br> >>>>> tcpdump error:<br> >>>>> --------------------<br> >>>>> tcpdump: pcap_loop: bogus savefile header<br> <br> i don't know what >>>>> is the problem, so i wanted to ask if anyone has experienced this >>>>> before or has any idea about it.<br> <br> thank you.<br></div> >>>>> </div> >>>>> </div><br> >>>>> >>>>> </body></html>_______________________________________________ Ntop >>>>> mailing list >>>>> [email protected] >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop >>>> >>>> >>> _______________________________________________ Ntop mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop >> >> --- >> >> "Debugging is twice as hard as writing the code in the first place. >> Therefore, if you write the code as cleverly as possible, you are, by >> definition, not smart enough to debug it. - Brian W. Kernighan > > > _______________________________________________ > Ntop mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop --- We can't solve problems by using the same kind of thinking we used when we created them - Albert Einstein _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
