Net-SNMP 5.4 traphandle not working.

This is a discussion on Net-SNMP 5.4 traphandle not working. within the SNMP Users forums, part of the Networking and Network Related category; Im at a compleate dead end here. Help is greatly appreciated. Here is my situation and let me first state ...


Go Back   Usenet Forums > Networking and Network Related > SNMP Users

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 02-22-2007
shanegin
 
Posts: n/a
Default Net-SNMP 5.4 traphandle not working.

Im at a compleate dead end here. Help is greatly appreciated. Here is
my situation and let me first state that Ive been dealing with this
for about 6 days and have read about every post related to my issue
and was not aboe to resolve the issue.


I have 5.3 running on Fedora Core5 and was doing alot with SNMP on
that server as it is my Network Monitoring Server. I had
snmptrapd.conf sending traps to different perl scripts with the
following lines in the config: (comment lines ommited for readability)

disableAuthorization yes
traphandle SNMPv2-SMI::enterprises.6431 /var/snmptrapd/scripts/
bsoft-handler.pl
traphandle SNMPv2-SMI::enterprises.9148 /var/snmptrapd/scripts/
acme-handler.pl
traphandle SNMPv2-SMI::enterprises.1991 /var/snmptrapd/scripts/
foundry-handler.pl
traphandle SNMPv2-SMI::enterprises.2636 /var/snmptrapd/scripts/
juniper-handler.pl
traphandle default /
var/snmptrapd/scripts/trap-handler.pl


This was working great and all my traps were being dealt with as
inteneded. UNTIL I upgraded to 5.4. I I upgraded to 5.4 because I was
trying to get the snmpset to work with counter32 and 5.3's snmpset.c
didnt support clearing Counter32. I fixed that by adding type c
support in snmpset.c before compiling 5.4 on the box. 5.4 went on
great and everything works great and as expected EXCEPT the TRAPHANDLE
directive!!!!


traphandle was working before and I didnt even change the config file
but instead of TRAPHANDLE matching on the OIDs above as they were
before the upgrade it only matches on the "default" TRAPHANDLE. If I
remove the "default" traphandle statement and restart then the traps
dont go anywhere (except syslog if i started with -Lsd). So Im sure
the traps are commign in correctly.


Here is what I have done so far to diagnose the issue:

- Insured that I was starting snmptrapd with the same output switches
as before (ie -Lsd) so that the traps OID will match. I wasnt using -
On in the 5.3 nor 5.4 implementation.

- I started trapd with -Dsnmptrapd,read_config:traphandle as well as
ALL and it loads the traphandles fine:

Starting snmptrapd: No log handling enabled - turning on stderr
logging (why do I always get this message even though i use -Lsd)?
registered debug token snmptrapd, 1
registered debug token read_config:traphandle, 1
snmptrapd: Freeing trap handler lists
read_config:traphandle: registering handler for: SNMPv2-
SMI::enterprises.6431
read_config:traphandle: registering handler for: SNMPv2-
SMI::enterprises.9148
read_config:traphandle: registering handler for: SNMPv2-
SMI::enterprises.1991
read_config:traphandle: registering handler for: SNMPv2-
SMI::enterprises.2636
read_config:traphandle: registering handler for: default

- I re-test and still the traps all get caught only by the "default"
traphandler. Its like the OID just doesnt match but if you look below
here is an incomming trap that shows the OID does match:

-----------------INBOUND TRAP FROM ETHERNET
SWITCH---------------------
---------UDP: [192.168.107.6]:161
---------DISMAN-EVENT-MIB::sysUpTimeInstance 128:2:31:14.50
---------SNMPv2-MIB::snmpTrapOID.0 SNMPv2-SMI::enterprises.1991.0.76
---------SNMPv2-SMI::enterprises.1991.1.1.2.1.44.0 "Security: telnet
logout by line password from src ---------IP 192.168.107.110, src MAC
0010.dbff.2000 "
---------SNMP-COMMUNITY-MIB::snmpTrapAddress.0 192.168.107.6

-------------------------SNMPTRAPD.conf statement for this
OID------------------
---------traphandle SNMPv2-SMI::enterprises.1991 /var/
snmptrapd/scripts/foundry-handler.pl

Ive read lots of posts on here about Traphandle not workign but none
are like this. Everyone else had missing MIBs and was using -On and
trying to match on teh verbal OID name and things like that. I have
seen no posts where everythign appears to be configured correctly and
still not working. Its just strange that this was workign BEFORE the
5.3 to 5.4 upgrade.



One other strange tidbit is that I did see one post where someone put
quotes around the word "default" and it made their trphandle
"default" statement work. So, at a loss I tried this around my OID:
traphandle "SNMPv2-SMI::enterprises.1991" /var/snmptrapd/
scripts/foundry-handler.pl.

I sent and received 2 traps and it worked like normal. I was shocked.
But then I restarted snmptrapd with the init.d scripts instead of
using /usr/sbin/snmptrapd like I was doing when testing and It didnt
work anymore. I tried to restart manuallly and I can not get it to
work again.


Pleaes help. I have about 3 weeks of development work to do and Im
already a week behind because of all these hangups with the upgrade
and now this traphandle not working. This has to be somethign so
stupid!!!!!


Thanks in advance,
Shane

Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 02:10 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0