| Module | Name | Version | License | Source | Languages | Platforms | Type | Author | Description |
|---|---|---|---|---|---|---|---|---|---|
| SNMP | SNMP client | 0.8 | GPL2 | daq_SNMP.so | en,uk,ru,de | x86,x86_64,ARM | DAQ | Roman Savochenko Maxim Lysenko (2009) — the page translation |
Provides an implementation of the client of SNMP-service. |
Contents
SNMP protocol was designed to verify the operation of network routers and bridges in 1988. Subsequently, the scope of the protocol coverage and other network devices such as hubs, gateways, terminal servers, and even devices that are remotely related to the network: printer, uninterpretable power supplies, PLC, etc. In addition, the protocol allows the possibility of changes in the functioning of these devices. At this time, SNMP protocol is standardized as RFC-1157, -1215, -1187, -1089.
This module provides the ability to gather information and set modification for various devices on the SNMP protocol by the library NetSNMP. Also, the module implements the functions of the horizontal reservation, that is working in conjunction with the remote station of the same level.
1 SNMP
The main interacting "individuals" of the protocols are the agents and management systems. If we consider these two concepts in the language of "client — server", then the server role is played by agents, that is the same devices for the survey of the state of which the protocol has been developed. Accordingly, the role of the clients is played by the management systems — network applications which are necessary to gather the information about the functioning of agents. In addition to these two entities in the model of the protocol it can be identified as two more: control information and the protocol for data exchange.
All information about the objects of system-agent is contained in the so-called MIB (management information base) — the base of control information, in other words, MIB is the totality of objects (MIB-variables) accessible to the reading-writing operations.
For this time there are four typical MIBs:
- 1. Internet MIB — base of objects for providing the diagnosis of errors and configurations. It includes 171 objects (including objects of MIB I).
- 2. LAN manager MIB — base of 90 objects - passwords, sessions, users, shared resources.
- 3. WINS MIB — base of objects required for the operation of a WINS server.
- 4. DHCP MIB – base of objects required for the operation of the DHCP server that serves for dynamic allocation of IP addresses on the network.
In addition to the above types of databases MIB can be additionally loaded by modules in a way related to the library NetSNMP.
1.1 MIB
All names of MIB have a hierarchical structure. There are ten root aliases:
- 1. System — the group of MIB II contains the seven objects, each of which serves to store information about the system (OS version, time, etc.).
- 2. Interfaces — contains 23 objects necessary for the conduct of network interfaces of agents (the number of interfaces, the size of MTU, the rate of transmission, physical addresses, etc.).
- 3. AT (3 objects) — are responsible for the broadcast address. No longer used. Was included in the MIB I. In SNMP v2 this information was transferred to the MIB for the relevant protocols.
- 4. IP (42 objects) — data on the passing IP packets (number of requests, responses, offcast packages).
- 5. ICMP (26 objects) — information about control messages (input/output messages, errors, etc.).
- 6. TCP (19) — all that relates to the same-name transport protocol (algorithms, constants, connections, open ports, etc.).
- 7. UDP (6) — the same one for UDP protocol (input/output datagram, ports, errors).
- 8. EGP (20) — data about the traffic Exterior Gateway Protocol (used by routers, object stores information about the received/sent/dropped frames).
- 9. Transmission — is reserved for specific MIB.
- 10. SNMP (29) — statistics on SNMP: input/output packets, limiting package size, errors, data on the process request, and much more.
1.2 Addressing
Each of the root alias appears in the form of a tree growing down. For example, to the address of the administrator you can contact by the means of the way: "system.sysContact.0", to the time of the system: "system.sysUpTime.0", to the description of the system (version, kernel and other information about the OS): "system.sysDescr.0". On the other hand, the same data can be specified in the point notation. So, "system.sysUpTime.0" value corresponds to "1.3.0", because "system" has an index "1" in groups of MIB II, and "sysUpTime" — "3" in the hierarchy of the group "system". Zero at the end of the path indicates the scalar type of data storage. During the work the symbolic names of the objects are not used, that is, if the manager asks the agent the contents of the parameter "system.sysDescr.0", then in the query string the link to the object will be converted to "1.1.0", and will not be handed over "as is".
In general, there are several ways to write the addresses of MIB-variable:
- 1. ".1.3.6.1.2.1.1" — direct code addressing for the object "System" (the root alias System). For the addressing method each MIB variable encoded by an identifier and the address in whole writing in view of a sequence of the identifiers separated by dots left to right. Such record of addresses is a common one and all other methods transfer to it.
- 2. ".iso.org.dod.internet.mgmt.mib-2.system" — full symbolic addressing to direct one for the object "System".
- 3. "system.sysDescr.0" — simple, not full path, addressing from a root alias (the object "System").
- 4. "SNMPv2-MIB::sysDescr.0" — addressing from the MIB base by the module name for "system.sysDescr.0".
1.3 Interaction
The SNMP client interacts with a server on the request-response principle. On its own, the agent is able to initiate only one action, called a trap interrupt. Besides, all the actions of agents are to respond to requests sent by managers.
There are three main versions of the protocol SNMP (v1 & v2 & v3), which are not compatible. SNMP v3 supports encryption of traffic, which, depending from implementation, uses the algorithms DES, MD5. This leads to the fact that while transfer the most critical and important data is unavailable for listening. As a transport protocol the UDP protocol is usually used in the SNMP. Although, in fact, SNMP supports a variety of other lower-level transport protocols.
1.4 Authorization
One of the key concepts of SNMP is the group. Procedure of the authorization of the manager is a simple test for membership of a particular group from the list, which belongs to the agent. If the agent does not find the group of the manager in its list, their further interaction is impossible. By default, the groups are used: public (for read) and private (for write). The protocol SNMP v3 for authentication uses an user with password of the authentication and privacy depended on the level of security.
2 Module
This module supports all versions of the protocol SNMP (1, 2 and 3) in the read-write modes of MIB-parameters due the library NetSNMP using.
2.1 Controller object
For addition of SNMP data sources the controller objects create and configure in OpenSCADA. Example of the configuration tab of a controller is shown in Figure 1.
From this tab you can set:
- State of the controller object, as follows: status, "Enabled", "Running" and the storage name containing the configuration.
- Identifier, name and description of the controller.
- The state "Enabled" and "Running", in which the controller object must be translated at start up.
- Policy of scheduling and priority of the data acquisition task.
- Remote host address of the agent.
- Number of retries of the requests.
- Responds timeout, in seconds.
- Used SNMP version.
- Community or user for connections establishing.
- Limit of the attributes number per one parameter object.
- Security level for v3 (No auth/No privacy; Auth/No privacy; Auth/Privacy).
- Encryption method (MD5, SHA) and user's password of the authentication for v3.
- Encryption method (DES, AES) and privacy of the authentication for v3.
2.2 Parameter of a controller object
Module SNMP provides only one type of parameters — "Standard". An additional configuration field of parameters of the module(Fig. 2) is a list of MIB-parameters, the branches or separated items (scalars) of which are to be read.
In accordance with a specified list of MIB-parameters is carried out a survey of their branches (or scalars) and creation of attributes of parameters. Further, updating of values of parameters is carried out. Attributes are named in accordance with the code addressing of MIB-parameters, as the ID, and the addressing from the base of MIB objects in the name of the attribute(Figure 3).
