SNMP Trap (PowerNet MIB 441) - OID Description Wrong for Temperature Threshold Violation Alarms

[shemil_usman]

Hi, 

We are using “PowerNet MIB 441” for “Network Management System Integration” to send SNMP Traps to a 3rd party trap receiver Server called Netboss XT.

When tested, the Trap Receiver is receiving Scrap/wrong value in the description OID area of the SNMP Trap. And this is happening only for Temperature Threshold violations. The return to normal description is coming correctly.

Rest all alarms description (humidity, communication loss, voltage, current etc..) are coming correctly.

Please find below screen shots for your ref:

SNMP Trap: Alarm Trap Description showing Scrap/Wrong values for Temperature Threshold Violation

21:41:36:003 - WARN - SNMPNotificationListener - 10.x.x.x : V1TRAP[reqestID=0,timestamp=1 day, 6:55:21.91,enterprise=1.3.6.1.4.1.318,genericTrap=6,specificTrap=742, VBS[1.3.6.1.4.1.318.2.3.10.0 = Bbf3aec_nbErrorCond_74E285A5; 1.3.6.1.4.1.318.2.3.23.0 = Value Too High; 1.3.6.1.4.1.318.2.3.1.0 = 5; 1.3.6.1.4.1.318.2.3.11.0 = Bbf3aec_nbSNMPEnc55C10FD7; 1.3.6.1.4.1.318.2.3.24.0 = NETBOTZ-250-4 (10.x.x.x); 1.3.6.1.4.1.318.2.3.16.0 = ; 1.3.6.1.4.1.318.2.3.25.0 = Rack Manager; 1.3.6.1.4.1.318.2.3.17.0 = QA2144170080; 1.3.6.1.4.1.318.2.3.20.0 = NetBotz Rack Monitor 250; 1.3.6.1.4.1.318.2.3.21.0 = 10.189.156.98; 1.3.6.1.4.1.318.2.3.26.0 = R05-08; 1.3.6.1.4.1.318.2.3.27.0 = ; 1.3.6.1.4.1.318.2.3.22.0 = Bbf3aec_nbSNMPEnc55C10FD7_MEM_TEMPERATURE_6_1; 1.3.6.1.4.1.318.2.3.28.0 = Temperature - R06-10_T.F :1; 1.3.6.1.4.1.318.2.3.29.0 = 37:39:2e:30:20:c2:b0:20:46; 1.3.6.1.4.1.318.2.3.6.0 = 1664822498; 1.3.6.1.4.1.318.2.3.7.0 = 0; 1.3.6.1.4.1.318.2.3.30.0 = 54:68:65:20:63:75:72:72:65:6e:74:20:76:61:6c:75:65:20:6f:66:20:27:54:65:6d:70:65:72:61:74:75:72:65:20:2d:20:52:30:36:2d:31:30:5f:54:2e:46:20:3a:31:27:20:28:37:39:2e:30:20:c2:b0:20:46:29:20:69:73:20:74:6f:6f:20:68:69:67:68:2e]]

SNMP Trap: Return to Normal showing Correct description for Temperature Value Alarms

