Sending Traps and Informs

 

 

Overview

 

In addition to retrieving data from the Managed Resource and sending response to them, Agents also have the ability to send unsolicited messages to Managers when they detect some significant event. An unsolicited message of this sort is called Trap (in SNMPv1) or Notification (in SNMPv2 and SNMPv3). The WebNMS C Agent supports both Traps and Notifications in all the three versions of SNMP. Informs (Confirmed Notification), on the other hand, is a Trap sent from the Agent, with a request to the Manager to acknowledge the receipt of Trap.

 

To learn more on Trap Basics, please refer to"SNMP Protocol Overview" in the Technologies Used section.

 

Generating Traps

 

For the SNMP Agent to generate a Trap/Notification, the respective MIB should have definition for that Trap/Notification. To define a Trap Type Construct (in SNMPv1 MIB Module) or Notification Type Construct (in  SNMPv2c Module) using MIB Editor, please refer to the "Defining a MIB" section.

 

Method Definition for Traps

 

The MACRO that has to be defined in the config.h file present under <WebNMS/C-gent>/projects/ProjectName/agent/source/system/include directory for Traps, Notification and Informs support is

    #define TRAPFORWARDING_REMOTE_IFC

 

The Agent will send Traps, Notification, and Informs only if this MACRO is defined.

 

For each trap definition in the MIB, the corresponding trap generation function is generated by the Agent Compiler in the file <MibName>traps.c under the directory <WebNMS/C-Agent\projects/<ProjectName>/agent\stubs/<Mib Name>/src. This file has the necessary function calls to generate the defined trap.

 

You can also call this function with required arguments from anywhere in the Agent or from your application and it sends the Trap to the corresponding Managers.

Generating Trap on SET

 

It is possible to generate Traps while setting a new value to a variable for which Trap is defined. The Generate Traps on Set option in Agent Compiler UI provides this facility. By default this option will be enabled. To view the same,

Manager Details for Sending Traps

 

To notify the significant state of change in the Agent to the Manager, it is required to store the Manager information in the Agent side. To maintain the Manager's information, the Trap Forwarding Tables in AGENT-SNMP-CONFIG-MIB -> agentConfiguration -> trapTables group is used.

 

Before moving into the Trap Forwarding Table, let us see a brief on IPv6 implementation in SNMP Agent.

 

IPv4 is the generally used addressing model. Agent Toolkit introduces IPv6 (IP Version 6 Protocol) model, which is a completely new and redesigned network-layer protocol defining an advanced format of IPv4. IPv6 is a 128-bit identifier, addressing interfaces and set of interfaces. Agent Toolkit SNMP Agent also provides the IPv6 addressing support apart from IPv4 for any network communication between the agent and the manager. Accordingly, the changes have been implemented in the trap forwarding table

 

v1v2TrapForwardingTable or v2ManagerTable

 

If you are creating SNMPv1 or SNMPv2c Agent, then you should use v1v2TrapForwardingTable. This table is used for storing SNMP v1 or SNMPv2c Manager's information.

The v1v2TrapForwarding Table with the OID.1.3.6.1.4.1.2162.10.2.1.2.2.1 has the following columns defined in it.

Default entry

v3TrapForwardingTable or v3ManagerTable

 

If you are creating SNMPv1 or SNMPv2c Agent, then you should use v1v2TrapForwardingTable. This table is used for storing SNMPv1 or SNMPv2c or SNMPv3 Manager's information.
The v3TrapForwardingTable with the OID .1.3.6.1.4.1.2162.10.2.1.2.2.2 has the following columns defined in it.

Default entry

    Host Type

    Host IpAddress

    		 Port Version Community Use Name SecModel SecLevel Context Name TimeOut Retries Row Status

    1

    127.0.0.1

    8003

    SNMP_VERSION_2c

    public

    noAuthUser

    USM

    NOAUTH

    noAuth

    5

    0

    ACTIVE

