AN0870 SNMP v2c agent for microchip TCPIP stack

• SNMP – Simple Network Management Protocol is the protocol used to communicate between the manager and the network element agent.. The following main features are included: • Portable a

Simple Network Management Protocol (SNMP) is one

of the key components of a Network Management

System (NMS) SNMP is an application layer protocol

that facilitates the exchange of management

informa-tion among network devices It is a part of the TCP/IP

protocol suite

SNMP is an Internet protocol that was originally

designed to manage different network devices, such as

file servers, hubs, routers and so on It can also be

used to manage and control an ever increasing number

of small embedded systems connected to one another

over any IP network Systems can communicate with

each other using SNMP to transfer control and status

information, creating a truly distributed system

SNMP is used in a variety of applications where remote

monitoring and controlling of the network node is

desired, such as a network printer, online Uninterrupted

Power Supply (UPS), security cameras, home and

industrial appliances monitor and control, automatic

energy meter readings, etc

Unlike more familiar human-oriented protocols, like

HTTP, SNMP is considered a machine-to-machine

protocol

There are three key components of TCP/IP Network

Management:

• MIB – Management Information Base is a

collection of the variables (managed objects) the

network elements/agents store The individual

variables are identified by Object Identifiers

(OIDs)

• SMI – Structure of Management Information is a

set of common structures and a way to refer to

variables in the database

• SNMP – Simple Network Management Protocol is the protocol used to communicate between the manager and the network element agent

Microchip TCP/IP Stack supports two versions ofSNMP:

• SNMP Version 1 (SNMP V1)

• SNMP Version 2 Community-Based (SNMP V2c) Most of the features are common to both versions.SNMP V2c offers additional protocol operations, such

as Get_Bulk, a rich set of error indications,community-based access, etc

The SNMP Agent described here is designed to run onMicrochip’s PIC® microcontrollers and is implementedusing services provided by the free Microchip TCP/IPStack The following main features are included:

• Portable across all PIC18, PIC24, PIC32 MCUs and dsPIC® DSC families of microcontrollers

• Functions independently of RTOS or application

• SNMP ‘C’ source code is supported on Microchip’s MPLAB® IDE and can be compiled with PIC18, PIC24, PIC32 MCUs and dsPIC DSC compilers ‘out of the box’

• Supports SNMP Version V1 and V2c over User

Datagram Protocol (UDP)

• Supports Get, Get_Bulk, Get_Next, Set and Trap Protocol Data Units (PDUs)

• Supports up to 255 dynamic OIDs and unlimited constant OIDs

• Supports sequence variables with a 7-bit index

• Supports enterprise-specific Trap(s) with one variable information

• Handles access to constant OIDs automatically

• Utilizes a MIB that can be stored internally or externally on EEPROM

• Includes PC-based Microchip customized MIB script compiler

Author: Amit Shirbhate

Microchip Technology Inc.

Note: The Microchip SNMP Agent does not contain built-in TCP/UDP statistic counters The number of TCP/UDP

packets transmitted/received by the node is generally maintained for applications running on switches, routers

or where the packet count is crucial to the node application The user application, if required, shouldimplement the packet counter mechanism and also define and manage the corresponding changes to theapplication MIB file

SNMP V2c Agent for Microchip TCP/IP Stack

This document describes the SNMP protocol to explain

the implementation and design of the SNMP Agent For

more information about the SNMP protocol, refer to:

• RFC 3416 and related documents

• TCPIP Stack Help.chm file (Microchip

Solutions\Microchip\Help), which comes with the

Microchip TCP/IP Stack

The latest Microchip TCP/IP Stack (in installer format)

can be downloaded from (www.microchip.com/tcpip)

The TCP/IP Stack and the accompanying software

tools, particularly the MPFS2 Microchip File System

Generator and mib2bib Microchip MIB script compiler

utility, are required utilities for the Microchip SNMP

in which this data must be transferred and interpreted.Once a device is SNMP-enabled, any SNMP compatiblehost system SNMP Manager/Client can monitor andcontrol that device The SNMP Manager uses the UDPPort Number 161 to send requests to the agent Theagent uses the UDP Port Number 162 to send Trap(s)

or notification events to the manager The manager canrequest data from the agent or set variable values in theagent The agent can respond and report events.The SNMP collects Network Management Station(NMS) information in two ways:

• The agents on the network are polled by NMS software

• Agents send alerts to the SNMP Managers The alert can be sent to all the SNMP Managers in the community

FIGURE 1: LOCATION OF SNMP IN THE TCP/IP PROTOCOL STACK

FIGURE 2: OVERVIEW OF THE SNMP MODEL

Embedded Device

Network Device

Memory for

Management Protocol (SNMP)

Managed Nodes (SNMP Agent) Management

Information Base (MIB)

MIB and Other Web Pages

Memory for MIB and Other Web PAGES

Memory for MIB and Other

SNMP TERMINOLOGY

This application note frequently uses terminology

described by the SNMP specification, which we will

briefly review here Figure 2 shows how the associated

terminology applies to the typical SNMP model The

SNMP Agent is also referred to as SNMP server and

the SNMP Client is also referred to as SNMP Manager

Network Management Station (NMS)

The NMS is one side of the SNMP Client-Server setup;

the other side is the SNMP Agent Because our focus

in this document is on the agent, we will only discuss

NMS here briefly

Typically, the NMS is a personal computer running

special or customized software that monitors and

con-trols managed devices; it could be any other embedded

device too NMS acts as an SNMP Client, periodically

polling an SNMP Agent for data

Once a device is SNMP enabled, any commercial or

customized NMS software can be used to monitor the

device NMS can be used to monitor the collection of

similar or dissimilar devices Many of the commercially

available PC-based NMS systems provide a graphical

representation of managed devices Also, the addition

of devices to a network does not require change in

NMS software Uploading the new device’s ASN.1 MIB

file to the NMS software provides the option to manage

the device All of these features give SNMP the

functionality that makes it a popular choice for network

as well as device management There are several

SNMP NMS Manager/Client or MIB browser software

vendors, for instance, SNMPc Manager from

CastleRock Computing, LoriotPro from LUTEUS,

iReasoning MIB browser and Trap Receiver and so on

Managed Node (SNMP Agent)

A Managed Node (or SNMP Agent, as it is very oftencalled) is the device that is being managed by NMS TheSNMP Agent is the software running on the ManagedNode or the network elements, such as a microcontroller

on an embedded device, switches, routers and so on.The SNMP Agent implements the server portion of theSNMP protocol, acting as the agent between the deviceapplication and the NMS software The relationship isnot necessarily one-to-one, as a single agent can simul-taneously serve data to several Network ManagementStations The agent waits for NMS requests andresponds with the appropriate information

Management Information Base (MIB)

Each SNMP Agent stores its own special collection ofvariables, called the Management Information Base(MIB) To organize the MIB, SNMP defines a schema,known as the Structure of Management Information(SMI)

Figure 3 shows a generic SMI The MIB is structured in

a tree-like fashion, with one root at the top of the treeand one or more children below the root Each childmay contain one or more children of its own, thus cre-ating an entire tree The bottom-most nodes that do nothave any children are called leaf nodes These nodescontain the actual data

SNMP and other RFC documents for the Internetdefine several MIBs Figure 4 shows a subtree of theactual MIB for the Internet Subtrees, such as “system”,

“udp” and “tcp”, are standard MIBs that are defined byspecific RFC documents These and other standardMIBs should not be modified if the SNMP Agent needs

to be compatible with other NMS software

A special subtree, called “enterprise”, is defined forprivate enterprises Any SNMP Agent device manufac-turer may obtain its own Private Enterprise Number(PEN) from Internet Assigned Number Authority(IANA) Once assigned a PEN, the manufacturer mayadd or remove any number of subtrees beneath it, asrequired Applications can be made at the web site:http://pen.iana.org/pen/PenApplication.page

FIGURE 3: GENERIC STRUCTURE OF MANAGEMENT INFORMATION (SMI)

FIGURE 4: EXAMPLE OF AN ACTUAL SMI (PARTIAL INTERNET SUBTREE)

OID of this Node:

OID of this Node:

Object Identifier (OID)

Each node in the MIB tree is identified by a sequence

of decimal numbers, called Object Identifier (OID) A

