On 17 May 2010 13:14, Rathod, Nitin <[email protected]> wrote: > Tried the patch , and it did worked for TRAP-TYPE, but it is creating > entries as TRAP-TYPE for the parent module of the Traps
Yes - that's correct. It is applying the conversion rules from RFC 3584, to map the SMIv1 TRAP-TYPE definition (which lies outside the OID tree) into the equivalent SMIv2 Notification definition (which is an object within this tree) The anomolous status of SMIv1 traps is one of the reasons behind the switch to SMIv2 notifications, with SMIv1 being deprecated (even when used with SNMPv1 requests). You should really be looking to define your MIB files using SMIv2. > After executing snmpTranslate with the patch provided we get the proper > TRAP-TYPE > but the Object-Identifier is getting converted into TRAP-TYPE i.e. > museSnmpTrapForwarder > > museSnmpTrapForwarder# TRAP-TYPE Not quite - take a closer look at that definition. The name of the object is "museSnmpTrapForwarder#". rather than "museSnmpTrapForwarder" - note the trailing # This is a dummy MIB object defined to act as a parent of the newly-converted trap object. See the Co-Existence RFC for details. Yes, it's being defined as TRAP-TYPE rather than OBJECT-IDENTIFIER (which is wrong) - the patch clearly needs to be a little more intelligent. But SMIv1 MIBs are essentially obsolete by now anyway. You should be using SMIv2 for any new MIB files. Perhaps you need to explain a bit more about what you are trying to do. Dave ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
