Page 1 of 1

TRAPS V3 received in hexadecimal format

Posted: Sun May 03, 2020 12:53 am
by FCC_Nagios_Support
Hello,

I am receivien traps V3 with OID in HEXADECIMAL format in the snmpttunknown.log as bellow:

Tue Apr 28 11:51:29 2020: Unknown trap (E070F000002) received from 10.5.98.15 at:
Value 0: 10.5.98.15
Value 1: 10.5.98.15
Value 2: The power supply has failed.
Value 3: E070F000002
Value 4: 10.5.98.15
Value 5:
Value 6:
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.6.3.1.1.4.1.0=SNMPv2-SMI::enterprises.11.2.36.1.0.6
Ent Value 1: .1.3.6.1.4.1.11.2.36.1.1.5.1.1.2.1=HPE StoreOnce 5650 CZ3003X401
Ent Value 2: .1.3.6.1.4.1.11.2.36.1.1.5.1.1.6.1=HPE StoreOnce 5650 CZ3003X401
Ent Value 3: .1.3.6.1.4.1.11.2.36.1.1.5.1.1.5.1=https://10.5.71.15
Ent Value 4: .1.3.6.1.2.1.1.3.0=25:23:40:39.00
Ent Value 5: .1.3.6.1.4.1.11.2.36.1.1.5.1.1.1.1=1
Ent Value 6: .1.3.6.1.4.1.11.2.36.1.1.5.1.1.4.1=SNMPv2-SMI::enterprises.11.10.3.1.3.27

Is it necessary to convert to decimal. IF I PUT A RULE IN SNMPTT.CONF Should I enter it in hexadecimal or in decimal notation converted.

Many Thanks in advance.
KR

Re: TRAPS V3 received in hexadecimal format

Posted: Sun May 03, 2020 1:29 am
by FCC_Nagios_Support
Should I emulate snmptrap with the oid in HEX format?
Thanks

Re: TRAPS V3 received in hexadecimal format

Posted: Mon May 04, 2020 12:01 pm
by ssax
I would try it, I've never personally seen this occur.

Do other ones show up properly from a different system?

Additionally, please run this command and attach the resulting /tmp/SNMPFILES.zip file:

Code: Select all

zip -r /tmp/SNMPFILES.zip /etc/snmp /usr/share/snmp/mibs /var/lib/net-snmp/snmpd.conf
And the output of this command:

Code: Select all

ps aux | grep trapd
What make/model/type of device is sending that?

Re: TRAPS V3 received in hexadecimal format

Posted: Tue May 05, 2020 12:09 am
by FCC_Nagios_Support
Hi,

The traps is sent by a Backup Robot StoreOnce.

Thanks

Re: TRAPS V3 received in hexadecimal format

Posted: Tue May 05, 2020 2:31 pm
by cdienger
I see a ticket was raised for this same issue. We'll lock the thread and continue to work this through the ticket to avoid duplicating efforts.