Solution 1:
The most common cause of this issue occurs when a malformed trap sent by a source device. To determine if this is the case, a third party tool and a snoop dump of the trap in question is needed. We recommend using the snoop utility to obtain a trap dump. This is available by default with the majority of Unix Operating Systems, or is readily available as shareware and can be found on the Internet.
Once the trap dump is obtained, we recommend using the Ethereal network protocol analyzer to verify if the contents are malformed. Ethereal is available for free download from their website here.
To obtain and review this data, complete the following to capture raw trap packets for analysis with Ethereal:
With snoop in place on the server where TrapEXPLODER is running, execute the following command *as root* (replace w.x.y.z with the IP address or hostname of the device sending the trap):
# snoop -o traps.cap src host w.x.y.z and dst port 162 and udp
Snoop will return the message:
"Using device /dev/eri (promiscuous mode)"
This indicates that snoop is listening for trap packets from the specified host. In addition to this message, a counter will appear. Once snoop is listening, send the problematic trap from the source. The snoop packet counter should increment. Snoop will also write the trap out to the file traps.cap. This is a binary file which can be read by network protocol analyzers. We can then open the trap with a network protocol analyzer, and determine if it is malformed, or if it is a 'good' trap. This technique does not necessarily have to be used on the machine where trapexploder is running. As long as snoop is installed, the trap can be captured. The source must send the trap to whichever system has snoop running.
Once the traps.cap file is created and contains the problem trap, within Ethereal running, go to the File->Open menu option and load the .cap file created. Find the problem IP and trap. If the same parse error is seen with Ethereal, then the problem is with the trap itself. Please consult the vendor of the software that is creating and sending the trap in question to proceed further.
NOTE: snoop does not work on Windows. To capture packets with traps in a Windows system for use with Ethereal, see this note from Ethereal concerning the use of WinPcap instead of snoop (again free software) at this link.
Solution 2:
If the trap does not show the same parse error in Ethereal once loaded, then the problem is with TrapEXPLODER. If this is the case, please open a new call ticket with Concord Technical Support. When opening the ticket please provide:
There are two possible causes to these types of errors.
Cause 1:
When a trap is sent by the trap source with malformed or incorrect values, TrapEXPLODER is not able to properly parse the trap and it's values.
Cause 2:
The SNMP libraries in TrapEXPLODER that define trap data or contents are incorrect, broken, or out of date.
Sample Errors:
A sample of some of the errors seen are:
snmp_parse: error parsing trap time-stamp
trapexploder: Parse error for trap from xx.xx.xx.xxsnmp_parse: error parsing varbind
trapexploder: Parse error for trap from xx.xx.xx.xx