This table is multi-lingual by nature, i.e., it can forward any version of Traps to the Managers registered in the Table. The userName, secModel, and contextName are used in the case of SNMPv3. The remaining columns are common to all the versions. The timeout and retries are used in case of INFORM requests. Using these columns you can set different timeout and retries value to each Manager. The community string is common to all the versions, because, in SNMPv3 if you want to generate a v1 or v2c trap, you can send it directly to the Manager without much of change in the code. For a v3 Trap, the Agent will call the IsAccessAllowed() method according to VACM MIB for each variable binding OID and trap OID. The IsAccessAllowed() method follows the VACM architecture to identify the MIB view for the particular trap. If no access is provided for the user in the VACM tables, then the Notification will not be sent to that Management target.

 

Adding Manager Entries

 

There are two ways in adding Manager entries to the Trap Forwarding Table. It can be done either : (1) Before Agent start-up or (2) During run time.

 

Before Agent Start-Up

 

Entries can be added to the Trap Forwarding Tables before Agent start-up using either of the following options : Using Agent Compiler UI / Text File/Function Calls.

 

1. Using Agent Compiler UI

2. Text File

 

The entries configured through Agent Compiler UI get stored in the configuration file, v2managertable.txt, or v3managertable.txt under <WebNMS>/C-Agent/projects/<ProjectName>/agent/conf/snmp directory, provided the storage type MACRO is defined in the config.h file as given below :

    #define AGENT_FILE_TO_VECTOR

This text file has to be edited for adding Manager Entries. The v2managertable.txt given below has been edited for adding a New Manager with Community. Host "127.0.0.1" and  Manager Port : "8004".

    1 127.0.0.1 8004 SNMP_VERSION_2c public 30 5 ACTIVE

Similarly, v3 entries can be added in v3managertable.txt file. Please note that the Agent has to be re-started for the changes to take effect.

 

4. Using Functional Calls

 

An entry can be added to the authentication table by calling the function CreateManagerEntry()

 

This function is defined in <WebNMS>/C-Agent/projects/<ProjectName>/agent/source/protocols/snmp/src/ managerlist.c and is called from <WebNMS>/C-Agent/projects/<ProjectName>/agent/stubs/submain.c file. By calling the following function with specified parameters, a new entry will be added to the authentication table. You can call this function either before Agent startup or during run time.

    V1/v2c : CHAR CreateManagerEntry(INT32 managerHostType, CHAR *managerHost, U_INT32 managerPort, INT32 managerVersion, CHAR *community, U_INT32 timeOut, U_INT32 retries, INT32 managerStatus)

     

    V3 : CHAR CreateManagerEntry(INT32 managerHostType, CHAR *managerHost, U_INT32 managerPort, INT32 managerVersion, CHAR *community, CHAR *userName,INT32 secModel, INT32 secLevel, U_CHAR *contextName, INT32 contextNameLen, U_INT32 timeOut, U_INT32 retries, INT32 managerStatus)

Examples

    V1/V2c : CreateManagerEntry(1, "127.0.0.1", 8003, SNMP_VERSION_2c, "public", 5, 0, SNMP_ROW_ACTIVE);

     

    V3 CreateManagerEntry(1, "127.0.0.1", 8003, SNMP_VERSION_2c, "public", "noAuthUser",

    USM_SECURITY_MODEL, SNMP_SEC_LEVEL_NOAUTH, (U_CHAR *)"noAuth", 6, 5, 0, SNMP_ROW_ACTIVE);

Similarly, to delete an entry from the Trap Forwarding Tables "DeleteManagerEntry" function can be called.

 

During Run Time: From the Manager

 

To add an entry to the trapForwardingTable from the Manager,

Testing the Agent for Traps

 

To test the Trap feature,

  1. Open the Trap Viewer in MIB Browser application and start listening for Traps in the Manager's port specified in Trap Forwarding Table.

  2. Load the MIB (MIB with which Agent was developed) in the MIB Browser application and start the Agent.

  3. First, you receive a StartupTrap. This can be configured using the API call GetStartUpTrapTypeAndPduVersion() in the submain.c file. You can provide the required trap type and version inside this method. The traps can be viewed by selecting the Trap and right-click on it. The Trap Details can also be seen.

  4. Now, SET a value to a variable for which trap is defined.

  5. Value would be set for the variable and a trap will be received in the Manager's Port (mentioned in Trap Forwarding Table).

Adding Extra Varbinds to Trap Varbinds

 

In v1 Traps

 

The prototype of the function is,

    void SendV1TrapOf< Trap Name >(vector *extraVarBinds)

