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 ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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 |