smidump -f xml is adding extra 0 to notifications to a SMIv1 mib

Hi, Please excuse me if this has been ask in the past, I did search the mailing list before writing this e-mail.
My question is when I'm trying to convert a SMIv1 mib to xml, the notification oid adds an extra 0, I believe this should only be done, if you wan the resulting xml out in SMIv2 representation. I did look up the extra 0 thing (section 3 http://www.mibdepot.com/downloads/rfcs/rfc2576.txt ), it is is valid if you want to convert a MIB from SMIv1 to SMIv2.
I'm trying to convert the following mib to xml http://www.baytech.net/downloads/gpm/bayuniv-4014.mib with the following command:
smidump -f xml ../mibs/bayuniv-4014.mib -o ./xml/bayuniv-4014.xml
header of xml: <module name="Baytech-MIB-401-4" language="SMIv1" />
the first trap:
<notifications> <notification name="communicationLost" oid="1.3.6.1.4.1.4779.0.1" status="current"> <objects> <object module="Baytech-MIB-401-4" name="mtrapargsTimeTicks" /> </objects> <description>SEVERE: Communication to the unit has been lost. Steps to reestablish communication are in progress. Argument is timeTicks when communication was lost.</description> </notification>
the oid should be: 1.3.6.1.4.1.4779.1 I know this mib has other issues, but for now, I would like to address this one. Any suggestions ???
Scott

On Wed, Jul 20, 2005 at 04:43:12PM -0400, R. Scott Baer 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.
/js

Juergen Schoenwaelder wrote:
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

On Wed, Jul 20, 2005 at 05:36:35PM -0400, R. Scott Baer wrote:
An SNMPv1 agent will send on the wire
enterprise = 1.3.6.1.4.1.4779 generic-trap = enterpriseSpecific(6) specific-trap = 1
and not the notification OID 1.3.6.1.4.1.4779.1. See RFC 1157 section 4.1.6 for the PDU format and RFC 3584 section 3 for the details. If you see "1.3.6.1.4.1.4779.1" displayed somewhere, then I suspect that you are looking at a program which gets the translation wrong.
The conversion procedure is actually already described in RFC 1908 section 3.1.2 which dates back to 1996 (almost 10 years now). But once again, if the device sends an SNMPv1 trap, the error is more likely on the receiving side and not on the sending side. If in doubt, check the packet on the wire using tcpdump/ethereal/you name it.
If there is not an option, thats fine, I can program around that.
The libsmi simply does the right thing. We can't fix a bug that seems to be somewhere else by making libsmi do the wrong thing.
/js
participants (2)
-
Juergen Schoenwaelder
-
R. Scott Baer