The Trap message sent by a SNMP v1 Agent contains Agent Address, TimeStamp, Enterprises OID, Generic Trap Type, Specific Trap Type, and the varbinds of the defined Trap. This function creates and sends a trap message to all the registered Managers. You can update these trap variables value before calling this function based on the event occurred.

 

Trap Varbinds (for scalar variables)

 

A Trap Varbind is the trap variable information defined in the Trap. For each trap variable defined in the trap-type construct, the trap function contains the following code to get the trap varbind and add it to the trap vector.

    AddVarBind(trapVect,

    trap variable oid,

    trap variable oid length,

    trap variable type,

    trap variable value,

    size of trap variable value,

    FALSE);

For example, the trap variable frCircuitIfIndex defined in RFC1315 MIB for SNMPv1 trap has the following code.

    AddVarBind(trapVect,

    frCircuitIfIndexOid,

    frCircuitIfIndexOidLen,

    ASN_INTEGER,

    (U_CHAR

    *)&frCircuitTableEntryPtr->frCircuitIfIndex,

    __Sizeof(frCircuitTableEntryPtr->frCircuitIfIndex),

    FALSE);

Trap Varbinds for Tables

 

For table objects, the trap function invokes the following method before adding the varbind to the trap vector. This is done for each variable defined in the trap-type construct.

    Get< table name >Instance(& trap variable Oid, &trap

    variable OID Length, tablename_ trap variable, &

    tablename EntryPtr);

where, Get< table name >Instance() is used to retrieve the first entry of a table (by default) and the OID of the given table column with the instance value.

 

If a table has more than one row, the user can decide about the row (table column instance) value in the run time. This is done by specifying the row of the table to be sent out in the trap inside this function. Refer to the section, Sending traps based on Instance of a Table.

 

Parameters

 

1. AddVarBind()

 

This method call adds a varbind to the trap vector.

    AddVarBind(trapVect,

    trap variable oid,

    trap variable oid length,

    trap variable type,

    trap variable value,

    size of trap variable value,

    FALSE);

For example, the trap variable frCircuitIfIndex defined in RFC1315 MIB for SNMPv1 trap has the following code:

    AddVarBind(trapVect,

    frCircuitIfIndexOid,

    frCircuitIfIndexOidLen,

    ASN_INTEGER,

    (U_CHAR

    *)&frCircuitTableEntryPtr->frCircuitIfIndex,

    Sizeof(frCircuitTableEntryPtr->frCircuitIfIndex),

    FALSE);

2. SNMP Version

 

The SNMP version of the trap is assigned based on the v1v2ManagerVersion (v3ManagerVersion for SNMP v3), specified in the v1v2TrapForwardingTable (v3TrapForwardingTable for SNMP v3).

 

3. Enterprise OID

 

The OID specified in the Enterprises field indicates exactly which management enterprise defines the trap.

    trapPdu->enterpriseLen =

    ConvertToOidOrIpFromString(&trapPdu->enterprise,

    ".1.3.6.1.2.1.10.32", FALSE);

4. Agent Address

 

It is the IP Address of the Agent Host that generated the trap.

    trapPdu->agentAddr = __Inet_addr(AGENT_ADDRESS);

Where AGENT_ADDRESS value will be defined in config.h header file.

 

5. Generic Trap

 

If the trap type value is zero through five, then the trap is one of the generic SNMP traps defined by the SNMP group of MIB-II and the Specific TrapType will be zero (i.e, trapPdu->specificTrap = 0).

 

coldStart (0),

warmStart (1),

linkDown (2),

linkUp (3),

authenticationFailure (4),

egpNeighborLoss (5),

enterpriseSpecific (6).

    trapPdu->trapType = 1;

6. Specific trap

 

If the trap type value is six (i.e., trapPdu->trapType = 6), then the trap is an enterprise-specific trap that is defined in a private MIB.

    trapPdu->specificTrapType = 2162;

7. Agent Time

 

The trap function contains the following code to get the AgentUptime and update the trap pdu:

    trapPdu->time = GetAgentTime(TRUE);

8. ExtraVarBinds

 

The trap function is generated with input parameter extraVarBinds.

    void SendV1TrapOfscalarNotifications(vector

    *extraVarBinds)