specific node is uniquely referenced by its own OID and

that of its parents’ OIDs Such an OID is written in

“dotted decimal” notation, similar to those used by IP

addresses but not limited to four levels For example,

the OID for the system node in Figure 4 is written as

‘1.3.6.1.2.1.1’ For the convenience of readers, an OID

is frequently written with each node name and its OID

in parenthesis Using this convention, the OID for

the system node can be rewritten as:

iso(1).org(3).dod(6)

internet(1).mgmt(2).mib(1).system(1)

By virtue of OID assignments, the first number is always

either ‘1’ or ‘2’, and the second number is less than 40

The first two numbers, ‘a’ and ‘b’, are encoded as one

byte, having the value 40a + b For the Internet, this

number is 43 As a result, the system OID is transmitted

as ‘43.6.1.2.1.1’, not ‘1.3.6.1.2.1.1’

SNMP Security

In SNMP, security is administered in two ways:

• Through community-based access architecture

• By sending a Trap if a predefined event occurs

There are different types of configuration parameters to

be configured to an agent depending on the kind of

security required:

1 A firewall should be used to protect the SNMP

Agent from the Internet

2 Authentication failure Traps are sent to the

Manager NMS

3 Only requests from the SNMP community group

members should be responded to

4 Accept request/information PDU from the host

belonging to a list of IP addresses This is an

An SNMP Agent can be a member of more than oneSNMP community An agent does not respond to therequest from management stations which do notbelong to one of its communities The pairing of SNMPAccess mode with the SNMP MIB view is called anSNMP community profile A shared printer in a LANcan be used as an example to understand the SNMPV2c community concept Every user in the LAN hasaccess to some of the limited variables of the printer,such as the printer_name, location, uptime,contact and so on These are standard MIB2 systemvariables

These variables provide general printer information tousers (SNMP Clients) These variables are themembers of the ‘public’ community of the printer, andevery user in LAN is also a default member of the

‘public’ community

Some of the MIB variables of the printer, like queuingpriorities, order print job, suspend, printing formatsand so on, can be accessed by limited users Thesetypes of variables are known as private variables Theprivate variables are members of the ‘private’ commu-nity and can be accessed only by a member of thesame ‘private’ community These variables will belocated as child to ‘enterprise’ node, identified by PEN

as OID in the MIB

Note: The Microchip SNMP MIB script,

discussed later in this document, requires

that all SNMP OIDs start with ‘43’

SNMP PROTOCOL DATA UNIT

(SNMP PDU)

Data packets exchanged between two SNMP nodes

are called Protocol Data Units (PDUs) SNMP V1 and

V2c define six main types of data packets, which are

exchanged between the SNMP Agent and Client

• Get_Request – Get one or more variables’

information from the agent (manager to agent)

• Get_Next_Request – Get next variable

informa-tion in the MIB after one or more variables are

specified in the request (manager to agent)

• Get_Bulk_Request – Get bulk operation is

normally used to retrieve a large amount of data,

particularly from large data tables residing in agent

memory (manager to agent)

• Set_Request – Set is to configure one or more variables in the agent (manager to agent)

• Get_Response – Return variable information for the requested OID (agent to manager)

• Trap – Notification from the agent to the manager

of a predefined event occurrence (agent to manager)

All Get and Set PDUs share a common messageformat; the format for Trap PDUs is somewhatdifferent

The two formats are compared in Figure 5

FIGURE 5: PDU FORMATS FOR Get/Set AND Trap PACKETS

Note: Users of the Microchip SNMP Agent do not need to know the details of the PDU format or its encoding;

the SNMP Agent module automatically handles all of the low-level protocol details, including theencoding and decoding of data variables For more information on the individual PDU fields, refer toRFC 1157 and RFC 3416

Ve

rsion Com

uni ty

PDU T

ype

Re que st ID

Error Status

Error I

ndex

na

me1 value1

Get and Set PDU Format

Trap PDU Format

nam

en

va luen

• • •

• • •

nam e1

va lue1• • • namenvaluen

• • •

En terp rise

Agen

t A dd ress

Tra

p Ty pe

SNMP PDU TYPES

It is mandatory for all SNMP Agents to be able to

