What you do is what I've asked people to do all along, but nobody seems
willing to help.
There's a script in the utils/ directory called linuxrelease, which
litterally roots around in /etc/ looking for a file to figure out what
version (distro & release) of Linux it is. See the uname will differentiate
between *BSD, Solaris, Linux, etc. and for most OSes will tell you
everything you need. Except the distribution/release info, which turns out
to be critical (e.g. NPTL is in RH9 not RH8.0, etc.).
Anyway, linuxrelease tells us what distro/release it is. IF it knows how to
find it. If not, it returns something generic. Those settings are used to
tell ntop which of the files in configureextra to use, so we have a way of
forcing specific settings per OS, per OS-Release, etc.
$ utils/linuxrelease --help
Usage: linuxrelease [--distro] [--[united|lsb|full]release] [--kernel]
[--help]
Uses the /etc/xxxxx-release or /etc/xxxxx_version file to figure out
a decent guess as to which Linux distro and release this is...
$ utils/linuxrelease --distro
redhat
$ utils/linuxrelease --release
9
$ utils/linuxrelease --fullrelease
Red Hat Linux release 9 (Shrike)
But nobody has ever told me what to look for in a Debian system, hence the
generic response. What I'm looking for is the responses from the current
linuxrelease to the various settings (--distro, --fullrelease --kernel and
no parameter), plys the names and contents of any 'release' or 'version'
files in /etc...
In those configureextra files is how you force the setting of parameters for
specific OS/Distro/Releases that need them. I pointed you @ the RedHat
example because I know it has the right -D option for the work-around.
You should be able to invoke it via the usual way of forcing variables:
CPPFLAGS="-DHAVE_FILEDESCRIPTORBUG" ./configure ...
followed by
CPPFLAGS="-DHAVE_FILEDESCRIPTORBUG" make
OK?
However, if you are getting to where you seem to be, it may well be that you
don't need this.
The flows data you're looking at is useless. It's just a count of packets
captured by libpcap which it sends into the plugin via the handle packet
interface. Since netFlow doesn't have one, of course it's zero.
The stats from the netFlow plugin are the gold standard and they show you
ARE seeing packets. Switch to the netflow device and there should be
statistics there.
The counter that reports flows processed is incremented after handleIP() is
called. So there should be something counted.
The only path that would tracelessly throw this away is:
if(idx == -1) {
return(-1); /* Unable to locate requested index */
} else if(idx >= myGlobals.numIpProtosToMonitor) {
traceEvent(CONST_TRACE_ERROR, "Discarding idx=%d for port=%d", idx,
port);
return(-1);
}
i.e. a -1 from mapGlobalToLocalIdx().
I would suggest you put a traceEvent in there that shows idx and port for
the leg that doesn't have one. That should create a log message. I think
you'll find ports you don't have tracking entries for in your portMapper, so
you'll probably need to adjust your -p protocols settings.
FWIW, mapGlobalToLocalIdx() is in ntop.c if you want to follow it along
farther. Esp. handleProtocols(), just above there, that's what builds the
mapper.
-----Burton
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> thefly
> Sent: Monday, May 10, 2004 9:02 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Ntop] ntop+netflow
>
>
> On Mon, May 10, 2004 at 07:40:18AM -0500, Burton M. Strauss III wrote:
> > Look in the configureextra files...
> >
> > -----Burton
> >
> if i knew what to do with those files i wouldn't have asked. Anyway i
> compiled with ./configure --prefix=/opt/ntop/ and make. Now it got on
> well, i don't know if the FILEDESCRIPTORBUG workaround was compiled,
> anyway now the netflow plugin starts without that old errors. The plugin
> reports this:
>
> Flow Senders 1.10.185.83 [11 pkts]
>
> Number of Packets received 11
> Number of Packets with bad version 0
> Number of Packets processed 11
> Number of Flows Received 32
> Average Number of Flows per Packet 2.9
> Number of V1 Flows Received 0
> Number of V5 Flows Received 32
> Number of V7 Flows Received 0
> Number of V9 Flows Received 0
> Number of nFlows Received 0
>
> Discarded Flows
> Number of Flows with Zero Packet Count 0
> Number of Flows with Zero Byte Count 0
> Number of Flows with Bad Data 0
> Number of Flows with Unknown Template 0
> Total Number of Flows Processed 32
>
> Less: Ignored Flows
>
> Flows Bytes
> Port(s) zero (not tcp/ip)
> 3 192
> netFlow port
> 0 0
> Unrecognized port <= 1023
> 0 0
> Unrecognized port > 1023
> 0 0
>
> Gives: Counted Flows
>
> Flows Bytes
> Processed
> 29 160.9 KB
>
> but in Summary->Netflows i got 0 flows processed, and in facts there's
> not information at all if i switch to the netflow device. Any idea?
> Logs report no problem at all.
>
> TIA
>
>
> --
> Claudio "thefly" Martella
> [EMAIL PROTECTED]
> GNU/PG keyid: 0x8EA95625
>
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
