mkeventd - Integer Overflow while Parsing TimeTicks in SNMP Trap

LAST TESTED ON CHECKMK 2.0.0P1

Problem

SNMP traps cannot be processed. An Integer overflow occurs while converting TimeTicks (in this case, the "time-stamp" of an snmpv1 trap).

This message is from the mkeventd.log with debug enabled Setup → Events → Event Console  → Settings → Event Console: Logging & diagnose → Log level → Processing of incoming events: Debug

2020-12-10 13:35:49,501 [10]
[cmk.mkeventd.EventServer.snmp] receiveMessage: <ConstraintsIntersection object at 0x7fb225b324d0 consts <ValueRangeConstraint object at 0x7fb225b32410 consts 0, 4294967295>> failed at: ValueConstraintError('<ValueRangeConstraint object at 0x7fb225b32410
consts 0, 4294967295> failed at: ValueConstraintError(-1935586285,)',) at TimeTicks

Solution

• The relevant part from the SNMP-RFCs https://www.rfc-editor.org/rfc/rfc1155 and https://www.rfc-editor.org/rfc/rfc1902 are:

  TimeTicks ::=
      [APPLICATION 3]
          IMPLICIT INTEGER (0..4294967295)

• INTEGER in ASN.1 is always signed, so when doing the BER encoding of such a value, one must add a leading zero for large numbers, otherwise interpreted as negative (2's complement). This is exactly what the faulty device doesn't do. If one likes to play around with such things a bit, there is https://lapo.it/asn1js/.
• tcpdump's output is not really correct; it seems to try to "fix" the value. One can do this by hand, BTW: -471450490 + 2^32 = 3823516806, which are the values we see above. This "fixing" is, in fact, incorrect; I guess it's tcpdump trying to be nice to the reader.
• The decoding on the Checkmk side is done by a rather standard library, which behaves in a totally correct way, so there is not much there can be done on our side.

In a nutshell: Contact the manufacturer of your device; perhaps there is a firmware update or something like that which fixes their bug.

Related articles