gener-ate Get_Response and Trap PDUs, and to receive

and process Get_Request, Get_Next_Request,

Get_Bulk_Request and Set_Request PDUs

Get_Request

• (PDU Type = 0x00)

This PDU is generated and transmitted as a

request to get information or value of the

requested OID

Upon receipt of the Get_Request PDU, the

receiving entity (the agent) processes each

vari-able binding in the varivari-able binding list to produce

a Get_Response PDU The response PDU has

the same values as the corresponding fields of the

received request, except in cases stated below:

- If the requested OID is found in the MIB

data-base, and the request is authenticated for the

access privileges, the value field is set to the

value of the requested variable Access

privileges refer to community name and the

read/ write access to the variable

- If the requested variable binding name does

not have an OID prefix that exactly matches

the OID prefix of any potential variable

accessible by this request, then the value

field is set to noSuchObject.

- Otherwise, the value field is set to

noSuchInstance, and the error-status and

the error-index fields would be

correspondingly set

Get_Next_Request

• (PDU Type = 0x01)

This PDU is generated and transmitted as a

request to get information or the value of the

lexi-cographical successor of the requested OID Upon

receipt of this request PDU, the receiving entity

(the agent) processes each variable binding in the

variable binding list to produce a Get_Response

PDU The response PDU has the same values as

the corresponding fields of the received request,

except in cases stated below:

- The variable is located, which is in the

lexico-graphically (in alphabetical order) ordered list

of the names of all variables accessible by

this request, and whose name is the first

lexicographical successor of the variable

binding’s name in the incoming

Get_Next_Request PDU The

correspond-ing variable bindcorrespond-ing’s name and value fields

in the response PDU are set to the name and

value of the located variable

OID in the requested PDU, the value field in

the response PDU is set to endOfMibView

and the name field is set to the requested OID

- Otherwise, the error-status field and the error-index would be correspondingly set.

Get_Bulk_Request

• (PDU Type = 0x05)Get_Bulk_Request PDU is to request andtransfer a large amount of information from theagent to the client (NMS) within the single PDU(particularly data from large tables) This will signif-icantly reduce the PDU network traffic Uponreceipt of this request PDU, the receiving entity(the agent) processes each variable binding in thevariable binding list to produce a Get_ResponsePDU, with the same request ID field

Get_Bulk_Request is made by giving an OID

list along with a Max-Repetitions value and Non-Repeater value.

The Get_Bulk operation is a continuousGet_Next operation depending on the

Max-Repetitions value The Non-Repeater

value determines the number of the first ‘N’ ables in the variable list of the request PDU forwhich a simple Get operation must be performed.The Get_Bulk operation is a result of a combi-nation of Get operations for the first ‘N’

vari-(Non-Repeater) variables in the request PDU

and Get_Next continuous operation for each ofthe remaining ‘R’ variables in the variable list TheGet_Next operation must be repeated for ‘M’

(Max-Repetitions) number of times for each of

the ‘R’ variables

Set_Request

• (PDU Type = 0x03)Set_Request PDU is generated and transmittedfrom an SNMP Client or the management station.The PDU contains the variable and thecorresponding value to be set to the variable in theagent The Set_Request will be processed at theagent if it is originated from the source, which ispart of the group/community an agent belongs to.Otherwise, the agent can generate anAuthenticationFailure Trap, if configured so.The variable to be set has to be of the read/write type.Depending upon the data type, variable type andaccess mode, the agent can generate the

notWritable, wrongType, wrongLength, wrongEncoding, wrongValue, noCreation, inconsistentName, inconsistentValue, resource- Unavailable, genErr, NoError, commitFailed and undoFailed errors in the response PDU.

Trap PDU

• (PDU Type = 0x04)

A Trap PDU is generated and transmitted by an

agent if an exception occurs The exception has to

be defined with the agent and the Trap destination

IPs to be configured with There are different types

of Trap(s):

- ColdStart Trap (Type = 0): If the agent is

reinitializing itself with either the agent’s

con-figuration or the protocol entity implementation

is altered

- WarmStart Trap (Type = 1): If the agent is

reinitializing itself with neither the agent’s

configuration, nor the protocol entity, the

implementation is altered

