Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-10830

zabbix_trap_receiver.pl script doesn't convert hexadecimal values in SNMPv3 traps, server doesn't process them correctly

    Details

      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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              zalex_ua Oleksiy Zagorskyi
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: