On Wed, 2011-04-13 at 20:08 +0100, Gavin McCullagh wrote: > 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?
http://www.sflow.org/ is a place to start with sflow. If you want to use tcpdump, let me know offline and I'll send you my latest print-sflow.c rick > > > > 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