21:46:36:158 - WARN - SNMPNotificationListener - 10.x.x.x : V1TRAP[reqestID=0,timestamp=1 day, 7:00:22.09,enterprise=1.3.6.1.4.1.318,genericTrap=6,specificTrap=743, VBS[1.3.6.1.4.1.318.2.3.10.0 = Bbf3aec_nbErrorCond_74E285A5; 1.3.6.1.4.1.318.2.3.23.0 = Value Too High; 1.3.6.1.4.1.318.2.3.1.0 = 5; 1.3.6.1.4.1.318.2.3.11.0 = Bbf3aec_nbSNMPEnc55C10FD7; 1.3.6.1.4.1.318.2.3.24.0 = NETBOTZ-250-4 (10.x.x.x); 1.3.6.1.4.1.318.2.3.16.0 = ; 1.3.6.1.4.1.318.2.3.25.0 = Rack Manager; 1.3.6.1.4.1.318.2.3.17.0 = QA2144170080; 1.3.6.1.4.1.318.2.3.20.0 = NetBotz Rack Monitor 250; 1.3.6.1.4.1.318.2.3.21.0 = 10.189.156.98; 1.3.6.1.4.1.318.2.3.26.0 = R05-08; 1.3.6.1.4.1.318.2.3.27.0 = ; 1.3.6.1.4.1.318.2.3.22.0 = Bbf3aec_nbSNMPEnc55C10FD7_MEM_TEMPERATURE_6_1; 1.3.6.1.4.1.318.2.3.28.0 = Temperature - R06-10_T.F :1; 1.3.6.1.4.1.318.2.3.29.0 = 37:38:2e:34:20:c2:b0:20:46; 1.3.6.1.4.1.318.2.3.6.0 = 1664822498; 1.3.6.1.4.1.318.2.3.7.0 = 1664822798; 1.3.6.1.4.1.318.2.3.30.0 = The value of 'Temperature - R06-10_T.F :1' was too high, but has now returned to normal.]]

We tested Temp. Alarm for Netbotz-250, EGX150 Ethernet gateway devices and it is giving same error.

Please advise a solution to fix this issue.

Thanks & Regards

Shemil

[ATrabert]

I'm not sure why this happens or have a resolution, but can confirm I can replicate it in DCE 7.9.2 and using a netbotz 250 with a manual temp threshold set.

we'll need to investigate this further.

[shemil_usman]

Hi,

We need to find a solution for this because our client acceptance test is on hold because of this.

Regards

Shemil

[Shaun]

Hi Shemil,

I don't have a solution, but to explain what's happening - there's two bytes in the threshold trap, c2:b0, which form the Unicode point °  (eg, °F). It appears the mtrapargsOctetString08 OID has no "TEXTUAL-CONVENTION" attached to it in the MIB, so it's up to the trap receiver what heuristic it uses to guess the convention being used.  It appears your system guesses ASCII if every byte is in the low7, and falls back to octet string otherwise.

(This is why it's only affecting this threshold - most traps don't use non-ascii characters.)

A potential solution would be to have RFC2579 Display-Hint of 255t added to the MIB.  I've no idea how the best way to go about that is, however.

If the customer can force the type to be 255t / UTF-8 on the trap receiver, this should resolve the issue also.

[shemil_usman]

Hi Shaun,

Please advise how the customer can force the type to be 255t / UTF-8 on the trap receiver,

The client is not ready to do anything from side because they are saying if its working for all other snmp traps, then you need

to fix this in your Mib file. They also have a lot of other systems connected to Netboss XT Trap receiver Server.

So, can we fix it in the mib file?

Thanks & Regards

Shemil

[ajoyce]

Hi Shemil,

Apologies for the delay in responding to your post,

We are currently looking into the issue and hope to have an update to share with you soon,

Many thanks for your patience,

Kind Regards

Alan 

[shemil_usman]

Hi,

I would like to know if any investigation was done on this issue and if a possible resolution was found.

Thanks & Regards

Shemil

[Shaun]

Hi @shemil_usman,

A resolution has been identified for this, it's currently in the testing process.

The issue identified is that we document that this field is Unicode, and the NetBotz is sending Unicode - however the MIB doesn't specify a unicode-safe type for this field, so software is treating it as ASCII.

So the issue you're seeing is when non-ASCII characters are present, the software doesn't know how to handle this so just shows the raw octets.  (This is why the "return to normal" messages come through fine - they don't contain the °C so the non-ascii ° isn't present.)

We have a resolution identified, but as this MIB is used for a large number of products, we need to be thorough in ensuring changes have no unintended consequences.

I'll update you here when we have something we can share.

Thanks,

  Shaun

[shemil_usman]

Hi Shaun,

Please update if we have a resolution for this issue.

In one our prestigious project where we are expecting a 2nd phase this year, client had mentioned this issue in their snag list and I am afraid if we don't find a solution we will face penalty and our hopes for 2nd phase expansion will be shutdown.

Thank you for your support.

Best Regards

Shemil