Uninitialized values for srcTransOctets and dstTransOctets lead to
incorrectly printed values in table output of IpfixPrinter if no
transport octets are delivered in the flow
This allows the logging level to set as part of configuration, instead
of having to use the `-l` CLI option. This mean it can also be changed
dynamically when the config file is re-read for changes.
This commit adds default values for two variables, ipfixId and
enterpriseId, in the IpfixDbWriterSQL. Usually, these variables will
always be set or an exception will be thrown, but gcc (tested with
gcc 8.3.0 on debian) doesn't see this and will fail to compile due
to -Werror. This commit fixes the issue by setting both variables to
zero at initialization.
The debug build asserts on the id field, but the release does
not have a check for an missing ID field in the configuration.
This commit introduces a check that is also performed in the
release build to avoid a null ptr dereference in broken config
files.
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.
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.