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

Reply via email to