Difference between revisions of "SNMP MIB Implementation"

From OpenCircuits
Jump to navigation Jump to search
Line 17: Line 17:
 
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].
 
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].
 
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].
 
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].
 
  
 
===Abstract Syntax Notation===
 
===Abstract Syntax Notation===
 
*Each MIB variable contains several attributes, such as data type, access type and object identifier.
 
*Each MIB variable contains several attributes, such as data type, access type and object identifier.
 
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.
 
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.
 +
  
 
==Convert MIB to Binary File==
 
==Convert MIB to Binary File==
Line 58: Line 58:
 
* if oid_i < 254: oid_i = char (oid_i)
 
* if oid_i < 254: oid_i = char (oid_i)
 
* else oid_i = char(255) + char(length of oid_i) + oid_i (base 255) + char(16)
 
* else oid_i = char(255) + char(length of oid_i) + oid_i (base 255) + char(16)
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font>
+
* where
  This is an workaround to store oids, but this isn't a standard representation or the microchip format.
+
** char(x) that's mean get ascii of x.
* <font color=red>What does char(.) mean?</font>
+
** char(16) is used to separate two oids.
  char(x) that's mean get ascii of x.
+
** char(255) is determined that oid geater than 254.
  char(16) is used to separate two oids.
+
** "length of oid_i" is length string of oid_i that's converted base 255.
  char(255) is determined that oid geater than 254.
+
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254
  "length of oid_i" is length string of oid_i that's converted base 255.
+
* <font color=red>Can you give an example</font>
  
 
====<nodeInfo> field====
 
====<nodeInfo> field====
Line 80: Line 80:
 
====[id] field====
 
====[id] field====
 
* If this record is leaf, id that's reference to function services the record.
 
* If this record is leaf, id that's reference to function services the record.
* <font color=red>leaf means child?</font>
 
  leaf means child, but child doesn't mean leaf.
 
  the comment fixed.
 
  
 
====[distantSiblingOffset] field====
 
====[distantSiblingOffset] field====
 
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.
 
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.
* <font color=red>root node should have no sibling. How come the example (below) has a distant offset BC000000? Also, is it big-endian or little-endian?</font>
+
* In little-endian format.
  distant offset point to next node sibling (that's "NULL" node).It's little-endian.
+
* The last node's distant offset is set to 0x00000000 to parse easier <font color=red>(is this a standard?)</font>.
  To parse easier, The last node's distant offset is set to 0x00000000.
 
  
 
====[siblingOffset] field====
 
====[siblingOffset] field====
 
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.
 
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font>
 
 
   siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling).  
 
   siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling).  
 
   They're only differences:
 
   They're only differences:
Line 98: Line 93:
 
       distantSiblingOffset use with node.
 
       distantSiblingOffset use with node.
 
   so it's same value.
 
   so it's same value.
 +
* <font color=red>So, this means there will never be nodes with different siblingOffset and distantSiblingOffset?</font>
  
 
====[dataType], [dataLen], [data] fields====
 
====[dataType], [dataLen], [data] fields====
Line 104: Line 100:
 
** [dataLen] is length of data.
 
** [dataLen] is length of data.
 
** [data] is data on string.
 
** [data] is data on string.
* <font color=red>How many dataType does it support?</font>
+
* The tool supports the following data types:
  The tool support types:
+
** INTEGER
      INTEGER
+
** OCTETSTRING
      OCTETSTRING
+
** Gauge
      Gauge
+
** TimeTicks
      TimeTicks
+
** Counter
      Counter
+
** DisplayString (ascii string)
      DisplayString (ascii string)
+
** IpAddress
      IpAddress
+
** Opaque
      Opaque
+
** SEQUENCE
      SEQUENCE
+
* <font color=red>Can you describe more about each datatype? For example, What is gauge? What kind of values it will take? Is this a complete list defined in SNMP protocol?</font>
  
 
====[{<index_number>}]====
 
====[{<index_number>}]====
* If this record is sequence, index_number is number of INDEXes in sequence.
+
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.
 
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]
 
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]
 
* If this record is sequence
 
* If this record is sequence
Line 123: Line 119:
 
** <IndexNodeInfo>: is info of index_node
 
** <IndexNodeInfo>: is info of index_node
 
** <indexDataType>: is data type of index_node
 
** <indexDataType>: is data type of index_node
* <font color=red>What kind of data will be a sequence node?</font>
+
* <font color=red>Can you give an example?</font>
  Sequence is An ordered list of objects, somewhat like a struct in the C language.
 
  Type of objects in sequence is same type of node
 
  
 
===Example===
 
===Example===
Line 141: Line 135:
 
   Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].
 
   Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].
  
* The detail description of mchip.bin is illuminated by structure diagram below <font color=red>can you upload a picture with higher resolution?</font>:
+
* The detail description of mchip.bin is illuminated by structure diagram below:
  This is picture with higher resolution.
 
 
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]
 
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]
  

Revision as of 00:54, 4 October 2010

This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.