It enables the user to add more varbinds to the trap vector other than the trap variables/objects defined in the trap of the MIB. It is optional. By default it will be NULL. Refer to the examples present under <WebNMS>/C-Agent/examples/snmp/traps directory.

    if (extraVarBinds != NULL)

    {

    for (i =0; i<extravarbinds->size; i++)

    {

    nodePtr = (node

    *)ElementAt(extraVarBinds,i);

    AddElement(trapVect, nodePtr);

    }

    }

In v2c Notifications

 

The prototype of the function is,

    void SendV2TrapOf<Trap Name>(vector *extraVarBinds,

    U CHAR informFlag)

The Trap message sent by the SNMP v2 Agent contains AgentUptime, Trap OID, and the trap objects varbinds of the defined Notification. This function creates and sends a notification message to all the registered Managers. You can update these notification objects value before calling this function based on the event occurred.

 

This function is generated with input parameters, extraVarBinds and informFlag.

 

Sysuptime

 

It is the time (in hundredths of a second) since the network portion of the system was last re-initialized. The trap function contains the following code to get the AgentUptime and add it to the trap vector.

    trapPdu->time = GetAgentTime(TRUE);

    AddVarBind(trapVect,

    sysUpTimeOid,

    gv_agentUpTimeOidLen,

    (U_CHAR)(ASN_TIMETICKS | ASN_PRIMITIVE),

    (U_CHAR *)&trapPdu->time,

    __Sizeof(trapPdu->time),

    FALSE);

where, sysUpTimeOid is the OID (.1.3.6.1.2.1.1.3) defined in RFC 1213 system group, gv_agentUpTimeOidLen is the lenght of sysUpTimeOid, GetAgentTime() gets the current agent uptime.

 

SNMP Trap OID

 

It is the OID value of the node which defines the notification. The trap function contains the following code to get the snmpTrapOid and add it to the trap vector.

    AddVarBind(trapVect,

    snmpTrapOid,

    gv_snmpV2TrapOidLen,

    ASN_OBJECT_ID,

    (U_CHAR *)snmpTrapVarVal,

    snmpTrapVarValLen,

    FALSE);

where, snmpTrapOid is the oid (.1.3.6.1.6.3.1.1.4.1) defined in RFC1907 snmpTrap group, gv_snmpV2TrapOidLen is the Length of the snmpTrapOid, snmpTrapVarVal is OID of this notification and snmpTrapVarValLen is length of snmpTrapVarVal value.

 

Trap Varbinds for Scalar Objects

 

It is the notification objects that are defined in the notification. For each notification object defined in the notification-type construct, the trap function contains the following code to get the trap varbind and add it to the trap vector.

    AddVarBind(trapVect,

    trap object Oid,

    trap object Oid Length ,

    trap object type,

    trap object value,

    size of trap object value,

    FALSE);

For example, the trap variable agentlocation defined in AGENT-SAMPLE-MIB for SNMPv2 notification has the following code:

Trap Varbinds for Tables

 

For table column objects, the trap function invokes the following method before adding the Varbind to the trap vector. This is done for each object defined in the notification-type construct.

where, Get<table name>Instance() is used to retrieve the first entry of a table (by default) and the OID of the given table column with the instance value.

 

If a table has more than one row , the user can decide about the row (table column instance) value in the run time. This is done by specifying the row of the table to be sent out in the trap inside this function. Refer to the section, Sending traps based on Instance of a Table.

 

Parameters

 

1. AddVarbind()

 

AddVarBind() adds the varbinds of the instance to the trap vector.

For example, the trap variable adiskname defined in AGENT-SAMPLE-MIB for SNMPv2 notification has the following code:

3. ExtraVarBinds

 

The trap function is generated with input parameters extraVarBinds and informFlag.

    void SendV2TrapOfscalarNotifications(vector

    *extraVarBinds, U_CHAR informFlag)

It enables the user to add more varbinds to the trap vector other than the notification objects defined in the trap of the MIB. It is optional. The user can send NULL as value for this parameter.

    if (extraVarBinds != NULL)

    {

    for (i =0; i<extravarbinds>size; i++)

    {

    nodePtr = (node

    *)ElementAt(extraVarBinds,i);

    AddElement(trapVect, nodePtr);

    }

    }

