Can't Compile 2 MIB Modules with MG-Soft Compiler - SNMP

This is a discussion on Can't Compile 2 MIB Modules with MG-Soft Compiler - SNMP ; I posted previously asking specifically about a couple of errors in two Fore MIB modules (Fore-Switch.mib and Fore-traplog.mib). I cannot get these to compile. I am new to MIBs and have been trying to understand what changes need to be ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Can't Compile 2 MIB Modules with MG-Soft Compiler

  1. Can't Compile 2 MIB Modules with MG-Soft Compiler

    I posted previously asking specifically about a couple of errors in two
    Fore MIB modules (Fore-Switch.mib and Fore-traplog.mib). I cannot get
    these to compile. I am new to MIBs and have been trying to understand
    what changes need to be made to these MIBs to get them to compile (it
    has been days now). Based on the previous response to this request I
    have notified the vendor that the MIBs are believed to be out of
    compliance. However, I need a workaround. Thus, modified MIBs until I
    can get this resolve through the proper channels. Also, I anticipate a
    little finger pointing between the vendor and MG-soft as to the
    interpretation of the standard. These two MIBs compile fine with HP
    Openview and the vendor's compiler (not sure what they are using). The
    product I am looking to integrate has MG-Soft as its backend compiler.
    Thus, I need an intermediate solution until I can find enough
    convincing evidence that the issue is with the MIBs or is with MG-Soft.
    Both have strong arguments, but it could result in a standoff (i.e.
    the MIBs compile with other browsers vs. the MIB is out of spec.) My
    guess is that some compilers are more lenient than others. If I point
    to the MIBs, I would like to know exactly how they do not comply (this
    is defined in a previous post for Error 35, but not for the other
    errors in these two MIBs). Also, being new to MIBs, I would like to
    ask if someone would be willing to walk me through the changes needed
    to effectively correct these MIBs such that they meet the standards
    MG-Soft is stating they violate without affecting the intended effect
    of the MIB.

    Help on this is appreciated.

    T


  2. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    T wrote:

    > I posted previously asking specifically about a couple of errors in two
    > Fore MIB modules (Fore-Switch.mib and Fore-traplog.mib). I cannot get
    > these to compile. I am new to MIBs and have been trying to understand
    > what changes need to be made to these MIBs to get them to compile (it
    > has been days now). Based on the previous response to this request I
    > have notified the vendor that the MIBs are believed to be out of
    > compliance. However, I need a workaround. Thus, modified MIBs until I
    > can get this resolve through the proper channels. Also, I anticipate a
    > little finger pointing between the vendor and MG-soft as to the
    > interpretation of the standard. These two MIBs compile fine with HP
    > Openview and the vendor's compiler (not sure what they are using). The
    > product I am looking to integrate has MG-Soft as its backend compiler.
    > Thus, I need an intermediate solution until I can find enough
    > convincing evidence that the issue is with the MIBs or is with MG-Soft.
    > Both have strong arguments, but it could result in a standoff (i.e.
    > the MIBs compile with other browsers vs. the MIB is out of spec.) My
    > guess is that some compilers are more lenient than others. If I point
    > to the MIBs, I would like to know exactly how they do not comply (this
    > is defined in a previous post for Error 35, but not for the other
    > errors in these two MIBs). Also, being new to MIBs, I would like to
    > ask if someone would be willing to walk me through the changes needed
    > to effectively correct these MIBs such that they meet the standards
    > MG-Soft is stating they violate without affecting the intended effect
    > of the MIB.


    People might be able to help if you can put the MIB modules and all
    the other non-standard MIB modules they depend on somewhere on a web
    server and post a pointer to it. Without getting the MIB modules you
    are actually using there is little help you can expect since there
    are usually lots of variations.

    /js

    P.S. Note that the HP OV MIB parser is know to be an extremly lenient
    MIB parser and not a good tool for validating MIB modules.

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

  3. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    Hi T,

    As Juergen pointed out, it is impossible to help without knowing
    the MIB specification. Using HP-OV to check MIB modules for
    SMI compliance is nonsense. This can be compared with checking
    C++ syntax with grep - also I admit that HP-OV would pip grep
    for this comparison ;-)

    If you need a second opinion about the MIB files you can also
    use my free Web service at:
    http://www.agentpp.com/mibtools/mibtools.html

    FYI, Fore people have ignored attempts to get the Fore MIB
    modules fixed even if those attempts were made from within
    Marconi. Nevertheless, I wish you good luck to get the modules
    fixed (by them).

    Regards,
    Frank Fock

    T wrote:

    >I posted previously asking specifically about a couple of errors in two
    >Fore MIB modules (Fore-Switch.mib and Fore-traplog.mib). I cannot get
    >these to compile. I am new to MIBs and have been trying to understand
    >what changes need to be made to these MIBs to get them to compile (it
    >has been days now). Based on the previous response to this request I
    >have notified the vendor that the MIBs are believed to be out of
    >compliance. However, I need a workaround. Thus, modified MIBs until I
    >can get this resolve through the proper channels. Also, I anticipate a
    >little finger pointing between the vendor and MG-soft as to the
    >interpretation of the standard. These two MIBs compile fine with HP
    >Openview and the vendor's compiler (not sure what they are using). The
    >product I am looking to integrate has MG-Soft as its backend compiler.
    >Thus, I need an intermediate solution until I can find enough
    >convincing evidence that the issue is with the MIBs or is with MG-Soft.
    > Both have strong arguments, but it could result in a standoff (i.e.
    >the MIBs compile with other browsers vs. the MIB is out of spec.) My
    >guess is that some compilers are more lenient than others. If I point
    >to the MIBs, I would like to know exactly how they do not comply (this
    >is defined in a previous post for Error 35, but not for the other
    >errors in these two MIBs). Also, being new to MIBs, I would like to
    >ask if someone would be willing to walk me through the changes needed
    >to effectively correct these MIBs such that they meet the standards
    >MG-Soft is stating they violate without affecting the intended effect
    >of the MIB.
    >
    >Help on this is appreciated.
    >
    >T
    >
    >
    >


  4. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    "T" writes:
    >I posted previously asking specifically about a couple of errors in two
    >Fore MIB modules (Fore-Switch.mib and Fore-traplog.mib). I cannot get
    >these to compile. I am new to MIBs and have been trying to understand
    >what changes need to be made to these MIBs to get them to compile (it
    >has been days now). Based on the previous response to this request I
    >have notified the vendor that the MIBs are believed to be out of
    >compliance. However, I need a workaround. Thus, modified MIBs until I
    >can get this resolve through the proper channels.


    OK, let's look at the reported "Error 35" in the Fore-Switch-MIB as
    relates to q2931AFTemplateTable:

    q2931AFTemplateTable OBJECT-TYPE
    SYNTAX SEQUENCE OF Q2931AFTemplateEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
    "A table of allowable (or rejectable) NSAP source and
    destination addresses."
    ::= { q2931AddressFilterGroup 1 }

    q2931AFTemplateEntry OBJECT-TYPE
    SYNTAX Q2931AFTemplateEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
    "A table entry containing NSAP address filtering
    information."
    INDEX { q2931AFTemplateIndex }
    ::= { q2931AFTemplateTable 1 }

    Q2931AFTemplateEntry ::= SEQUENCE {
    q2931AFTemplateIndex Integer32,
    q2931AFTemplateSrcPort Integer32,
    q2931AFTemplateSrcVPI Integer32,
    q2931AFTemplateSrcNsap NsapAddr,
    q2931AFTemplateSrcNsapMask Integer32,
    q2931AFTemplateDstPort Integer32,
    q2931AFTemplateDstVPI Integer32,
    q2931AFTemplateDstNsap NsapAddr,
    q2931AFTemplateDstNsapMask Integer32,
    q2931AFTemplateAction INTEGER,
    q2931AFTemplateName OCTET STRING,
    q2931AFTemplateStatus RowStatus
    }

    [ ... ]

    q2931AFTemplateStatus OBJECT-TYPE
    SYNTAX RowStatus
    MAX-ACCESS read-write
    STATUS current
    DESCRIPTION
    "The status of this table entry. This entry may not
    be destroyed if there are any filter entries that
    refer to it."
    ::= { q2931AFTemplateEntry 12 }

    q2931AFTemplateNextIndex OBJECT-TYPE
    SYNTAX TestAndIncr
    MAX-ACCESS read-write
    STATUS current
    DESCRIPTION
    "The index of the next free row in the
    q2931AFTemplateTable."
    ::= { q2931AFTemplateTable 2 }

    The "Error 35" results because one is NOT allowed to put the scalar
    q2931AFTemplateNextIndex immediately beneath q2931AFTemplateTable.

    So, my question is: what do you intent to do with this table?

    If you don't intend to create any rows in it, then you do not
    care what is the next free index. You can discover all the
    rows by a MIB walk. And in that case you could just delete the
    definition of q2931AFTemplateNextIndex. A MIB walk would cause
    you to retrieve q2931AFTemplateNextIndex after finishing with
    the table, and that object would be unknown, but a properly coded
    management app should be able to cope with that. Note that this
    is not the only errant object that would need to be excised.

    If you do intend to create new rows in this table then I am not
    sure what to tell you, for in this case there is another bug:
    all columns in a table that allows dynamic creation of rows
    should have a MAX-ACCESS if read-create, not read-write. This
    MIB module is so non-standard that I wonder if the designers
    decided to have successful writes to q2931AFTemplateNextIndex
    (which cause it to increment -- see RFC 2579) create a row as
    a side effect. Maybe, but then again maybe not ... maybe they
    just wrote read-write where they meant read-create.

    >Also, I anticipate a
    >little finger pointing between the vendor and MG-soft as to the
    >interpretation of the standard. These two MIBs compile fine with HP
    >Openview and the vendor's compiler (not sure what they are using). The
    >product I am looking to integrate has MG-Soft as its backend compiler.
    >Thus, I need an intermediate solution until I can find enough
    >convincing evidence that the issue is with the MIBs or is with MG-Soft.
    >Both have strong arguments, but it could result in a standoff (i.e.
    >the MIBs compile with other browsers vs. the MIB is out of spec.)


    The MIB module is out of spec. That's not subject to debate.

    >My guess is that some compilers are more lenient than others.


    Yep. The compilers that accept it are also out of spec.

    >If I point
    >to the MIBs, I would like to know exactly how they do not comply (this
    >is defined in a previous post for Error 35, but not for the other
    >errors in these two MIBs). Also, being new to MIBs, I would like to
    >ask if someone would be willing to walk me through the changes needed
    >to effectively correct these MIBs such that they meet the standards
    >MG-Soft is stating they violate without affecting the intended effect
    >of the MIB.


    Sorry, I don't have the time to give you detailed help.

    nobody

  5. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    Hi,

    In your MIB file.

    q2931AFTemplateNextIndex OBJECT-TYPE
    SYNTAX TestAndIncr
    MAX-ACCESS read-write
    STATUS current
    DESCRIPTION
    "The index of the next free row in the
    q2931AFTemplateTable."
    ::= { q2931AFTemplateTable 2 }

    You can NOT put the scalar q2931AFTemplateNextIndex in the table
    q2931AFTemplateTable.

    I think that's the point. And you don't need to add the ..nextindex
    scalar.

    Regards,
    Robie


  6. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    nobody wrote:
    > The MIB module is out of spec. That's not subject to debate.
    >
    > >My guess is that some compilers are more lenient than others.

    >
    > Yep. The compilers that accept it are also out of spec.


    I agree that the mib is busted. The question is, what's the right thing
    for a mib compiler to do about it?

    There is no doubt that it's useful to have compilers which are very strict.
    I used to use SMIC-NG; it was extremely picky about syntax. It would
    simply refuse to process a mib if anything was out of spec. For a mib
    author, that's an excellent tool to have. For an agent developer, that's
    probably a good tool too.

    But, for the average Joe NOC Operator, it's a terrible tool. All the JNO
    wants (most of the time) is to be able to map a name to a numeric oid so he
    can get a value. We used to spend days trying to get some mibs to compile,
    often because of picayune errors in stuff that just wasn't important (i.e.
    a date in the MODULE-IDENTITY section was formatted wrong). There is value
    in a tool which will ignore as many mib errors as possible and just keep
    building name->oid mappings as best as it can.

    BTW, the above three paragraphs are busted. Almost everyplace I wrote
    "mib", I really meant "mib module". Did you get this far, or did you stop
    processing my posting at the first syntax error?

  7. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    I totally agree that the MIB definition is broekn... I also agree that
    the MIB compiler caught this and stands on its ruling. (Too often, some
    vendors have gotten real SLOPPY with their MIB compilers.)

    What would I do in this situation?

    1. Contact the vendor and open up a Ticket with them if I have access
    to support.

    2. Take the offending portion of the definition out of the MIB
    definition and do not use it. After all, the MIB definition is a
    Schema Definition of the elements and structure of the Data the Agent
    is supposed to support. in effect, edit it out.

    3. Test this by doing a Walk against the agent to see if it does return
    the offending data faux pah. You may still be able to get to the data
    but not within a given name mapping back to an OID.

    HTH,

    Dougie!!!

    Douglas W. Stevenson
    ENMS Propellor Head
    http://www.phaults.com


  8. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    Roy Smith wrote:
    > nobody wrote:
    > > The MIB module is out of spec. That's not subject to debate.
    > >
    > > >My guess is that some compilers are more lenient than others.

    > >
    > > Yep. The compilers that accept it are also out of spec.

    >
    > I agree that the mib is busted. The question is, what's the
    > right thing for a mib compiler to do about it?


    Indeed.

    > There is no doubt that it's useful to have compilers which are
    > very strict. I used to use SMIC-NG; it was extremely picky about
    > syntax. It would simply refuse to process a mib if anything was
    > out of spec. For a mib author, that's an excellent tool to
    > have. For an agent developer, that's probably a good tool too.


    For just doing syntax checking it pays to use a MIB compiler that
    strictly enforces the SMI rules and that also warns about bad
    practices. Making this part of one's review process (as is now
    done in the IETF) is one way to help prevent broken stuff from
    ending up in the field.

    > But, for the average Joe NOC Operator, it's a terrible tool.
    > All the JNO wants (most of the time) is to be able to map a name
    > to a numeric oid so he can get a value. We used to spend days
    > trying to get some mibs to compile, often because of picayune
    > errors in stuff that just wasn't important (i.e. a date in the
    > MODULE-IDENTITY section was formatted wrong). There is value in
    > a tool which will ignore as many mib errors as possible and just
    > keep building name->oid mappings as best as it can.


    For sure, even a picky MIB compiler should do its best to produce
    output when that's what you've asked it to do. It's a poor tool
    that simply stops and gives up.

    On the other hand, how much broken stuff can be reasonably tolerated
    depends on what the MIB compiler is asked to produce. For just
    doing simple browsing, the descriptor->OID mappings indeed do suffice,
    and that is usually very easy to generate except perhaps in the
    presence of really egregious syntax errors. However, if you have a
    complicated MIB module with read-create tables, and you want to
    generate manager-side code to deal with them, it's another story.

    > BTW, the above three paragraphs are busted. Almost everyplace I
    > wrote "mib", I really meant "mib module". Did you get this far,
    > or did you stop processing my posting at the first syntax error?


    Heh. I noticed :-) But seriously, even if all you want to do is
    a syntax check, a tool that stops after the first error (instead
    of continuing on if it can) is a huge waste of time. That's dumb
    for a tool, and it's dumb for a human, too.

    nobody

  9. Re: Can't Compile 2 MIB Modules with MG-Soft Compiler

    Roy Smith wrote:

    > But, for the average Joe NOC Operator, it's a terrible tool. All the JNO
    > wants (most of the time) is to be able to map a name to a numeric oid so he
    > can get a value. We used to spend days trying to get some mibs to compile,
    > often because of picayune errors in stuff that just wasn't important (i.e.
    > a date in the MODULE-IDENTITY section was formatted wrong). There is value
    > in a tool which will ignore as many mib errors as possible and just keep
    > building name->oid mappings as best as it can.


    I frankly disagree. The real reason JNO has to spend much time on
    fixing MIB modules is caused by the fact that market leaders ship
    lousy MIB parsers. I am so tired of vendors telling me that their
    MIB modules are fine because GO-PW accepts them, even if the modules
    exhibit clear flaws that reasonable MIB compilers are able to detect
    for more than a decade.

    /js

    --
    Juergen Schoenwaelder International University Bremen
    P.O. Box 750 561, 28725 Bremen, Germany

+ Reply to Thread