Page Comparison

...

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 very much like a rather common bug in SNMP devices when they try to encode large positive numbers, we have already seen this for "Counter" values, this time it's "TimeTicks". The gory details:

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

  Code Block
  language bash theme RDark
  TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

  
  

• INTEGER in ASN.1 are alwas signed, so when doing the BER encoding of such a value, one needs to add a leading zero for large numbers, which would otherwise be 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 just tcpdump trying to be nice for the reader.
• The decoding on the Checkmk side is done by a rather standard library, which is behaving in a totally correct way, so there is not really 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

...