4. Inform Flag

 

In SNMPv2, the agent sends unconfirmed trap (NOTIFICATION) and confirmed trap (INFORM) to manager. If the user wants confirmation (response) for the traps sent make informFlag as TRUE or else make it as FALSE.

    if (informFlag == TRUE)

    trapPdu->command = SNMP_MSG_INFORM;

    else

    trapPdu->command =SNMP_MSG_TRAP2;

5. SNMP version

 

The function void SendV2TrapOf< Trap Name > generates code for the trap version based on the v1v2ManagerVersion, specified in the v1v2TrapForwardingTable.

 

In v3 Notifications

 

The prototype of the function is,

    void SendV2TrapOfscalarNotifications(vector

    *extraVarBinds, U_CHAR informFlag)

The code generated for SNMPv3 is same as that for SNMPv2. The only modification you have to make is in SNMP version.

 

SNMP version

 

The function void SendV2TrapOf< Trap Name > generates code for the trap version based on the v3ManagerVersion, specified in the v3TrapForwardingTable.

 

The agent will take care of the remaining process, such as DoFilteringForSnmpTraps, IsAccessAllowed(), USM user information, etc. Note that the manager entry in the manager list contains extra information in addition to the SNMP v1 and v2c information.

 

Sending Traps Based on the Instance of a Table

 

Identifying the Instance of a Table

 

A trap can be defined for a scalar/table column object defined in the MIB. But when a trap is sent for a table column object, how will the Agent identify which row data should be sent in the Trap. The MIB standards do not specify which instance of a columnar object to return. The DESCRIPTION clause must be used for this purpose wherein you can describe which instance of a columnar object to return in the event report.

 

When the WebNMS C agent generates a trap/notification, by default it uses the data in the first row to be sent along with the trap, though the data belong to second row or third row. But, it is possible to indicate to the trap function which instance of the variable should be included in the trap.

 

Identifying a particular row in a table to collect trap variable data is purely implementation dependent. For example, you may want to retrieve Table A's data from second or third row along with the trap.

 

In Standalone SNMP Agent, the trap function SendV2TrapOf(vector *extraVarBinds) calls the following method which by default takes the first row from the table as instance.

    Get<tablename>Instance(&trap objectOid, & trap object

    OidLength, table name_ trap object name, &table name EntryPtr);

To take the first element from the table, the ElementAt(vectorName, 0) function call is used in this method. Here, instead of 0 you can give any valid row number. There are different ways of identifying the row of a table column whose data are to be sent with the trap function :

Example on Identifying the Instance

 

Let us take the AGENT-SAMPLE-MIB as an example. A notification is sent out when a set request is made for the trap object aaplicationUserName of the aaplicationUserTable. The notification is sent with the instance for which the set request is made.

 

In this example, the following modification is made to the ./stubs/agent-sample-mib/src/ aaplicationusertablehdlr.c file to specify the row index in the trap function :

This method is to be called in AaplicationUserTableProcessWriteReq() before calling SendV2TrapOfscalarNotification() for aaplicationUserName as shown below:

    gv_index =

    GetRowIndexByEntry(&gv_aaplicationUserTableVector,aaplicationUserTableEntryPtr);

    /* Send V2 trap , if TRUE means it is INFORM */

    if (*status != VALIDATE)

    {

    SendV2TrapOftableNotifications(tableNotificationsVect,

    FALSE);

    trapFlag = TRUE;

    }

The GetRowIndexByEntry() method will return the row index value and it will be stored in the global variable gv_index. This variable will be used in GetaaplicationUserTableInstance() method as shown below while calling SendV2TrapOfscalarNotification().

    nodePtr = ElementAt(&gv_aaplicationUserTableVector,

    gv_index);

Now if you do a set for 1st row, then trap will contain 1st row's attribute. If you do a set for 2nd row, then 2nd rows attributes will be present and so on. To use this file,

Now if you do a set (aplicationuserName) for 1st row then trap will contain 1st row's attribute (if it is a trap for the 2nd row, then 2nd row attributes will be present and so on).

 

Example on Passing an Extra Argument into the Generated Trap Method

 

