Latest revision as of 12:09, 28 May 2009

The parser doesn't handle comments properly. Why not?

The way that comments are handled in a MIB file is subtly different to the equivalent syntax in most typical programming languages, and this difference can catch out the unwary. In particular, there are two common situations which can lead to problems.

The first scenario is where the MIB designer has attempted to "comment out" an unwanted line that already contains a comment:

       --   broken ::= { myMIB 1 }   -- This isn't working yet

The assumption here is that a comment continues to the end of the line. Unfortunately, this is not correct. A comment will continue either to the end of the line, or the next occurance of a pair of dashes.

Thus in this case, the definition of "broken" is commented out (as untended) but the following text ("This isn't working yet") is treated as an active part of the MIB, and will generate an error.

The second scenario is where a line of dashes has been used to mark out separate parts of a MIB file. Depending on the exact number of dashes used, this may still result in a syntactically valid MIB file, but has a 1-in-4 possibility of triggering an error. This means that this particular situation can be particularly difficult to spot!

Most of the Net-SNMP applications have a command-line option (-Pc) which will work around this problem by treating the whole line as a comment. But this is not strictly legal, and the offending MIB file should really be corrected.

   FAQ:MIBs
   

1. Where can I find a MIB compiler?
2. Why aren't my MIB files being read in?
3. Where should I put my MIB files?
4. What does "Cannot find module (XXX-MIB)" mean?
5. I'm getting answers, but they're all numbers. Why?
6. What does "unlinked OID" mean?
7. The parser doesn't handle comments properly. Why not?
8. How can I get more information about problems with MIB files?
9. What's this about "too many imported symbols"?
10. Do I actually need the MIB files?