Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Current »

This article explains an integer overflow error that can happen while converting TimeTicks.

LAST TESTED ON CHECKMK 2.0.0P1

Table of Contents

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

This looks like a relatively common bug in SNMP devices when they try to encode large positive numbers; we have already seen this for "Counter" values, and this time it's "TimeTicks."


  • 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 that 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 that fixes their bug.


  • No labels