[prev in list] [next in list] [prev in thread] [next in thread]
List: ntop
Subject: [Ntop] -o parameter (was: dying / crash - with GUI usage?)
From: "Burton Strauss" <Burton () ntopSupport ! com>
Date: 2006-03-31 18:14:15
Message-ID: 096f01c654ee$ed0adea0$648ea8c0 () burtonstrauss ! local
[Download RAW message or body]
-o (myGlobals.runningPref.dontTrustMACaddr) does turn off a couple of
things.
I'd love to see (via gdb) - the host traffic entry contents it is dying on
so we could see why -o changes things...
Note that the single MAC address is not abnormal for some network
configurations, those where the router is rewritting the Ethernet frames per
the Ethernet protocol (read the article on this in docs/FAQ).
-----Burton
-----Original Message-----
From: ntop-bounces@unipi.it [mailto:ntop-bounces@unipi.it] On Behalf Of Gary
Gatten
Sent: Friday, March 31, 2006 9:47 AM
To: Burton@ntopSupport.com; ntop@unipi.it
Subject: RE: [Ntop] ntop dying / crash - with GUI usage?
Before I read the FAQ on running with gdb, I started it with these
args:
-o -K -t 5 -d -L --skip-version-check -x 16384 -X 65536 -m
10.0.0.0/8,192.168.0.0/16
Since then, it hasn't crashed! Normally it would've two or three times by
now, especially since I've actually been trying to break it.
I'm wondering if the -o might have fixed my problem in a round about way?
Without it ALL traffic was associated with one host, the router.
My max sessions is around 40,000.
I don't know if this matters or not, just thought I'd mention it. If you
still want me to start it with gdb I will.
Thanks!
Gary
>>> "Burton Strauss" <Burton@ntopSupport.com> 3/30/2006 6:07:43 PM >>>
Buffer too short is just a warning - the snprintf() call (C library)
truncates it - so you might get a messed up web page, but that's it...
Could cause the ECONRESET I guess.
Bad Magic Number is a big problem - it means that the Host Traffic Structure
is corrupted (you can read about this in the FAQ or some of my back postings
- search for that specific phrase.
I can easily see how a corrupted HTS could cause SIG11 ... And all that the
gdb / bt full stuff will show is WHERE it finally died, not why (where the
corruption occurred). But I'd still like to see that - information about
the HT record that was being processed might give a clue (i.e. if it's an
unusually HT type)...
As a protective measure, it may be time to code an optional pointer test as
part of the idle host purge...
-----Burton
-----Original Message-----
From: Gary Gatten [mailto:Ggatten@waddell.com]
Sent: Thursday, March 30, 2006 10:35 AM
To: Burton@ntopSupport.com; ntop@unipi.it
Subject: RE: [Ntop] ntop dying / crash - with GUI usage?
I had a problem getting nTop to bind to to v4 stack, so I removed v6.
This was before I knew about the -4 switch. I figured it would bind to both
stacks by default, but it would only bind to the v6 stack. Don't really
care much about that right now, nor the ECONNRESET - so I'll start a new
thread on those if needed.
The crashing... Recent log entries:
Mar 30 10:15:01 wanmon1 ntop[53513]: **ERROR** Buffer too short @
report.c:3637 (increase to at least 2018) A BUNCH of these....
hundreds...
Mar 30 10:15:31 wanmon1 ntop[50780]: **ERROR** Bad magic number
(expected=1968/real=0) [deviceId=0] lookupHost()[pbuf.c/1101] Mar 30
10:15:31 wanmon1 kernel: pid 50780 (ntop), uid 65534: exited on signal
11
more of these
Mar 30 10:15:32 wanmon1 ntop[53513]: **ERROR** Buffer too short @
report.c:3637 (increase to at least 2018)
"Bad magic number" seems to be a recurring theme just before the sig11.
Current startup options: ntop -d -L --skip-version-check -x 16384 -X
65536 -m 10.0.0.0/8,192.168.0.0/16
Pretty simple... This system is a PIII-750 with 384MB of RAM. I noticed
nTop using about 200MB or so, but there's still 40Mb or so real remaining
and nearly all the swap file.
I'll start in debug mode and try to break it again.
Gary
>>> Burton@ntopSupport.com 3/29/2006 5:46:15 PM >>>
I doubt they're connected - there's a separation both in time and
function...
Invalid address family is during startup scan of the interfaces. Most
likely this is an INET6 issue - we don't recognize your system as having it,
so we don't enable the code... Need to look in config.log.
ECONNRESET is pretty much what you think it would be - the browser
disconnected w/o closing the connection, ntop finds this out when it tries
to send the next chunk of page. Try a different browser... And/or enable
the -t 6 and debug messages to see what's causing it.
The crash - usual answer - run under debug (gdb - instructions at the bottom
of docs/FAQ) and capture the failure point info.
Please split this into three separate message threads w/ appropriate
subjects... It will make it easier for people to find later on.
-----Burton
-----Original Message-----
From: ntop-bounces@unipi.it [mailto:ntop-bounces@unipi.it] On Behalf Of Gary
Gatten
Sent: Wednesday, March 29, 2006 3:32 PM
To: ntop@unipi.it
Subject: [Ntop] ntop dying with GUI usage?
FreeBSD 6.0, nTop 3.2.1, compiled from CVS - I think....
Using netflow plugin. Was working OK for a number of days, but there was no
GUI/web usage as I've been working on other stuff. Left by browser
connected before lunch, came back and the page was not found.
Checked the box and all ntop processes were killed. An excerpt of my
messages file is below. Thanks in advance for your help! - Gary
Mar 27 09:47:32 wanmon1 ntop[8249]: **WARNING** Invalid address
family (0) found!
Mar 27 13:49:09 wanmon1 ntop[8249]: **WARNING** Invalid address
family (0) found!
Mar 28 11:35:44 wanmon1 ntop[8249]: **WARNING** Invalid address
family (0) found!
Mar 29 10:21:54 wanmon1 ntop[8249]: **WARNING** ECONNRESET during
sending of page to web client
Mar 29 10:23:57 wanmon1 ntop[8249]: **WARNING** ECONNRESET during
sending of page to web client
Mar 29 11:07:19 wanmon1 ntop[8249]: **WARNING** ECONNRESET during
sending of page to web client
Mar 29 11:15:35 wanmon1 ntop[8249]: **ERROR** Bad magic number
(expected=1968/real=0) [deviceId=0] lookupHost()[pbuf.c/1088]
Mar 29 11:15:36 wanmon1 ntop[8249]: **ERROR** Bad magic number
(expected=1968/real=0) [deviceId=1] lookupHost()[netflowPlugin.c/529] Mar 29
11:15:36 wanmon1 kernel: pid 50124 (ntop), uid 65534: exited on signal
11
Mar 29 11:15:36 wanmon1 kernel: pid 50125 (ntop), uid 65534: exited on
signal 11 Mar 29 11:15:36 wanmon1 kernel: pid 50126 (ntop), uid 65534:
exited on signal 11 Mar 29 11:15:36 wanmon1 kernel: pid 50127 (ntop), uid
65534: exited on signal 11 Mar 29 11:15:37 wanmon1 kernel: pid 50128 (ntop),
uid 65534: exited on signal 11 Mar 29 11:15:37 wanmon1 kernel: pid
50129
(ntop), uid 65534: exited on signal 11 Mar 29 11:15:37 wanmon1 kernel:
pid
8249 (ntop), uid 65534: exited on signal 11
_______________________________________________
Ntop mailing list
Ntop@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
Ntop@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