http://www.opencircuits.com/api.php?action=feedcontributions&user=Tcwden&feedformat=atomOpenCircuits - User contributions [en]2024-03-29T06:49:30ZUser contributionsMediaWiki 1.34.2http://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=20909SNMP MIB Implementation2011-05-06T06:30:11Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html SNMP's PDU using BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build SNMP API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to four files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo_trap.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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 FAT32 file system.<br />
** '''<name>_trap.bin''' is the binary file storing information of TRAP of MIB. This file can be placed on an SD media card to be read by the FAT32 file system.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the four files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format <name>.bin===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* In the binary file, A parent is stored first, followed by its first-child to last-child. Next, the structure of next this parent is stored. This structure is repeated until the entire tree is stored.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>}, {<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
* where:<br />
** fields indicated by angle brackets (< >) are always present<br />
** fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
** fields in braces ({ }) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* The microchip format only supports OIDs upto 255. The following is an workaround to store OID greater than 255.<br />
* Format of OID:<br />
An OID is a series of (one or more) octets (e.g. 04 01 82 99 5D). Bit 8 of each octet indicates whether it is the last octet in the series: <br />
If bit 8 of is zero, it is the last octet (e.g. 04, 01, 5D), otherwise, bit 8 is set to one (e.g. 82, 99).<br />
<br />
Bits 7 to 1 of the octets are used to encode the OID. Conceptually, these bits are concatenated to form an unsigned binary number whose most <br />
significant bit (bit 7) of the first octet and the least significant bit (bit 1) of the last octet. The OID shall be encoded in the fewest <br />
possible octets, that is, the leading octet of the OID shall not have the value 0x80.<br />
* Example:<br />
The OID encode of OID in binary file (hex)<br />
4 BYTE(0x04)<br />
1 BYTE(0x01)<br />
36061 BYTE(0x80 + 0x02) BYTE(0x80 + 0x19) BYTE(0x5D)<br />
The OID = 36061 is decoded by 0x02*0x80*0x80 + 0x19*0x80 + 0x5D<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node has sibling node<br />
1 Node has default data<br />
2 Node is sequence <br />
3 Node is readable<br />
4 Node is a parent<br />
5 Node is writable <br />
6 Node is able to modify<br />
7 Node has sibling field (in IndexNodeInfo this bit indicate that Indexes is imply)<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType] field====<br />
*If this record is a leaf<br />
** [dataType] is type of leaf's data.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is id of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* See [http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example] of accessing data in a table<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x05<br />
<IndexNodeInfo> = 0x28<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x08<br />
<IndexNodeInfo> = 0xA4<br />
<IndexDataType> = 0x04<br />
In this example, '''trap''' is a table which has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row defined in the '''trap''' table. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has id = 5, info is 0x28 and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0x28<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has id = 8, info is 0xA4 and data type is DisplayString (0x04). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0xA4<br />
IndexDataType = 0x04<br />
<br />
===Binary File Format <name>_trap.bin===<br />
* The binary file store TRAP information. It is generated by mib2bin tool. Agents will read binary file to get information of TRAP when something bad occurs.<br />
* In the binary file, An enterprise OID is stored first, followed by its first specific trap number and ID (this ID matches with ID of leaf in <name>.bin) <font color=red>data bindings to be included in this trap to last specific trap number and ID data bindings to be included it. Next, the structure of next this enterprise is stored. This structure is repeated until all enterprise in MIB file is stored.</font><br />
* The format of enterprise in <name>_trap.bin<br />
<enterprise_oid><sibling_enterprise><enterprise_index>[specific_trap_number][sibling_specific_trap][number_varbinds][id_varbind]...<br />
* where:<br />
** fields indicated by angle brackets (< >) are always present.<br />
** fields in square brackets ([ ]) are optional depending on characteristics of the trap.<br />
<br />
====<enterprise_oid> field====<br />
* Enterprise oid is full oid of enterprise trap that want to send in MIB file.<br />
* The format of enterprise oid. <br />
<sub_oid> <info_sub_oid> ... <br />
* where:<br />
** <font color=red><sub_oid>:</font> is same format of <oid> field in MIB file.<br />
** <font color=red><info_sub_oid>:</font> Information of sub_oid.<br />
<info_sub_oid> format:<br />
bit when (set = 1)<br />
0 the first sub_oid in enterprise<br />
1 no use<br />
2 no use<br />
3 no use<br />
4 sub_oid is a parent<br />
5 no use<br />
6 no use<br />
7 the last sub_oid in enterprise<br />
* If <sub_oid> == BYTE (0x00) and <info_sub_oid> == BYTE(0xFF), this is the end of infomation traps.<br />
<br />
====<sibling_enterprise> field====<br />
* Point to next enterprise OID.<br />
* In little-endian format.<br />
====<enterprise_index> field====<br />
* Index of enterprise OID traps in <name>_trap.bin file.<br />
* Size of <enterprise_index> is 1 byte.<br />
====[specific_trap_number] field====<br />
* If the trap is sent is specific trap, specific trap number is a number indicting specific trap.<br />
* specific trap number is integer in little-endian format.<br />
====[sibling_specific_trap] field====<br />
* Point to next specific trap.<br />
* In little-endian format.<br />
====[number_varbinds] field====<br />
* A number of data bindings to be included in the specific trap.<br />
* Size of [number_varbinds] is 1 byte.<br />
====[id_varbind] field====<br />
* [id_varbind] define data bindings (OID and value of OID leaf) that is included specific trap.<br />
* [id_varbind] is reference to id of the leaf oid in <name>.bin.<br />
* In little-endian format.<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File <name>.bin====<br />
* The corresponding binary file is <name>.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''type''' is [dataType] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of <name>.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File <name>_trap.bin====<br />
* The corresponding binary file is <name>_trap.bin and it has data describe in table below:<br />
** '''enterp''' is <enterprise_oid> fields.<br />
** '''sibl_ep''' is <sibling_enterprise> fields.<br />
** '''index_ep''' is <enterprise_index> fields.<br />
** '''spec_id''' is [specific_trap_number] fields.<br />
** '''sibl_sid''' is [sibling_specific_trap] fields.<br />
** '''num_var''' is [number_varbinds] fields.<br />
** '''id_var''' is [id_varbind] fields.<br />
[[File:Snmp mib binary trap example.jpg | thumb | center | 900px]]<br />
<br />
==[http://www.rane.com/note161.html=Build SNMP's PDU using BER]==<br />
* SNMP is the protocol that allows communicate between NMS and agents by exchanging SNMP messages. the SNMP message is a single field, of the Sequence type. SNMP message use data types specified by ASN.1 and use Basic Encoding Rules (BER) to encode data. The entire SNMP message is a Sequence of three smaller fields: the SNMP Version (Integer), the SNMP Community String (Octet String), and the SNMP PDU. <br />
* The SNMP's PDU is reference to SNMP version 1 (SNMPv1) PDU.<br />
* SNMPv1 PDU have five different PDU types:GetRequest, GetNextRequest, GetResponse, SetRequest and Trap.<br />
* Get Request, GetNext Request, Get Response, Set Request are same format PDU. Trap use other format PDU.<br />
===ASN.1 data types===<br />
* ASN.1 data types fall into two categories: primitive and complex.<br />
* ASN.1 data types is used to build SNMP messages.<br />
** ASN.1 primitive data types include Integer, Octet (byte, character) String, Null, Boolean and Object Identifier.<br />
** ASN.1 complex data types are used to build SNMP message are Sequence type, Sequence-of type.<br />
<br />
===[http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBgQFjAA&url=http%3A%2F%2Fwww.itu.int%2FITU-T%2Fstudygroups%2Fcom17%2Flanguages%2FX.690-0207.pdf&rct=j&q=x.690-0207&ei=cde_TcrvJouMvQOm5-jABA&usg=AFQjCNGYmD4USBwcWoeHoRFZ3zdP39kosw&cad=rja=Basic Encoding Rules (BER)]===<br />
* BER has three parts: Type, Length and Data field.<br />
BER format: <br />
+------+--------+------+<br />
| Type | Length | Data |<br />
+------+--------+------+<br />
<br />
* Type field is single byte identifier.<br />
'''Constructing byte Data type.'''<br />
Format of byte Data type<br />
+--+-+-----+<br />
| | | +<br />
+--+-+-----+<br />
2 1 5<br />
Bits 8 and 7 shall be encoded to represent the class of Data type follow table:<br />
+------------------+-------+-------+<br />
| Class | Bit 8 | Bit 7 |<br />
+------------------+-------+-------+<br />
| Universal | 0 | 0 |<br />
| Application | 0 | 1 |<br />
| Context-specific | 1 | 0 |<br />
| Private | 1 | 1 |<br />
+------------------+-------+-------+<br />
Bit 6 is encoded data is Primitive or Constructed follow table:<br />
+-------+-------------+<br />
| Bit 6 | Type |<br />
+-------+-------------+<br />
| 0 | Primitive |<br />
| 1 | Constructed |<br />
+-------+-------------+ <br />
Bits 5 to 1 encode the number of Data type as a integer number. <br />
<br />
'''Data type identifier in SNMP'''<br />
'''Data type''' '''Identifier''' '''Note'''<br />
Integer 0x02 Primitive ASN.1 types<br />
Octet String 0x04 Primitive ASN.1 types <br />
Null 0x05 Primitive ASN.1 types<br />
Object identifier 0x06 Primitive ASN.1 types<br />
Sequence 0x30 Constructed ASN.1 types<br />
IpAddress 0x40 Primitive SNMP application types<br />
Counter 0x41 Primitive SNMP application types<br />
Gauge 0x42 Primitive SNMP application types<br />
TimeTicks 0x43 Primitive SNMP application types <br />
Opaque 0x44 Primitive SNMP application types<br />
NsapAddress 0x45 Primitive SNMP application types<br />
GetRequest PDU 0xA0 Context-specific Constructed SNMP types<br />
GetNextRequest PDU 0xA1 Context-specific Constructed SNMP types<br />
GetResponse PDU 0xA2 Context-specific Constructed SNMP types<br />
SetRequest PDU 0xA3 Context-specific Constructed SNMP types<br />
Trap PDU 0xA4 Context-specific Constructed SNMP types<br />
* Length field is the number of bytes in Data field.<br />
** Length field is used either the short form or the long form as a option depend on Data field.<br />
*** The short form, Length field is a single octet in which bit 8 is zero and bits 7 to 1 encode the number of bytes in Data field, as an unsigned binary integer with bit 7 as the most significant bit.<br />
*** The long form, Length field shall consists of an initial octet and one or more subsequent octets.<br />
**** The initial octet is encoded as follows:<br />
***** Bit 8 shall be one.<br />
***** Bits 7 to 1 shall encode the number of subsequent octets in the length field, as an unsigned binary integer with bit 7 as the most significant bit.<br />
***** The value 0xFF shall not be used.<br />
**** Subsequent octets:<br />
***** From the first subsequent octet to the last subsequent octet, shall be the encoding of an unsigned binary integer equal to the number bytes in Data field, with bit 8 of the first subsequent octet as the most significant bit.<br />
* Data field is actual data content.<br />
<br />
* Example:<br />
Actual Data is an integer, the value 100 can be encode as:<br />
The short form:<br />
+------+--------+-------+<br />
| Type | Length | Data |<br />
+------+--------+-------+<br />
| 0x02 | 0x01 | 0x64 |<br />
+------+--------+-------+<br />
The long form:<br />
+------+-----------+-------+<br />
| Type | Length | Data |<br />
+------+-----------+-------+<br />
| 0x02 | 0x81 0x01 | 0x64 |<br />
+------+-----------+-------+<br />
===SNMP Message Format===<br />
* SNMP Message is a Sequence of three smaller fields: the SNMP Version (Integer), the SNMP Community String (Octet String), and the SNMP PDU.<br />
SNMP Message Format use BER.<br />
+------------------------------------------------------------------------+<br />
| SNMP Message (Sequence type) |<br />
+------+----------------+------------------------------------------------+<br />
| Type | Length of Data | Data |<br />
+------+----------------+-------------+-----------------------+----------+<br />
| 0x30 | Length |SNMP Version | SNMP Community String | SNMP PDU | <br />
| | | (Integer) | (Octet String) | |<br />
+------+----------------+-------------+-----------------------+----------+<br />
|<--------------------Length-------------------->|<br />
* Length is bytes of Data field (SNMP Version, SNMP Community String and SNMP PDU).<br />
* SNMP Version is an integer that identifies the version of SNMP, SNMP version 1 = 0.<br />
* SNMP Community String is an Octet String to add security to Agents.<br />
* SNMP PDU is a SNMP verion 1 (SNMPv1) PDU.<br />
<br />
===SNMP PDU Format===<br />
* SNMP PDU is is reference to SNMP version 1 (SNMPv1) PDU. <br />
====GetRequest PDU, GetNextRequest PDU, GetResponse PDU, SetRequest PDU Format====<br />
* GetRequest PDU, GetNextRequest PDU, GetResponse PDU, SetRequest PDU Format is shown here.<br />
+-------------------------------------------------------------------------------------------------------------------------------------+<br />
| SNMPv1 PDU (GetRequest, GetNextRequest, GetResponse, SetRequest |<br />
+------+--------+---------------------------------------------------------------------------------------------------------------------+<br />
| PDU | Length | Data of SNMP PDU |<br />
| type | Data | |<br />
+------+--------+---------+---------+---------+---------------------------------------------------------------------------------------+<br />
| PDU | Length | Request | Error | Error | VarBind List (Sequence) |<br />
| type | PDU | ID | Status | Index +------+--------+--------------------------------+--------------------------------+-----+<br />
| | | | | | 0x30 | Length | Varbind 1 | Varbind 2 | ... |<br />
| | |(Integer)|(Integer)|(Integer)| | | (Sequence) | (Sequence) | ... | <br />
| | | | | | | +------+-------+-------+---------+------+-------+-------+---------+-----+<br />
| | | | | | | | 0x30 | Len 1 | OID 1 | Value 1 | 0x30 | Len 2 | OID 1 | Value 2 | ... |<br />
+------+--------+---------+---------+---------+------+--------+------+-------+-------+---------+------+-------+-------+---------+-----+<br />
| | |<-----Len 1----->| |<-----Len 2----->| |<br />
| |<-------------------------------Length-------------------------------->|<br />
|<----------------------------------------------Lenght PDU----------------------------------------------------------->| <br />
* PDU Type is specific type of PDU, PDU Type is a single byte identifier.<br />
* Length Data is a number bytes of Data of SNMP PDU field.<br />
* Data of SNMP PDU is data content in SNMP PDU.<br />
* Request ID is an Integer that identifies a particular SNMP request. This index is echoed back in the response from the SNMP agent, allowing the SNMP manager to match an incoming response to the appropriate request.<br />
* Error Status is an Integer set to 0x00 in the request sent by the NMS. The SNMP agent places an error code in this field in the response message if an error occurred processing the request.<br />
Some error codes include:<br />
+-------------------+---------------------------------------------------------------------------+<br />
| Error Status | |<br />
+------------+------+ Description |<br />
| Name | Code | |<br />
+------------+------+---------------------------------------------------------------------------+<br />
| noError | 0x00 | No error occurred. |<br />
| tooBig | 0x01 | The response to your request was too big to fit into one response. |<br />
| noSuchName | 0x02 | The OID in the request was not found.the OID doesn't exist. |<br />
| badValue | 0x03 | A data type in the request did not match the data type in the SNMP agent. |<br />
| readOnly | 0x04 | The SNMP manager attempted to set a read-only parameter. |<br />
| genErr | 0x05 | General Error (some error other than the ones listed above). |<br />
+------------+------+---------------------------------------------------------------------------+<br />
* Error Index is an Integer. Only the response operation sets this field, if an Error occurs, the Error Index holds a pointer to the Object that caused the error. Other operations set this field to zero.<br />
* Varbind List is a Sequence of Varbinds.<br />
** Varbind is a Sequence of two fields, an OID and the value of OID.<br />
*** OID is an Object Identifier that points to a particular parameter in the SNMP agent. The first two object identifier components in the object identifier value being encoded, using the formula: <font color=red>(X*40) + Y</font>; where X is the value of the first object identifier component and Y is the value of the second object identifier component. The first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by X = 0 and X = 1.<br />
*** Value is the value of OID.<br />
+--------------------+-----------------------------------------------------------------+<br />
| SNMP PDU type | Value |<br />
+--------------------+-----------------------------------------------------------------+<br />
| SetRequest PDU | Value is applied to the specified OID of the SNMP agent. |<br />
| GetRequest PDU | Value is a Null that acts as a placeholder for the return data. |<br />
| GetNextRequest PDU | Value is a Null that acts as a placeholder for the return data. |<br />
| GetResponse PDU | The returned Value from the specified OID of the SNMP agent. |<br />
+--------------------+-----------------------------------------------------------------+<br />
====[http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch10_03.htm= Trap PDU Format]====<br />
* The format of the Trap PDU is shown below:<br />
+------------------------------------------------------------------------------------------------------------------------------------------+<br />
| TRAP SNMPv1 PDU |<br />
+----+------+------------------------------------------------------------------------------------------------------------------------------+<br />
|PDU |Length| Data of SNMP PDU |<br />
|type| Data | |<br />
+----+------+----------+-------+-------+--------+------+---------------------------------------------------- ------------------------------+<br />
|0xA4|Length|Enterprise| Agent |Generic|Specific|Time | VarBind List (Sequence) |<br />
| | PDU | OID |Address| Trap | Trap |Stamp +------+--------+------------------------------+------------------------------+-----+<br />
| | | | | Type | Number | | 0x30 | Length | Varbind 1 | Varbind 22 | ... |<br />
| | | (OID) | | | | | | | (Sequence) | (Sequence) | ... |<br />
| | | | | | | | | +----+-------+-------+---------+----+-------+-------+---------+-----+<br />
| | | | | | | | | |0x30| Len 1 | OID 1 | Value 1 |0x30| Len 2 | OID 1 | Value 2 | ... |<br />
+----+------+----------+-------+-------+--------+------+------+--------+----+-------+-------+---------+----+-------+-------+---------+-----+<br />
| | |<-----Len 1----->| |<-----Len 2----->| |<br />
| |<-----------------------------Length------------------------------>|<br />
|<--------------------------------------------Lenght PDU----------------------------------------------------------->|<br />
* PDU type is TRAP PDU = 0xA4.<br />
* Length Data is a number bytes of Data of SNMP PDU field. <br />
* Enterprise OID identifies the type of managed object generating the trap. <br />
* Agent Address is the IP address of the agent that is sending the trap. <br />
* [http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch02_06.htm#enettdg-CHP-2-TABLE-8= Generic Trap Type] indicates one of a number of generic trap types.<br />
Generic Trap Type has seven values are defined: <br />
+------------------------------+---------------------------------------------------------------------------+<br />
| Generic Trap Type | |<br />
+-----------------------+------+ Description |<br />
| Name | Code | |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| coldStart | 0x00 | Indicates that the agent has rebooted. All management variables will be |<br />
| | | reset; specifically, Counters and Gauges will be reset to zero (0). |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| warmStart | 0x01 | Indicates that the agent has reinitialized itself. None of the management |<br />
| | | variables will be reset. |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| linkDown | 0x02 | Sent when an interface on a device goes down. The first variable binding |<br />
| | | identifies which interface went down. |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| linkUp | 0x03 | Sent when an interface on a device comes back up. The first variable | <br />
| | | binding identifies which interface came back up. |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| authenticationFailure | 0x04 | Indicates that someone has tried to query your agent with an incorrect |<br />
| | | community string; useful in determining if someone is trying to gain |<br />
| | | unauthorized access to one of your devices. |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| egpNeighborLoss | 0x05 | Indicates that an Exterior Gateway Protocol (EGP) neighbor has gone down. |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
| enterpriseSpecific | 0x06 | Indicates that the trap is enterprise-specific. SNMP vendors and users |<br />
| | | define their own traps under the private-enterprise branch of the SMI |<br />
| | | object tree. To process this trap properly, the NMS has to decode the |<br />
| | | specific trap number that is part of the SNMP message. |<br />
+-----------------------+------+---------------------------------------------------------------------------+<br />
* Specific trap number is a number indicating the specific trap you want to send. If you're sending a generic trap, this parameter is ignored -- you're probably better off setting it to zero.<br />
* Time stamp is the time elapsed between the last initialization of the network entity and the generation of the trap.<br />
* Varbind List is a Sequence of Varbinds to be included in the trap.<br />
** Varbind is a Sequence of two fields, an OID and the value of OID. The OIDs for these variable bindings are often specific to the trap and therefore "underneath" the specific OID for the trap. But this isn't a requirement, and it's often useful to send bindings that aren't defined as part of the trap. <br />
*** OID is an Object Identifier that points to a particular parameter in the SNMP agent.<br />
*** Value is the value of OID<br />
<br />
===Example SNMP Message===<br />
====GetRequest PDU====<br />
* The example gets the value of name agent with above MIB file.<br />
* Community String is "public"<br />
+---------+-----------+--------------------------------------------------------------------------------------------+-------------------+<br />
| SNMP | Type | 0x30 | Sequence |<br />
| message +-----------+--------------------------------------------------------------------------------------------+-------------------+<br />
| |Length | 0x2B | Length: 43 |<br />
| +-----------+--------------------------------------------------------------------------------------------+-------------------+<br />
| | Version | 0x02 | Integer |<br />
| | | 0x01 | Length: 1 |<br />
| | | 0x00 | Value: 0 |<br />
| +-----------+--------------------------------------------------------------------------------------------+-------------------+<br />
| | Community | 0x04 | Octet String |<br />
| | | 0x06 | Length: 6 |<br />
| | | 0x70 0x75 0x62 0x6C 0x69 0x63 | Value: public |<br />
| +-----------+ -------+--------------+--------------------------------------------------------------------+-------------------+<br />
| | Data | SNMPv1 | PDU type | 0xA0 | GetRequest PDU |<br />
| | | PDU +--------------+--------------------------------------------------------------------+-------------------+<br />
| | | | PDU length | 0x1E | Length: 30 |<br />
| | | + -------------+--------------------------------------------------------------------+-------------------+<br />
| | | | Request ID | 0x02 | Integer |<br />
| | | | | 0x04 | Length: 4 |<br />
| | | | | 0x37 0x9C 0x57 0x89 | Value: |<br />
| | | + -------------+--------------------------------------------------------------------+-------------------+<br />
| | | | Error Status | 0x02 | Integer |<br />
| | | | | 0x01 | Length: 1 |<br />
| | | | | 0x00 | Value: 0 |<br />
| | | + -------------+--------------------------------------------------------------------+-------------------+<br />
| | | | Error Index | 0x02 | Integer |<br />
| | | | | 0x01 | Length: 1 |<br />
| | | | | 0x00 | Value: 0 |<br />
| | | + -------------+--------------------------------------------------------------------+-------------------+<br />
| | | | VarBind List | 0x30 | Sequence |<br />
| | | | +-----------+--------------------------------------------------------+-------------------+<br />
| | | | | Length | 0x10 | Length: 16 |<br />
| | | | +-----------+--------------------------------------------------------+ ------------------+<br />
| | | | | VarBind 1 | 0x30 | Sequence |<br />
| | | | | +---------+----------------------------------------------+-------------------+<br />
| | | | | | Len 1 | 0x0E | Length: 14 |<br />
| | | | | +---------+----------------------------------------------+-------------------+<br />
| | | | | | OID 1 | 0x06 | Object identifier |<br />
| | | | | | | 0x0A | Length: 10 |<br />
| | | | | | | 0x2B 0x06 0x01 0x04 0x01 0x82 0x99 0x5D 0x02 | Value: |<br />
| | | | | +---------+----------------------------------------------+-------------------+<br />
| | | | | | Value 1 | 0x05 | NULL |<br />
| | | | | | | 0x00 | Length: 0 |<br />
+---------+-----------+--------+--------------+-----------+---------+----------------------------------------------+-------------------+<br />
====TRAP PDU====<br />
* The example TRAP above MIB file.<br />
* Community String is "public"<br />
* Agent's IPAddress is 192.168.1.128<br />
* Timestamp is 123456<br />
* The operMasterControl OID is in TRAP that has value is 1<br />
+---------+-----------+-------------------------------------------------------------------------------------------------------+-------------------+<br />
| SNMP | Type | 0x30 |Sequence |<br />
| message +-----------+-------------------------------------------------------------------------------------------------------+-------------------+<br />
| | Length | 0x82 0x00 0x44 |Length: 68 |<br />
| +-----------+-------------------------------------------------------------------------------------------------------+-------------------+<br />
| | Version | 0x02 |Integer |<br />
| | | 0x01 |Length: 1 |<br />
| | | 0x00 |Value: 0 |<br />
| +-----------+-------------------------------------------------------------------------------------------------------+-------------------+<br />
| | Community | 0x04 |Octet String |<br />
| | | 0x06 |Length: 6 |<br />
| | | 0x70 0x75 0x62 0x6C 0x69 0x63 |Value: public |<br />
| +-----------+ -------+------------+---------------------------------------------------------------------------------+-------------------+<br />
| | Data | SNMPv1 | PDU type | 0xA4 |TRAP PDU |<br />
| | | PDU +------------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | PDU length | 0x82 0x00 0x35 |Length: 53 |<br />
| | | + -----------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | Enterprise | 0x06 |Object identifier |<br />
| | | | OID | 0x09 |Length: 9 |<br />
| | | | | 0x2B 0x06 0x01 0x04 0x01 0x82 0x99 0x5D 0x00 |Value: |<br />
| | | + -----------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | Agent | 0x40 |IpAddress |<br />
| | | | Address | 0x04 |Length: 4 |<br />
| | | | | 0xC0 0xA8 0x01 0x80 |Value:192.168.1.128|<br />
| | | + -----------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | Generic | 0x02 |Integer |<br />
| | | | Trap Type | 0x01 |Length: 1 |<br />
| | | | | 0x06 |Value: 6 |<br />
| | | + -----------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | Specific | 0x02 |Integer |<br />
| | | | Trap | 0x01 |Length: 1 |<br />
| | | | Number | 0x01 |Value: 1 |<br />
| | | + -----------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | Time | 0x43 |TimeTicks |<br />
| | | | Stamp | 0x03 |Length: 3 |<br />
| | | | | 0x01 0xE2 0x40 |Value: 123456 |<br />
| | | + -----------+---------------------------------------------------------------------------------+-------------------+<br />
| | | | VarBind | 0x30 |Sequence |<br />
| | | | List +-----------+---------------------------------------------------------------------+-------------------+<br />
| | | | | Length | 0x82 0x00 0x15 |Length: 21 |<br />
| | | | +-----------+---------------------------------------------------------------------+ ------------------+<br />
| | | | | VarBind 1 | 0x30 |Sequence |<br />
| | | | | +-------+-------------------------------------------------------------+-------------------+<br />
| | | | | | Len 1 | 0x82 0x00 0x11 |Length: 17 |<br />
| | | | | +-------+-------------------------------------------------------------+-------------------+<br />
| | | | | | OID 1 | 0x06 |Object identifier |<br />
| | | | | | | 0x0C |Length: 12 |<br />
| | | | | | | 0x2B 0x06 0x01 0x04 0x01 0x82 0x99 0x5D 0x03 0x01 0x01 0x01 |Value: |<br />
| | | | | +-------+-------------------------------------------------------------+-------------------+<br />
| | | | | | Value | 0x02 |Integer |<br />
| | | | | | 1 | 0x01 |Length: 1 |<br />
| | | | | | | 0x01 |Length: 1 |<br />
+---------+-----------+--------+------------+-----------+-------+-------------------------------------------------------------+-------------------+<br />
==[http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch02_06.htm= SNMP operations]==<br />
* NMS uses GetRequest command to retrieve the value of objects from agents. Objects that is defined by object identifier in MIB file. It is possible for an NMS to get more than one object at a time. The agent receives the request and processes it. After that, it sends GetResponse back to NMS with current value of objects.<br />
* NMS uses GetNextRequest command to discover available objects and the value of these objects from agents. The GetNextRequest command traverses a subtree in lexicographic order. Based on the OIDs in GetNextRequest PDU, it's easy for an agent to start at the root of its SMI object tree and work its way down until it finds the OID it is looking for. After the agent found avaible objects, it sends GetResponse back to NMS with current value of objects.<br />
* NMS uses SetRequest command to change the value of objects from agents. After the agent processes SetRequest, it send GetResponse back to NMS with new value of objects (value of objects that get from SetRequest).<br />
* The agent sends Trap to NMS when agent's something bad operation conditions. No repspone is sent from the NMS to the agent when NMS receives Trap.<br />
* Example SNMP operations with net-snmp:<br />
'''GetRequest command:'''<br />
>> snmpget -v 1 -c public 192.168.1.128 1.3.6.1.4.1.36061.1.1<br />
This command will send GetRequest to the agent (IP address of agent is 192.186.1.128). The SNMP is SNMPv1 (the option ''-v 1'') with community <br />
string is public (the option ''-c public''). In above demo MIB file, 1.3.6.1.4.1.36061.1.1 is OID reference to devID object. <br />
The effect of this command will get the value of agent's devID .<br />
'''GetNextRequest command:'''<br />
>> snmpgetnext -v 1 -c public 192.168.1.128 1.3.6.1.4.1.36061.1<br />
This command will send GetNextRequest to the agent (IP address of agent is 192.186.1.128). The SNMP is SNMPv1 (the option ''-v 1'') with community <br />
string is public (the option ''-c public''). In above demo MIB file, 1.3.6.1.4.1.36061.1 is OID.<br />
The effect of this command will get the value of agent's devID.<br />
'''SetRequest command:'''<br />
>> snmpset -v 1 -c public 192.168.1.128 1.3.6.1.4.1.36061.1.1 s "Hello"<br />
This command will send SetRequest to the agent (IP address of agent is 192.186.1.128). The SNMP is SNMPv1 (the option ''-v 1'') with community <br />
string is public (the option ''-c public''). In above demo MIB file, 1.3.6.1.4.1.36061.1.1 is OID reference to devID object. <br />
The effect of this command will set the value of agent's devID to "Hello".<br />
'''Receiving Traps'''<br />
To receive Traps, snmptrapd.conf file must be configured and snmptrapd must be running.<br />
The easiest way to configure this is by adding this line to snmptrapd.conf file:<br />
disableAuthorization yes<br />
The following command will receive and view trap<br />
>>snmptrapd -f -Le</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19843SNMP MIB Implementation2010-10-07T02:24:32Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html SNMP's PDU using BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build SNMP API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
* where:<br />
** fields indicated by angle brackets (< >) are always present<br />
** fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
** fields in braces ({ }) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* The microchip format only supports OIDs upto 255. The following is an workaround to store OID greater than 255.<br />
* Format of OID:<br />
oid_1 <0x10> oid_2 <0x10> ....<br />
*if (oid_i < 0xFF): oid_i = BYTE (oid_i)<br />
*else: oid_i = <0xFF> + BYTE (length) + BYTE (oid_i.B0) + BYTE (oid_i.B1) + ...<br />
* where<br />
** '''BYTE (x)''' mean the byte representation of x.<br />
** '''<0x10>''' is the OID separator.<br />
** '''<0xFF>''' is used to indicate that the OID is greater than 254.<br />
** '''length''' is the number of bytes of oid_i that follows.<br />
** '''oid_i.Bj''' is j-th byte of oid_i in hexadecimal representation, j = 0 corresponds to the Least Significant Byte (LSB), i.e. little-endian format.<br />
* Example:<br />
The OID for a node is '''4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> BYTE (oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> BYTE (oid_2) = 0x01</font><br />
<font color=blue>oid_3 = 17095 = 0x42C7 </font> => <font color=green>0xFF</font> <font color=red>BYTE (length) = 0x02</font> <font color=blue>BYTE (oid_3.B0) BYTE (oid_3.B1) = 0xC7 0x42 (In little-endian format)</font><br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is OID of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* See [http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example] of accessing data in a table<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row defined in the '''trap''' table. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
<br />
==Build SNMP's PDU using BER==</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19842SNMP MIB Implementation2010-10-07T02:21:26Z<p>Tcwden: /* Binary File */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
* where:<br />
** fields indicated by angle brackets (< >) are always present<br />
** fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
** fields in braces ({ }) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* The microchip format only supports OIDs upto 255. The following is an workaround to store OID greater than 255.<br />
* Format of OID:<br />
oid_1 <0x10> oid_2 <0x10> ....<br />
*if (oid_i < 0xFF): oid_i = BYTE (oid_i)<br />
*else: oid_i = <0xFF> + BYTE (length) + BYTE (oid_i.B0) + BYTE (oid_i.B1) + ...<br />
* where<br />
** '''BYTE (x)''' mean the byte representation of x.<br />
** '''<0x10>''' is the OID separator.<br />
** '''<0xFF>''' is used to indicate that the OID is greater than 254.<br />
** '''length''' is the number of bytes of oid_i that follows.<br />
** '''oid_i.Bj''' is j-th byte of oid_i in hexadecimal representation, j = 0 corresponds to the Least Significant Byte (LSB), i.e. little-endian format.<br />
* Example:<br />
The OID for a node is '''4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> BYTE (oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> BYTE (oid_2) = 0x01</font><br />
<font color=blue>oid_3 = 17095 = 0x42C7 </font> => <font color=green>0xFF</font> <font color=red>BYTE (length) = 0x02</font> <font color=blue>BYTE (oid_3.B0) BYTE (oid_3.B1) = 0xC7 0x42 (In little-endian format)</font><br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is OID of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* See [http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example] of accessing data in a table<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row defined in the '''trap''' table. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19841SNMP MIB Implementation2010-10-07T02:19:52Z<p>Tcwden: /* [{}] and [{, , }] fields */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
* where:<br />
** fields indicated by angle brackets (< >) are always present<br />
** fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
** fields in braces ({ }) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* The microchip format only supports OIDs upto 255. The following is an workaround to store OID greater than 255.<br />
* Format of OID:<br />
oid_1 <0x10> oid_2 <0x10> ....<br />
*if (oid_i < 0xFF): oid_i = BYTE (oid_i)<br />
*else: oid_i = <0xFF> + BYTE (length) + BYTE (oid_i.B0) + BYTE (oid_i.B1) + ...<br />
* where<br />
** '''BYTE (x)''' mean the byte representation of x.<br />
** '''<0x10>''' is the OID separator.<br />
** '''<0xFF>''' is used to indicate that the OID is greater than 254.<br />
** '''length''' is the number of bytes of oid_i that follows.<br />
** '''oid_i.Bj''' is j-th byte of oid_i in hexadecimal representation, j = 0 corresponds to the Least Significant Byte (LSB), i.e. little-endian format.<br />
* Example:<br />
The OID for a node is '''4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> BYTE (oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> BYTE (oid_2) = 0x01</font><br />
<font color=blue>oid_3 = 17095 = 0x42C7 </font> => <font color=green>0xFF</font> <font color=red>BYTE (length) = 0x02</font> <font color=blue>BYTE (oid_3.B0) BYTE (oid_3.B1) = 0xC7 0x42 (In little-endian format)</font><br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is OID of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* See [http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example] of accessing data in a table<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row defined in the '''trap''' table. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19840SNMP MIB Implementation2010-10-07T02:09:27Z<p>Tcwden: /* Binary File Format */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
* where:<br />
** fields indicated by angle brackets (< >) are always present<br />
** fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
** fields in braces ({ }) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* The microchip format only supports OIDs upto 255. The following is an workaround to store OID greater than 255.<br />
* Format of OID:<br />
oid_1 <0x10> oid_2 <0x10> ....<br />
*if (oid_i < 0xFF): oid_i = BYTE (oid_i)<br />
*else: oid_i = <0xFF> + BYTE (length) + BYTE (oid_i.B0) + BYTE (oid_i.B1) + ...<br />
* where<br />
** '''BYTE (x)''' mean the byte representation of x.<br />
** '''<0x10>''' is the OID separator.<br />
** '''<0xFF>''' is used to indicate that the OID is greater than 254.<br />
** '''length''' is the number of bytes of oid_i that follows.<br />
** '''oid_i.Bj''' is j-th byte of oid_i in hexadecimal representation, j = 0 corresponds to the Least Significant Byte (LSB), i.e. little-endian format.<br />
* Example:<br />
The OID for a node is '''4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> BYTE (oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> BYTE (oid_2) = 0x01</font><br />
<font color=blue>oid_3 = 17095 = 0x42C7 </font> => <font color=green>0xFF</font> <font color=red>BYTE (length) = 0x02</font> <font color=blue>BYTE (oid_3.B0) BYTE (oid_3.B1) = 0xC7 0x42 (In little-endian format)</font><br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>'''trap''' is node of mchip.txt example. '''trap''' is name of a table. This table has rows, and the rows are define by '''trapEntry''' node.<br />
The '''trapEntry''' node has 4 leaf nodes are '''trapReceiverNumber (1)''', '''trapEnabled (2)''', '''trapReceiverIPAddress (3)''', '''trapCommunity(4)'''; <br />
each vaule of them will make a row of '''trap''' table.<br />
The trap table will be:</font><br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the '''trap''' table <font color=red>(which table?)</font>. <br />
<font color=red>this table is '''trap''' above.</font><br />
Because SNMP can't retrievable a row (SNMP can retrievable columnar objects within a row or a table).<br />
So, we need an index node to determine the row number to get all columnar objects of a row. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
<font color=blue>In fact, with this example, we need only trapReceiverNumber (1) INDEX to determine a row in this example (This example don't need <br />
use trapCommunity (4) node as INDEX , I added this node be INDEX only to test compiler only).<br />
With a table have multiple INDEX fields to access a row, we need used all INDEXes node (INDEXes node's associated to determine a row).</font><br />
<font color=red>Is it because they takes unique values? </font><br />
<font color=blue>yes, a table need a specify rules to access a row and association of INDEXes is unique values.<br />
[http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example access a table]</font><br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19839SNMP MIB Implementation2010-10-07T02:08:24Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* The microchip format only supports OIDs upto 255. The following is an workaround to store OID greater than 255.<br />
* Format of OID:<br />
oid_1 <0x10> oid_2 <0x10> ....<br />
*if (oid_i < 0xFF): oid_i = BYTE (oid_i)<br />
*else: oid_i = <0xFF> + BYTE (length) + BYTE (oid_i.B0) + BYTE (oid_i.B1) + ...<br />
* where<br />
** '''BYTE (x)''' mean the byte representation of x.<br />
** '''<0x10>''' is the OID separator.<br />
** '''<0xFF>''' is used to indicate that the OID is greater than 254.<br />
** '''length''' is the number of bytes of oid_i that follows.<br />
** '''oid_i.Bj''' is j-th byte of oid_i in hexadecimal representation, j = 0 corresponds to the Least Significant Byte (LSB), i.e. little-endian format.<br />
* Example:<br />
The OID for a node is '''4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> BYTE (oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> BYTE (oid_2) = 0x01</font><br />
<font color=blue>oid_3 = 17095 = 0x42C7 </font> => <font color=green>0xFF</font> <font color=red>BYTE (length) = 0x02</font> <font color=blue>BYTE (oid_3.B0) BYTE (oid_3.B1) = 0xC7 0x42 (In little-endian format)</font><br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>'''trap''' is node of mchip.txt example. '''trap''' is name of a table. This table has rows, and the rows are define by '''trapEntry''' node.<br />
The '''trapEntry''' node has 4 leaf nodes are '''trapReceiverNumber (1)''', '''trapEnabled (2)''', '''trapReceiverIPAddress (3)''', '''trapCommunity(4)'''; <br />
each vaule of them will make a row of '''trap''' table.<br />
The trap table will be:</font><br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the '''trap''' table <font color=red>(which table?)</font>. <br />
<font color=red>this table is '''trap''' above.</font><br />
Because SNMP can't retrievable a row (SNMP can retrievable columnar objects within a row or a table).<br />
So, we need an index node to determine the row number to get all columnar objects of a row. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
<font color=blue>In fact, with this example, we need only trapReceiverNumber (1) INDEX to determine a row in this example (This example don't need <br />
use trapCommunity (4) node as INDEX , I added this node be INDEX only to test compiler only).<br />
With a table have multiple INDEX fields to access a row, we need used all INDEXes node (INDEXes node's associated to determine a row).</font><br />
<font color=red>Is it because they takes unique values? </font><br />
<font color=blue>yes, a table need a specify rules to access a row and association of INDEXes is unique values.<br />
[http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example access a table]</font><br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19838SNMP MIB Implementation2010-10-07T01:37:20Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
I mean the oid_i (oid_i <= 254) is a number that's represented to single byte type. When write to file, this number's represented character <br />
in ASCII table. So, char(oid_i) is a character that has order in ASCII table is equal oid_i number.<br />
About oid (17095) is greater than 254, I use char(255) to mark and use little-endian format to store this oid. <br />
The bytes in little-endian format is represented character in ASCII table to write to file. Number of oid's bytes in little-endian format <br />
is length of this oid.<br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>'''trap''' is node of mchip.txt example. '''trap''' is name of a table. This table has rows, and the rows are define by '''trapEntry''' node.<br />
The '''trapEntry''' node has 4 leaf nodes are '''trapReceiverNumber (1)''', '''trapEnabled (2)''', '''trapReceiverIPAddress (3)''', '''trapCommunity(4)'''; <br />
each vaule of them will make a row of '''trap''' table.<br />
The trap table will be:</font><br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the '''trap''' table <font color=red>(which table?)</font>. <br />
<font color=red>this table is '''trap''' above.</font><br />
Because SNMP can't retrievable a row (SNMP can retrievable columnar objects within a row or a table).<br />
So, we need an index node to determine the row number to get all columnar objects of a row. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
<font color=blue>In fact, with this example, we need only trapReceiverNumber (1) INDEX to determine a row in this example (This example don't need <br />
use trapCommunity (4) node as INDEX , I added this node be INDEX only to test compiler only).<br />
With a table have multiple INDEX fields to access a row, we need used all INDEXes node (INDEXes node's associated to determine a row).</font><br />
<font color=red>Is it because they takes unique values? </font><br />
<font color=blue>yes, a table need a specify rules to access a row and association of INDEXes is unique values.<br />
[http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example access a table]</font><br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19837SNMP MIB Implementation2010-10-07T01:36:32Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
I mean the oid_i (oid_i <= 254) is a number that's represented to single byte type. When write to file, this number's represented character <br />
in ASCII table. So, char(oid_i) is a character that has order in ASCII table is equal oid_i number.<br />
About oid (17095) is greater than 254, I use char(255) to mark and use little-endian format to store this oid. <br />
The bytes in little-endian format is represented character in ASCII table to write to file. Number of oid's bytes in little-endian format <br />
is length of this oid.<br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font> <br />
<br />
yes, it's right.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>'''trap''' is node of mchip.txt example. '''trap''' is name of a table. This table has rows, and the rows are define by '''trapEntry''' node.<br />
The '''trapEntry''' node has 4 leaf nodes are '''trapReceiverNumber (1)''', '''trapEnabled (2)''', '''trapReceiverIPAddress (3)''', '''trapCommunity(4)'''; <br />
each vaule of them will make a row of '''trap''' table.<br />
The trap table will be:</font><br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the '''trap''' table <font color=red>(which table?)</font>. <br />
<font color=red>this table is '''trap''' above.</font><br />
Because SNMP can't retrievable a row (SNMP can retrievable columnar objects within a row or a table).<br />
So, we need an index node to determine the row number to get all columnar objects of a row. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
<font color=blue>In fact, with this example, we need only trapReceiverNumber (1) INDEX to determine a row in this example (This example don't need <br />
use trapCommunity (4) node as INDEX , I added this node be INDEX only to test compiler only).<br />
With a table have multiple INDEX fields to access a row, we need used all INDEXes node (INDEXes node's associated to determine a row).</font><br />
<font color=red>Is it because they takes unique values? </font><br />
<font color=blue>yes, a table need a specify rules to access a row and association of INDEXes is unique values.<br />
[http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example access a table]</font><br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19836SNMP MIB Implementation2010-10-07T01:36:11Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse] (Now using).<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
I mean the oid_i (oid_i <= 254) is a number that's represented to single byte type. When write to file, this number's represented character <br />
in ASCII table. So, char(oid_i) is a character that has order in ASCII table is equal oid_i number.<br />
About oid (17095) is greater than 254, I use char(255) to mark and use little-endian format to store this oid. <br />
The bytes in little-endian format is represented character in ASCII table to write to file. Number of oid's bytes in little-endian format <br />
is length of this oid.<br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font> <br />
<br />
yes, it's right.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>'''trap''' is node of mchip.txt example. '''trap''' is name of a table. This table has rows, and the rows are define by '''trapEntry''' node.<br />
The '''trapEntry''' node has 4 leaf nodes are '''trapReceiverNumber (1)''', '''trapEnabled (2)''', '''trapReceiverIPAddress (3)''', '''trapCommunity(4)'''; <br />
each vaule of them will make a row of '''trap''' table.<br />
The trap table will be:</font><br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the '''trap''' table <font color=red>(which table?)</font>. <br />
<font color=red>this table is '''trap''' above.</font><br />
Because SNMP can't retrievable a row (SNMP can retrievable columnar objects within a row or a table).<br />
So, we need an index node to determine the row number to get all columnar objects of a row. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
<font color=blue>In fact, with this example, we need only trapReceiverNumber (1) INDEX to determine a row in this example (This example don't need <br />
use trapCommunity (4) node as INDEX , I added this node be INDEX only to test compiler only).<br />
With a table have multiple INDEX fields to access a row, we need used all INDEXes node (INDEXes node's associated to determine a row).</font><br />
<font color=red>Is it because they takes unique values? </font><br />
<font color=blue>yes, a table need a specify rules to access a row and association of INDEXes is unique values.<br />
[http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example access a table]</font><br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19835SNMP MIB Implementation2010-10-07T01:33:58Z<p>Tcwden: /* Binary File Format */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script <font color=red>Which tool are you using now?</font>:<br />
now, i'm using ASN.1 Editor plugin for Eclipse tool.<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
I mean the oid_i (oid_i <= 254) is a number that's represented to single byte type. When write to file, this number's represented character <br />
in ASCII table. So, char(oid_i) is a character that has order in ASCII table is equal oid_i number.<br />
About oid (17095) is greater than 254, I use char(255) to mark and use little-endian format to store this oid. <br />
The bytes in little-endian format is represented character in ASCII table to write to file. Number of oid's bytes in little-endian format <br />
is length of this oid.<br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font> <br />
<br />
yes, it's right.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>'''trap''' is node of mchip.txt example. '''trap''' is name of a table. This table has rows, and the rows are define by '''trapEntry''' node.<br />
The '''trapEntry''' node has 4 leaf nodes are '''trapReceiverNumber (1)''', '''trapEnabled (2)''', '''trapReceiverIPAddress (3)''', '''trapCommunity(4)'''; <br />
each vaule of them will make a row of '''trap''' table.<br />
The trap table will be:</font><br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the '''trap''' table <font color=red>(which table?)</font>. <br />
<font color=red>this table is '''trap''' above.</font><br />
Because SNMP can't retrievable a row (SNMP can retrievable columnar objects within a row or a table).<br />
So, we need an index node to determine the row number to get all columnar objects of a row. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
<font color=blue>In fact, with this example, we need only trapReceiverNumber (1) INDEX to determine a row in this example (This example don't need <br />
use trapCommunity (4) node as INDEX , I added this node be INDEX only to test compiler only).<br />
With a table have multiple INDEX fields to access a row, we need used all INDEXes node (INDEXes node's associated to determine a row).</font><br />
<font color=red>Is it because they takes unique values? </font><br />
<font color=blue>yes, a table need a specify rules to access a row and association of INDEXes is unique values.<br />
[http://www.simpleweb.org/w/images/9/91/Tutorial_Slides_Smi.pdf example access a table]</font><br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
To parse MIB structure data we need only pointer's represented by green arrows.<br />
Which red arrows, I add them to represent relationship of a node's pointer with position of others nodes (the last sibling node's pointer <br />
will point to where). It don't need to parse MIB data.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19828SNMP MIB Implementation2010-10-06T04:07:48Z<p>Tcwden: /* Binary File */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script <font color=red>Which tool are you using now?</font>:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The black arrow lines represent the OID tree structure.<br />
** The red and green lines represent pointers to data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19827SNMP MIB Implementation2010-10-06T04:05:18Z<p>Tcwden: /* Binary File Format */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script <font color=red>Which tool are you using now?</font>:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset]/[distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The arrow lines represent the OID tree structure.<br />
** The red and green lines represents pointers of data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19826SNMP MIB Implementation2010-10-06T04:04:42Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script <font color=red>Which tool are you using now?</font>:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension. Can you give me some reference material discussing this issue?</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The arrow lines represent the OID tree structure.<br />
** The red and green lines represents pointers of data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19825SNMP MIB Implementation2010-10-06T04:02:52Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script <font color=red>Which tool are you using now?</font>:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The arrow lines represent the OID tree structure.<br />
** The red and green lines represents pointers of data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19824SNMP MIB Implementation2010-10-06T04:01:57Z<p>Tcwden: /* Example */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
<br />
====OID Tree====<br />
* An example OID tree is given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
====Binary File====<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The arrow lines represent the OID tree structure.<br />
** The red and green lines represents pointers of data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why do '''product''' and '''name''' point to '''experimental''', and etc.?</font><br />
<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19823SNMP MIB Implementation2010-10-06T03:57:48Z<p>Tcwden: /* Example */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
** '''oid''' is <oid> fields.<br />
** '''info''' is <nodeInfo> fields.<br />
** '''dist''' is [distantSiblingOffset]/[siblingOffset] fields.<br />
** '''id''' is [id] fields.<br />
** '''defval''' is data fields, include [dataType], [dataLen], [data] fields.<br />
** '''index''' is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
** The arrow lines represent the OID tree structure.<br />
** The red and green lines represents pointers of data.<br />
** The dist field points to next sibling record. After parent record is it's children.<br />
<font color=red>I can understand the relationship given by the green arrows, but how about the red arrows? For example, why does '''product'' and '''name''' points to '''experimental''', etc.?</font><br />
<br />
<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19822SNMP MIB Implementation2010-10-06T03:46:06Z<p>Tcwden: /* [{}] */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}] and [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}] fields====<br />
* If this record is sequence (an order list of objects), <br />
** <IndexNumber> is the number of INDEXes in sequence.<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example: <br />
** '''trap''' node is a sequence to inform the NMS of a significant event (an extraordinary event has occurred at an agent) asynchronously. This sequence has two INDEXes, so we have:<br />
<IndexNumber> = 0x02<br />
with the 1st INDEX:<br />
<IndexCount> = 0x04<br />
<IndexNodeInfo> = 0xCC<br />
<IndexDataType> = 0x02<br />
with the 2nd INDEX:<br />
<IndexCount> = 0x01<br />
<IndexNodeInfo> = 0x80<br />
<IndexDataType> = 0x03<br />
In this example, '''trap''' is a table which has 4 columns <font color=red>(4 leaf nodes?)</font>: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table <font color=red>(which table?)</font>. <br />
So, we need an index node to determine the row number. A table needs at least one index. <br />
<br />
This example has two INDEXes: the 1st INDEX node is trapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1) <br />
<font color=red>Why these two are INDEXes, and not trapReceiverIPAddress or trapEnabled? Is it because they takes unique values?</font>.<br />
In fact, we need only trapReceiverNumber (1) INDEX to determine a row in this example (two INDEXes case is used to test complier only).<br />
<br />
Each INDEX is a node, so it has OID, info, data type.<br />
The 1st INDEX node is trapCommunity, which has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node is trapReceiverNumber, which has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19821SNMP MIB Implementation2010-10-06T03:27:04Z<p>Tcwden: /* Example */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example:<br />
mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with the 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with the 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
* <font color=red>What does this '''trap''' use for? What does the different values of IndexCount, IndexNodeInfo, and IndexDataType mean?</font>:<br />
This is an example, How to use '''trap''' by agents to asynchronously inform the NMS of a significant event (an extraordinary event has occurred at an agent).<br />
In this example, '''trap''' is a table has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table. So, we need index node to determine row. A table need at least one index. <br />
This example has two INDEXes: the 1st INDEX node is istrapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1).<br />
In the fact, need only trapReceiverNumber (1) INDEX to determine a row in example. (two INDEXes case is used to test complier).<br />
Each INDEX is a node, so it has OID, info, data type.<br />
In this binary file format:<br />
IndexCount is oid of index node.<br />
IndexNodeInfo is info of index node.<br />
IndexDataType is data type of index node.<br />
The 1st INDEX node istrapCommunity has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node trapReceiverNumber has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illustrated in the diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19820SNMP MIB Implementation2010-10-06T03:26:27Z<p>Tcwden: /* [siblingOffset] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example:<br />
mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with the 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with the 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
* <font color=red>What does this '''trap''' use for? What does the different values of IndexCount, IndexNodeInfo, and IndexDataType mean?</font>:<br />
This is an example, How to use '''trap''' by agents to asynchronously inform the NMS of a significant event (an extraordinary event has occurred at an agent).<br />
In this example, '''trap''' is a table has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table. So, we need index node to determine row. A table need at least one index. <br />
This example has two INDEXes: the 1st INDEX node is istrapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1).<br />
In the fact, need only trapReceiverNumber (1) INDEX to determine a row in example. (two INDEXes case is used to test complier).<br />
Each INDEX is a node, so it has OID, info, data type.<br />
In this binary file format:<br />
IndexCount is oid of index node.<br />
IndexNodeInfo is info of index node.<br />
IndexDataType is data type of index node.<br />
The 1st INDEX node istrapCommunity has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node trapReceiverNumber has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19819SNMP MIB Implementation2010-10-06T03:20:16Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=grey>In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.</font><br />
<br />
<font color=red>In my concept, people usually refer to ASCII code when they have some human readable characters (i.e. printable characters) to represent. It is kind of weird to me the the OID will be in the format oid1.oid2.oid3.... where oid_i may take some non-printable characters such as the 4th ASCII character (end of transmission). Also, a number such as 17095th of ASCII is out of my comprehension.</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored). <br />
For example, in case of '''private (4) -> enterprises (1) -> microchip (17095)''', where '''private''' has no sibling and only has one child, <br />
and '''enterprises''' also has no sibling and only has one child, they can combined to a record has oid field is 4.1.17095. <font color=red>Am I right?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, can siblingOffset and distantSiblingOffset be combined to 1 field?</font><br />
yes, they can be combined to 1 field.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example:<br />
mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with the 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with the 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
* <font color=red>What does this '''trap''' use for? What does the different values of IndexCount, IndexNodeInfo, and IndexDataType mean?</font>:<br />
This is an example, How to use '''trap''' by agents to asynchronously inform the NMS of a significant event (an extraordinary event has occurred at an agent).<br />
In this example, '''trap''' is a table has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table. So, we need index node to determine row. A table need at least one index. <br />
This example has two INDEXes: the 1st INDEX node is istrapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1).<br />
In the fact, need only trapReceiverNumber (1) INDEX to determine a row in example. (two INDEXes case is used to test complier).<br />
Each INDEX is a node, so it has OID, info, data type.<br />
In this binary file format:<br />
IndexCount is oid of index node.<br />
IndexNodeInfo is info of index node.<br />
IndexDataType is data type of index node.<br />
The 1st INDEX node istrapCommunity has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node trapReceiverNumber has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19818SNMP MIB Implementation2010-10-06T02:48:37Z<p>Tcwden: /* Binary File Format */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
<font color=red>Since [siblingOffset] and [distantSiblingOffset] can be combined to 1 field, can I represent the above as:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset/distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]</font><br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 255: oid_i = char (oid_i)<br />
* else oid_i = char(256) + char(length of oid_i base 256) + oid_i (base 256) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 256.<br />
* The microchip format only supports OIDs upto 255. The above is an workaround to store OID greater than 255<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0xC7 0x42</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
* In the example, i use the hexadecimal to easier to read. When i write to a file oid_1 = 4 will be fourth character in ASCII table (isn't the hexadecimal representation of 4). So i use char(oid_i), where: oid_i is number 4, isn't character '4'. Therefore, char(oid_i) = oid_i.<br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(256) = 0xFF</font> <font color=red>char(length of oid_3 base 256) = 0x02</font> <font color=blue> char(oid_3) = 0xC742 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
* The meaning of "oid_i base 256" (i changed 255 to 256 follow little-endian format): the integer oid_i is wrote to a file in little-endian format and "length of oid_3 base 256" means number of bytes of the integer oid_i in little-endian format. So, 17095 = 0x42*0x100 + 0xC7.<br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
* Example:<br />
In mchip.txt file,the nodes have no sibling and only has one child: private (4), enterprises (1), microchip (17095). <br />
They can combined to a record has oid field is 4.1.17095.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, can siblingOffset and distantSiblingOffset be combined to 1 field?</font><br />
yes, they can be combined to 1 field.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is oid of index node in table<br />
** <IndexNodeInfo>: is info of index node<br />
** <IndexDataType>: is data type of index node<br />
* Example:<br />
mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with the 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with the 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
* <font color=red>What does this '''trap''' use for? What does the different values of IndexCount, IndexNodeInfo, and IndexDataType mean?</font>:<br />
This is an example, How to use '''trap''' by agents to asynchronously inform the NMS of a significant event (an extraordinary event has occurred at an agent).<br />
In this example, '''trap''' is a table has 4 columns: <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
<font color=blue>trapReceiverNumber (1)</font>, trapEnabled (2), trapReceiverIPAddress (3), <font color=blue>trapCommunity(4)</font>. <br />
Each significant event will be a row in the table. So, we need index node to determine row. A table need at least one index. <br />
This example has two INDEXes: the 1st INDEX node is istrapCommunity (4) and the 2nd INDEX node trapReceiverNumber (1).<br />
In the fact, need only trapReceiverNumber (1) INDEX to determine a row in example. (two INDEXes case is used to test complier).<br />
Each INDEX is a node, so it has OID, info, data type.<br />
In this binary file format:<br />
IndexCount is oid of index node.<br />
IndexNodeInfo is info of index node.<br />
IndexDataType is data type of index node.<br />
The 1st INDEX node istrapCommunity has OID = 4, info is 0xCC and data type is INTEGER (0x02). so<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
The 2nd INDEX node trapReceiverNumber has OID = 1, info is 0x80 and data type is DisplayString (0x03). so<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19811SNMP MIB Implementation2010-10-05T06:26:41Z<p>Tcwden: /* [{}] */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i base 255) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0x0A 0x43</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(255) = 0xFF</font> <font color=red>char(length of oid_3 base 255) = 0x02</font> <font color=blue> char(oid_3) = 0x0A43 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, can siblingOffset and distantSiblingOffset be combined to 1 field?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <IndexDataType>: is data type of index_node<br />
* Example:<br />
mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
* <font color=red>What does this '''trap''' use for? What does the different values of IndexCount, IndexNodeInfo, and IndexDataType mean?</font>:<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19810SNMP MIB Implementation2010-10-05T06:23:34Z<p>Tcwden: /* [dataType], [dataLen], [data] fields */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i base 255) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0x0A 0x43</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(255) = 0xFF</font> <font color=red>char(length of oid_3 base 255) = 0x02</font> <font color=blue> char(oid_3) = 0x0A43 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, can siblingOffset and distantSiblingOffset be combined to 1 field?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <IndexDataType>: is data type of index_node<br />
* <font color=red>Can you give an example?</font><br />
The example, mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19809SNMP MIB Implementation2010-10-05T06:23:11Z<p>Tcwden: /* [dataType], [dataLen], [data] fields */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i base 255) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0x0A 0x43</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(255) = 0xFF</font> <font color=red>char(length of oid_3 base 255) = 0x02</font> <font color=blue> char(oid_3) = 0x0A43 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, can siblingOffset and distantSiblingOffset be combined to 1 field?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following base data types defined in SNMPv1:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
* <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><br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <IndexDataType>: is data type of index_node<br />
* <font color=red>Can you give an example?</font><br />
The example, mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19808SNMP MIB Implementation2010-10-05T06:20:48Z<p>Tcwden: /* [siblingOffset] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i base 255) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0x0A 0x43</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(255) = 0xFF</font> <font color=red>char(length of oid_3 base 255) = 0x02</font> <font color=blue> char(oid_3) = 0x0A43 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, can siblingOffset and distantSiblingOffset be combined to 1 field?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following data types:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
* <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><br />
The data types are described above.<br />
This is the list base data types defined in SNMPv1.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <IndexDataType>: is data type of index_node<br />
* <font color=red>Can you give an example?</font><br />
The example, mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19807SNMP MIB Implementation2010-10-05T06:19:08Z<p>Tcwden: /* [distantSiblingOffset] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i base 255) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0x0A 0x43</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(255) = 0xFF</font> <font color=red>char(length of oid_3 base 255) = 0x02</font> <font color=blue> char(oid_3) = 0x0A43 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, this means there will never be nodes with different siblingOffset and distantSiblingOffset?</font><br />
Yes, that's right.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following data types:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
* <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><br />
The data types are described above.<br />
This is the list base data types defined in SNMPv1.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <IndexDataType>: is data type of index_node<br />
* <font color=red>Can you give an example?</font><br />
The example, mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19806SNMP MIB Implementation2010-10-05T06:18:20Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<IndexNumber>},{<IndexCount>, <IndexNodeInfo>, <IndexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i base 255) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* Example:<br />
The OID for a node is '''.4.1.17095.''' After compiling to binary, the OID is represented as:<br />
The OID: <font color=blue>4</font> . <font color=blue>1</font> . <font color=blue>17095</font> .<br />
The result: <font color=blue>0x04</font> 0x10 <font color=blue>0x10</font> 0x10 <font color=green>0xFF</font> <font color=red>0x02</font> <font color=blue>0x0A 0x43</font> 0x10<br />
where:<br />
<font color=blue>oid_1 = 4 </font> => <font color=blue> char(oid_1) = 0x04</font><br />
<font color=blue>oid_2 = 2 </font> => <font color=blue> char(oid_2) = 0x01</font><br />
<br />
<font color=red>0x04 is not the ASCII of 4. The ASCII of 4 should be 0x34. I think you are saying the hexadecimal representation of 4. In such case, I think you can use HEX(.) instead of char(.)</font><br />
<br />
<font color=blue>oid_3 = 17095 </font> => <font color=green>char(255) = 0xFF</font> <font color=red>char(length of oid_3 base 255) = 0x02</font> <font color=blue> char(oid_3) = 0x0A43 (In little-endian format)</font><br />
char(16) = 0x10<br />
<br />
<font color=red>So, "length of oid_3 base 255" means the number of bytes representing oid_3? How can you calculate 0x0A43 from 17095? I still don't quite understand the meaning of "oid_i (base 255)"</font><br />
<br />
Note: When a node have no sibling and only has one child, the node's OID will be merged with its child's OID (reduce data's stored).<br />
<font color=red>How can it be combined? Any example?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000 to parse easier <font color=red>(is this a standard?)</font>.<br />
No, this is not a standard. The last node don't point to other node, so assign its distant offset to 0.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, this means there will never be nodes with different siblingOffset and distantSiblingOffset?</font><br />
Yes, that's right.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following data types:<br />
** '''INTEGER''': The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647.<br />
** '''OCTETSTRING''': Octet strings are ordered sequences of 0 to 65,535 octets.<br />
** '''Gauge''': Nonnegative integers that can increase or decrease but retain the maximum value reached. The limit of 2^32 -1.<br />
** '''TimeTicks''': A hundredth of a second since some event. The limit of 2^32 -1.<br />
** '''Counter''': Nonnegative integers that increase until they reach a maximum value (2^32 -1); then, the integers return to zero.<br />
** '''DisplayString''': a special case of the octet string type where all the bytes are printable ASCII characters, include formatting characters such as CR and LF, and the C programming language string terminator character zero.<br />
** '''IpAddress''': A four byte octet string in network order.<br />
** '''NetworkAddress''': Used to indicate an address choice from one of the possible protocol families. Currently, only IP addresses are supported. <br />
** '''Opaque''': An arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the mib.<br />
** '''SEQUENCE''': An ordered list of objects, somewhat like a struct in the C language. Type of objects in sequence is same type of node.<br />
* <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><br />
The data types are described above.<br />
This is the list base data types defined in SNMPv1.<br />
<br />
====[{<IndexNumber>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <IndexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <IndexDataType>: is data type of index_node<br />
* <font color=red>Can you give an example?</font><br />
The example, mchip.txt file has '''trap''' node is a sequence. This sequence has two INDEXes, so we have:<br />
IndexNumber = 0x2<br />
with 1st INDEX:<br />
IndexCount = 0x04<br />
IndexNodeInfo = 0xCC<br />
IndexDataType = 0x02<br />
with 2nd INDEX:<br />
IndexCount = 0x01<br />
IndexNodeInfo = 0x80<br />
IndexDataType = 0x03<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19800SNMP MIB Implementation2010-10-04T07:54:10Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base 255) + char(16)<br />
* where<br />
** char(x) that's mean get ascii of x.<br />
** char(16) is used to separate two oids.<br />
** char(255) is determined that oid geater than 254.<br />
** "length of oid_i" is length string of oid_i that's converted base 255.<br />
* The microchip format only supports OIDs upto 254. The above is an workaround to store OID greater than 254<br />
* <font color=red>Can you give an example</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* In little-endian format.<br />
* The last node's distant offset is set to 0x00000000 to parse easier <font color=red>(is this a standard?)</font>.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
* <font color=red>So, this means there will never be nodes with different siblingOffset and distantSiblingOffset?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* The tool supports the following data types:<br />
** INTEGER<br />
** OCTETSTRING<br />
** Gauge<br />
** TimeTicks<br />
** Counter<br />
** DisplayString (ascii string)<br />
** IpAddress<br />
** Opaque<br />
** SEQUENCE<br />
* <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><br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence (an order list of objects), index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
* <font color=red>Can you give an example?</font><br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below:<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19799SNMP MIB Implementation2010-10-04T07:16:50Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* Tutorial: [http://www.scribd.com/doc/276412/Understanding-SNMP-Stack Understanding SNMP Stack] to create ASN.1 MIB Script.<br />
* Tools to create ASN.1 MIB Script:<br />
** [http://www.asnlab.com/asndt/installing.html ASN.1 Editor plugin for Eclipse].<br />
** [http://packages.ubuntu.com/karmic/asn1-mode Emacs mode for editing ASN.1 files].<br />
<br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
This is an workaround to store oids, but this isn't a standard representation or the microchip format.<br />
* <font color=red>What does char(.) mean?</font><br />
char(x) that's mean get ascii of x.<br />
char(16) is used to separate two oids.<br />
char(255) is determined that oid geater than 254.<br />
"length of oid_i" is length string of oid_i that's converted base 255.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
leaf means child, but child doesn't mean leaf. <br />
the comment fixed.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
distant offset point to next node sibling (that's "NULL" node).It's little-endian.<br />
To parse easier, The last node's distant offset is set to 0x00000000.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font><br />
siblingOffset and distantSiblingOffset in this format is same function (point to next node sibling). <br />
They're only differences:<br />
siblingOffset use with leaf node.<br />
distantSiblingOffset use with node.<br />
so it's same value.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* <font color=red>How many dataType does it support?</font><br />
The tool support types:<br />
INTEGER<br />
OCTETSTRING<br />
Gauge<br />
TimeTicks<br />
Counter<br />
DisplayString (ascii string)<br />
IpAddress<br />
Opaque<br />
SEQUENCE<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
* <font color=red>What kind of data will be a sequence node?</font><br />
Sequence is An ordered list of objects, somewhat like a struct in the C language.<br />
Type of objects in sequence is same type of node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below <font color=red>can you upload a picture with higher resolution?</font>:<br />
This is picture with higher resolution.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19781SNMP MIB Implementation2010-09-30T05:33:24Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
This is an workaround to store oids, but this isn't a standard representation or the microchip format.<br />
* <font color=red>What does char(.) mean?</font><br />
char(x) that's mean get ascii of x.<br />
char(16) is used to separate two oids.<br />
char(255) is determined that oid geater than 254.<br />
"length of oid_i" is length string of oid_i that's converted base 255.<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a leaf)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
leaf means child, but child doesn't mean leaf. <br />
the comment fixed.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* <font color=red>How many dataType does it support?</font><br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
* <font color=red>What kind of data will be a sequence node?</font><br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below <font color=red>can you upload a picture with higher resolution?</font>:<br />
This is picture with higher resolution.<br />
[[File:Snmp mib binary detail example.jpg | thumb | center | 900px]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19769SNMP MIB Implementation2010-09-28T05:38:01Z<p>Tcwden: /* Example */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* <font color=red>How many dataType does it support?</font><br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
* <font color=red>What kind of data will be a sequence node?</font><br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram below <font color=red>can you upload a picture with higher resolution?</font>:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19768SNMP MIB Implementation2010-09-28T05:36:25Z<p>Tcwden: /* [dataType], [dataLen], [data] fields */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
* <font color=red>How many dataType does it support?</font><br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
* <font color=red>What kind of data will be a sequence node?</font><br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19767SNMP MIB Implementation2010-09-28T05:34:29Z<p>Tcwden: /* [{}] */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
* <font color=red>What kind of data will be a sequence node?</font><br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19766SNMP MIB Implementation2010-09-28T04:32:37Z<p>Tcwden: /* [siblingOffset] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
* <font color=red>I can see some child nodes in the example, but the table does not have any siblingOffset, can you explain?</font><br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19765SNMP MIB Implementation2010-09-28T04:31:00Z<p>Tcwden: /* [siblingOffset] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enabled. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19764SNMP MIB Implementation2010-09-28T04:30:01Z<p>Tcwden: /* [distantSiblingOffset] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enabled. Point to next node sibling.<br />
* <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><br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19763SNMP MIB Implementation2010-09-28T04:26:22Z<p>Tcwden: /* [id] field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
* <font color=red>leaf means child?</font><br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19762SNMP MIB Implementation2010-09-28T04:24:38Z<p>Tcwden: /* Binary File Format */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, <br />
[id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], <br />
[{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19761SNMP MIB Implementation2010-09-28T04:22:12Z<p>Tcwden: /* Convert MIB to Binary File */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files, because the microchip '''mib2bib''' converter only supports upto 255 OIDs.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19760SNMP MIB Implementation2010-09-28T04:19:42Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
* <font color=red>What does char(.) mean?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19759SNMP MIB Implementation2010-09-28T04:17:53Z<p>Tcwden: /* field */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
* <font color=red>If this a standard representation, or is a workaround of the microchip format?</font><br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19758SNMP MIB Implementation2010-09-28T04:03:52Z<p>Tcwden: /* Convert MIB to Binary File */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** '''<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.<br />
** '''<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.<br />
** '''<name>.h''' is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19757SNMP MIB Implementation2010-09-28T04:02:50Z<p>Tcwden: /* Convert MIB to Binary File */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files.<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf foo.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
* where MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
** <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.<br />
** <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.<br />
** <name>.h is C header file storing ID that's reference to function service of OID.<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
* Example:<br />
mib2bin mchip.txt<br />
<br />
mib2bin will generate three files: mchip.bin, mchip_data.h and mchip.h<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19756SNMP MIB Implementation2010-09-28T03:57:51Z<p>Tcwden: </p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Is this file needed?</font><br />
* <font color=red>If so any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf mchip.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files:<br />
** Binary file ('''foo.bin''') storing information of OID tree. This file can be placed on an SD media card to be read by the FAT16 file system.<br />
** C header file ('''foo_data_h''') 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.<br />
** C header file ('''foo.h''') storing ID that's reference to function service of OID.<br />
<br />
===How to use===<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
where:<br />
MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
* mib2bin tool will create three files:<br />
** <name>.bin is the binary file.<br />
** <name>_data.h is C header file store OID tree.<br />
** <name>.h is C header file. (The file store Ids).<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
* Example:<br />
mib2bin mchip.txt<br />
<br />
mib2bin will generate three files: mchip.bin, mchip_data.h and mchip.h<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19755SNMP MIB Implementation2010-09-28T03:55:12Z<p>Tcwden: /* Example */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf mchip.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files:<br />
** Binary file ('''foo.bin''') storing information of OID tree. This file can be placed on an SD media card to be read by the FAT16 file system.<br />
** C header file ('''foo_data_h''') 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.<br />
** C header file ('''foo.h''') storing ID that's reference to function service of OID.<br />
<br />
===How to use===<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
where:<br />
MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
* mib2bin tool will create three files:<br />
** <name>.bin is the binary file.<br />
** <name>_data.h is C header file store OID tree.<br />
** <name>.h is C header file. (The file store Ids).<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
* Example:<br />
mib2bin mchip.txt<br />
<br />
mib2bin will generate three files: mchip.bin, mchip_data.h and mchip.h<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
* The example mchip.txt describe the OID tree given below: <br />
[[File:Snmp mib oid tree example.jpg | thumb | center | 900px]]<br />
<br />
* The corresponding binary file is mchip.bin and it has data describe in table below:<br />
[[File:Snmp mib binary example.jpg | thumb | center | 900px]]<br />
<br />
OID is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
* The detail description of mchip.bin is illuminated by structure diagram blow:<br />
[[File:Snmp mib binary detail example.jpg]]<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=File:Snmp_mib_binary_detail_example.jpg&diff=19754File:Snmp mib binary detail example.jpg2010-09-28T03:54:59Z<p>Tcwden: </p>
<hr />
<div></div>Tcwdenhttp://www.opencircuits.com/index.php?title=File:Snmp_mib_binary_example.jpg&diff=19753File:Snmp mib binary example.jpg2010-09-28T03:52:14Z<p>Tcwden: </p>
<hr />
<div></div>Tcwdenhttp://www.opencircuits.com/index.php?title=File:Snmp_mib_oid_tree_example.jpg&diff=19752File:Snmp mib oid tree example.jpg2010-09-28T03:49:11Z<p>Tcwden: </p>
<hr />
<div></div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19751SNMP MIB Implementation2010-09-28T03:47:14Z<p>Tcwden: /* How to use */</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf mchip.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files:<br />
** Binary file ('''foo.bin''') storing information of OID tree. This file can be placed on an SD media card to be read by the FAT16 file system.<br />
** C header file ('''foo_data_h''') 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.<br />
** C header file ('''foo.h''') storing ID that's reference to function service of OID.<br />
<br />
===How to use===<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
where:<br />
MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
* mib2bin tool will create three files:<br />
** <name>.bin is the binary file.<br />
** <name>_data.h is C header file store OID tree.<br />
** <name>.h is C header file. (The file store Ids).<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
* Example:<br />
mib2bin mchip.txt<br />
<br />
mib2bin will generate three files: mchip.bin, mchip_data.h and mchip.h<br />
<br />
===Binary File Format===<br />
* The binary file is an image of MIB file. It is generated by mib2bin tool. Agents will read binary file to respond NMS request.<br />
* 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.<br />
* A parent or child is a record. Single record of binary file have format:<br />
<oid>, <nodeInfo>, [id], [siblingOffset], [distantSiblingOffset], [dataType], [dataLen], [data], [{<index_number>},{<IndexCount>, <IndexNodeInfo>, <indexDataType>} ...]<br />
<br />
where:<br />
fields indicated by angle brackets (< >) are always present<br />
fields in square brackets ([ ]) are optional depending on characteristics of the current node.<br />
fields in braces ({}) are optional but always occur together.<br />
<br />
====<oid> field====<br />
* Format of OID:<br />
oid1 char(16)<br />
oid2 char(16)<br />
....<br />
* if oid_i < 254: oid_i = char (oid_i)<br />
* else oid_i = char(255) + char(length of oid_i) + oid_i (base on 255) + char(16)<br />
<br />
====<nodeInfo> field====<br />
* information of node<br />
bit when (set = 1)<br />
0 Node is a parent (0: node is a child)<br />
1 Node is sequence<br />
2 Node is readable<br />
3 Node is writable<br />
4 Node is able to create<br />
5 Node has default data<br />
6 (if node is sequence, this is mean implied index node)<br />
7 always set 1<br />
<br />
====[id] field====<br />
* If this record is leaf, id that's reference to function services the record.<br />
<br />
====[distantSiblingOffset] field====<br />
* If this record is a node [distantSiblingOffset] is enable. Point to next node sibling.<br />
<br />
====[siblingOffset] field====<br />
* If this record is a leaf [siblingOffset] is enable. Point to next leaf sibling.<br />
<br />
====[dataType], [dataLen], [data] fields====<br />
* If this record is a leaf and has default data<br />
** [dataType] is type of leaf's data.<br />
** [dataLen] is length of data.<br />
** [data] is data on string.<br />
<br />
====[{<index_number>}]====<br />
* If this record is sequence, index_number is number of INDEXes in sequence.<br />
** [{<IndexCount>, <IndexNodeInfo>, <indexDataType>}]<br />
* If this record is sequence<br />
** <IndexCount>: is index of INDEX in table<br />
** <IndexNodeInfo>: is info of index_node<br />
** <indexDataType>: is data type of index_node<br />
<br />
===Example===<br />
The example, mchip.txt has the oid tree that's describe by tree graph below<br />
<br />
when compiler mchip.txt to binary file. The binary file is mchip.bin has data describe in table below:<br />
<br />
Oid is <oid> fields.<br />
Info is <nodeInfo> fields.<br />
Dist is [distantSiblingOffset]/[siblingOffset] fields.<br />
Id is [id] fields.<br />
Defval is data fields, include [dataType], [dataLen], [data] fields.<br />
Index is index fields of sequence, include [{index_number} , {<IndexCount>, <IndexNodeInfo>, <indexDataType>, ...}].<br />
<br />
the detail description of mchip.bin is illuminated by structure diagram blow:<br />
<br />
<br />
<br />
The hidden linear is oid tree structure.<br />
The red and green continue linear is pointer of data.<br />
The dist field point to next sibling record. After parent record is it's children.</div>Tcwdenhttp://www.opencircuits.com/index.php?title=SNMP_MIB_Implementation&diff=19750SNMP MIB Implementation2010-09-28T03:29:00Z<p>Tcwden: Created page with 'This wiki describe how to generate a MIB (Management Information Base) for SNMP agent. ==Steps== # Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for t…'</p>
<hr />
<div>This wiki describe how to generate a MIB (Management Information Base) for SNMP agent.<br />
<br />
==Steps==<br />
# Create a Microchip Custom MIB script '''snmp.mib''' (an ASCII text file) for the tree structure.<br />
# Create a ASN.1 MIB script '''foo.mib''' (an ASCII text file) for the tree structure.<br />
# Convert foo.mib to binary file using '''mib2bin'''<br />
# Build [http://www.rane.com/note161.html snmp's PDU use BER (Base encoding rules)] encoder and decoder library to process data that's transfer between NMS and agents.<br />
# Build snmp API use [http://www.sics.se/~adam/uip/index.php/Main_Page 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).<br />
# Build binary MIB file reader library.<br />
# Build functions service oid tree.<br />
# Merge MIB ANS.1 file to NMS.<br />
<br />
<br />
==Create Microchip Custom MIB Script==<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
<br />
==Create ASN.1 MIB Script==<br />
* Build MIB file's written in [http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf ANS.1 notation].<br />
* <font color=red>Any tutorial to create this file?</font><br />
<br />
===Abstract Syntax Notation===<br />
*Each MIB variable contains several attributes, such as data type, access type and object identifier.<br />
*Abstract Syntax Notation version 1 (ASN.1) is a language to define these attributes in SNMP.<br />
<br />
<br />
==Convert MIB to Binary File==<br />
MIB compiler tools: '''mib2bin'''<br />
[http://www.modtronix.com/products/sbc44ec/00870a.pdf mchip.mib] (ANS.1 format) -----------------------------------> foo.bin + foo.h + foo_data.h<br />
<br />
* mib2bin tool is modified from [http://net-snmp.sourceforge.net/ net-snmp] to convert ASN.1 format file to three files:<br />
** Binary file ('''foo.bin''') storing information of OID tree. This file can be placed on an SD media card to be read by the FAT16 file system.<br />
** C header file ('''foo_data_h''') 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.<br />
** C header file ('''foo.h''') storing ID that's reference to function service of OID.<br />
<br />
===How to use===<br />
* Syntax to use mib2bin tool:<br />
'''mib2bin <MIBfile>...<br />
where:<br />
MIBfile file is ASN.1 format file. MIBfile = <name>.<type><br />
* mib2bin tool will create three files:<br />
** <name>.bin is the binary file.<br />
** <name>_data.h is C header file store OID tree.<br />
** <name>.h is C header file. (The file store Ids).<br />
* Note: <br />
** 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.<br />
** If the three files exist, mib2bin tool will overwrite the files.<br />
* Example:<br />
mib2bin mchip.txt<br />
<br />
mib2bin will generate three files: mchip.bin, mchip_data.h and mchip.h</div>Tcwden