Steps

  1. Create a ASN.1 MIB script foo.mib (an ASCII text file) for the tree structure.
  2. Convert foo.mib to binary file using mib2bin
  3. Build snmp's PDU use BER (Base encoding rules) encoder and decoder library to process data that's transfer between NMS and agents.
  4. Build snmp API use uIP-stack to communicate between NMS and Agents (open two ports: The manager speak to agents on one port, the agent responds manager on the other port).
  5. Build binary MIB file reader library.
  6. Build functions service oid tree.
  7. Merge MIB ANS.1 file to NMS.


Create ASN.1 MIB Script

Abstract Syntax Notation

  • Each MIB variable contains several attributes, such as data type, access type and object identifier.
  • Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.


Convert MIB to Binary File

  • mib2bin tool is modified from net-snmp to convert ASN.1 format file to three files, because the microchip mib2bib converter only supports upto 255 OIDs.
                                MIB compiler tools: mib2bin
 foo.mib (ANS.1 format)   -----------------------------------> foo.bin + foo.h + foo_data.h
  • Syntax to use mib2bin tool:
  mib2bin <MIBfile>...
  • where MIBfile file is ASN.1 format file. MIBfile = <name>.<type>
    • <name>.bin is the binary file storing information of OID tree. This file can be placed on an SD media card to be read by the FAT16 file system.
    • <name>_data.h is C header file storing information of OID tree. This file is generated by converting mchip.bin file to the C header file. It's only used when a system don't have system file and place on program memory.
    • <name>.h is C header file storing ID that's reference to function service of OID.
  • Note:
    • Subfolder mibs containing the basics MIB files (e.g.: RFC1155-SMI, RFC1213-MIB, RFC-1215, SNMPv2-MIB ... for us MIB file), must be present under the directory of execution.
    • If the three files exist, mib2bin tool will overwrite the files.

Binary File Format

  • The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.
  • In the binary file, A parent is stored first, followed by its last-child to first-child. Next, the structure of next this parent is stored. This structure is repeated until the entire tree is stored.
  • A parent or child is a record. Single record of binary file have format:
 <oid>, <nodeInfo>, 
 [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], 
 [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]
 
 where:
 fields indicated by angle brackets (< >) are always present
 fields in square brackets ([ ]) are optional depending on characteristics of the current node.
 fields in braces ({}) are optional but always occur together.

<oid> field

  • Format of OID:
  oid1 char(16)
  oid2 char(16)
  ....
  • if oid_i < 254: oid_i = char (oid_i)
  • else oid_i = char(255) + char(length of oid_i) + oid_i (base 255) + char(16)
  • where
    • char(x) that's mean get ascii of x.
    • char(16) is used to separate two oids.
    • char(255) is determined that oid geater than 254.
    • "length of oid_i" is length string of oid_i that's converted base 255.
  • The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254
  • Can you give an example

<nodeInfo> field

  • information of node
  bit        when (set = 1)
  0          Node is a parent (0: node is a leaf)
  1          Node is sequence
  2          Node is readable
  3          Node is writable
  4          Node is able to create
  5          Node has default data
  6          (if node is sequence, this is mean implied index node)
  7          always set 1

[id] field

  • If this record is leaf, id that's reference to function services the record.

[distantSiblingOffset] field

  • If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.
  • In little-endian format.
  • The last node's distant offset is set to 0x00000000 to parse easier (is this a standard?).

[siblingOffset] field

  • If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.
  siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). 
  They're only differences:
     siblingOffset use with leaf node.
     distantSiblingOffset use with node.
  so it's same value.
  • So, this means there will never be nodes with different siblingOffset and distantSiblingOffset?

[dataType], [dataLen], [data] fields

  • If this record is a leaf and has default data
    • [dataType] is type of leaf's data.
    • [dataLen] is length of data.
    • [data] is data on string.
  • The tool supports the following data types:
    • INTEGER
    • OCTETSTRING
    • Gauge
    • TimeTicks
    • Counter
    • DisplayString (ascii string)
    • IpAddress
    • Opaque
    • SEQUENCE
  • Can you describe more about each datatype? For example, What is gauge? What kind of values it will take? Is this a complete list defined in SNMP protocol?

[{<index_number>}]

  • If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.
    • [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]
  • If this record is sequence
    • <IndexCount>: is index of INDEX in table
    • <IndexNodeInfo>: is info of index_node
    • <indexDataType>: is data type of index_node
  • Can you give an example?

Example

  • The example mchip.txt describe the OID tree given below:
Snmp mib oid tree example.jpg
  • The corresponding binary file is mchip.bin and it has data describe in table below:
Snmp mib binary example.jpg
  OID is <oid> fields.
  Info is <nodeInfo> fields.
  Dist is [distantSiblingOffset]/[siblingOffset] fields.
  Id is [id] fields.
  Defval is data fields, include [dataType], [dataLen], [data] fields.
  Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].
  • The detail description of mchip.bin is illuminated by structure diagram below:
Snmp mib binary detail example.jpg
  The hidden linear is oid tree structure.
  The red and green continue linear is pointer  of data.
  The dist field point to next sibling record. After parent record is it's children.