On Mon, May 10, 2004 at 09:50:40AM -0500, Burton M. Strauss III wrote:
> 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.

Thanks, now everything is clear.

> 
> 
> 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.

I must admit i don't have the problem clear at this point. What i'm
using is a FreeBSD router with ng_netflow. With my tcpdump i see the
flow starting to my workstation, at the end of each www connection i'm
doing here and there, for test. Ntop should show me these connections,
thery are normal www. But what i get in Summpary->Traffic and others is
NULL, as i told you about the Summpary->Netflow stats. Being my
situations *standard* i don't know what's wrong with it, and therefore
can't understand what i should trace inside the code, i mean, i don't
know what to look for. Or maybe you'r just telling me that my
configuration isn't standard, and that's why i should put some
traceEvent to see what's wrong?

TIA


> 
> -----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
> 
> 

-- 
    Claudio "thefly" Martella
    [EMAIL PROTECTED]
    GNU/PG keyid: 0x8EA95625

Attachment: signature.asc
Description: Digital signature

Reply via email to