[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntop
Subject:    Re: [Ntop] pf_ring + tcpdump capture: bogus savefile header
From:       Luca Deri <deri () ntop ! org>
Date:       2011-08-01 6:20:27
Message-ID: 00072AB7-49B6-484D-9212-A02BECE58F90 () ntop ! org
[Download RAW message or body]


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 <deri@ntop.org> 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
> > > > > Ntop@listgateway.unipi.it
> > > > > http://listgateway.unipi.it/mailman/listinfo/ntop
> > > > 
> > > > 
> > > _______________________________________________ Ntop mailing list
> > > Ntop@listgateway.unipi.it
> > > 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
> Ntop@listgateway.unipi.it
> 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
Ntop@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic