[#ZBXNEXT-747] More efficient SNMP trapping

Thank you for the info, Oleksiy. Added return statements for both OK and FAIL cases. The second message seems like a debug message so it should be ok, those can probably be switched off in the daemon configuration file.

zalex_ua added 10-02-2015
Latest net-snmp in a source file TrapReceiver.xs contains this piece of code:

    /* actually call the callback function */
    if (SvTYPE(pcallback) == SVt_PVCV) {
        noValuesReturned = perl_call_sv(pcallback, G_SCALAR);
        /* XXX: it discards the results, which isn't right */
    } else if (SvROK(pcallback) && SvTYPE(SvRV(pcallback)) == SVt_PVCV) {
        /* reference to code */
        noValuesReturned = perl_call_sv(SvRV(pcallback), G_SCALAR);
    } else {
        snmp_log(LOG_ERR, " tried to call a perl function but failed to understand its type: (ref = %p, svrok: %lu, SVTYPE: %lu)\n", pcallback, (unsigned long)SvROK(pcallback), (unsigned long)SvTYPE(pcallback));
	callingCFfailed = 1;
    }

    if (!callingCFfailed) {
      SPAGAIN;

      if ( noValuesReturned == 0 ) {
        snmp_log(LOG_WARNING, " perl callback function %p did not return a scalar, assuming %d (NETSNMPTRAPD_HANDLER_OK)\n", pcallback, NETSNMPTRAPD_HANDLER_OK);
      }
      else {
	SV *rv = POPs;

	if (SvTYPE(rv) != SVt_IV) {
	  snmp_log(LOG_WARNING, " perl callback function %p returned a scalar of type %lu instead of an integer, assuming %d (NETSNMPTRAPD_HANDLER_OK)\n", pcallback, (unsigned long)SvTYPE(rv), NETSNMPTRAPD_HANDLER_OK);
	}
	else {
	  int rvi = (IV)SvIVx(rv);

	  if ((NETSNMPTRAPD_HANDLER_OK <= rvi) && (rvi <= NETSNMPTRAPD_HANDLER_FINISH)) {
	    snmp_log(LOG_DEBUG, " perl callback function %p returns %d\n", pcallback, rvi);
	    result = rvi;
	  }
	  else {
	    snmp_log(LOG_WARNING, " perl callback function %p returned an invalid scalar integer value (%d), assuming %d (NETSNMPTRAPD_HANDLER_OK)\n", pcallback, rvi, NETSNMPTRAPD_HANDLER_OK);
	  }
	}
      }

      PUTBACK;
    }

Looks like the page for version 5.0404 "published" in CPAN tree at 17 Oct 2013, i.e. after I wrote my comment above.
Also - I'd not miss requirements about returned value (like NETSNMPTRAPD_HANDLER_OK) when reading the page, so indeed, I was reading the CPAN page for version 5.0401 (supposedly published 18 Sep 2007)

But below are some interesting details I investigated today.
Looks like NetSNMP::TrapReceiver was initially and currently is just part of Net-SNMP package.
It has been firstly included in Net-SNMP 5.2 released 2004-11-25.
It was added to Net-SNMP sources 2004-02-11:

# cpan -D NetSNMP::TrapReceiver
CPAN: Storable loaded ok (v2.49)
Reading '/root/.cpan/Metadata'
  Database was generated on Sat, 14 Feb 2015 05:29:02 GMT
NetSNMP::TrapReceiver
-------------------------------------------------------------------------
        CPAN: Module::CoreList loaded ok (v5.020001)
(no description)
        H/HA/HARDAKER/NetSNMP-TrapReceiver-5.0404.tar.gz
        /usr/lib/x86_64-linux-gnu/perl5/5.20/NetSNMP/TrapReceiver.pm
        Installed: 5.07021
        CPAN:      5.0404  up to date
        Wes Hardaker (HARDAKER)
        [email protected]

Note that Installed version shows correct value.
If the module is not installed - the value is empty.

To install the module on different distro: centos7 - "net-snmp-perl", Debian - "libsnmp-perl".
Then actual documentation will be available by "man NetSNMP::TrapReceiver"
Note - the man page for Debian is (was?) in separate "libsnmp-dev" package.
Note that all of man pages of NetSNMP::TrapReceiver I googled in the Internet - are outdated.

So be careful when reading NetSNMP::TrapReceiver documentation - don't use CPAN or Internet. Use only net-snmp sources/packages.

# snmptrapd -f -Lsd -p /run/snmptrapd.pid -n
Can't locate NetSNMP/TrapReceiver.pm in @INC (you may need to install the NetSNMP::TrapReceiver module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.1 /usr/local/share/perl/5.20.1 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /usr/share/snmp/snmp_perl_trapd.pl line 13.
BEGIN failed--compilation aborted at /usr/share/snmp/snmp_perl_trapd.pl line 13.

Those LOG_DEBUG level messages may be indeed suppressed by corresponding configuration of snmptrapd.
For example on my Debian/testing host the daemon is running with option -Lsd.
If replace the option to -LS6-0d - it will suppress those LOG_DEBUG messages and they will not appear in different syslog files.
I'd recommend to do that for all users.

Just small unrelated note: snmpd daemon (agent) logs a line like "Connection from UDP: [127.0.0.1]:32942->[127.0.0.1]:161" in syslog for every incoming snmp request. They are LOG_INFO level messages.
They also may be suppressed if run the snmpd with option -LS5-0d instead of -Lsd.

#!/usr/bin/perl sub my_receiver { use Time::HiRes qw ( time ); open (DEBUG, ">>$debuglogfile") or die "Cannot open $debuglogfile\n"; print DEBUG time." $$ \n"; # Print current time and snmptrapd's PID close (DEBUG); # sleep 5; return NETSNMPTRAPD_HANDLER_OK; } NetSNMP::TrapReceiver::register("all", \&my_receiver) || warn "failed to register our perl trap handler\n"; $debuglogfile = "/tmp/zabbix_snmptrap_debug_handler.log"; # FULL Path to this debug log print STDERR "Loaded zabbix debug handler\n";

[ZBXNEXT-747] More efficient SNMP trapping Created: 2011 Apr 13 Updated: 2025 Mar 24 Resolved: 2011 Sep 09
Status:	Closed
Project:	ZABBIX FEATURE REQUESTS
Component/s:	Proxy (P), Server (S)
Affects Version/s:	1.9.3 (alpha)
Fix Version/s:	1.9.6 (beta)

[ZBXNEXT-747] More efficient SNMP trapping Created: 2011 Apr 13 Updated: 2025 Mar 24 Resolved: 2011 Sep 09