Hi Vito, On Fri, May 10, 2013 at 06:13:46PM +0200, [email protected] wrote:
> Interesting, I missed this feature out as I'm actually using the debian > packet (version 0.14.0.1) and if I'm right it's was introduces in the > last version of your software, specifically 0.14.3. Correct. > How would this impact on the DB schema, pls can you point me out to a > correct usage of these "new" parameters as the use case I need to handle > is accounting the start and the end of a flow. When downloading the 0.14.3 tarball, a) look into the sql/ directory README files, especially README.mysql and README.timestamp and b) look at the QUICKSTART document, section III. > Related to this, is there an appropriated way to setup the timeout > values for the L4 connections (tcp and udp). From what I've understood > pmacct doesn't have a protocol machine (FSM) to handle the connection > states, do it? Should I work with the netflow collector instead? I believe you mean the NetFlow probe/exporter. Yes: that's where the FSM is, ie. timeouts and/or closure of flows basing on TCP flags. > no, not actually but in my use case it's been expected.. I'm working on > a patch, it looks very easy but maybe I've underestimated it Correct :) > > Yes. Set sql_history_since_epoch to true. It applies to stamp_inserted > > and stamp_updated if sql_history is enabled; and to timestamp_start and > > timestamp_end aggregation primitives. > > in the light of this timestamp_start/end usage can you suggest me a > correct aggregation line? Well, the one you had in your original post plus the two primitives, ie.: "aggregate: src_host, dst_host, src_port, dst_port, vlan, proto, timestamp_start, timestamp_end" Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