- LinkDown Trap (Type = 2): If one of the

communication links of the agent fails, the

Trap PDU will have the name and the

instance of the interface instance that failed

- LinkUp Trap (Type = 3): Indicates that one

of the communication links of the agent has

come up

- AuthenticationFailure Trap (Type = 4):

Signifies that an unauthenticated request has

come for private variable access from a non-

member of the community This Trap adds

the security to the agent In this case, the

agent can be configured to hibernate to

protect from any unauthorized access or

snooping

- EgpNeighborLoss Trap (Type = 5): Signifies

that an Exterior Gateway Protocol (EGP)

neigh-bor, with whom the agent had an EGP link, is

no longer in the link and the peer relationship is

no longer obtained

- EnterpriseSpecific Trap (Type = 6):

Signifies that the sending agent has

encountered an enterprise-specific event

The Trap field will have the code of the event

that occurred

Get_Response

• (PDU Type = 0x02)The response PDU is generated by the SNMPAgent once it receives a Get_Request,Get_Next_Request, Get_Bulk_Request orSet_Request PDU

If the error status field of the response PDU is notzero, the value fields of the variable bindings in thevariable bindings list are ignored on the manager’sside

If the error-status and error-index fields are both non-zero, then the error-index value is the index

of the variable in the variable binding for which therequest processing failed The SNMPManager/Client NMS should be able to properly

handle errors, such as noSuchName, badValue, readOnly, etc.

SNMP PDU PROCESSING

The actual SNMP Agent is implemented by several

files working together with the Microchip TCP/IP Stack

The SNMP Agent and the corresponding APIs are

implemented in SNMP.c and CustomSNMPApp.c

Apart from this, a few callback functions must also be

implemented to provide communication among the

SNMP module, the host application and the rest of the

TCP/IP Stack

well-defined methods for communicating betweenapplications and the SNMP Agent, and are alsodesigned to make application design easier for theuser Example 1 illustrates the PDU processing by theagent This pseudocode enables the users to under-stand the execution flow at the Microchip SNMP Agentfor the received request PDUs from the manager/client

EXAMPLE 1: SNMP PDU PROCESSING FLOW – PSEUDOCODE

EXAMPLE 1: SNMP PDU PROCESSING FLOW – PSEUDOCODE (CONTINUED)

//Process each of the variables in varbind list

WRITE_COMMUNITY case SM_FIND_OID_IN_MIB:

//Search for the requested OID in the MIB database with the agent.

OIDLookup(pduDbPtr,OIDValue, OIDLen, &OIDInfo);

if(oidLookUpRet != TRUE ) //Set the error index and error code accrodingly else

//proceed to next state in the statte machine case SM_NON_REPETITIONS:

/*Variables in get,get_next,set and get_bulk request(non-repetition variables)are processed in this part of the state machine.*/

//Process every veriable in the request.

for(varBindCntr=0;varBindCntr<Getbulk_R;varBindCntr++) {

OIDLookup(pduDbPtr,OIDValue, OIDLen, &OIDInfo)) ProcessGetBulkVar(&OIDInfo, &OIDValue[0],&OIDLen,&successor);

} } }

}

(ASN) LANGUAGE

Each MIB variable contains several attributes, such as

data type, access type and Object Identifier SNMP

uses a special language, called Abstract Syntax

Notation Version 1 (ASN.1), to describe details about

variables ASN.1 is also used to describe SNMP and

other protocol data exchange formats ASN.1 is written

as a text file and compiled using an ASN syntax

com-piler Most of the NMS and SNMP Agent software is

An example of a variable description in ASN.1 syntax isshown in Example 2

There are commercially available ASN.1MIB buildersthat allow users to build ASN.1 MIBs graphically with-out the need to learn ASN syntax first The MicrochipSNMP Agent uses its own special script to describe itsagent OIDs, as well as its own script compiler to createcompact binary representations of the MIB The cus-tom script also allows the assignment of constant data

to OIDs The Microchip MIB script and its compiler aredescribed in greater detail, starting on page 14.Example 2 provides the Microchip demo ASN.1 MIB file

EXAMPLE 2: MICROCHIP SNMP ASN.1 MIB FILE

