Smarts traps discarded with error "SNMP-EPARSER-Mangled or incorrect packet" with sysUpTime missing from trap-PDU
search cancel

Smarts traps discarded with error "SNMP-EPARSER-Mangled or incorrect packet" with sysUpTime missing from trap-PDU

book

Article ID: 331963

calendar_today

Updated On:

Products

VMware Smart Assurance Network Observability

Issue/Introduction

Some traps are failing with following error with sysUpTime missing from traps pdu:

SNMP-EPARSER-Mangled or incorrect packet; parsing aborted and data discarded; in file "/work/redcurrent/DMT-<VERSION>/10/smarts/snmp/lib/SNMP_Parser.c" at line 1339

Environment

All Supported Smarts releases

Cause

These errors come when the trap does not follow RFC - 1448 (External Link: rfc1448) .

RFC 1448 states for SNMPv2 traps:

  1. The first variable is sysUpTime.0 [9].
  2. The second variable is snmpTrapOID.0 [11], which contains the administratively assigned name of the notification.
  3. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable is copied, in order, to the variable-bindings field.
  4. At the option of the SNMPv2 entity acting in an agent role, additional variables may follow in the variable- bindings field.

So for SNMPv2-Trap PDU, the1st and 2nd varbinds are pre-defined:

  • 1st: sysUpTime.0 (.1.3.6.1.2.1.1.3.0)
  • 2nd: snmpTrapOID.0 (.1.3.6.1.6.3.1.1.4.1.0)

In this instance the mangled trap did not start with sysupTIme which is mandatory,

Example of mangled trap:

: VarBindList ->
35: VarBind -> SEQUENCE (0x30), 23 bytes:
37: OBJ-ID (0x06), 10 bytes == ".1.3.6.1.6.3.1.1.4.1.0" #snmpTrapOID
49: OBJ-ID (0x06), 9 bytes == "<snmpTrapOID Returned Value>"

for the ones with no error you can see

29: VarBindList ->
SEQUENCE (0x30), 238 bytes:
32: VarBind -> SEQUENCE (0x30), 16 bytes:
34: OBJ-ID (0x06), 8 bytes == ".1.3.6.1.2.1.1.3.0" #sysUpTime
44: TIME-TICKS (0x43), 4 bytes == <sysUpTime Returned Value>

Resolution

Smarts is working as designed as it conforms to RFC 1448.
Hence this needs to be evaluated with the Device Vendor to ensure the traps sent by the device adhere to RFC 1448