[ZBX-10830] zabbix_trap_receiver.pl script doesn't convert hexadecimal values in SNMPv3 traps, server doesn't process them correctly Created: 2016 May 19  Updated: 2017 May 30  Resolved: 2016 Sep 02

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: 2.0.18, 2.2.13, 3.0.3
Fix Version/s: 2.2.15rc1, 3.0.5rc1, 3.2.0beta2

Type: Incident report Priority: Blocker
Reporter: Oleksii Zagorskyi Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: snmptraps, snmpv3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate

 Description   

When you get a SNMPv3 trap, in the zabbix_traps.tmp file you can see it this way:

PDU INFO:
  contextName                    my-context
  notificationtype               TRAP
  version                        3
  messageid                      2039715439
  receivedfrom                   UDP: [127.0.0.1]:33625->[127.0.0.1]:162
  securityName                   traptest
  securitylevel                  3
  securitymodel                  3
  transactionid                  16
  securityEngineID               .^@^@^@^A^B^C^D
  errorstatus                    0
  errorindex                     0
  requestid                      1149152746
  contextEngineID                .^@^_.....nV..T^@^@^@^@
VARBINDS:
  DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=Timeticks: (0) 0:00:00.00
  SNMPv2-MIB::snmpTrapOID.0      type=6  value=OID: IF-MIB::linkUp.0

Note the strings like ".@@^@^A^B^C^D" are actually not ASCII bytes.

When zabbix server reads such traps from the tmp file - it stops at this incorrect lines and on latest data page, collected values look truncated.
For example only one line like "2016-05-19 13:18:59 PDU INFO:" could be visible.
Minor note: order of values passed to the script from snmptrapd looks like is random for each trap, so the broken records may appear on trap start too, then you see only that one line ... PDU INFO ... in collected value.

Or when interval between traps id for example ~1 second - it's possible to see that next gathered value started from the "end" of the truncated previous trap. When sends traps with a bit longer interval - then only new trap is visible, but I'd say it's inconsistent.

Suggested fix for the script is 

	foreach my $key(keys(%pdu_info))
	{
		printf OUTPUT_FILE "  %-30s %s\n", $key, $pdu_info{$key};
	}

to:

	foreach my $key(keys(%pdu_info))
	{
		if ( $key =~ /contextEngineID|securityEngineID/i ) 
		{
			my $HexAsText = unpack('H*',$pdu_info{$key}) ;  #convert hex to ascii string
			$pdu_info{$key} = "0x$HexAsText" ;              #apply 0x header for consistency
                }
                
		printf OUTPUT_FILE "  %-30s %s\n", $key, $pdu_info{$key};
	}

The fix has been tested and work well, example trap:

2016-05-19 14:49:12 ZBXTRAP 127.0.0.1
PDU INFO:
  errorstatus                    0
  requestid                      236555220
  securityEngineID               0x8000000001020304
  receivedfrom                   UDP: [127.0.0.1]:35633->[127.0.0.1]:162
  transactionid                  7
  messageid                      1573489199
  securitymodel                  3
  contextName                    my-context
  contextEngineID                0x80001f888095b5c26e5694d85400000000
  securityName                   traptest
  securitylevel                  3
  version                        3
  notificationtype               TRAP
  errorindex                     0
VARBINDS:
  DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=Timeticks: (0) 0:00:00.00
  SNMPv2-MIB::snmpTrapOID.0      type=6  value=OID: IF-MIB::linkUp.0

How to configure and send SNMPv3 traps is nicely described here http://net-snmp.sourceforge.net/wiki/index.php/TUT:Configuring_snmptrapd_to_receive_SNMPv3_notifications

This issue also in forum https://www.zabbix.com/forum/showthread.php?t=51691

 Comments   
Comment by Oleksii Zagorskyi [ 2016 May 19 ]

(1) But maybe also worth to check C code of snmp trapper process to be more robust against non-printable characters present in the tmp file?
Because I suppose such a data still could appear in the tmp file from trap values.
We could separate it to another ZBX, if required.

viktors.tjarve Some of the security related values from snmptrap are encoded as octet strings. I have modified the zabbix_trap_receiver.pl script so that all received trap values are checked and if not printable then converted to hex. No changes to C code are necessary.
RESOLVED r61089.

wiper CLOSED

Comment by Oleksii Zagorskyi [ 2016 May 19 ]

Let's include a tiny ZBX-10634 here too, as it's "prioritized" as well ?

viktors.tjarve After small discussion it was decided to deal with this issue separately and not mix it with this problem here.

zalex_ua heh, will hope ZBX-10634 will be considered one day ...

Comment by Aleksandrs Saveljevs [ 2016 Jul 18 ]

(2) This is not related to this issue, but richlv spotted a small improvement that can be made to shutdown.sh script for Java gateway:

$ svn di
Index: src/zabbix_java/shutdown.sh
===================================================================
--- src/zabbix_java/shutdown.sh (revision 61071)
+++ src/zabbix_java/shutdown.sh (working copy)
@@ -7,7 +7,7 @@
        if [ -f "$PID_FILE" ]; then
                PID=`cat "$PID_FILE"`
                if ps -p "$PID" > /dev/null 2>&1; then
-                       kill `cat $PID_FILE`
+                       kill "$PID"
                        for i in 1 2 3 4 5; do
                                sleep 1
                                ps -p "$PID" > /dev/null 2>&1

asaveljevs RESOLVED in r61072.

viktors.tjarve CLOSED

Comment by Viktors Tjarve [ 2016 Jul 19 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-10830

Comment by Andris Zeila [ 2016 Jul 28 ]

(3) The script converts value to hex string only if the first character is not number or letter. It works in this specific example, but more robust solution would be to check if the value contains unprintable characters in any places and convert it to hex string.

viktors.tjarve RESOLVED in r62029.

wiper Please check a minor improvement in r62037 .

viktors.tjarve Looks good. CLOSED

Comment by Aleksandrs Saveljevs [ 2016 Aug 30 ]

(4) The following lines do not look to be according to coding guidelines:

my $OctetAsHex = unpack('H*',$pdu_info{$key}) ;	# convert octet string to hex
$pdu_info{$key} = "0x$OctetAsHex" ;		# apply 0x prefix for consistency

There is a space before the semicolon and there is also no space after "," in the function call.

viktors.tjarve Additionally fixed coding style according to guidelines in folowing lines:

-	if ($hostname ne 'unknown') {
+	if ($hostname ne 'unknown')
+	{

viktors.tjarve RESOLVED in r62115, r62136.

sasha CLOSED

Comment by Viktors Tjarve [ 2016 Aug 31 ]

Released in:

  • pre-2.2.15rc1 r62053
  • pre-3.0.5rc1 r62054
  • pre-3.2.0beta2 r62056
Comment by Viktors Tjarve [ 2016 Aug 31 ]

Released with fixed (4) in:

  • pre-2.2.15rc1 r62115
  • pre-3.0.5rc1 r62115
  • pre-3.2.0beta2 r62136
Comment by Miguel Carrillo [ 2016 Sep 01 ]

Hello,

Just one question, will there be a release with fixed for 2.4 Zabbix version?

Thanks

Comment by richlv [ 2016 Sep 01 ]

miguel.carrillo, no - zabbix 2.4 is not supported or updated anymore

Generated at Fri Apr 26 22:45:05 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.