Juergen Schoenwaelder wrote:
Let me see whether I understand your question.
You have a TRAP-TYPE definition with enterprise = 1.3.6.1.4.1.4779 and a specifc trap value of 1. smidump generates the notification OID 1.3.6.1.4.1.4779.0.1 and you believe this is wrong and you expect 1.3.6.1.4.1.4779.1.
The relevant document here is RFC 3584 (which obsoletes RFC 2576) and in particular section 3.1 transformation (2):
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of the SNMPv1 enterprise parameter and two additional sub- identifiers, '0', and the SNMPv1 specific-trap parameter.
I think this text clearly supports what libsmi does.
First, thanks for the quick reply... and to answer your questions...
I believe you understand the question, and I agree with what you've said,it is what libsmi does.
I guess what I'm asking here is is there an option read and SMIv1 mib, and output the oid in the xml, in a SMIv1 style.
The reason being, is on these old devices that supported SMIv1/SNMPv1 the traps that get sent across the wire are 1.3.6.1.4.1.4779.1 not 1.3.6.1.4.1.4779.0.1
When I'm referring to the xml doc, I'm missing the traps.... When the device was created and mib were created, RFC 2576 was not published
If there is not an option, thats fine,I can program around that.
Thanks for your time,
Scott