For any table in the MIB which is associated with a trap, a Get<TableName>Instance() function is generated. When you send a trap say XXX, in the SendV2TrapOfXXX() function, the GetlrcsSystemTableInstance() is called to get the systemNumber. By default it always gets the first row in the LrcsSystemTable. If you want to change GetlrcsSystemTableInstance() function to return a different row than the default then you can do it in two ways of which one is explained in the above example.  

 

The same functionality can be achieved by passing an extra argument for the function SendV2TrapOfXXX(), such that the instance can be known while calling that method to send out the traps. You also need to modify the method SendV2TrapOfXXX() according to your needs while sending the trap. In the prototype of the function SendV2TrapOfXXX() and extra argument should be added before compiling the code.

 

Converting the Version of Traps

 

By default, traps will be sent based on the ManagerVersion specified in the v1v2TrapForwardingTable or v3TrapForwardingTable. To convert the version of the trap, the ManagerVersion has to be changed in the TrapForwardingTable.

 

Knowing the Details of the Trap Generated (Reliable Traps)

 

There are times where the generated Traps could have been missed or lost during communication. In a situation like this, the Manager might not be aware as to how many traps were generated by the Agent and the details of those Traps. To overcome the uncertainty involved in receiving traps, the option of sending Reliable Traps is provided.

 

Implementing Reliable Traps

 

This feature can be implemented by defining the following MACRO in the config.h file present in <WebNMS/C-Agent>/projects/<Project-Name>/agent/source/system/include

    # define NOTIFICATION_REL_TRAP

This MACRO also gets defined when the UI option is enabled.

 

By default, the Maximum number of Traps that can be stored by the Agent is 10, so the last 10 traps are stored here.

 

Accessing the Trap Details

 

To know the information of Traps generated, two tables, namely : notificationLogTable and notificationVarbindTable are included under the notificationLogModule of AGENT-SNMP-CONFIG-MIB file. These tables help the Manager in finding out the details of the Traps by just sending a query to the Agent. Try acquiring the Trap details by loading the MIB in MIB Browser and querying.

 

The notificationLogTable stores information of the Traps sent from the Agent This table contains the following information :

The notification VarbindTable stores information of the varbind values present in the Trap PDU. This table contains the following information.

Information of the trap get stored in the text files, notificatioLogTable.txt and notificationVarbindTable.txt. The details of the trap are read from these text files. These text files do not reflect any changes if they are modified dynamically.

 

Sending Periodic Traps

 

The Manager-Agent communication existence is possible only when the device in which the Agent is present or any external application for which the Agent is created is running. In any case where the managed device is not running or is down and is not able to provide the details to the Agent, then the Agent will not be able to respond to the requests from the Manager and so it sends a trap to the Manager stating the application is down.

 

These traps are generated in the name of LinkUp and LinkDown traps. They can also be sent periodically. LinkDown Traps are sent when the Managed device is down and LinkUp on the other hand is sent when the Agent is up. Hereby the Manager will not forward the requests to the Agent until the System is up. Thus to intimate the Manager on the status of the Managed Device and the Agent, a facility for "Sending Periodic Traps" is provided.

 

Implementation Details

 

The method CreateAndSendStandardTrap() defined in

<WebNMS/C-Agent>/projects/<Project-Name>/agent/source/protocols/snmp/src/snmpmain.c can be used to implement the LinkUp and LinkDown traps. The prototype of this method is given below:

    CHAR CreateAndSendStandardTrap(LONG trapType, LONG trapVersion)

This method can be called in the DoOtherWorks() method in WebNMS/C-Agent>/projects/<Project-Name>/agent/stubs/submain.c file. In this method, user can write his own code to check if the managed device is up or down.

 

If the managed device is Down, a LinkDown trap can be sent by passing the trap type as Linkdown in CreateAndSendStandardTrap(). If the managed device is Up, a LinkUp trap can be sent, by passing the trap type as LinkUp in CreateAndSendStandardTrap().

 

Implementing Informs

 

SNMP Notifications can be sent as Traps or Inform requests. Traps are unreliable because the Manager does not send any acknowledgment on receiving the Trap. So, the Agent cannot determine whether the Trap was received by the Manager or not. However, an SNMP Manager that receives an Inform request acknowledges the message with an SNMP response PDU. If the Manager does not receive an inform request, it does not send a response. If the Agent does not receive a response at all, the inform request can be sent again.

 