Microchip DEFINITIONS ::= BEGIN

IMPORTS

enterprises, IpAddress, Gauge, TimeTicks FROM RFC1155-SMI

DisplayString FROM RFC1213-MIB

OBJECT-TYPE FROM RFC-1212

TRAP-TYPE FROM RFC-1215;

microchip OBJECT IDENTIFIER ::= { enterprises 17095 }

product OBJECT IDENTIFIER ::= { microchip 1 }

setup OBJECT IDENTIFIER ::= { microchip 2 }

control OBJECT IDENTIFIER ::= { microchip 3 }

ON-OFF ::= INTEGER { ON(1), OFF(0) }

EXAMPLE 2: MICROCHIP SNMP ASN.1 MIB FILE (CONTINUED)

EXAMPLE 2: MICROCHIP SNMP ASN.1 MIB FILE (CONTINUED)

Binary Encoding Rules (BER)

SNMP uses ASN.1 syntax to describe its packet and

variable contents ASN is an abstract syntax; that is, it

does not specify how the actual data is encoded and

transmitted between two nodes A special set of rules,

called Binary Encoding Rules (BER), is used to encode

what is described by the ASN.1 syntax BER is

self-contained and platform independent Each data

item encoded with BER contains its data type, data

length and its actual value; this is in contrast to regular

data, where only the data content is given

A data variable encoded by BER consists of a tag byte,

one or more length bytes and one or more value bytes.

The tag byte describes the data type associated with

the current data variable The length byte(s) gives the

number of bytes used to describe the data content The

value bytes are the actual data content Figure 6 shows

the breakdown of typical BER values and an example

of encoding

It is not necessary for users to learn the encoding rules

The SNMP Agent automatically handles encoding and

decoding of all supported data types

FIGURE 6: GENERIC BER FORMAT

(TOP) AND AN EXAMPLE OF BER ENCODING (BOTTOM)

DESCRIBING THE MIB WITH

MICROCHIP MIB SCRIPT

Microchip’s SNMP Agent uses a custom script to

describe the MIB This script is designed to simplify the

MIB definition and its integration with the main

applica-tion The actual MIB used by the SNMP Agent is a

binary image created by the Microchip mib2bib (MIB to

BIB) compiler (page 23)

Microchip MIB Script Commands

A Microchip MIB file is an ASCII text file consisting ofmultiple command lines Each command line consists of

a single command, starting with the dollar sign character(“$”), and one or more command parameters delimitedwith commas and enclosed in parentheses Lines that donot start with a dollar sign are interpreted as commentsand are not processed by the compiler Commands must

be written in a single line; they cannot span multiple lines The MIB script language includes a total of fivecommands, each having a specific syntax Only onecommand, DeclareVar, is mandatory; the others areoptional depending on the application and the types ofinformation to be defined In practice, at least one othercommand will be used in defining an MIB The syntax ofthe script commands is explained on page 14through 26

Example 3 shows a Microchip MIB file In this example,seven separate items are being defined In the script,

“Microchip MIB Compiler (mib2bib)”, a read-only node

is being established at the OID of 43.6.1.2.1.1.5; it tains the identifier string, “PICDEM.net 2”, as staticinformation

con-In the fourth section of the Microchip MIB script,

“microchip.control”, a node with dynamic LED5status information is being established at the OID of43.6.1.4.1.1.17095.3.1 The variable, called “LED_D5”,

is assigned an identifier of 1

In section, “microchip.setup”, a two-column,four-row data array is being created with the followingvariables:

Encoding the Integer Value ‘49’ (0x31):

Note: • Both the ASN.1 MIB file and the Microchip

MIB script use the same mib file sion, but the files have distinctly differentpurposes The ASN.1 MIB file is used bythe MIB browser (NMS) to properly displaycontext for your application

• The Microchip MIB script is compiled

using mib2bib to create a BIB file The BIBfile is later converted using MPFS2 tostore the MIB data for your application ininternal Flash or EEPROM

includes this header file and refers to this OID using oidName.

WORD 16-bit (2-byte) data

DWORD 32-bit (4-byte) data

IP_ADDRESS 4-byte IP address data

COUNTER32 4-byte COUNTER32 data as defined by the SNMP specification

