| Info |
|---|
This article explains an integer overflow error that can happen while converting TimeTicks. |
| Status |
|---|
| colour | Green |
|---|
| title | LAST TESTED ON CHECKMK 2.3.0P1 |
|---|
|
| Panel |
|---|
| borderColor | black |
|---|
| bgColor | #f8f8f8 |
|---|
| title | Table of Contents |
|---|
|
|
Problem
SNMP traps cannot be processed. While An Integer overflow occurs while converting TimeTicks (in this case case, the "time-stamp" of an snmpv1 trap) an Integer overflow occurs.
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)
| Code Block |
|---|
|
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
...
...
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 is:RFC 1155 and RFC 1902 are:
| Code Block |
|---|
|
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295) |
.
- INTEGER in ASN.1 areis alwasalways signed, so when doing the BER encoding of such a value, one needs to must 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/is 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 just tcpdump trying to be nice for to the reader.
- The decoding on the Checkmk side is done by a rather standard library, which is behaving behaves in a totally correct way, so there is not really 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
| Filter by label (Content by label) |
|---|
| showLabels | false |
|---|
| max | 5 |
|---|
| spaces | CON |
|---|
| showSpace | false |
|---|
| sort | modified |
|---|
| reverse | true |
|---|
| type | page |
|---|
| cql | label = in ( "event_console" , "snmp" , "troubleshooting" ) and type = "page" and space = "CONKB" |
|---|
| labels | event_console |
|---|
|