I noticed later on that the output format for the variable values had changed
to the equivalent of “-OQUt” (see snmpcmd man page), and the variable names are
formatted as for “-Os” (leaf name without module id). Sure enough, if I run
"sudo snmptrapd -OQUts -Le -f -m ALL” then I consistently get the same output:-
———————————————————————————————————————————
2014-12-04 08:56:05 localhost [UDP: [127.0.0.1]:42028->[127.0.0.1]:162]:
sysUpTimeInstance = 5717369 snmpTrapOID.0 = coldStart sysLocation.0 =
Just here
*** trap receiver ***
VARBINDS:
sysUpTimeInstance = 5717369 (67)
snmpTrapOID.0 = coldStart (6)
sysLocation.0 = "Just here" (4)
SNMP::MIB info for VARBINDS:
sysUpTimeInstance has no instance index
snmpTrapOID.0 parent label = snmpTrapOID
sysLocation.0 parent label = sysLocation
———————————————————————————————————————————
What’s more, if I change the command line to "sudo snmptrapd -OQUtn -Le -f -m
ALL” to output numeric OIDs and send in 2 traps then the bug is even more
apparent:-
———————————————————————————————————————————
2014-12-04 09:00:18 localhost [UDP: [127.0.0.1]:50081->[127.0.0.1]:162]:
.1.3.6.1.2.1.1.3.0 = 5742652 .1.3.6.1.6.3.1.1.4.1.0 = .1.3.6.1.6.3.1.1.5.1
.1.3.6.1.2.1.1.6.0 = Just here
*** trap receiver ***
VARBINDS:
.1.3.6.1.2.1.1.3.0 = 5742652 (67)
.1.3.6.1.6.3.1.1.4.1.0 = .1.3.6.1.6.3.1.1.5.1 (6)
.1.3.6.1.2.1.1.6.0 = "Just here" (4)
SNMP::MIB info for VARBINDS:
.1.3.6.1.2.1.1.3.0 parent label = sysUpTime
snmpTrapOID.0 parent label = snmpTrapOID
sysLocation.0 parent label = sysLocation
perl callback function 0x9bc3eb8 returns 1
2014-12-04 09:00:22 localhost [UDP: [127.0.0.1]:58763->[127.0.0.1]:162]:
sysUpTimeInstance = 5743117 snmpTrapOID.0 = coldStart sysLocation.0 =
Just here
*** trap receiver ***
VARBINDS:
sysUpTimeInstance = 5743117 (67)
snmpTrapOID.0 = coldStart (6)
sysLocation.0 = "Just here" (4)
SNMP::MIB info for VARBINDS:
sysUpTimeInstance has no instance index
snmpTrapOID.0 parent label = snmpTrapOID
sysLocation.0 parent label = sysLocation
perl callback function 0x9bc3eb8 returns 1
———————————————————————————————————————————
I get numeric OIDs up to the point where $SNMP::MIB{$oid}->{parent} gets called
for the first time, then after that I get textual leaf-only OIDs. This affects
the trap daemons own output logging as well as what’s coming from Perl.
So it’s pretty certain that using %SNMP::MIB affects the output flags for the
underlying SNMP session. The problem is that I’m running in the context of
NetSNMP::TrapReceiver so there’s no session object for me to examine - I guess
that’s hidden in the guts of the implementation.
Perhaps %SNMP::MIB is only designed to be used in the context of an SNMP agent
(or at least has only been tested there). Or maybe the problem is that I
haven’t called SNMP::session->new before attempting to use %SNMP::MIB.
Kevin
> On 3 Dec 2014, at 23:21, Kevin Broadey <ke...@broadey.net> wrote:
>
> This is weird. Probably best if I just show you what I did, what I saw, and
> what I expected to see…
>
> I’m running an Ubuntu 14.04 LTS server with Net-SNMP version 5.7.2. I’ve
> also installed Lubuntu desktop to give me a lightweight GUI environment.
>
> My /etc/snmp/snmptrapd.conf file contains this:-
> ——————————————————————————————————————————
> authCommunity log,execute,net public
> perl do "/usr/share/snmp/traphandlers/default_handler.pl";
> ——————————————————————————————————————————
>
> and the default_handler.pl file contains this:-
> ——————————————————————————————————————————
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use SNMP;
>
> sub trap_receiver {
> my ($pdu, $vars) = @_;
>
> print "VARBINDS:\n";
>
> foreach (@{$vars}) {
> my ($oid, $value, $type) = @$_;
> print "$oid = $value ($type)\n";
> }
>
> print "\nSNMP::MIB info for VARBINDS:\n";
>
> foreach (@{$vars}) {
> my ($oid, $value, $type) = @$_;
>
> if ($oid =~ /^(.*)\.[0-9]+$/) {
> print "$oid parent label = $SNMP::MIB{$1}->{label}\n";
> } else {
> print "$oid has no instance index\n";
> }
> }
>
> return NETSNMPTRAPD_HANDLER_OK;
> }
>
> unless (NetSNMP::TrapReceiver::register("all", \&trap_receiver)) {
> warn "Failed to register default Perl traphandler\n";
> } else {
> warn "Registered default Perl traphandler\n";
> }
> ——————————————————————————————————————————
>
> now I run “sudo snmptrapd -Le -f -m ALL” to get the trap daemon running in
> test mode (it isn’t running from init) and then inject a test trap with
> “snmptrap -v 2c -c public localhost '' SNMPv2-MIB::coldStart
> SNMPv2-MIB::sysLocation.0 s 'Just here’” from a separate terminal window.
>
> Here’s the output I get:-
> ——————————————————————————————————————————
> 2014-12-03 22:57:32 localhost [UDP: [127.0.0.1]:44173->[127.0.0.1]:162]:
> DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (2677185) 7:26:11.85
> SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart
> SNMPv2-MIB::sysLocation.0 = STRING: Just here
> VARBINDS:
> DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (2677185) 7:26:11.85
> (67)
> SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart (6)
> SNMPv2-MIB::sysLocation.0 = STRING: "Just here" (4)
>
> SNMP::MIB info for VARBINDS:
> DISMAN-EXPRESSION-MIB::sysUpTimeInstance has no instance index
> SNMPv2-MIB::snmpTrapOID.0 parent label = snmpTrapOID
> sysLocation.0 parent label = sysLocation
> perl callback function 0x882ee04 returns 1
> ——————————————————————————————————————————
>
> Everything looks okay, with the stuff from my Perl script matching what’s
> come from SNMP’s built-in logging, except that "sysLocation.0” is missing its
> "SNMPv2-MIB::” module id on the line before last. This is the weird thing.
> What caused the stringification of the blessed OID object to change?
>
> Leaving snmptrapd running, run the snmptrap command again to inject exactly
> the same trap message. This time the output is:-
> ——————————————————————————————————————————
> 2014-12-03 23:06:35 localhost [UDP: [127.0.0.1]:37609->[127.0.0.1]:162]:
> sysUpTimeInstance 0:7:35:14.59 snmpTrapOID.0 coldStart sysLocation.0
> Just here
> VARBINDS:
> sysUpTimeInstance = 0:7:35:14.59 (67)
> snmpTrapOID.0 = coldStart (6)
> sysLocation.0 = "Just here" (4)
>
> SNMP::MIB info for VARBINDS:
> sysUpTimeInstance has no instance index
> snmpTrapOID.0 parent label = snmpTrapOID
> sysLocation.0 parent label = sysLocation
> perl callback function 0x882ee04 returns 1
>
> ——————————————————————————————————————————
>
> This time around the module name is missing from the snmptrapd standard
> logging as well as from ALL the Perl script output, so the problem is deeper
> than the Perl layer. Somehow, accessing %SNMP::MIB has affected the
> underlying Net-SNMP C library.
>
> The line that causes the damage is 'print "$oid parent label =
> $SNMP::MIB{$1}->{label}\n”;’ when called for SNMPv2-MIB::snmpTrapOID.0, which
> is the very first time the tied hash is called, so something in the code from
> that point changes the setting that tells the library whether to include the
> module id in the OID name.
>
> Can someone please give this a try and tell the list whether you can
> reproduce my observations? Can someone tell me what to do to avoid this
> behaviour? As you can imagine, this is seriously hampering my trap handler
> development as my callback function needs the module name and oid for each
> varbind in the trap message in order to correctly process it.
>
> Many thanks for your help!
> Kevin
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
