On Wed, 13 Apr 2011, Rick Jones wrote: > I'd suggest checking the sflow "flow" with tcpdump but there are still > some holes there. At first blush that sounds like something is off by a > byte or four somewhere. Certainly I've had a few of those while I've > been trying to flesh-out tcpdump's support of sflow printing.
I've looked at it, but not that sure what to look for. Is there a spec somewhere I can compare to? > > Any thoughts on what to do? > > ulimit -c unlimited?-) At least that is what I've done on the off > chance I'll get another crash. Tried that. No core that I can find. I stuck it in /etc/default/ntop (which is sourced into the init script). I then ran ntop manually with it set and no luck either. > Thusfar I'm just getting the "attempt to write a second time with the > same timestamp" messages from RRD. (where I suspect if the interval is > ever just a skosh less than one second that will happen... although I > thought I saw it at least once when I had the "store every" settings > above one second) I tried to increase the sample rate to 10000 so I didn't get more than one report per second. Then, on the console I ran it on, ntop stays up for a while (probably waiting for the first sample), then I get a gazillion lines of output all saying: flow_sample_element length error (expected 0, found 4) flow_sample_element length error (expected 0, found 4) I'll keep looking, thanks. Gavin _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
