FAQ:Coding 08

What's the difference between the various mib2c configuration files?

Most of the mib2c config files are concerned with implementing MIB tables, and generate various alternative code templates. These basically fall into four distinct categories.

There are various alternative configuration templates for mib2c, mostly concerned with implementing MIB tables. These basically fall into four distinct categories.

'mib2c.raw-table.conf' is the lightest of the templates, and just provides a fairly basic table framework. Most of the work of implementing the table - detecting which row is required for a given request, retrieving or updating the relevant column values, and interacting with the underlying subsystem - are all left to the MIB programmer.

The second group of templates - 'table_data', 'container' and 'row' - all share the same basic model (although the internal details are rather different). The MIB implementer should define a data structure to represent a row of the table, and the helper then takes care of holding the table internally, as a collection of such per-row data structures. This includes identifying which row is required for a given request. Retrieving or updating the appropriate column value is left to the MIB programmer, although the generated framework includes most of the necessary code. Allied to this is a fourth "internal data" mib2c configuration file ('create-dataset') which handles the individual columns as well. This is the closest to a Plug-and-Play configuration, and the MIB implementer only needs to be concerned with any special processing, such as linking the table with the underlying subsystem.

The specific style of data access for these four schemes is:

1. table_data uses the agent/table_tdata.h style
2. container uses the agent/table_container.h style
3. row uses the agent/table_data.h style
4. create-dataset uses the agent/table_dataset.h style

The third style of mib2c config assumes that the table data is held externally to the helper - either within the MIB module code itself, or in the external subsystem. The generated code framework includes routines to "iterate" through the rows of the table, with the iterator helper simply deciding which row is required for a particular request. Once again, the MIB programmer must handle retrieving or updating the appropriate column value, although the generated framework includes most of the necessary code. There is a variant of this config ('iterate_access') which works in basically the same way. However this tries to separate out the standard processing, from the code that needs to be amended by the programmer for retrieving and updating the individual column values.

This is also the idea behind the final table-oriented mib2c config template - 'mib2c.mfd.conf' (or "MIBs for Dummies"). This is a much more flexible framework, which can be used with either internally held data, or iterating through an external representation. The distinguishing feature of this framework is that it separates out standard and table-specific processing, at a much finer level of detail than the others.

The other mib2c config templates are concerned with implementing scalar objects ('scalar', 'int_watch'), code to generating traps ('notify'), and various specialised requirements. There is also a template ('old-api') to generate code suitable for the previous v4 UCD agent - though this is not particularly complete or reliable. It's probably better to use a pure v4 mib2c environment (or switch wholeheartedly to the v5 style).

   FAQ:Coding
   

1. How do I write C code to integrate with the agent?
2. How does the agent fetch the value of a MIB variable from the system?
3. Mib2c complains about a missing "mib reference" - what does this mean?
4. Mib2c complains about not having a "valid OID" - what does this mean?
5. Why doesn't mib2c like the MIB file I'm giving it?
6. Mib2c ignores my MIB and generates a pair of 'mib-2' code files. Why?
7. What's the difference between the various mib2c configuration files?
8. Which mib2c configuration file should I use?
9. How can I have mib2c generate code for both scalars and tables?
10. Are there any examples, or documentation for generating MIB modules?
11. Where should I put the files produced by 'mib2c'?
12. Why doesn't my new MIB module report anything?
13. Why does the iterator call my get_{first,next} routines so often?
14. How can I get the agent to generate a trap (or inform)?
15. How can I get an AgentX sub-agent to generate a trap (or inform)?
16. How can I get the agent to send an SNMPv1 (or SNMPv2c) trap?
17. How can I get the agent to include varbinds with an SNMPv1 trap?
18. How can I get the agent to send an SNMPv1 enterprise-specific trap?
19. How can I get the agent to send an SNMPv3 trap (or inform)?
20. Why does calling 'send_v2trap' generate an SNMPv1 trap (or vice versa)?
21. How can I register a MIB module in a different (SNMPv3) context?