Generating SNMPv2c Inform

 

No change is required in the generated code of the notification function, if you want to send the SNMPv2 trap as a INFORM. Pass TRUE as a second argument in the SendV2TrapOf<trap> (extraVarBinds, TRUE) method. The Agent will take care of the remaining things, such as timeOut, retransmission, etc. Each Manager entry will have values for both timeOut and retransmission variables.

 

After INFORM is transmitted, the Agent waits for the response message from the corresponding Manager. After receiving the response it calls the following function from the file <WebNMS>/C-Agent/projects/<Project Name>/agent/stubs/inform.c.

This function displays all the information of the received response message. If you want to take some action on receiving response from the Manager, then you can edit this function.

 

Receiving SNMPv2c Inform

 

The Agent can also receive a SNMPv2c INFORM request from the Manager. For this no extra configuration is required. After receiving the INFORM, the Agent calls the following function from the file <WebNMS>/C-Agent/projects/<Project Name>/agent/stubs/inform.c.

Before calling the above method, the Agent calls the authentication module to authenticate the received INFORM request. The DisplayInformInfo() function displays all the information of the received INFORM message. If you want to take some action on receiving INFORM request from the Manager, then edit this function.

 

Testing Informs

 

To test the feature,

Generating SNMPv3 Inform

 

The Generated code for SNMPv3 agent is almost same of SNMPv2c Agent. Changes required to send SNMPv3 Inform are as follows.

 

If Text File Storage for API option has been selected in Agent Compiler and v3managertable.txt file (available under projects/<project-name>/agent/conf/snmp directory), then the default entry of snmp version has to be changed to SNMP_VERSION_3 from SNMP_VERSION_2c. After changing the entry in v3managertable.txt file will look like the one given below

    Host Type

    Host

    		 Port Version Community Use Name SecModel SecLevel Context Name TimeOut Retries Row Status

    1

    127.0.0.1

    8003

    SNMP_VERSION_3

    public

    noAuthUser

    USM

    NOAUTH

    noAuth

    5

    0

    ACTIVE

If Text File Stroage for API option is not chosen, then you have to specify the value of snmp version to SNMP_VERSION_3 in CreateManagerEntry() function used in submain.c available under projects/<project-name>/agent/stubs directory.   

 

In SendV2TrapOf<trap>(), the value of second argument will be FALSE by default. This will ensure that the SNMPv3 traps are sent. As we need to send Informs here, change the second argument as TRUE from FALSE. Finally, the function will look like SendV2TrapOf<trap>(extraVarBinds, TRUE).
The Agent will take care of the remaining things, such as timeOut, retransmission, etc. Each Manager entry will have values for both timeOut and retransmission variables.

 

After INFORM is transmitted, the Agent waits for the response message from the corresponding Manager. After receiving the response it calls the following function from the file <WebNMS>/C-Agent/projects/<Project Name>/agent/stubs/inform.c.

This function displays all the information of the received response message. If you want to take some action on receiving response from the Manager, then you can edit this function.

 

Receiving SNMPv3 Inform

 

The Agent can also receive a SNMPv3 INFORM request/response from the Manager. For this no extra configuration is required. After receiving the INFORM, the Agent calls the following function from the file <WebNMS>/C-Agent/projects/<Project Name>/agent/stubs/inform.c.

Before calling the above method, the Agent calls the authentication module to authenticate the received INFORM request. The DisplayInformInfo() function displays all the information of the received INFORM message. If you want to take some action on receiving INFORM request from the Manager, then edit this function.

 

Testing SNMPv3 Informs

 

SNMPv3 Informs can be tested either using MIB Browser or using the SNMP UDP command line applications.
Following are steps to test the SNMPv3 Informs using the Command line applications

 

Running the Example

 

To know more about Traps, please go through the example available in <WebNMS/C-Agent>/examples/snmp/traps directory. The examples are available for both v1 traps and v2 traps.

 

The README file available in the trapv1 folder explains how the v1trap is generated from the agent to manager and how extra varbinds is added to the previous varbinds.

 

The README file available in the trapv2 folder explains how the v2trap is generated from the agent to manager and how extra varbinds is added to the previous varbinds.


Copyright © 2009, ZOHO Corp. All Rights Reserved.