Page Comparison

...

Problem

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

...

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 RFC 1155 and RFC 1902 are:

  Code Block
  language bash theme RDark
  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/ JavaScript decoder.
  
  
• 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 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 which that fixes their bug.

Related articles

...