On Feb 10, "Burton M. Strauss III" wrote:
> Yeah, well, take it up with the packager of your version of gd. If you look
> at the code path, it's all routines and headers from other places. My gd.h,
> v1.8.4, doesn't even HAVE 276 lines...
>
> Even better,
>
> $ grep y1 myrrd/*.[ch]
> $
>
> Seriously, it's some kind of a gcc artifact - there's discussions all over
> the web about it - google for 'em - there's talk of a new parameter in 3.3.4
> or some such to suppress these spurious warnings. Of course, you're running
> 2.94, so you get what you get...
Thanks for the background info. I've upgraded to gcc 3.3.3.
> As to the rest, you're just going to have to buckle down and read the code.
> That's how you debug.
>
> A word of warning... those messages are useless. They're in
> receiveSflowSample(), but if you follow it, you'll see that they come from
> the COUNTERSSAMPLE case and below that sample->counterBlockVersion is one of
> the 'good' ones, probably INMCOUNTERSVERSION_ETHERNET. But - all of those
> debug messages come from interpreting the raw data, not interpreting what
> ntop is being fed...
>
> if(debug) {
> u_int64_t cntr64;
> GETDATA64(cntr64, datap);
> traceEvent(CONST_TRACE_INFO, "SFLOW_DEBUG: ifInOctets %Lu",
> cntr64);
> ...
> GETDATA32(cntr64, datap);
> traceEvent(CONST_TRACE_INFO, "SFLOW_DEBUG: ifPromiscuousMode
> %Lu", cntr64);
> }
> }
> break;
>
> See it... it's useless. It just tells you there's good data in there, not
> that the plugin is DOING anything with it.
>
> The part that matters is the OTHER path... that leads to this in
> writePcapPacket():
>
> if(sample->headerProtocol == INMHEADER_ETHERNET_ISO8023)
> queuePacket((u_char*)myGlobals.sflowDeviceId,
> &hdr, sample->header); /* Pass the packet to ntop */
>
> If you go back to receiveSflowSample(), writePcapPacket is NOT called in
> COUNTERSSAMPLE, but rather in the case before, case FLOWSAMPLE, which
> has an entirely different set of debug lines.
>
> I think you're just going to have to work through receiveSflowSample() and
> understand what it really does...
>
> It may be as simple as your sflow probe is misconfigured and is sending the
> wrong type of data...
>
> That's basically all I can do for you. If it's truly important to you,
> contact me off-list and let's discuss paid support.
This info was just what I was looking for to get me started. I'll let you
know what I come up with. Thanks again for the help.
Mike
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
