Looks like constcast repo has fallen off the internet :
fatal: remote error: access denied or repository not exported: /a/nw/ad/0c/93/1421452/254611723.wiki.git
fatal: clone of 'git://github.com/constcast/vermont.wiki.git' into submodule path '/Users/Nick/Software/vermont/docs/wiki' failed
Probably best to use tumi8 as that's the definitive uptream anyway.
Should not be generating logs per ipfix frame.
Use DPRINT_ functions in the critical datapath so that they disabled
by default and don't impact performance.
LOG_* should be used for interesting state that's not per
packets/frame, and DPRINTF_ used for per packet/frame logging, and
then explicitly enabled and compile time.
Commented out stage showing how scan-build can be run.
It fails the build with about 50 errors.
scan-build is very conservative, producing almost no false positives,
so these are probably all real issues that need investigating.
This actually deletes the object on exit.
Better would be to use proper RAII instead of using pointers for this
class data, but would involve checking if the document is shared, and
if reference or shr_ptr was needed in that case. It's probaby not
shared in which case simply RAII with class data would be work.
Valgrind was reporting lots of leaks of the form:
==5048== at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5048== by 0x5D50D18: xmlBufCreateSize (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.4)
==5048== by 0x5CDDD91: xmlNodeGetContent (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.4)
==5048== by 0x38EB01: XMLNode::getContent[abi:cxx11]() const (in /usr/sbin/vermont)
==5048== by 0x285B62: CollectorCfg::CollectorCfg(XMLElement*, unsigned int) (in /usr/sbin/vermont)
The API guide for xmlNodeGetContent() states:
Returns: a new #xmlChar * or NULL if no content is available. It's up to the caller to free the memory with xmlFree().
So call xmlFree() after using the std:string copy constructor
Fixes#117
stringstream treats uint8_t as a char which in some cases may be
unprintable ascii (eg 255 might be the protocol), so explicitly print
it as a string so it can be read.
Using a 'traditional' flow definition like that below will result in:
vermont[4729]: Field bgpDestinationAsNumber configured as nonFlowKey will not be Aggregated
vermont[4729]: Field bgpSourceAsNumber configured as nonFlowKey will not be Aggregated
vermont[4729]: Field destinationIPv4PrefixLength configured as nonFlowKey will not be Aggregated
vermont[4729]: Field egressInterface configured as nonFlowKey will not be Aggregated
vermont[4729]: Field ipNextHopIPv4Address configured as nonFlowKey will not be Aggregated
vermont[4729]: Field sourceIPv4PrefixLength configured as nonFlowKey will not be Aggregated
<rule>
<flowKey>
<ieName>destinationIPv4Address</ieName>
<autoAddV4PrefixLength>false</autoAddV4PrefixLength>
</flowKey>
<flowKey>
<ieName>destinationTransportPort</ieName>
</flowKey>
<flowKey>
<ieName>ingressInterface</ieName>
</flowKey>
<flowKey>
<ieName>ipClassOfService</ieName>
</flowKey>
<flowKey>
<ieName>protocolIdentifier</ieName>
</flowKey>
<flowKey>
<ieName>sourceIPv4Address</ieName>
<autoAddV4PrefixLength>false</autoAddV4PrefixLength>
</flowKey>
<flowKey>
<ieName>sourceTransportPort</ieName>
</flowKey>
<nonFlowKey>
<ieName>bgpDestinationAsNumber</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>bgpSourceAsNumber</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>destinationIPv4PrefixLength</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>egressInterface</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>flowEndMilliseconds</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>flowStartMilliseconds</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>ipNextHopIPv4Address</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>octetDeltaCount</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>packetDeltaCount</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>sourceIPv4PrefixLength</ieName>
</nonFlowKey>
<nonFlowKey>
<ieName>tcpControlBits</ieName>
</nonFlowKey>
</rule>
This allows calls set HWM socket options to happen on an unconnected
socket, thus working round ZMQ bug https://github.com/zeromq/libzmq/issues/2228
This works with both versions of ZMQ that do and do not have the bug.