GAUGE32 4-byte GAUGE32 data as defined by the SNMP specification

OCTET_STRING Up to 127 bytes of binary data bytes

ASCII_STRING Up to 127 bytes of ASCII data string

OID Up to 127 bytes of dotted decimal OID string value If any of the individual OID values are

greater than 127, the total number of allowable OID bytes will be less than 127

SINGLE If this variable contains a single value

SEQUENCE If this variable contains an array of values All variables with an oidType of SEQUENCE

must be assigned an “index” OID variable using the SequenceVar command

READONLY If this variable can only be read

READWRITE If this variable can be read and written

If compiled successfully, this command will create a new OID variable This variable can be used as an OID parameter

in other commands, such as StaticVar, DynamicVar or SequenceVar

Precondition

None

Examples

This command declares an OID variable, named “sysName”, as defined in the standard MIB subtree system:

$DeclareVar(sysName, ASCII_STRING, SINGLE, READONLY, 43.6.1.2.1.1.5)

This command declares an OID variable of type, BYTE:

$DeclareVar(LED_D5, BYTE, SINGLE, READWRITE, 43.6.1.4.1.17095.3.1)

If compiled successfully, this command will declare the given oidName as a static OID A static OID contains constant

data that is stored in the BIB Static OIDs are automatically managed by the SNMP Agent module; the application neednot implement callback logic to provide data for this OID variable

Precondition

The given oidName must have been declared using the previous DeclareVar command.

Examples

This command declares an OID variable, named “sysName”, as defined in the standard MIB subtree system:

$StaticVar(sysName, PICDEM.net running Microchip SNMP Agent)

These commands declare an OID variable, named “sysID”:

$DeclareVar(sysID, OID, SINGLE, READONLY, 43.6.1.2.1.1.2)

$StaticVar(sysID, 43.6.1.4.1.17095)

These commands declare an OID variable of a MAC type address:

$DeclareVar(macID, OCTET_STRING, SINGLE, READONLY, 44.6.1.4.1.17095.10)

$StaticVar(macID, 0, 1, 2, 3, 4, 5)

BYTE, WORD, or DWORD Must be written in decimal notation

IP_ADDRESS and OID Must be written in appropriate dotted decimal notation for data type

ASCII_STRING Must be free form ASCII string with no quotes Commas, parentheses and

backslashes must be preceded by the backslash (“\”) as an escape character.OCTET_STRING Must be written in multiple individual bytes separated by commas

Any 8-bit identifier value, from 0 to 255 It must be unique among all dynamic OID variables The main application uses

this value to refer to the actual OID string defined by oidName.

Result

If compiled successfully, this command will declare the given oidName as a dynamic variable An entry will be created

in the mib.h header file of the form:

These commands declare an OID variable, named LED_D5, as a dynamic variable:

$DeclareVar(LED_D5, BYTE, SINGLE, READWRITE, 43.6.1.4.1.17095.3.1)

$DynamicVar(LED_D5, 5)

Note: An OID variable of data type OID cannot be declared as dynamic

This command declares a previously defined OID variable as a sequence variable and assigns an index to it Asequence variable can contain an array of values and any instance of its values can be referenced by an index Morethan one sequence variable may share a single index, creating multi-dimensional arrays The current version limits thesize of the index to 7 bits wide, meaning that such arrays can contain up to 127 entries

Name of OID variable that will form an index to this sequence It must have been declared by a previous DeclareVar

command with a dataType of BYTE

Any row in this table can be accessed using TRAP_RECEIVER_ID as an index

$DeclareVar(TRAP_RECEIVER_ID, BYTE, SEQUENCE, READWRITE, 43.6.1.4.1.17095.2.1.1.1)

The given oidName must have been declared using a previous DeclareVar command with an oidType of OID It

must also have been declared static using a previous StaticVar command

Example

The following command sequence declares the Agent ID for this SNMP Agent:

$DeclareVar(MICROCHIP, OID, SINGLE, READONLY, 43.6.1.2.1.1.2)

$StaticVar(MICROCHIP, 43.6.1.4.1.17095)

$AgentID(MICROCHIP, 255)

Note: The data type of oidName must be OID; oidName must be declared static.