Errors for SNMP Trap Receiver

[flle]

Hi,

I am experiencing an issue/bug with the SNMP trap receiver of the SNMP modular input.

Working Trap:
09:22:56.553974 IP 172.17.xxx.xxx.43321 > myhost.snmptrap: V2Trap(87) system.sysUpTime.0=1113987000 S:1.1.4.1.0=E:7244.1.2.1.1651 E:7244.1.2.1.3.3="Test Trap"

Non-working Trap:
09:24:14.598038 IP 172.17.xxx.yyy.58003 > myhost.snmptrap: V2Trap(87) system.sysUpTime.0=3084126100 S:1.1.4.1.0=E:7244.1.2.1.1651 E:7244.1.2.1.3.3="Test Trap"
Error:
06-11-2015 09:24:14.600 +0200 ERROR ExecProcessor - message from "python /opt/splunk/etc/apps/snmp_ta/bin/snmp.py" Exception receiving trap ConstraintsIntersection(ConstraintsIntersection(), ValueRangeConstraint(0, 4294967295)) failed at: "ValueRangeConstraint(0, 4294967295) failed at: "-1210841196"" at TimeTicks snmp_stanza:snmp://snmptrap

Apparently, its related to an out of bounds value while handling the system uptime. Th shown "failed at" value -1210841196 would be the result-1 when deducting the upper ValueRage limit (4294967295) from the sysUpTime (3084126100 ). I am not sure, why this is done or why it is not failing for the first trap but should be fixed in the app.
Will this question be read by one of the authors (By Damien Dallimore and Scott Spencer) or can anybody with personal contacts point them to this?

Regards
Florian

[Damien_Dallimor]

There is some commentary on this error here : http://pysnmp.sourceforge.net/faq.html

The suggested solution is to have the vendor (trap source) fix their BER encoding (presumably for the contents component of the ASN data structure)

[flle]

ok, thanks for the clarification.
The traps I posted above is a tcpdump output. So likely the values are encoded and tcpdump just decodes them.
Unfortunately, fixing the encoding on the source will not be that simple. The trap Sender is a BMC of a Quanta Server. That means for us updating the BMC firmware on hundreds of Servers (given an update is available) ...
Would implementing the Workaround hack described in http://pysnmp.sourceforge.net/faq.html into snmp.py be a workaround Option or would that introduce other issues?

[Damien_Dallimor]

If you require some customization that is specific to the behavior of your environment , then I recommend forking the App from Github and adding in your own customizations.

[Damien_Dallimor]

This has nothing to do with snmp.py nor any math calculations.

I can't see the trap bytes on the wire , but I can reasonably infer that the ASN values are being BER integer encoded as unsigned integers at the trap source.

Time for some binary math.

3084126100 fails because the encoded unsigned binary value is actual the signed integer value -1210841196 , ergo MIB validation fails.

3084126100 unsigned integer value = B7D40794 hex = 10110111110101000000011110010100 binary (most significant bit is a 1) = -1210841196 signed integer value

1113987000 works , because the encoded unsigned binary value is the signed integer value 1113987000

1113987000 unsigned integer value = 426617B8 hex = 01000010011001100001011110111000 binary (most significant bit is a 0) = 1113987000 signed integer value

[flle]

Hi Damien,

thanks a lot for the quick answer. but I don't quite get it. Where is Encoding used here on the vendor side? The system.sysUpTime.0 field in the trap supplies the System uptime in miliseconds.

system.sysUpTime.0=3084126100 (356 days) triggers the error
system.sysUpTime.0=1113987000 (240 days) works ok.
What exactly does snmp.py with those values?
Looking at the error: "ValueRangeConstraint(0, 4294967295) failed at: "-1210841196"" at TimeTicks
it seems that there is a calculation of sysUptime - upperBoundValue (3084126100 - 4294967295 -1) =-1210841196, which Triggers the error. But why is this done? And why does the other other trap gets processe ok as it would also result in a negative value if the above calculation would be done.