Trabajo Fin de Grado -...

Equation Chapter 1 Section 1

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de

Telecomunicación

Desarrollo de sensor de temperatura gestionable

Autor: Daniel Rodríguez León

Tutor: Antonio Estapa Alonso

Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

iii

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de Telecomunicación

Desarrollo de sensor de temperatura gestionable

Autor:

Daniel Rodríguez León

Tutor:

Antonio Estepa Alonso

Profesor titular

Departamento de Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

v

Trabajo Fin de Grado: Desarrollo de sensor de temperatura gestionable

Autor: Daniel Rodríguez León

Tutor: Antonio Estepa Alonso

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

El Secretario del Tribunal

vii

A mi familia

A mis maestros

A mis compañeros

ix

Agradecimientos

A mi familia y amigos, sin su esfuerzo y apoyo no me habría sido posible llegar hasta aquí.

Daniel Rodríguez León

Sevilla, 2017

Resumen

En el mercado existen hoy numerosas soluciones comerciales para diferentes usos en nuestras casas, desde

dispositivos de vigilancia o domótica para la regulación de la temperatura, luz interior y calefacción, hasta

dispositivos que te permiten estar en contacto con tu mascota desde cualquier lugar. Además, existen numerosas

aplicaciones open source para el uso y disfrute de funcionalidades como las descritas anteriormente.

El objetivo de este Trabajo de Fin de Grado es implementar un agente SNMP para Raspberry Pi para la

monitorización de un conjunto de elementos que recogen el estado en tiempo real de un terrario casero. Esto es,

una serie de sensores (humedad, temperatura, luz) y actuadores (bombillas) que son monitorizados por un agente

SNMP funcionando en una Raspberry Pi conectada al router casero que permite hacer consultas mediante el uso

del protocolo SNMP. Se mostrará el camino seguido para el desarrollo de unos scripts de lectura de sensores, la

creación de un módulo Mib y el desarrollo de un agente SNMP.

Abstract

Nowadays, there are lots of commercial products with a variety of uses at our homes, from surveillance devices

or domotics devices to regulate temperature, indoor light or heat; to devices that allow you to keep in contact

with your pet from anywhere. Furthermore, there is also a great number of open source applications that provide

those previous functionalities.

The aim of this thesis is to implement a SNMP agent for Raspberry Pi, in order to monitor a set of elements that

describe the state of a homemade terrarium in real time. More specifically, a set of sensors (temperature, light

and humidity) and an actuator (light bulb) which are managed by a SNMP agent running in a Raspberry Pi

connected to a home router, allowing the user to send requests using the SNMP protocol.

The development process will be shown within this document, such as how to use scripts with the sensors, how

to create a MIB module and how to implement a SNMP agent.

xiii

Índice

Agradecimientos ........................................................................................................................................... ix

Resumen ........................................................................................................................................................ x

Abstract ....................................................................................................................................................... xii

Índice .......................................................................................................................................................... xiii

Índice de Tablas ........................................................................................................................................... xv

Índice de Figuras ......................................................................................................................................... xvi

Notación .................................................................................................................................................... xvii

1 Introducción .......................................................................................................................................... 1 1.1. Antecedentes ............................................................................................................................................... 1 1.2. Objetivos ....................................................................................................................................................... 1 1.3. Metodología ................................................................................................................................................. 2 1.4. Estructura de la Memoría ........................................................................................................................... 2 1.5. Diagrama de Gantt ...................................................................................................................................... 3

2 Puesta en marcha del sistema de control .............................................................................................. 5 2.1. Conexión de sensores a Raspberry Pi ......................................................................................................... 6 2.2. Conexión de actuadores a Raspberry Pi ..................................................................................................... 7 2.3. Manejo de sensores mediante script .......................................................................................................... 9

2.3.1 Script de sensor luz .............................................................................................................................. 9 2.3.2 Script de sensor temperatura y humedad ....................................................................................... 10

3 Diseño de sistema de gestión .............................................................................................................. 13 3.1. Escenario de sistema de gestión ............................................................................................................... 13 3.2. Objetos de gestión ..................................................................................................................................... 14 3.3. Diseño de módulo TERRARIO-MIB ............................................................................................................ 16

3.3.1 Árbol de objetos del modulo ............................................................................................................ 17 3.3.2 Comprobación validez MIB – librería libsmi .................................................................................... 22

4 Desarrollo del Agente SNMP................................................................................................................ 26 4.1. Librerías necesarias para el agente .......................................................................................................... 26

4.1.1 PySNMP .............................................................................................................................................. 26 4.1.2 Net-SNMP ........................................................................................................................................... 27

4.2. Diseño e implementación del agente ....................................................................................................... 28 4.2.1 Librerías importadas .......................................................................................................................... 28 4.2.2 Clase Mib ............................................................................................................................................ 29 4.2.3 Clase SNMPAgent .............................................................................................................................. 29 4.2.4 Clase Worker ...................................................................................................................................... 29 4.2.5 Clase VigilanteTraps ........................................................................................................................... 29

4.3. Funciones para los OIDs ............................................................................................................................ 30 4.3.1 Compilación del modulo TERRARIO-MIB ......................................................................................... 30 4.3.2 Funciones asociadas a los OIDs ........................................................................................................ 32 4.3.3 Funciones auxiliares .......................................................................................................................... 33

4.4. Ejecución del agente .................................................................................................................................. 34

5 Gestor SNMP ....................................................................................................................................... 37

6 Pruebas y validación ............................................................................................................................ 39 6.1. Informe de pruebas realizadas ................................................................................................................. 39

6.1.1 Ejecución snmpwalk, P01B ............................................................................................................... 40 6.1.2 snmpget con nombre de OID, P02B................................................................................................. 40 6.1.3 snmpget con identificadores numéricos, P03B............................................................................... 40 6.1.4 snmpset con nombres de OID y comunidad public, P04B ............................................................. 41 6.1.5 snmpset con nombres de OID y comunidad private, P05B ........................................................... 41 6.1.6 snmpset con nombres de OID de nivel read-only, P06B ................................................................ 41 6.1.7 snmpget con OID no accesibles, P07B ............................................................................................. 41 6.1.8 snmpget a los elementos de tipo notificación, P08B ..................................................................... 42 6.1.9 Reiniciar el agente, P09B .................................................................................................................. 42 6.1.10 Recepción de traps en Equipo B, P10B ............................................................................................ 42 6.1.11 Recepción de traps en Equipo B y puerto diferente, P11B ............................................................ 42 6.1.12 Recepción de traps en Equipo B y paro del envío, P12B ................................................................ 43 6.1.13 Paro de funcionamiento de sensor luz, P13B.................................................................................. 43 6.1.14 Paro de funcionamiento de sensor luz y puesta en funcionamiento P14B .................................. 43 6.1.15 Paro de funcionamiento de sensor temperatura y humedad, P15B............................................. 43 6.1.16 Paro de funcionamiento de sensor temperatura y humedad y puesta en funcionamiento, P16B 44 6.1.17 Cambiar el valor máximo de temperatura aceptable a uno no válido, P17B ............................... 44 6.1.18 Cambiar el valor mínimo de temperatura aceptable a uno no válido, P18B ................................ 44 6.1.19 Cambiar el valor máximo de humedad aceptable a uno no válido, P19B .................................... 44 6.1.20 Cambiar el valor mínimo de humedad aceptable a uno no válido, P20B ..................................... 45 6.1.21 Cambio de estado de la bombilla, apagado y encendido, P21B .................................................... 45 6.1.22 Apagado de bombilla y poner temporizador a 3 minutos, P22B ................................................... 45 6.1.23 Poner un segundo temporizador para la bombilla, P23B .............................................................. 46

6.2. Informe de resultados ............................................................................................................................... 46

7 Conclusiones y desarrollos futuros....................................................................................................... 48 7.1. Conclusiones del proyecto......................................................................................................................... 48 7.2. Desarrollos futuros .................................................................................................................................... 48

Referencias.................................................................................................................................................. 50

Anexos ........................................................................................................................................................ 11 Anexo A: Módulo TERRARIO-MIB ................................................................................................................ 11 Anexo B: Plan de Pruebas ............................................................................................................................. 20

xv

ÍNDICE DE TABLAS

Tabla 1-1. Actividades del proyecto con fechas de inicio y fin. 3

Tabla 1-2. Diagrama de Gantt del proyecto. 3

Tabla 6-3. Resultados de las pruebas. 47

Tabla 6-4. Resumen de resultados. 47

ÍNDICE DE FIGURAS

Figura 2-1. Sensores AM2302 y TSL2561, respectivamente. 5

Figura 2-2. Distribución pines Raspberry Pi 1. 6

Figura 2-3. Circuito de conexión de sensores a Raspberry Pi. 7

Figura 2-4. Conexión de actuador a Raspberry Pi. 8

Figura 2-5. Diagrama de flujo de sensores. 9

Figura 3-1. Escenario de sistema de gestión. 14

Figura 3-2. Esquema de objetos de gestión del elemento agente. 14

Figura 3-3. Esquema de objetos de gestión del elemento sensor temperatura y humedad. 15

Figura 3-4. Esquema de objetos de gestión del elemento bombilla. 15

Figura 3-5. Esquema de objetos de gestión del elemento sensor luz. 16

Figura 3-6. Árbol de OIDs de TERRARIO-MIB. 18

Figura 3-7. Árbol OID TERRARIO-MIB, rama generalConfig. 19

Figura 3-4. Árbol OID TERRARIO-MIB, rama sensorLuzConfig. 20

Figura 3-9. Árbol OID TERRARIO-MIB, rama sensorTemperaturaHumedadConfig. 21

Figura 3-10. Árbol OID TERRARIO-MIB, rama bombillaLuzConfig. 22

Figura 3-11. Texto añadido a TERRARIO-MIB. 24

Figura 4-1. Estructuras internas de SNMPv3 (izquierda) y PySNMP (derecha). 26

Figura 4-2. Conexión entre el módulo TERRARIO-MIB y el programa agente. 31

Figura 4-3. Relación entre los objetos gestionables de TERRARIO-MIB 33

Figura 6-1. Escenario de pruebas. 39

xvii

Notación

Código Texto de código de un fichero

Inglés Palabra en inglés

Comando Comando de la terminal

Fichero Nombre de fichero

iso.org.dod.internet OID – Identificador de Objeto

1

1 INTRODUCCIÓN

esde la década de los 90, cuando surgió el primer RFC para la primera versión del protocolo SNMP, el

uso de dicho protocolo se ha extendido a prácticamente cualquier lugar en el que se necesite gestionar

de manera sencilla y flexible los elementos interconectados en la red sin importar el fabricante.

En 2012, la Fundación Raspberry Pi lanzaba al mercado un computador de placa reducida de bajo coste con el

objetivo de contribuir a la enseñanza de ciencias de la computación en el ámbito académico. Éste consistía

básicamente en un ordenador de tamaño pequeño sin periféricos, con una serie de puertos y pines para conectar

elementos externos y corriendo sistemas operativos como Debian o Ubuntu optimizados para el dispositivo.

Aunque las especificaciones de aquel primer modelo eran bastante humildes, los modelos actuales cuentan con

salida HDMI, 1GB RAM, Bluetooth 4.1 e incluso con procesadores 1.2GHz 64-bit quad-core ARMv8. Su uso

se ha generalizado hoy en día y no sólo en la enseñanza, sino que cuenta con una gran comunidad de

desarrolladores que crean aplicaciones útiles para otros usuarios [1].

Por ello, aprovechando el potencial de un dispositivo como Raspberry Pi y la flexibilidad del protocolo SNMP,

se pretende realizar una serie de programas que permitan la supervisión de un terrario casero. Para ello, se

utilizará el lenguaje de programación Python.

1.1. Antecedentes

El actual TFG es una continuación del trabajo de curso de la asignatura Gestión de Redes de Telecomunicación.

Esta asignatura es del tercer curso del Grado en Ingeniería de las Tecnologías de Telecomunicación.

1.2. Objetivos

El objetivo de este TFG es la implementación de un sistema de gestión totalmente funcional en un dispositivo

Raspberry Pi para el escenario de un terrario casero. Para ello, se desarrollará un agente SNMP por lo que se

profundizará en la implementación del protocolo SNMP. Como consecuencia del desarrollo de un agente, será

necesario crear un módulo MIB complejo con ramas específicas para cada sensor y notificaciones trap. Además,

se incluye en una parte del proyecto, el desarrollo de scripts que se encarguen del manejo de sensores.

A diferencia de otros proyectos ya existentes sobre el tema de monitorización casera de temperatura, humedad

y/o luz que utilizan Arduino en vez de Raspberry Pi como GardenBot [2] o que utilizan Raspberry Pi, pero se

D

Nuestra recompensa se encuentra en el esfuerzo y no en

el resultado. Un esfuerzo total es una victoria completa.

- Mohandas Karamchand Gandhi -

Introducción

2

centran en la realización de programas para ser gestionados mediante servidores web; este proyecto utiliza para

ese mismo fin el protocolo SNMP como elemento estructurador. Además, un objetivo fijado para el futuro del

proyecto es la adaptación del manejo de sensores a cualesquiera que se encuentren conectados, de manera que

puedan ser usados sin importar su fabricante.

1.3. Metodología

Para el desarrollo del sistema de gestión de red será necesario el diseño de un módulo MIB, la obtención de

sensores adecuados, y su manejo; y la implementación de un agente SNMP en el entorno de desarrollo.

Para el desarrollo del software se utilizará Python como ya se ha comentado anteriormente. Las razones son que

es un lenguaje sencillo de aprender, bastante libre en cuanto a la manera de estructurar el código, multiplataforma

(Linux - Windows - Mac), potente y con una gran documentación y librerías existentes para su uso tanto con

sensores como para la implementación de SNMP.

Además, se estructurará el proyecto de forma distribuida y el programa principal del agente de manera multihilo.

De forma distribuida por constar de no un único programa sino varios programas que colaboran para tomar los

datos (scripts de lectura de sensores) y atender las peticiones SNMP (programa agente). De esta manera se

simplifica el funcionamiento del proyecto, se puede depurar una parte del proyecto mientras las otras siguen

totalmente operativas e incluso permite la extensibilidad de cada parte hacia nuevos objetivos y funcionalidades.

Para el proyecto se ha utilizado el entorno de desarrollo detallado a continuación:

Raspberry Pi 1 model B.

Sistema Operativo: Raspbian 8 (jessie).

Kernel: 4.1.7+.

Entorno de ejecución: Terminal Unix de comandos Bash.

Editor de texto: Vim, configuración estándar.

Intérprete: Python 3.4.2.

Protocolo de gestión: SNMP versión 2c.

1.4. Estructura de la Memoría

Esta memoria se divide en 7 bloques que detallan la motivación del proyecto, las fases de diseño del conjunto

del proyecto, la implementación del mismo, pruebas realizadas y conclusiones finales.

En la Sección 1, Introducción, se da información sobre el ánimo del TFG como el origen de la idea del proyecto,

el entorno de trabajo y la estructura de la memoria.

En la Sección 2, Puesta en marcha del sistema de control, se incluyen los scripts realizados específicamente para

los sensores usados para captar la humedad, la temperatura y diferentes valores de luz.

En la Sección 3, Diseño de sistema de gestión, se habla del estándar que define las reglas de los RFCs para

escribir un modulo MIB válido y se detalla el módulo específicamente creado para este proyecto.

En la Sección 4, Desarrollo del Agente SNMP, se listan las librerías necesarias usadas para el desarrollo de un

agente SNMP en Python, se describe el esqueleto del agente SNMP en Python, se describen las funciones

específicas para cada OID y se describe cómo poner a funcionar el agente SNMP.

En la Sección 5, Gestor SNMP, se describe un gestor que recibe los traps generados por el agente para cerciorarse

de la entrega de los avisos en las situaciones de alarma descritos por la MIB.

En la Sección 6, Pruebas y validación, Se describen las pruebas realizadas para certificar el buen funcionamiento

del agente SNMP. Asímismo, se listan los casos límites a los que se ha sometido el agente y sus limitaciones de

uso.

3

3 Desarrollo de sensor de temperatura gestionable

Por último, en la Sección 7, Conclusiones y desarrollos futuros, se describen las conclusiones como resultado

del proyecto y se describen las actuales vías de mejora del conjunto.

1.5. Diagrama de Gantt

Para la planificación del proyecto se ha procedido a la realización de un Diagrama de Gantt con las principales

actividades previstas. Estas actividades se describen a continuación:

Actividades Inicio Duración Fin

A. Búsqueda sensores y librerías compatibles. 21/09/2016 19 días 10/10/2016

B. Desarrollo de scripts para sensores. 11/10/2016 10 días 21/10/2016

C. Creación de módulo TERRARIO-MIB. 22/10/2016 6 días 28/10/2016

D. Creación de programa del agente SNMP. 29/10/2016 32 días 30/11/2016

E. Fase de pruebas. 01/12/2016 8 días 09/12/2016

F. Corrección de errores e implementación de mejoras. 10/12/2016 33 días 12/01/2017

G. Documentación del proyecto. 13/01/2017 32 días 14/02/2017

Tabla 1-1. Actividades del proyecto con fechas de inicio y fin.

Estas actividades se desarrollan según la línea temporal descrita en el Diagrama de Gantt siguiente:

Tabla 1-2. Diagrama de Gantt del proyecto.

21/09/16 11/10/16 31/10/16 20/11/16 10/12/16 30/12/16 19/01/17 08/02/17 28/02/17

A

B

C

D

E

F

G

5

2 PUESTA EN MARCHA DEL SISTEMA DE

CONTROL

os sensores que se utilizarán finalmente serán el sensor de luz TSL2561 y el sensor de temperatura y

humedad AM2302. Actualmente, estos sensores son ampliamente utilizados y por ello disponen de

bastantes librerías para su uso con varios lenguajes de programación. De inicio, en la página del fabricante

Adafruit [3] están disponibles librerías para su manejo en Arduino mayormente, y un número reducido para

Raspberry Pi, además de foros donde se da soporte a los usuarios. En la Figura 2-1 se puede comprobar el

aspecto de los sensores que se usarán.

Figura 2-1. Sensores AM2302 y TSL2561, respectivamente.

L

If you want to find the secrets of the universe, think

in terms of energy, frequency and vibration.

- Nikola Tesla -

Puesta en marcha del sistema de control

6

2.1. Conexión de sensores a Raspberry Pi

Los sensores se conectan a la Raspberry Pi mediante sus pines, conocidos como GPIO (general purpose

input/output). Éstos, constituyen una interfaz física entre la Raspberry Pi y el mundo exterior. En algunos casos,

estos pines se pueden utilizar como interruptores pues se pueden configurar en modo de salida (OUTPUT) para

que aporten una tensión de 3.3V de salida para, por ejemplo, encender un LED en un circuito externo. En otros

casos, se pueden configurar en modo de entrada (INPUT) para recibir datos del exterior. En mi caso, se utilizarán

algunos pines como entrada para recibir datos de los sensores ya comentados [4].

En la web de Adafruit, al buscar los sensores utilizados en el proyecto, se puede encontrar información detallada

sobre las características de ambos sensores, explicación de cómo conectar los sensores a Arduino y cómo usarlo

en esta plataforma. Debido a que la plataforma usada es Raspberry Pi, se van a describir unos pasos para

conectarlo a Raspberry Pi. Es importante conocer qué usos tienen los pines de la Raspberry Pi 1. Para ello, se

muestra en la Figura 2-2, la distribución de los pines con su uso. La distribución consiste en 13 pares con el

orden incrementándose de izquierda a derecha. Así, la primera fila son el pin de orden 1 (izquierda) y 2 (derecha),

la siguiente fila el 3 y 4, la siguiente el 5 y 6, etc.

Figura 2-2. Distribución pines Raspberry Pi 1.

El sensor TSL2561 dispone de 4 pines que van a ser usados para su conexión:

VCC – a este pin se debe conectar una fuente de alimentación de 3.3V o 5V. En la Raspberry Pi lo

conectaremos al pin número 2 (5V).

GND – este pin se debe conectar al polo negativo de la fuente de alimentación o tierra. En la Raspberry

Pi lo conectaremos al pin número 6 (GND).

SDA – este pin se debe conectar a otro pin I2C SDA Data en la Raspberry Pi. En la Raspberry Pi lo

conectaremos al pin número 3 (SDA).

SCL – este pin se debe conectar a otro pin I2C SCL clock en la Raspberry Pi. En la Raspberry Pi lo

conectaremos al pin número 5 (SCL).

7


El sensor AM2302 dispone de 3 pines que van a ser usados en su conexión (el restante se deja sin conectar:

VCC – este pin se conecta a una fuente de alimentación de 5V. En la Raspberry Pi lo conectaremos al

pin número 1 (3.3V).

DATA – este pin se conecta a un pin GPIO de las Raspberry Pi, el número 7 (el sistema lo reconoce

como GPIO 4). Se necesita, además, conectar una resistencia de valor 10kΩ entre este pin y el pin VCC

de este sensor.

GND – este pin se conecta a tierra al pin número 6 (GND).

Con todo esto, las conexiones quedarían como se describe en la Figura 2-3.

Figura 2-3. Circuito de conexión de sensores a Raspberry Pi.

2.2. Conexión de actuadores a Raspberry Pi

Como se ha comentado, el sistema de gestión hará uso de un actuador que permitirá iluminar el terrario, una

bombilla. Para su uso será necesario la intermediación de un relé, que permite que un circuito actúe de interruptor

de la bombilla conectada a la corriente eléctrica. Para ello, se utilizará cualquier placa de relé del tipo “Relay

SRD-05VDC-SL-C” [5] que tenga a la entrada pines para alimentación a 5V, pin GND y un pin que actúa de

interruptor al proporcionarle una tensión de 3V. Además, en la salida tiene 3 pines: el pin Normalmente Abierto

(N.O.), el pin Normalmente Cerrado (N.C.) y el pin Común. De los dos cables conectados a la corriente eléctrica

de casa, uno de ellos se conectará directamente a un polo del actuador y el otro se conectará al pin Común de la

placa de relé.


8

En función de como se quiera plantear la funcionalidad de la placa de relé, se encuentran dos casos:

Cuando la placa de relé no está funcionando, el actuador conectado se encuentra encendido → para ello

se conecta un cable desde el pin N.C. al otro polo del actuador.

Cuando la placa de relé no está funcionando, el actuador conectado se encuentra apagado → para ello

se conecta un cable desde el pin N.O. al otro polo del actuador.

En el caso de este proyecto, se conectará el actuador a la Raspberry de la siguiente manera en la Figura 2-4,

permaneciendo desactivado el actuador cuando la placa de relé no está activada:

Figura 2-4. Conexión de actuador a Raspberry Pi.

Pin GND placa de relé conectado al pin GND de Raspberry Pi.

Pin 5V placa de relé conectado al pin 5V de Raspberry Pi.

Pin de señal placa de relé conectado al pin GPIO 17 (pin número 11) de Raspberry Pi.

Para uso de este circuito dentro del proyecto, lo único que se necesita es exportar el pin GPIO en el que se

encuentra conectado el pin “Señal” y cambiar su valor entre ‘0’ y ‘1’, implicando la aportación de una tensión

de 3.3V suficiente para la activación del relé.

Para la exportación, se realizan los siguientes comandos:

sudo echo 17 > /sys/class/gpio/export

sudo echo out > /sys/class/gpio/gpio17/direction

Y para encender/apagar la bombilla sólo se necesita ejecutar el siguiente comando:

sudo echo <valor> > /sys/class/gpio/gpio17/value

donde <valor> es ‘1’ para encender y ‘0’ para apagar.

Para “des-exportar” el pin previamente exportado, sólo se necesita ejecutar el siguiente comando:

9


sudo echo 17 > /sys/class/gpio/unexport

2.3. Manejo de sensores mediante script

Ambos scripts utilizados para la lectura de los sensores funcionarán de la siguiente manera:

La información que los scripts lean de los sensores se almacenará en archivos con nombres descriptivos de la

información que contienen en un directorio accesible para el agente SNMP. El modo de funcionamiento de

ambos scripts es continuo, es decir, cuando el script es puesto en marcha se mantendrá en un bucle de lectura de

los sensores y volcado de la información en los archivos, seguido de un tiempo de espera determinado para

volver a leer. Estos diagramas de flujo describen el funcionamiento de los sensores:

While (true)

Lectura de sensor

- temperatura

- humedad

Volcado de

lectura a archivo

Espera de 5

segundos

Inicio

While (true)

Lectura de sensor

- infrarrojo

- luminosidad

- lux

- visible

Volcado de

lectura a archivo

Espera de 5

segundos

Inicio

Figura 2-5. Diagrama de flujo de sensores.

Para la creación de los dos scripts de lectura de sensores se ha creado un directorio identificado con la variable

de entorno $TERRARIO_SNMP_AGENT_DIR en el cual se encontrarán los dos scripts.

2.3.1 Script de sensor luz

El sensor TSL2561 es una excelente herramienta para medir diferentes tipos de luz que habrá en el terrario.

Tiene diodos que pueden captar tanto luz en frecuencias del rango visible para el ojo humano como aquellas en

las frequencias de infrarrojos. Además, tiene la funcionalidad de aportar resultados de medición en Lux, una

unidad de medida del Sistema Internacional de Unidades para la iluminancia o nivel de iluminación. Esta medida

proporciona un valor sobre la cantidad de iluminación que incide por unidad de superficie.

El script que permite leer la información del sensor está escrito para la versión 3 de Python y tiene como nombre

TSL2561.testsensorluz-int.py y se describe a continuación. Se describirá con extractos del fichero de código


10

fuente para no masificar la explicación con código menos importante.

El script, en primer lugar, importa la librería llamada “TSL2561” [6] que no es más que un fichero que contiene

la definición de la clase TSL2561. Esta clase representa al sensor real y contiene atributos y funciones por las

que se puede leer el sensor TSL2561. Para el uso de esta librería, se necesitan otras librerías, las cuales se listan

en la página web del autor. Luego, crea una instancia de la clase TSL2561 de manera que se puedan usar, de

hecho, las funciones definidas para leer el sensor y comprueba si el sensor se encuentra conectado a la Raspberry

Pi. Si está conectado el sensor entonces entra en un bucle while infinito.

#!/usr/bin/env python3

from TSL2561 import *

tsl = TSL2561()

Además, el script del sensor mantiene un fichero de log con las medidas tomadas y la marca temporal. Para ello,

utiliza la clase “logging”. Se configura el log de la siguiente manera:

logging.basicConfig(filename='sensor_luz.log',format='%(asctime)s --

%(levelname)s::%(message)s', datefmt='%d/%m/%Y %I:%M:%S %p',

level=logging.DEBUG)

De esta manera, el fichero sensor_luz.log se creará en el mismo directorio del script con el formato “Timestamp

– nivel de log::mensaje” para las líneas de log.

Ahora procede a determinar si el sensor está conectado al equipo con la función “foundSensor”.

if (tsl.foundSensor()):

while(1):

Dentro del bucle, se lee la información del sensor mediante el uso de la función “getLuminosity” a la cual se le

pasa un argumento que indica qué rango de frecuencias debe captar el sensor para obtener un valor. La función

“calculateLux” permite obtener el valor de lux mediante las medidas de luminosidad de todo el espectro y la de

infrarrojos.

full = tsl.getLuminosity(tsl.FULLSPECTRUM)

visible = tsl.getLuminosity(tsl.VISIBLE)

infrared = tsl.getLuminosity(tsl.INFRARED)

lux = tsl.calculateLux(full, infrared)

Registra las mediciones en el log.

logging.info("LUM "+str(luminosidad)+" | FULL "+str(full)+" |

VISIBLE "+str(visible)+" | IR "+str(infrared)+" | LUX "+str(lux) )

Entonces, se escribirán los datos en cada fichero correspondiente. A continuación, un ejemplo de escritura para

el dato “visible” correspondiente al valor de luz visible. Aclarar que “d” es un variable que contiene el camino

al directorio donde están los ficheros, que es un subdirectorio de $TERRARIO_SNMP_AGENT_DIR llamado

“param-values”.

fvis = open( d + '/visible' ,"w")

fvis.write(str(visible))

fvis.close()

Por último, se manda a esperar al programa un tiempo hasta volver a ejecutar el mismo procedimiento.

time.sleep(TIEMPO)

2.3.2 Script de sensor temperatura y humedad

El sensor AM2302 también es una excelente herramienta para medir tanto temperatura como humedad de

11


manera sencilla. Proporciona medidas de temperatura en un rango de -40 a 80 ºC y de humedad en un rango

de 0 a 100%, lo cual es adecuado para cualquier animal viviendo en un terrario. Para su uso se necesita la

instalación de la librería “Adafruit_Python_DHT” [7].

El script que lee las medidas del sensor se llama AM2302.simple_tofile-int.py y está escrito para el intérprete

de Python versión 3. Como en el caso anterior, se describirá con extractos del fichero de código fuente para no

masificar la explicación con código menos importante.

En primer lugar, se importa la librería “Adafruit_DHT” y se crea una instancia de la clase “AM2302” para poder

usar las funciones para leer del sensor.

#!/usr/bin/env python3

import Adafruit_DHT

import logging

sensor_AM2302 = Adafruit_DHT.AM2302

Tras crear la instancia del sensor, se procede como en el anterior caso; se entra en un bucle infinito en el que se

lee, se almacena la información y se espera un tiempo determinado.

Además, el script del sensor mantiene un fichero de log con las medidas tomadas y la marca temporal. Para ello,

utiliza la clase “logging”. Se configura el log de la siguiente manera:

logging.basicConfig(filename='sensor_th.log',format='%(asctime)s --



De esta manera, el fichero sensor_th.log se creará en el mismo directorio del script con el formato “Timestamp

– nivel de log::mensaje” para las líneas de log.

En este caso, se lee del lector de la siguiente manera:

while ( 1 ):

humidity, temperature = Adafruit_DHT.read_retry(sensor_AM2302, pin)

Así, mediante la función “read_retry” se reciben los valores de temperatura y humedad directamente. Además,

se le indica por argumento el pin donde está conectado el sensor.

Para el fichero de log, se registra cada medida tomada con las siguientes líneas:

logging.info("TEMPERATURA "+str(temperature))

logging.info("HUMEDAD "+str(temperature))

Por último, se escribe la información en el mismo directorio que el anterior script y se manda al programa a

esperar durante unos secundos para volver a repetir el proceso.

fhum = open( d + '/humidity', "w")

fhum.write(str(int(humidity)))

fhum.close()

NOTA: denotar que el valor “humidity” y “temperature” son convertidos explícitamente a tipo “int”

(entero) en la función “write”. Esto se debe hacer al escribir cualquier valor que contenga decimales (tipos

“float”, por ejemplo) ya que el agente SNMP deberá manejar valores enteros.

time.sleep(TIEMPO)

13

3 DISEÑO DE SISTEMA DE GESTIÓN

l término MIB se refiere a un tipo de base de datos que contiene una serie de objetos siguiendo una

estructura arbolada. Estos objetos son variables usadas por el protocolo SNMP para supervisar y gestionar

una máquina en una red. Cada uno de esos objetos tiene un identificador único e información sobre su

sintaxis (entero, cadena de caracteres, contador), el nivel de acceso (lectura y escritura), restricciones de tamaño

y otros detalles como la descripción del mismo.

Como se comentó en la introducción, el fin de SNMP y, por tanto, también de la MIB es hacer posible gestionar

máquinas de distintos fabricantes. Para ello, se recurre a un subconjunto de tipos de ASN.1 (Notación Sintáctica

Abstracta). ASN describe la forma en la que se almacena la información de manera que mediante su uso se

pueden representar datos independientemente del fabricante de la misma. ASN.1 es la segunda versión de la

Estructura de la Información de Gestión (Structure of Management Information Version 2 o SMIv2) definido

en el RFC 2578 [8].

3.1. Escenario de sistema de gestión

En un sistema de gestión de red, se encuentran dos roles: el gestor y el agente (o nodo gestionado). Este tipo de

sistema sigue la arquitectura Cliente - Servidor.

El agente es el equipo instrumentalizado que gestiona los objetos de la base de datos de gestión (o MIB).

Recibe comandos que actúan sobre esos objetos de gestión. Además, puede generar notificaciones de aviso

en determinadas ocasiones o ante determinados eventos. Estas notificaciones se denominan traps y sirven

para informar al gestor de los eventos ante los que debe tomar decisiones y actuar.

El gestor es el equipo que usa el operador humano para comunicarse con el agente. Aquí se generan las

peticiones y se reciben las notificaciones.

En este caso, el sistema de gestión estará compuesto por uno o varios gestores, ya sea ordenador u otra Raspberry

Pi y por un único agente. Este agente, como ya se ha comentado, funciona en una Raspberry Pi 1.

La base de datos de gestión estará compuesta por objetos que representan el estado del agente, objetos que

permiten configurar ciertos parámetros del agente, objetos sobre el estado de los sensores usados y objetos que

permiten realizar acciones sobre sensores y actuadores usados por el agente.

El escenario descrito se describe en la siguiente Figura 3-1:

E

Diseño de sistema de gestión

14

Figura 3-1. Escenario de sistema de gestión.

3.2. Objetos de gestión

El agente utiliza una base de datos de objetos de gestión llamada MIB. Esos objetos modelan (hacen referencia

a) recursos lógicos o físicos: configuraciones, estados, estadísticas de uso, etc.

Los recursos se centrarán en la configuración y estado del agente, de los sensores y en proporcionar

funcionalidades al agente.

A continuación, se ofrece una lista de las ideas sobre los objetos que se debe gestionar de cada elemento.

Para el agente (como elemento del sistema), el esquema es el siguiente:

Figura 3-2. Esquema de objetos de gestión del elemento agente.

estado

•Tiempo de funcionamiento. Versión de software

•¿Dónde se encuentra instalado en la casa?

•¿Qué sensores tiene conectados? ¿Qué mide?

configuración

•¿El envío de traps está activado?

•¿Adónde se envían los traps?

funcionalidades

•Envío de traps.

•Reinicio.

AGENTE

15


Para el sensor de temperatura y humedad, el esquema es el siguiente:

Para el actuador bombilla, el esquema es el siguiente:

Figura 3-4. Esquema de objetos de gestión del elemento bombilla.

estado

•¿Está encendida?

•¿Qué tiempo programado le queda para apagarse?

configuración

•Apagar / encender.

•¿De qué potencia es la bombilla?

funcionalidades

•Temporizador de apagado.

•Consumo de energía (desarrollos futuros).

estado• ¿Está funcionando?

configuración

• ¿Qué modelo de sensor?

• ¿Rango de temperatura y humedad máximas y mínimas aceptables?

funcionalidades

• Lectura humedad.

• Lectura temperatura.

• Avisos de alerta.

SENSOR

TEMPERATURA

y HUMEDAD

Figura 3-3. Esquema de objetos de gestión del elemento sensor temperatura y humedad.

BOMBILLA


16

Y, por último, el esquema del sensor de luz es el siguiente:

Este conjunto de objetos de gestión permite establecer un sistema de gestión de un terrario para un animal que

necesite unas condiciones ambientales específicas.

3.3. Diseño de módulo TERRARIO-MIB

Para poder crear un modulo cualquiera de MIB, primero se necesita revisar al menos el RFC2578 para entender

cómo se definen los tipos de datos que se pueden necesitar y seleccionar los más útiles para el módulo.

En este caso, al usar SNMP versión 2c, se necesita revisar también el RFC1442 (“Structure of Management

Information for versión 2 of the Simple Network Management Protocol”) [9] que es un RFC más específico a

la situación de este TFG. En este RFC se definen los tipos de datos para su uso con SNMP versión 2c.

De este RFC1442 se ha extraido la información con la que se ha creado el módulo “SNMPv2-SMI”, el cual será

importado en la definición del módulo TERRARIO-MIB para hacer posible la creación del módulo propio.

Para poder importar un módulo, es necesario que el fichero con el mismo nombre se encuentre en un directorio

donde el sistema operativo busca las MIBs y que pueda ser accesible. Para obtener el fichero se puede

simplemente buscar el nombre del archivo en Internet.

El conjunto de objetos gestionables que existen están organizados como objetos en una jerarquía administrada

por la organización ITU-T y la organización OSI. Cada objeto en la jerarquía dispone de un identificador

númerico, llamado Object Identifier (OID), y un nombre simbólico de forma que cada objeto posee un

identificador único que además representa su localización relativa a la raíz del árbol.

La mayoría de esos objetos son de dominio público, pero existen ramificaciones para estructuras privadas. Estas

ramificaciones privadas se sitúan debajo de la rama “private”, de identificador iso.org.dod.internet.private o

1.3.6.1.4 en forma numérica. Para situar una empresa, organización u otro dentro del árbol, se debe hacer por

debajo del elemento “enterprise” de identificador 1.3.6.1.4.1. Sin embargo, para poder incluir un objeto, se

necesita licencia por parte de la organización IANA; pero se puede hacer libremente siempre que sea para uso

estrictamente privado, evitando problemas con elementos ya existentes en el árbol de manera oficial.

estado• ¿Está funcionando?

configuración

• ¿Qué modelo de sensor?

funcionalidades

• Lectura distintos valores de luz:- luz infrarroja.- lux.- luz visible.- luminosidad.

Figura 3-5. Esquema de objetos de gestión del elemento sensor luz.

SENSOR LUZ

17


Entonces, suponiendo que el módulo MIB que se cree será para uso privado y denotando al objeto que representa

al proyecto como “terrarioproject” con identificador 54321, se identificará de manera global como

iso.org.dod.internet.private.enterprise.terrarioproject o 1.3.6.1.4.1.54321.

Para crear el módulo TERRARIO-MIB se ha creado un directorio llamado “mibs-terrario” dentro del anterior

directorio $TERRARIO_SNMP_AGENT_DIR, de manera que sea accesible para el programa del agente

SNMP. Dentro de este directorio, se ha creado el fichero TERRARIO-MIB que contiene la definición del

módulo de este proyecto.

3.3.1 Árbol de objetos del modulo

Los objetos que han sido definidos en el modulo se encuentran descritos en las siguientes Figuras. En cada

elemento de las figuras se encuentra el nombre identificativo del objeto y su índice dentro de la rama.

En la Figura 3-6 se muestra el módulo TERRARIO-MIB completo. En él, se encuentra el objeto

“generalConfig”, que contiene los objetos de gestión y configuración de carácter general; el objeto

“sensorLuzConfig”, que contiene los objetos de configuración y de medidas del sensor de luz; el objeto

“sensorTemperaturaHumedadConfig”, que contiene los objetos de configuración y de medidas del sensor; y el

objeto “bombillaLuzConfig”, que contiene los objetos de configuración del actuador “bombilla”.

Estos objetos son grupos, actúan como “directorios” de objetos y contienen objetos relacionados.

En la siguiente Figura 3-6 se muestra el módulo completo de TERRARIO-MIB como un árbol de OIDs.


18

Figura 3-6. Árbol de OIDs de TERRARIO-MIB.

19


A continuación, se describirán los objetos contenidos en las diferentes ramas, su información de objeto y su uso.

Recordar que el nivel de acceso especificado en los objetos es máximo, es decir, cuando se diga que un objeto

es de escritura significará que también es posible leerlo.

En la rama “generalConfig” se encuentran los objetos siguientes:

“agenteUpTime” es un tipo entero de sólo lectura y muestra el tiempo de funcionamiento del agente en

segundos.

“localización” es un tipo cadena de caracteres de posible escritura y muestra la localización del terrario.

“versiónSoftware” es un tipo cadena de caracteres de sólo lectura y muestra la versión del software del

agente.

“disponibilidadSensorLuz” muestra con ‘1’ si el sensor de luz está disponible para el agente. Es de tipo

entero y de sólo lectura.

“disponibilidadSensorTH” ídem al anterior con el sensor de temperatura y humedad. Es de tipo entero y de

sólo lectura.

“disponibilidadBombillaLuz” ídem al primero con la bombilla. Es de tipo entero y de sólo lectura.

“resetAgente” es un tipo entero y de escritura. Cuando se introduce el valor ‘1’ se reinicia el agente.

“envioTraps” es un tipo entero y de escritura. Permite activar o desactivar el envío de traps.

“destinoIPTraps” es un tipo IpAddress y de escritura. Indica con una dirección IP, la máquina a la que se

deben enviar los traps.

“destinoPortTraps” es un tipo entero y de escritura. Indica el puerto al que se deben enviar los traps.

En la Figura 3-7 se aprecia la rama “generalConfig” y los objetos descritos.

Figura 3-7. Árbol OID TERRARIO-MIB, rama generalConfig.


20

En la rama “sensorLuzConfig” se encuentran los siguientes objetos:

“modeloSensorLuz” es un tipo cadena y de escritura. Indica el nombre, referencia o modelo del sensor.

“estadoSensorLuz” es un tipo entero y de escritura. Permite iniciar o parar el funcionamiento del sensor.

“luzInfrarroja” cantidad de luz de rango infrarrojo medida por el sensor. Es de tipo entero y de sólo

lectura.

“lux” cantidad de lux medido por el sensor. Es de tipo entero y de sólo lectura.

“luzVisible” cantidad de luz de rango visible medida por el sensor. Es de tipo entero y de sólo lectura.

“luminosidad” cantidad de iluminación de todo el rango de frecuencias medida por el sensor. Es de tipo

entero y de sólo lectura.

En la figura 3-8 se aprecia la rama “sensorLuzConfig” y los objetos descritos anteriormente.

Figura 3-4. Árbol OID TERRARIO-MIB, rama sensorLuzConfig.

En la rama “sensorTemperaturaHumedadConfig” se encuentran los objetos siguientes:

“modeloSensorTH” es un tipo cadena y de escritura. Indica el nombre, referencia o modelo del sensor

“estadoSensorTH” es un tipo entero y de escritura. Permite iniciar o parar el funcionamiento del sensor.

“funcionalidadesSensorTH” es un objeto vacío que contiene las diferentes mediciones que puede hacer

el sensor y otros parámetros de configuración. Todos los objetos en su interior son de tipo entero.

o “temperatura” es de sólo lectura y muestra la temperatura medida por el sensor.

o “maxTemperatura” es de escritura y define la temperatura máxima aceptable para el terrario.

o “trapMaxTemperatura” es una notificación (trap) que se envía cuando la temperatura medida

sobrepasa el valor máximo aceptable.

o “minTemperatura” es de escritura y define la temperatura mínima aceptable para el terrario.

o “trapMinTemperatura” es una notificación (trap) que se envía cuando la temperatura medida

sobrepasa el valor mínimo aceptable.

21


o “humedad” es de sólo lectura y muestra la humedad medida por el sensor.

o “maxHumedad” es de escritura y define la humedad máxima aceptable para el terrario.

o “trapMaxHumedad” es una notificación (trap) que se envía cuando la humedad medida

sobrepasa el valor máximo aceptable.

o “minHumedad” es de escritura y define la humedad mínima aceptable para el terrario.

o “trapMinHumedad” es una notificación (trap) que se envía cuando la humedad medida

sobrepasa el valor mínimo aceptable.

En la Figura 3-9 se aprecia la rama “sensorTemperaturaHumedadConfig” y los objetos descritos anteriormente.

Figura 3-9. Árbol OID TERRARIO-MIB, rama sensorTemperaturaHumedadConfig.

En la rama “bombillaLuzConfig” se encuentran los siguientes objetos:

“potenciaBombillaLuz” es de tipo entero y de escritura. Muestra la potencia de la bombilla usada en

vatios. Este OID tiene uso por motivos de consumo de energía.

“estadoBombillaLuz” es de tipo entero y de escritura. Permite encender y apagar la bombilla.


22

“temporizadorBombillaEncendida” es de tipo entero y de escritura. Permite iniciar un temporizador que

mantiene la bombilla encendida. Al indicar un valor de minutos a este OID, se enciende la bombilla y

al terminar ese periodo de tiempo se apagará.

En la Figura 3-10 se aprecia la rama “bombillaLuzConfig” y los objetos citados anteriormente.

Figura 3-10. Árbol OID TERRARIO-MIB, rama bombillaLuzConfig.

3.3.2 Comprobación validez MIB – librería libsmi

El modulo TERRARIO-MIB ya está casi listo para su uso con SNMP. Antes de pasar a la fase de desarrollo

del agente, se necesita comprobar la validez de la sintaxis y semántica del modulo creado acorde con SMIv2.

Para ello se utilizará la herramienta “smilint”. Dicha herramienta forma parte de la libreria “libsmi”, desarrollada

por el Instituto de Sistemas Operativos y Redes de Computadoras de la Universidad Técnica de Braunschweig.

La librería libsmi es una librería que permite a las aplicaciones de gestión acceder a las definiciones de módulos

MIB. Proporciona herramientas para la comprobación, análisis, compilación, conversion y comparación de

módulos MIB.

Se ha procedido a descargar la version “0.4.8”, desde la página del proyecto de la Universidad de Braunschweig,

y a su instalación según las indicaciones de la página.

Si, por cuestión de la distribución del Sistema Operativo usado o cualquier otro motivo, fuera imposible instalar

la librería libsmi en el sistema; se puede recurrir al apartado “Tools” – “Web Interface” de la página web del

proyecto libsmi. En este apartado se puede usar la herramienta “smilint” de manera online subiendo un fichero

del equipo para ser comprobado.

Smilint proporciona como salida un número de nivel de severidad de los errores encontrados. Los errores de

nivel 0 a nivel 3 necesitan ser solucionados para dar validez a la MIB. Errores de nivel 4, 5 o 6 no se consideran

errores como tal, sino que se recomienda su solución o se consideran como correcto; pero “posiblemente

problemático” en determinadas situaciones.

Si, dentro del directorio donde se encuentra el modulo TERRARIO-MIB, se ejecuta la herramienta smilint con

el argumento “-s” que detalla el nivel de severidad de los errores, obtenemos la siguiente salida:

pi $ raspberrypi: smilint -s ./TERRARIO-MIB

./TERRARIO-MIB-2:188: [5] notification-not-reversible warning:

notification `trapMaxTemperatura' is not reverse mappable


notification `trapMinTemperatura' is not reverse mappable


notification `trapMaxHumedad' is not reverse mappable


23


notification `trapMinHumedad' is not reverse mappable

./TERRARIO-MIB-2:27: [4] group-membership warning: node `agenteUpTime'

must be contained in at least one conformance group

./TERRARIO-MIB-2:36: [4] group-membership warning: node `localizacion'

must be contained in at least one conformance group

./TERRARIO-MIB-2:43: [4] group-membership warning: node

`versionSoftware' must be contained in at least one conformance group

Como se ve, se producen básicamente dos errores: uno de nivel 5 que es tolerable, y afecta a los objetos de tipo

notificación (traps) definidos en el módulo; y otro de nivel 4 que se recomienda ser solucionado y afecta a todos

los objetos del módulo.

El error de nivel 5 se produce por un problema de incompatibilidad en la traducción entre los traps de

SNMPv1, SNMPv2 y SNMPv3. Como en este caso la versión usada de SNMP es la version 2, se

ignorará este error.

El error de nivel 4 se produce por la inexistencia de un grupo de conformidad en el módulo, el cual es

requerido por el RFC2580 [10]. Para solucionar este error se necesita recurrir a las macros “OBJECT-

GROUP”, “NOTIFICATION-GROUP” y “MODULE-COMPLIANCE” del propio RFC2580.

Realmente, el módulo MIB es válido sin errores de sintaxis ni de semántica, pero con intención de realizar un

módulo más válido; se resolverá el error de nivel 4. Por lo tanto, se introducen las siguientes macros y cláusulas:

La macro “OBJECT-GROUP” se utiliza para definir una colección de objetos relacionados entre ellos. La

cláusula “OBJECTS” identifica los objetos contenidos dentro del grupo en cuestión. Se ha creado un grupo

llamado “terrarioGroup” que contiene todos los objetos del módulo que no son notificaciones.

La macro “NOTIFICATION-GROUP” se utiliza con el mismo propósito que la macro anterior, pero en el caso

de los objetos tipo notificación. La cláusula “NOTIFICATIONS” identifica los objetos contenidos dentro del

grupo. Se ha creado igualmente un grupo llamado “notificacionesGroup” que contiene los cuatro objetos tipo

notificación del módulo.

Finalmente, la macro “MODULE-COMPLIANCE” (en castellano, módulo de conformidad) se utiliza para

expresar un mínimo conjunto de requerimientos sobre la implementación de uno o más módulos MIBs. Con las

cláusulas “MODULE” y “MANDATORY-GROUPS” se identifican qué grupos son de obligada conformidad

con este módulo de conformidad, entre los cuales se encuentran los grupos definidos anteriormente.

En la Figura 3-11 se muestra el texto añadido al fichero TERRARIO-MIB y que soluciona los errores de nivel

4.


24

-- definicion de grupos

terrarioGroup OBJECT-GROUP

OBJECTS agenteUpTime,

localizacion,

versionSoftware,

disponibilidadSensorLuz,

disponibilidadSensorTH,

disponibilidadBombillaLuz,

resetAgente,

envioTraps,

destinoIPTraps,

destinoPortTraps,

modeloSensorLuz,

estadoSensorLuz,

luzInfrarroja,

lux,

luzVisible,

luminosidad,

modeloSensorTH,

estadoSensorTH,

temperatura,

maxTemperatura,

minTemperatura,

humedad,

maxHumedad,

minHumedad,

potenciaBombillaLuz,

estadoBombillaLuz,

temporizadorBombillaEncendida

STATUS current

DESCRIPTION "Grupo de configuracion general."

::= terrarioproject 5

notificacionesGroup NOTIFICATION-GROUP

NOTIFICATIONS trapMaxTemperatura,

trapMinTemperatura,

trapMaxHumedad,

trapMinHumedad

STATUS current

DESCRIPTION "Grupo de notificaciones."


-- modulo de conformidad

terrarioCompliance MODULE-COMPLIANCE

STATUS current

DESCRIPTION "Modulo de conformidad del proyecto."

MODULE

MANDATORY-GROUPS terrarioGroup,

notificacionesGroup


Figura 3-11. Texto añadido a TERRARIO-MIB.

25


Ahora, al ejecutar la herramienta Smilint con el argumento “-s” se produce la siguiente salida, lo que confirma

que se ha solucionado el error de nivel 4.

pi $ raspberrypi: smilint -s ./TERRARIO-MIB

./TERRARIO-MIB:188: [5] warning: notification `trapMaxTemperatura' is not

reverse mappable

./TERRARIO-MIB:201: [5] warning: notification `trapMinTemperatura' is not

reverse mappable

./TERRARIO-MIB:222: [5] warning: notification `trapMaxHumedad' is not

reverse mappable

./TERRARIO-MIB:235: [5] warning: notification `trapMinHumedad' is not

reverse mappable

En este punto ya se ha creado el módulo TERRARIO-MIB y se ha validado. Se puede proceder con la

compilación del módulo para su uso con el agente SNMP.

Antes de pasar al siguiente apartado, se debe copiar el módulo a un directorio donde el sistema buscará las MIBs

disponibles. Puede haber casos específicos, pero generalmente el sistema busca las MIBs en los siguientes

directorios:

$HOME/.snmp/mibs

/usr/local/share/snmp/mibs

Desarrollo del Agente SNMP

26

4 DESARROLLO DEL AGENTE SNMP

Un agente SNMP es un programa que se ejecuta en cada uno de los nodos de una red que se deseen gestionar o

monitorizar. Para su funcionamiento, emplea una base de datos con los objetos que se quieren gestionar llamada

MIB.

El agente recibe comandos de los gestores que actúan sobre esos objetos, bien para consultar sus valores o bien

para cambiarlos. Incluso puede generar notificaciones de aviso ante la ocurrencia de eventos en el propio agente,

ya sean cambios de estado de un objeto de gestión, una alerta o un aviso.

Un agente SNMP se sitúa en la capa OSI de aplicación. El protocolo SNMP sigue la implementación de Cliente

– Servidor. Los comandos se encapsulan en APDUs y existen 5 diferentes en el protocolo SNMP:

GetRequest – es una consulta sobre uno o una lista de objetos de gestión.

GetNextRequest – parecido a GetRequest pero lo que se devuelve en la respuesta es el valor de la

instancia del objeto que está a continuación lexicográficamente.

SetRequest – es un mensaje de actualización de valor del objeto u objetos a los que se refiere.

GetResponse – es la contestación a una PDU del tipo GetRequest, GetNextRequest o SetRequest.

Trap – es utilizada para comunicar de forma asíncrona información sobre un evento.

4.1. Librerías necesarias para el agente

4.1.1 PySNMP

Para el desarrollo del agente SNMP, se utilizará la librería PySNMP [11]. PySNMP es una implementación de

un motor SNMP puramente escrito en Python. Este motor puede funcionar en los roles de

Agente/Manager/Proxy, con las versiones v1/v2c/v3 de SNMP sobre los protocolos IPv4/IPv6. La versión actual

más estable, la 4.3, puede funcionar con Python en las versiones desde la 2.4 hasta la 3.5. Es una herramienta

open-source (libre) y su código fuente está disponible en GitHub. Su página oficial se encuentra en la web

pysnmp.sourceforge.net.

La arquitectura de PySNMP ha ido evolucionando a la par con el protocolo SNMP hasta una versión modular

tal y como SNMPv3. Así, PySNMP está forma por un gran número de componentes con interfaces bien

definidas. La siguiente Figura 4-1 refleja su estructura interna en comparación con la de SNMPv3.

Figura 4-1. Estructuras internas de SNMPv3 (izquierda) y PySNMP (derecha).

27


Para instalar la librería PySNMP, se necesita instalar primero instalar el gestor de paquetes Pip. Para ello:

sudo apt-get install python-pip

Luego, se necesitan ejecutar los siguientes comandos:

pi $ raspberrypi: sudo apt-get install python-pysnmp-common --fix-missing

pi $ raspberrypi: pip install pysnmp

Requirement already satisfied (use --upgrade to upgrade): pysnmp in

/usr/lib/python2.7/dist-packages

Requirement already satisfied (use --upgrade to upgrade): pyasn1>=0.1.2 in

/usr/lib/python2.7/dist-packages (from pysnmp)

Requirement already satisfied (use --upgrade to upgrade): pycrypto>=2.4.1

in /usr/lib/python2.7/dist-packages (from pysnmp)

Cleaning up...

Al ejecutar el comando anterior con pip, la salida debe ser similar a la anterior para entender que se ha instalado

correctamente.

Ahora ya se encuentra instalada la librería PySNMP. Como se puede intuir, el fin del uso de esta librería dentro

de este TFG es que, en la construcción del agente, el mismo haga uso de ese motor SNMP.

4.1.2 Net-SNMP

Net-SNMP es una suit de aplicaciones usada para implementar SNMP en sus tres versiones. Entre otras cosas,

incluye aplicaciones de línea de comandos que permiten obtener información de dispositivos que implementan

SNMP. Algunas de estas herramientas son: snmpget, snmpgetnext, snmpwalk, snmptable, snmpset y

snmptranslate.

Para instalar Net-SNMP [12], se puede entrar en su web www.net-snmp.org donde se explica el proceso de

instalación.

Básicamente, el fin de la librería Net-SNMP dentro de este TFG es tener a disposición unas herramientas para

probar el agente SNMP implementado. Se usarán las herramientas snmpget, snmpwalk, snmpset y

snmptranslate.

Previamente a la implementación del agente, se pueden hacer consultas de los objetos de la MIB para comprobar

si son correctos o si están en el orden deseado. Para ello, se utilizará snmptranslate que realiza la traducción del

nombre del objeto a su OID.

Para obtener el OID del objeto proporcionando su nombre como argumento, situados en el directorio del módulo

TERRARIO-MIB:

snmptranslate -m ./TERRARIO-MIB -IR -On <nombre_objeto>

Si el módulo MIB definido fue copiado a un directorio donde el sistema pueda encontrarlo, entonces la opción

“-m” no es necesaria y se puede realizar el comando de la siguiente manera:

snmptranslate -IR -On TERRARIO-MIB::<nombre_objeto>

Un ejemplo de funcionamiento de la herramienta snmptranslate para el caso del módulo MIB, produce la

siguiente salida con el primer y el último elemento del módulo TERRARIO-MIB:

pi $ raspberrypi: snmptranslate -m ./TERRARIO-MIB -IR -On agenteUpTime


28

.1.3.6.1.4.1.54321.1.1

pi $ raspberrypi: snmptranslate -IR -On TERRARIO-MIB::agenteUpTime

.1.3.6.1.4.1.54321.1.1

pi $ raspberrypi: snmptranslate -m./TERRARIO-MIB -IR -On


.1.3.6.1.4.1.54321.4.3

pi $ raspberrypi: snmptranslate -IR -On TERRARIO-

MIB::temporizadorBombillaEncendida

.1.3.6.1.4.1.54321.4.3

4.2. Diseño e implementación del agente

En el programa del agente se usará la programación multihilo. La programación multihilo aporta concurrencia

a su funcionamiento, pudiento gestionar las peticiones SNMP y supervisar las variables sensibles al envío de

avisos traps al mismo tiempo. Pero, sobre todo, permite no bloquear funcionalidades independientes. Debido a

su programación, la supervisión de las variables necesita de un bucle infinito de comprobación de sus valores

(bucle while infinito). Ésto sería interrumpido por el despachador del objeto agente para atender las peticiones

SNMP en un mismo hilo.

Para el esqueleto del agente se ha utilizado un fichero de ejemplo de la página nealc.com [13] donde se describe

un esqueleto básico sacado de la documentación de la página de PySNMP.

El programa agente elabora un fichero de log para tener constancia de las consultas realizadas, cambios y errores.

Para ello, utiliza la librería “logging” y se configura de la siguiente manera:

logging.basicConfig(filename='agente_terrario.log',format='%(asctime)s --



Esta configuración indica que se elabora un fichero de nombre agente_terrario.log en el mismo directorio de

ejecución del agente en el formato “timestamp -- nivel de log::mensaje”.

El programa agente hace uso de unas instancias de clases, a modo de esqueleto, que le permite articular todas

las actividades que corresponden a un agente SNMP.

En dicho esqueleto se encuentran las siguientes clases, que serán descritas en sus respectivos apartados.

4.2.1 Librerías importadas

Como se aprecia en el fichero, se importan de algunas librerías los módulos: “engine”, “config”, “cmdrsp”,

“context”, “ntforg”, “v2c”, “udp”, “builder”, “threading”, “time”, “collections”, “os”, “rfc1902”, “Popen”, “re”

y “sys”.

Estos módulos serán usados en el programa del agente para hacer posible ciertas acciones.

Algunos como “engine”, “config”, “context”, “cmdrsp”, “ntforg”, “udp”, “builder”, “threading”, “v2c”, “time”

o “collections” se utilizan para implementar el agente SNMP.

Otros como “os”, “rfc1902”, “Popen”, “re” y “sys” se utilizan en las funciones que se ejecutan con las consultas

SNMP o con otras funciones auxiliares.

29


4.2.2 Clase Mib

La clase Mib contiene todos los datos que podrán ser servidos e implementa el concepto de MIB dentro del

programa del agente como un objeto. Como cualquier clase de un lenguaje de programación orientado a objeto,

la clase contiene los atributos y los métodos que dan funcionalidad a la misma.

Los atributos que contiene la clase Mib son variables que tienen que ver con el estado de los objetos de gestión

y con otros parámetros de importancia.

Los métodos de la clase implementan las funciones de consulta y de actualización de los objetos de gestión.

Estos métodos serán referenciados en la clase SNMPAgent para indicar la relación entre el objeto de la MIB y

sus funciones asociadas de consulta y actualización.

4.2.3 Clase SNMPAgent

La clase SNMPAgent contiene a la MIB, al motor SNMP, implementa la capacidad de envío de traps y la

capacidad de servir ininterrumpidamente a las peticiones SNMP.

PySNMP exige que se utilice un motor SNMP por cada instancia de agente SNMP funcionando. Por ello, se

instancia un objeto de la clase “SnmpEngine” de la librería PySNMP en el programa. Si se utilizara una copia

de este programa en otra máquina se crearía otra instancia de “SnmpEngine” al ser ejecutado el programa, así

que esta directiva de PySNMP quedaría satisfecha.

En el código dentro de esta clase también se configura el agente, indicándole una interfaz de red en la que atender

peticiones SNMP; se configura la comunidad del agente; se carga la MIB proporcionada en el argumento de la

clase (una instancia de la clase Mib); y se indican qué peticiones SNMP que deben ser atendidas.

A continuación, encontramos las funciones “setTrapReceiver” y “sendTrap” que permiten configurar el destino

de los traps e implementan el envío de los mismos.

Por último, la función “serve_forever” permite registrar una tarea para el agente, de manera que mantenga el

despachador de entrada/salida funcionando ininterrumpidamente.

4.2.4 Clase Worker

La clase Worker utiliza las anteriores definiciones de clases y sus instancias, de manera que al ejecutar el

programa se crea un hilo en el que se puede atender las peticiones SNMP.

Nótese que en la propia definición de esta clase se indica, entre paréntesis, la clase “threading.Thread”. Esto se

utiliza en Python para indicar de qué clase se debe heredar la definición de la clase corriente. De esta manera se

pretende utilizar definir la clase Worker como una subclase de “Thread”.

En la función “init” se redefine el constructor de la clase hilo (“Thread”) con las instancias de las clases Mib y

SNMPAgent a su disposición como atributos. Esto quiere decir, que se redefine el constructor de la clase hilo

de manera que se crea el hilo, pero con las instancias de clases Mib y SNMPAgent. Así, este bloque de código

se ejecuta en un hilo diferente al del programa principal, permitiendo la atención a las consultas SNMP de forma

independiente.

En la función “run”, que se ejecuta al llegar al comando “Worker(agent, mib).start()”, se encuentran varias

sentencias que permiten poner en funcionamiento los sensores y que inicia la monitorización de las variables

que activan el envío de traps SNMP.

Por lo tanto, esta clase es la clave en el funcionamiento del programa del agente para atender peticiones SNMP.

4.2.5 Clase VigilanteTraps

Esta clase se ha creado de manera similar a la anterior, Worker, para poder monitorizar los OID que generan

traps en un hilo diferente al del programa principal. Así mismo, dentro de la clase, se establece un bucle while


30

infinito que permite el envoi de traps de la siguiente forma:

Primero, si el envío de traps se encuentra activo se pasa a comprobar si el sensor está funcionando y tomando

lecturas. Segundo, si las anteriores condiciones se cumplen, se comprueba cada valor de OID si supera los límites

fijados. Por ultimo, si se superara el límite de alguno de ellos, se configuraría el receptor de los traps y se

procedería al envío del trap mediante la función “sendTrap”.

4.3. Funciones para los OIDs

4.3.1 Compilación del modulo TERRARIO-MIB

Como se comentó al principio de la memoria, se utilizará python como lenguaje de programación para el agente

SNMP. Para el uso de python como lenguaje en un Sistema de Monitorización de Red (Network Management

System, en inglés), se necesita convertir el actual módulo en texto plano a un módulo en el lenguaje que pueda

entender el motor SNMP que atiende las consultas SNMP.

Para este apartado se utilizará una herramienta de la librería PySNMP llamada “build-pysnmp-mib” que

convertirá el módulo en texto plano en un módulo python que PySNMP pueda leer.

Para ello, será necesario ejecutar el siguiente comando. El argumento “-o” indica el nombre del archivo de salida,

que será el mismo que el del módulo, pero con la extensión “.py” característica del lenguaje python.

pi $ raspberrypi: build-pysnmp-mib -o TERRARIO-MIB.py ./TERRARIO-MIB

Si se revisa el archivo surgido, se aprecian diferentes apartados escritos en lenguaje python:

La clase “mibBuilder” es usada para contener toda la información del módulo MIB. Es un constructor

de MIBs que permite cargar MIBs en el agente. Dicha clase “mibBuilder”, será utilizada en el programa

principal del agente SNMP para cargar este módulo y poder utilizarlo.

El primer apartado etiquetado con “# Imports” contiene la parte del módulo TERRARIO-MIB que

enumera los objetos que se importan y de qué otros módulos mediante la función “importSymbols”, en

lenguaje python.

Luego, en el apartado “# Objects”, se aprecia cómo se define el módulo como una instancia de un objeto

python “terrarioproject” con su identificación y la demás información dentro de la macro “MODULE-

IDENTITY”. El objeto “generalConfig” (que era un objeto vacío en el módulo MIB) es transformado

en una instancia de un objeto python mediante la función “MibIdentifier” al igual que “agenteUpTime”

con la función “MibScalar”. Este último, además, es llenado con su información de la MIB mediante

las funciones “setMaxAccess”, “setUnits” y “setDescription”.

Este procedimiento se aplica de igual manera con el resto de objetos del módulo MIB que no son de

tipo notificación.

En el apartado “# Notifications” se definen los cuatro objetos tipo notificación mediante la función

“NotificationType” y se llena con información del módulo MIB del objeto con la función

“setDescription”.

En el apartado “# Groups” se definen los grupos del módulo MIB como objetos python mediante la

función “ObjectGroup” y se listan los objetos que lo componen mediante la función “setObjects”.

En el apartado “# Compliances” se define el módulo de conformidad descrito en el módulo MIB como

objeto python mediante la función “ModuleCompliance”. Además, se listan los objetos que forman

parte del módulo, los grupos “terrarioGroup” y “notificacionesGroup”, mediante la función

“setObjects”.

Por último, en el apartado “# Exports”, se exportan todos los elementos de la MIB como objetos python

31


para poder ser usados por el agente SNMP.

En este momento, el módulo MIB está compilado y listo para ser usado por Python en el programa del agente

SNMP.

En la Figura 4-2, se ha descrito gráficamente cómo es el proceso de compilación de la MIB y cómo se conecta

ese archivo compilado con el programa del agente para hacer uso de esos objetos gestionables.

Como ya se ha dicho, al compilar TERRARIO-MIB se obtiene el archivo para Python TERRARIO-MIB.py

(A). Este archivo es usado en el programa del agente por la instancia de la clase “mibBuilder” para cargar dicho

módulo y poder usar el módulo.

Tras indicar dónde se encuentran los módulos que debe manejar el agente (B), se procede a instanciar los objetos

del módulo para poder hacer uso de ellos (en los lenguajes orientados a objeto, se necesitan instanciar objetos

de las clases para poder ser usados) y para ello se necesita aún un par de datos más: ¿Cuáles son las funciones a

las que debe recurrir el agente al recibir peticiones SNMP del tipo GetRequest y SetRequest?

Para indicar cuáles son dichas funciones, se necesita elaborar una lista con tuplas en las que se tenga la siguiente

relación lógica: ( MÓDULO, NOMBRE_OID, FUNCION_GET, FUNCION_SET ).

Esa lista es la variable “mibObjects” (C) y es usada junto con la información extraída por mibBuilder del archivo

TERRARIO-MIB.py en la instanciación de los objetos (D).

Figura 4-2. Conexión entre el módulo TERRARIO-MIB y el programa agente.


32

4.3.2 Funciones asociadas a los OIDs

En el módulo TERRARIO-MIB existe un total de 27 objetos gestionables. Algunos objetos deben disponer de

dos funciones para las consultas de gestión, aquellos con nivel de acceso “read-write”; cada una de ellas

asociadas a una petición SNMP de consulta (GetRequest, GetNextRequest) y a una petición SNMP de

actualización (SetRequest). Mientras tanto, otros objetos sólo necesitan de una función para las consultas de

gestión, aquellos con nivel de acceso “read-only”; de manera que esa función será la asociada a la petición

SNMP de consulta (GetRequest, GetNextRequest).

A continuación, se muestra el conjunto de objetos gestionables del módulo MIB con sus OIDs relativos a la

rama “enterprise” y sus funciones asociadas para responder a las peticiones SNMP. La primera función, que

comienza normalmente con “Get” o “Read”, se ejecuta con las peticiones GetRequest y GetNextRequest. La

segunda función, que comienza normalmente con “Update” o “Set”, se ejecuta con las peticiones SetRequest.

Estos objetos junto con sus funciones asociadas compondrán tuplas que serán pasados a la instancia de la clase

SNMPAgente como argumento y que permitirá establecer la relación entre el objeto de gestión, su función

asociada a las peticiones Get y su función asociada a las peticiones Set. Como se ha comentado antes, se puede

apreciar en la Figura 4-2 esta lista de tuplas.

La Figura 4-3 muestra los objetos de la lista de tuplas con su nombre de identificación y sus funciones asociadas.

agenteUpTime

.54321.1.1

• ReadAgenteUpTime

localizacion

.54321.1.2

• ReadLocalizacion

• UpdateLocalizacion

versionSoftware

.54321.1.3

• ReadVersionSW

• UpdateVersionSW

disponibilidadSensorLuz

.54321.1.4

• CheckSensorLuz

disponibilidadSensorTH

.54321.1.5

• CheckSensorTH

disponibilidadBombillaLuz

.54321.1.6

• CheckBombillaLuz

resetAgente

.54321.1.7

• ReadResetAgente

• InitResetAgente

envioTraps

.54321.1.8

• CheckEstadoEnvioTraps

• UpdateEstadoEnvioTraps

destinoIPTraps

.54321.1.9

• ReadDestinoIPTraps

• UpdateDestinoIPTraps

destinoPortTraps

.54321.1.10

•ReadDestinoPortTraps

•UpdateDestinoPortTraps

modeloSensorLuz

.54321.2.1

•ReadModeloSensorLuz

•UpdateModeloSensorLuz

estadoSensorLuz

.54321.2.2

•ReadEstadoSensorLuz

•UpdateEstadoSensorLuz

33


Figura 4-3. Relación entre los objetos gestionables de TERRARIO-MIB

y sus funciones asociadas para consultar y modificación.

4.3.3 Funciones auxiliares

Así mismo, existen otras funciones auxiliares para hacer posible el trabajo del agente SNMP. Éstas son:

“EncuentraSensorLuz” utiliza la función “foundSensor” de la librería “TSL2561” del propio sensor

para devolver un valor si se encuentra el sensor disponible para el sistema (conectado a un pin).

“EncuentraSensorTH” utiliza la función “read_retry” de la librería “Adafruit_DHT” del propio sensor

para hacer una lectura del sensor. Si la lectura devuelve un valor, entonces la función devuelve un valor

luzInfrarroja

.54321.2.3

• ReadLuzInfrarroja

lux

.54321.2.4

• ReadLux

luzVisible

.54321.2.5

• ReadLuzVisible

luminosidad

.54321.2.6

• ReadLuminosidad

modeloSensorTH

.54321.3.1

• ReadModeloSensorTH

• UpdateModeloSensorTH

estadoSensorTH

.54321.3.2

• CheckStatusSensorTH

• UpdateStatusSensorTH

temperatura

.54321.3.3

• ReadTemperatura

maxTemperatura

.54321.3.4

• ReadMaxT

• SetMaxT

minTemperatura

.54321.3.6

• ReadMinT

• SetMinT

potenciaBombillaLuz

.54321.4.1

• ReadPotenciaBombilla

• UpdatePotenciaBombilla

estadoBombillaLuz

.54321.4.2

• GetBombillaEstado

• SetBombillaEstado

temporizadorBombilla

Encendida

.54321.4.3

• GetTemporizadorBombillaEncendida

• InitTemporizadorBombillaEncendida

humedad

.54321.3.8

• ReadHumedad

maxHumedad

.54321.3.9

• ReadMaxH

• SetMaxH

minHumedad

.54321.3.11

• ReadMinH

• SetMinH


34

indicando que el sensor está disponible.

“compruebagpio” se utiliza para comprobar si el pin que utiliza un sensor ha sido exportado en el

directorio adecuado en el sistema Raspbian. Si se descubre que el pin ha sido exportado, entonces

significaría que el pin además ha sido debidamente configurado en el sistema y se devolvería un valor

indicando este hecho.

“iniciagpio” se utiliza para inicializar un pin en el sistema exportándolo si no se ha hecho ya, para lo

que se utiliza la anterior función “compruebagpio”.

“CierraAgente” se utiliza cuando se quiere finalizar el funcionamiento del agente. Se llama a la función

que cancela los posibles temporizadores activos, se para el funcionamiento de los sensores y se “des-

exportan” los pines previamente exportados. Esta función proporciona una salida limpia del programa

para el sistema operativo.

“CancelTimers” se utiliza para comprobar si existe algún temporizador activo y, en ese caso, pararlo.

“controlminutos” es una de las dos funciones a las que a los temporizadores se les indica ejecutar al

finalzar los mismos. Ésta, en particular permite decrementar el valor del OID

“temporizadorBombillaEncendida” que permite al Gestor conocer cuánto tiempo queda del

temporizador de la bombilla encendida.

“apagabombilla” es la otra de las dos funciones que ejecutan los temporizadores. Ésta simplemente

permite apagar la bombilla cuando el tiempo indicado en el OID “temporizadorBombillaEncendida”

llega al valor ‘0’.

“EscribirInformacionAgenteDisps” se utiliza para escribir información sobre el agente en unos ficheros

que luego serán leídos por el propio agente en respuesta a peticiones de lectura sobre algunos OIDs.

“ReiniciaAgente” se utiliza para reiniciar el programa del agente.

4.4. Ejecución del agente

Para la ejecución del programa del agente SNMP, se necesita tener los ficheros que se utilizarán para la lectura

de los sensores y el programa del propio agente en el mismo directorio. Lo siguiente que se necesita es tener el

fichero MIB legible para python TERRARIO-MIB.py en un subdirectorio. Además, es necesario comprobar

que los scripts tanto del agente como de los sensores tengan los permisos necesarios (755 – lectura y ejecución

mínimos para cualquier usuario) al igual que el fichero de MIB de python (644 – lectura mínima para cualquier

usuario).

A continuación, para la ejecución, se necesita ejecutar el programa con privilegios de administrador. Para ello,

se hará como usuario root o utilizando el comando “sudo”. Así:

pi $ raspberrypi: sudo ./agente-snmp_pyv3-int.py

Agente SNMP listo!

Sensor TSL2561 encontrado, sensor listo!

Sensor AM2302 listo!

El programa del agente ya está funcionando y podemos realizar una prueba de su funcionamiento ejecutando

desde otra máquina el comando “snmpwalk”. Para ello, se necesita tener el fichero del módulo TERRARIO-

MIB en un directorio donde el sistema busca las MIBs disponibles. En otro caso, se utilizará la opción “-m” del

comando indicando el fichero del módulo. Se utiliza la comunidad “private”, con la opción “-c”, del usuario

SNMPv2 “agent-private”. Ésta será la salida del comando:

35


pi $ raspberrypi: snmpwalk -m ./TERRARIO-MIB -v 2c -c private 192.168.1.110

1.3.6.1.4.1.54321

TERRARIO-MIB::agenteUpTime.0 = Counter32: 489 Segundos

TERRARIO-MIB::localizacion.0 = STRING: "Interior, cocina"

TERRARIO-MIB::versionSoftware.0 = STRING: "4.0"

TERRARIO-MIB::sensorLuz.0 = INTEGER: 1

TERRARIO-MIB::sensorTemperaturaHumedad.0 = INTEGER: 1

TERRARIO-MIB::bombillaLuz.0 = INTEGER: 1

TERRARIO-MIB::resetAgente.0 = INTEGER: 0

TERRARIO-MIB::envioTraps.0 = INTEGER: 1

TERRARIO-MIB::destinoIPTraps.0 = IpAddress: 192.168.1.110

TERRARIO-MIB::destinoPortTraps.0 = INTEGER: 162

TERRARIO-MIB::modeloSensorLuz.0 = STRING: "TSL2561"

TERRARIO-MIB::estadoSensorLuz.0 = INTEGER: 1

TERRARIO-MIB::luzInfrarroja.0 = INTEGER: 0

TERRARIO-MIB::lux.0 = INTEGER: 0 Lux

TERRARIO-MIB::luzVisible.0 = INTEGER: 0

TERRARIO-MIB::luminosidad.0 = INTEGER: 0

TERRARIO-MIB::modeloSensorTH.0 = STRING: "AM2302"

TERRARIO-MIB::estadoSensorTH.0 = INTEGER: 1

TERRARIO-MIB::temperatura.0 = INTEGER: 24 grados C

TERRARIO-MIB::maxTemperatura.0 = INTEGER: 80 grados C

TERRARIO-MIB::minTemperatura.0 = INTEGER: -40 grados C

TERRARIO-MIB::humedad.0 = INTEGER: 35 %

TERRARIO-MIB::maxHumedad.0 = INTEGER: 100 %

TERRARIO-MIB::minHumedad.0 = INTEGER: 0 %

TERRARIO-MIB::potenciaBombillaLuz.0 = INTEGER: 75 W

TERRARIO-MIB::estadoBombillaLuz.0 = INTEGER: 1

TERRARIO-MIB::temporizadorBombillaEncendida.0 = INTEGER: 0 Minutos

Como se ve, cada OID devuelve un valor adecuado a su tipo y además, gracias a la cláusula “UNITS” de SMIv2;

se indican las unidades de algunos OIDs como “Segundos” o “W” (Vatios).

El usuario asociado a la comunidad “private” tiene permisos de lectura y escritura para los objetos gestionables.

Prueba de ello es la posibilidad de realizar una petición “SetRequest” al objeto “localización”.

pi $ raspberrypi: snmpget -m TERRARIO-MIB -v 2c -c private 192.168.1.110

TERRARIO-MIB::localizacion.0

TERRARIO-MIB::localizacion.0 = STRING: "Interior, cocina"

pi $ raspberrypi:

pi $ raspberrypi: snmpset -m TERRARIO-MIB -v 2c -c private 192.168.1.110


36

TERRARIO-MIB::localizacion.0 s "Interior, Sala de estar"

TERRARIO-MIB::localizacion.0 = STRING: "Interior, Sala de estar"

pi $ raspberrypi:

pi $ raspberrypi: snmpget -m TERRARIO-MIB -v 2c -c private 192.168.1.110



Por otro lado, la comunidad “public” asociada al usuario “agent” sólo tiene accesos de lectura. Por lo que si se

intenta realizar un cambio en algún objeto gestionable devolverá información de error.

pi $ raspberrypi: snmpget -m TERRARIO-MIB -v 2c -c public 192.168.1.110



pi $ raspberrypi:

pi $ raspberrypi: snmpset -m TERRARIO-MIB -v 2c -c public 192.168.1.110

TERRARIO-MIB::localizacion.0 s "Exterior"

Error in packet.

Reason: notWritable (That object does not support modification)

Failed object: TERRARIO-MIB::localizacion.0

pi $ raspberrypi:

Por último, cuando se cierra el agente presionando “Ctrl+C” en el teclado, se muestra la siguiente salida:

^CCerrando agente...

pi $ raspberrypi:

37


5 GESTOR SNMP

El gestor también tiene un papel importante en este proyecto, pues será el que reciba las notificaciones traps y

las mostrará al operador humano. Éste, tomará decisiones sobre si actuar y cómo hacerlo en función de la

información obtenida del agente y mostrada por el gestor. Para la recepción de traps se utilizará “snmptrapd”.

La herramienta “snmptrapd” forma parte de la suite de aplicaciones Net-SNMP y consiste en un daemon (o

demonio) que permite recibir notificaciones SNMP. Si no estuviera instalada la herramienta, simplemente

ejecute el comando “sudo apt-get install snmptrapd --fix-missing”.

Por defecto, esta herramienta escucha en el puerto UDP 162 de todas las interfaces IPv4. Esta configuración por

defecto se dejará tal como está y conllevará el uso de privilegios de administrador para su ejecución al ser un

puerto menor a 1024. Siguiendo la guía de configuración de snmptrapd proporcionada en la propia página de

Net-SNMP, se han realizado las siguientes acciones sobre la configuración de la herramienta:

Se necesita proporcionar a la herramienta la comunidad del agente para poder recibir esos traps. Para

ello, en el fichero de configuración snmptrapd.conf se han incluido las siguientes líneas.

authCommunity log,execute,net traps

[snmp] logOption f /home/pi/Proyecto21-09/scripts-python/traps-

terrario

pidFile /home/pi/Proyecto21-09/scripts-python/traps-terrario

La primera línea establece que las notificaciones recibidas con la comunidad “traps” pueden ser tanto

logueadas como reenviadas a otra red y, además, permite la realización de acciones en el sistema.

La segunda línea establece que las notificaciones recibidas con la comunidad “traps” deberán ser

logueadas en el fichero indicado.

La tercera línea establece que se almacene el PID del proceso en el fichero indicado.

La herramienta snmptrapd se encuentra ahora configurada para nuestro uso como servidor de traps del agente

SNMP. A continuación, se informará de cómo se ejecutará la herramienta por línea de comandos y cuál es la

salida que se espera en su fichero de log.

Para poner a funcionar el servidor de traps “snmptrapd”, se ejecutará el siguiente comando:

sudo snmptrapd -m +TERRARIO-MIB -A

La opción “-A” le indica al programa que continúe completando el fichero de log ya que en otro caso borraría

lo que estuviera en el fichero y empezaría escribiendo por el principio. Así mismo, la opción “-m +TERRARIO-

MIB” indica un módulo MIB adicional que tendrá cargar la herramienta en su ejecución. Por último, recordar

que la herramiento por defecto carga su configuración del fichero por defecto; el que se había modificado

previamente. Esa configuración previa no entra en conflicto con estas opciones indicadas por línea de comandos.

A continuación, se configura el agente para que se envíe un trap de cada tipo. Ahora, si se comprueba el fichero

de log indicado, se encontrarán las siguientes líneas:

32190

NET-SNMP version 5.7.2.1

<UNKNOWN> [UDP: [192.168.1.110]:161->[192.168.1.110]:162]: Trap , DISMAN-

EVENT-MIB::sysUpTimeInstance = Timeticks: (1561) 0:00:15.61, SNMPv2-

MIB::snmpTrapOID.0 = OID: TERRARIO-MIB::maxTemperatura.0, TERRARIO-

Gestor SNMP

38

MIB::temperatura = INTEGER: 21 grados C



MIB::snmpTrapOID.0 = OID: TERRARIO-MIB::minTemperatura.0, TERRARIO-

MIB::temperatura = INTEGER: 21 grados C



MIB::snmpTrapOID.0 = OID: TERRARIO-MIB::maxHumedad.0, TERRARIO-

MIB::humedad = INTEGER: 50 %



MIB::snmpTrapOID.0 = OID: TERRARIO-MIB::minHumedad.0, TERRARIO-

MIB::humedad = INTEGER: 50 %

2017-01-29 20:15:14 NET-SNMP version 5.7.2.1 Stopped.

Stopping snmptrapd

Como se puede apreciar, se encuentran los siguientes elementos en el fichero de log del servidor de traps:

El número de proceso PID al inicio del fichero “32190”. De esta manera se puede matar el proceso con

ese ID para apagar el servidor de traps.

A continuación, se muestra el mensaje “NET-SNMP version 5.7.2.1” sin ningún mensaje adicional de

aviso o error, lo que indica que el programa snmptrapd ha sido iniciado con éxito.

Los traps recibidos del agente, de los cuatro tipos disponibles “maxTemperatura”, “minTemperatura”,

“maxHumedad” y “minHumedad”. En las notificaciones se aprecia como, acompañando al tipo de trap,

se encuentra el OID de la temperatura o humedad y el valor del mismoque ha provocado el aviso.

Por último, tras matar el proceso del servidor de traps, se encuentra el mensaje “2017-01-29 20:15:14

NET-SNMP version 5.7.2.1 Stopped.” indicando la finalización de su ejecución y su marca temporal.

Llegados a este punto, ya se ha explicado cómo implementar el agente y cómo configurar el servidor de los traps

que dará los avisos. Se tiene un sistema de monitorización de red totalmente operativo para su uso.

39


6 PRUEBAS Y VALIDACIÓN

En esta sección se ofrece un compendio de pruebas realizadas para certificar el buen funcionamiento del sistema

y conocer las limitaciones del mismo. Como proyecto de software, necesita la inversión de una vasta cantidad

de tiempo en la comprobación de las funcionalidades del mismo y corrección de errores e incluso en la

incorporación de mejoras.

Con motivo de esta sección, se ha redactado un documento aparte que detalla la metodología seguida en las

pruebas, los criterios de superación de las mismas y demás detalles. Dicho documento se incluye como el Anexo

2 al final de la memoria y, con motivos orientativos, se detallan a continuación las pruebas en versión resumida.

6.1. Informe de pruebas realizadas

Como se detalla en el Anexo 2, el escenario de prueba consiste en el siguiente:

Una subred interna compuesta por un Router y una serie de elementos conectados. La dirección de

subred es 192.168.1.0/24 y no es necesaria la conexión a Internet para la realización de las pruebas.

Un agente SNMP en el equipo Raspberry Pi 1 (Equipo A) conectado al Router y con dirección IP

192.168.1.110. En este equipo es en el único que se encontrará funcionando el programa del agente.

Además, tendrá funcionando el servidor de traps en el puerto 162 para ciertos casos de prueba y aquí se

deberá consultar el log del programa agente para certificar que el programa ha recibido consultas

SNMP. Este equipo sólo responderá a las peticiones del gestor y enviará los Traps.

Un gestor SNMP en el equipo Raspberry Pi 3 (Equipo B) conectado al Router y con dirección IP

192.168.1.151. Desde este equipo se generarán las peticiones SNMP hacia el agente. Así mismo, en

este equipo se encuentra funcionando el servidor de traps en el puerto 162 para determinados casos de

prueba.

En ambos equipos se encuentran instaladas las herramientas necesarias para los casos de prueba (suite Net-

SNMP), y configuradas acorde con los apartados de esta memoria.

El anterior escenario se encuentra descrito gráficamente en la Figura 6-1.

Figura 6-1. Escenario de pruebas.

Pruebas y validación

40

Se procede a listar las diferentes pruebas realizadas en el escenario. Cada subapartado se titulará según el nombre

de la prueba junto con el número identificativo de la misma. Para más detalles, consulte el Anexo 2.

6.1.1 Ejecución snmpwalk, P01B

Se realiza un snmpwalk sobre el agente SNMP. Espera recibir información de todos los OIDs del módulo

TERRARIO-MIB. Usa tanto la comunidad “public” como “private” y “otra”.

Comando: snmpwalk -v 2c -m +TERRARIO-MIB -c public 192.168.1.110

1.3.6.1.4.1.54321

snmpwalk -v 2c -m +TERRARIO-MIB -c private 192.168.1.110

1.3.6.1.4.1.54321

snmpwalk -v 2c -m +TERRARIO-MIB -c otra 192.168.1.110

1.3.6.1.4.1.54321

Criterio: Para los dos primeros comandos: el Equipo A debe responder al B y mostrar los OIDs del

módulo, así como sus valores. El agente debe registrar las peticiones en el log.

Para el tercer comando: el Equipo A NO debe responder al B. El agente NO debe registrar

la petición en el log.

6.1.2 snmpget con nombre de OID, P02B

Realizar una petición GetRequest con la herramienta snmpget para cada OID individual del módulo

TERRARIO-MIB. Se puede usar tanto la comunidad “public” como “private” indiferentemente.

Comando: snmpget -v 2c -m +TERRARIO-MIB -c public 192.168.1.110

<nombre>.0

Criterio: El agente responde con el valor del OID para cada caso. El agente debe registrar las

peticiones en el log.

6.1.3 snmpget con identificadores numéricos, P03B

Realizar una petición GetRequest con la herramienta snmpget en cada OID individual del módulo

TERRARIO-MIB en su formato numérico. Se puede usar tanto la comunidad “public” como “private”

indiferentemente.


<identificador>

Criterio: El agente responde con el valor del OID. El agente debe registrar las peticiones en el log.

41


6.1.4 snmpset con nombres de OID y comunidad public, P04B

Realizar una petición SetRequest con la herramienta snmpset en cada OID modificable del módulo

TERRARIO-MIB, con la comunidad que no permite la modificación del valor de los OIDs

Comando: snmpset -v 2c -m +TERRARIO-MIB -c private 192.168.1.110

<nombre>.0 <tipo> <valor>

Criterio: El agente responde con el mensaje de error de modificación. El agente NO debe registrar las


6.1.5 snmpset con nombres de OID y comunidad private, P05B

Realizar una petición SetRequest con la herramienta snmpset en cada OID modificable del módulo

TERRARIO-MIB. con la comunidad que sí permite la modificación del valor de los OIDs.



Criterio: El agente responde con el nuevo valor del OID. El agente debe registrar las peticiones en el

log con el valor nuevo.

6.1.6 snmpset con nombres de OID de nivel read-only, P06B

Realizar una petición SetRequest con la herramienta snmpset en cada OID NO modificable del módulo

TERRARIO-MIB. En este caso, se debe comprobar con la comunidad “private”.



Criterio: El agente responde con el mensaje de OID no modificable. El agente NO debe registrar las


6.1.7 snmpget con OID no accesibles, P07B

Realizar una petición GetRequest a los OIDs del módulo que son no accesible por su definición.


<nombre>.0

Criterio: Al realizar la petición, la respuesta del agente debe ser “No Such Object available on this

agent at this OID”.


42

6.1.8 snmpget a los elementos de tipo notificación, P08B

Realizar una petición GetRequest a los OIDs del módulo que son de tipo notificación (traps). Se puede usar

tanto la comunidad “public” como “private” indiferentemente.

Comando: snmpget -v 2c -m +TERRARIO-MIB -c private 192.168.1.110

<nombre>.0

Criterio: Al realizar la petición, la respuesta del agente debe ser “No Such Object available on this

agent at this OID”.

6.1.9 Reiniciar el agente, P09B

Realizar una petición SetRequest con la herramienta snmpset al OID “resetAgente” del módulo TERRARIO-

MIB con tipo “i” (integer) y valor “1”. La comunidad debe ser “private”.


TERRARIO-MIB::resetAgente.0 i 1

Criterio: El agente al reiniciarse muestra un valor de tiempo de funcionamiento menor que el previo

al reinicio.

6.1.10 Recepción de traps en Equipo B, P10B

Configurar ambos equipos A y B para el envío de traps de A hacia B y controlar el registro de dichos sucesos

mediante sus archivos de log.


TERRARIO-MIB::maxTemperatura.0 i 10 TERRARIO-

MIB::minTemperatura.0 i 30 TERRARIO-MIB::maxHumedad.0 i 20

TERRARIO-MIB::minHumedad.0 i 70

tail -f <archivo-log>

Criterio: El log del agente debe registrar el envío de los traps. El log del Equipo B debe registrar la

recepción de los traps indicando su tipo y valor.

6.1.11 Recepción de traps en Equipo B y puerto diferente, P11B

Continuar la prueba anterior P10B que consistía en configurar ambos equipos A y B para el envío de traps de

A hacia B y controlar el registro de dichos sucesos mediante sus archivos de log. En este caso, el puerto

destino de los traps será modificado en destinoPortTraps. Además, se reiniciará la herramienta snmtrapd en

Equipo B con una nueva configuración.


TERRARIO-MIB::envioTraps i 0

snmpset -v 2c -m +TERRARIO-MIB -c private 192.168.1.110

TERRARIO-MIB:: destinoPortTraps i 9999

sudo pkill -9 <PID>

43


snmptrapd -A udp:9999



Criterio: El log del agente debe registrar el envío de los traps. El log del Equipo B debe registrar la


6.1.12 Recepción de traps en Equipo B y paro del envío, P12B

El propósito es cortar el envío de traps cambiando el valor de envioTraps durante el envío de traps.



Criterio: El log del Equipo B deja de registrar la recepción de traps y el log del Equipo A deja de

registrar el envío de los mismos.

6.1.13 Paro de funcionamiento de sensor luz, P13B

Parar el funcionamiento del sensor de luz, previamente funcionando, modificando el valor de

estadoSensorLuz.


TERRARIO-MIB::estadoSensorLuz i 0

snmpget -v 2c -m +TERRARIO-MIB -c private 192.168.1.110

TERRARIO-MIB::estadoSensorLuz.0

Criterio: En las dos respuestas del agente, el OID estadoSensorLuz tiene el valor ‘0’.

6.1.14 Paro de funcionamiento de sensor luz y puesta en funcionamiento P14B

Continuar el escenario de la prueba anterior P13B y cambiar de nuevo el valor de estadoSensorLuz a ‘1’.


TERRARIO-MIB::estadoSensorLuz i 1



Criterio: En las dos respuestas del agente, el OID estadoSensorLuz tiene el valor ‘1’.

6.1.15 Paro de funcionamiento de sensor temperatura y humedad, P15B

Parar el funcionamiento del sensor de temperatura y humedad, previamente funcionando, modificando el

valor de estadoSensorTH.


TERRARIO-MIB::estadoSensorTH i 0


TERRARIO-MIB::estadoSensorTH.0


44

Criterio: En las dos respuestas del agente, el OID estadoSensorTH tiene el valor ‘0’.

6.1.16 Paro de funcionamiento de sensor temperatura y humedad y puesta en funcionamiento, P16B

Continuar el escenario de la prueba anterior P15B y cambiar de nuevo el valor de estadoSensorTH a ‘1’.


TERRARIO-MIB::estadoSensorTH i 1



Criterio: En las dos respuestas del agente, el OID estadoSensorTH tiene el valor ‘1’.

6.1.17 Cambiar el valor máximo de temperatura aceptable a uno no válido, P17B

El sensor de temperatura y humedad toma lecturas en un rango de temperaturas de -40ºC a 80ºC. Por lo tanto,

los OID que marcan la temperatura máxima/mínima aceptable tienen que encontrarse dentro de este rango.

En esta prueba se intentarán introducir valores de temperatura fuera de este rango.


TERRARIO-MIB::maxTemperatura.0 i 90


TERRARIO-MIB::maxTemperatura.0 i -60

Criterio: Las respuestas, en sus valores devueltos, deben devolver el valor original que tenía el OID

como si no hubiera sido modificado.

6.1.18 Cambiar el valor mínimo de temperatura aceptable a uno no válido, P18B

El sensor de temperatura y humedad toma lecturas en un rango de temperaturas de -40ºC a 80ºC. Por lo tanto,

los OID que marcan la temperatura máxima/mínima aceptable tienen que encontrarse dentro de este rango.

En esta prueba se intentarán introducir valores de temperatura fuera de este rango.


TERRARIO-MIB::minTemperatura.0 i 90


TERRARIO-MIB::minTemperatura.0 i -60



6.1.19 Cambiar el valor máximo de humedad aceptable a uno no válido, P19B

El sensor de temperatura y humedad toma lecturas en un rango de humedad de 0% a 100%. Por lo tanto, los

OID que marcan la humedad máxima/mínima aceptable tienen que encontrarse dentro de este rango. En esta

prueba se intentarán introducir valores de humedad fuera de este rango.


TERRARIO-MIB::maxHumedad.0 i 110

45



TERRARIO-MIB::maxHumedad.0 i -20



6.1.20 Cambiar el valor mínimo de humedad aceptable a uno no válido, P20B

El sensor de temperatura y humedad toma lecturas en un rango de humedad de 0% a 100%. Por lo tanto, los

OID que marcan la humedad máxima/mínima aceptable tienen que encontrarse dentro de este rango. En esta

prueba se intentarán introducir valores de humedad fuera de este rango.


TERRARIO-MIB::minHumedad.0 i 110


TERRARIO-MIB::minHumedad.0 i -20



6.1.21 Cambio de estado de la bombilla, apagado y encendido, P21B

Hacer dos cambios de valor del OID estadoBombillaLuz que determina el estado de la bombilla, primero

apagándola y luego encendiéndola.


TERRARIO-MIB::estadoBombillaLuz i 0


TERRARIO-MIB::estadoBombillaLuz i 1

Criterio: La bombilla se apaga con el primer comando y se enciende con el segundo.

6.1.22 Apagado de bombilla y poner temporizador a 3 minutos, P22B

Programar un temporizador de 3 minutos para la bombilla.


TERRARIO-MIB::temporizadorBombillaEncendida.0 i 3

snmpget -m +TERRARIO-MIB -v 2c -c private 192.168.1.110

temporizadorBombillaEncendida.0


estadoBombillaLuz.0




estadoBombillaLuz.0

Criterio: La bombilla se mantiene encendida hasta que pasan 3 minutos. El temporizador va


46

disminuyendo su valor con cada minuto que pasa.

6.1.23 Poner un segundo temporizador para la bombilla, P23B

Intentar programar un segundo temporizador de 3 minutos para la bombilla.






estadoBombillaLuz.0



Criterio: La respuesta muestra los minutos restantes del primer temporizador y no el nuevo valor dado.

El agente debe registrar los sucesos en el log y se encontrará un mensaje de advertencia

“WARNING::Temporizado bombilla existente no finalizado”.

6.2. Informe de resultados

A continuación, se muestra una tabla con las identificaciones de pruebas realizadas y resultados según sus

criterios.

ID PRUEBA RESULTADO

P01B Funciona

P02B Funciona

P03B Funciona

P04B Funciona

P05B Funciona

P06B Funciona

P07B Funciona

P08B Funciona

P09B Funciona

P10B Funciona

47


P11B Funciona

P12B Funciona

P13B Funciona

P14B Funciona

P15B Funciona

P16B Funciona

P17B Funciona

P18B Funciona

P19B Funciona

P20B Funciona

P21B Funciona

P22B Funciona

P23B Funciona

Tabla 6-2. Resultados de las pruebas.

Con lo que, el resumen de los resultados es:

Nº pruebas Aprobadas No aprobadas Índice de éxito Resultado

23 23 0 100% Exitoso.

Tabla 6-3. Resumen de resultados.

Basándose en los resultados de las pruebas realizadas previamente, se le concede al sistema el nivel correcto de

funcionamiento.

Conclusiones y desarrollos futuros

48

7 CONCLUSIONES Y DESARROLLOS FUTUROS

En esta última sección se pretende resumir el proyecto desarrollado con sus conclusiones y puntos de mejora y

de futuro desarrollo.

7.1. Conclusiones del proyecto

En primer lugar, se ha conseguido implementar un sistema de gestión para Raspberry Pi basado en el protocolo

SNMP. Éste, dispone de un módulo de monitorización de variables y envío de notificaciones trap.

En segundo lugar, se hace uso de varios scripts para el manejo de los sensores seleccionados para el proyecto.

Estos sensores son los únicos que funcionarán con el agente en esta versión. Se marca como punto de mejora la

implementación de los scripts de sensores con independencia del fabricante.

El módulo MIB desarrollado cuenta con un amplio número de objetos gestionables relacionados con los sensores

y con el estado y configuración del agente. Además, estos objetos proporcionan no sólo información sino

funcionalidades diversas como, por ejemplo, temporizador de encendido para la bombilla.

Así mismo, el proyecto ha sido desarrollado de manera que pueda ser fácilmente reproducible en otros equipos

que cuenten con hardware y software compatibles; y cuenten con los sensores adecuados. Su posible adaptación

a otras plataformas o a otro hardware queda supeditado a los desarrollos futuros del proyecto.

Como resultado, se ha obtenido un sistema de gestión de red para el caso específico de un terrario casero que

actualmente está siendo usado por el desarrollador en un terrario casero real y sigue en continuo desarrollo.

Por último, se ha conseguido desarrollar la memoria de manera suficientemente ilustrativa para aquellos alumnos

que deseen implementar un agente SNMP para sus propios proyectos. Si el lector ha llegado hasta aquí de

manera exitosa, le transmito mucho ánimo para su proyecto de aquí en adelante.

7.2. Desarrollos futuros

A continuación, se exponen ideas de mejora y desarrollo que han estado en mente, pero por cuestión de tiempo

no se han podido llevar a cabo.

Desde el primer momento se planteó que el funcionamiento del agente se mantuviera ajeno al manejo de los

scripts de gestión de los sensores. Esto planteaba un tremendo potencial a la hora de distribuir el desarrollo en

dos variantes específicas, una centrada en el desarrollo y mejora del agente SNMP; y otra centrada en la mejora

de la funcionalidad en el manejo de los sensores en términos de homogeneidad del fabricante, del tipo de sensor

o del circuito usado. Por ello, en el momento en el que tome este proyecto un equipo de dos personas, se podría

convertir los actuales scripts en scripts “multiplataforma” (para múltiples sensores diversos).

Así mismo, quedó en mente el desarrollo de una interfaz gráfica en el equipo donde trabaja el agente SNMP

mediante el uso de una página web y el servidor Apache. De esta manera se podría supervisar el estado del

terrario de manera atractiva mediante acceso web y proporcionar algunas funcionalidades de gestión sobre el

mismo sistema.

Siguiendo con las ideas expuestas en cuanto a la programación multihilo en el proyecto, se ha marcado el

objetivo de generar hilos para atender peticiones SNMP de manera individual. De esta manera, se hace posible

atender peticiones simultáneas provenientes de diferentes orígenes o de múltiples peticiones sistemáticas.

Como continuación del punto anterior, se establece la idea de la creación de un Manager SNMP que permita

mostrar a un usuario información y recopilar información en una base de datos remota. Así mismo, esta

funcionalidad permitiría a un técnico encontrar fallos de funcionamiento y arreglar el sistema para un futuro

cliente. Además, siguiendo la creciente tendencia de ciertas empresas en crear dispositivos “tontos” que

desarrollan tareas sencillas mientras un único equipo inteligente gestionar esos dispositivos y realiza tareas más

49


complejas, se marca este objetivo como más interesante.

Para esa comunicación producido entre el propietario del sistema y el equipo se marca la creación de una red

VPN que conecte un Manager SNMP funcionando en un Smartphone, por ejemplo, con el equipo agente.

Incluso se marca para el futuro la adaptación del funcionamiento del agente de manera individual hacia un

funcionamiento en cooperación con otros agentes del mismo tipo en una red más grande para monitorización a

mayor escala.

Referencias

50

REFERENCIAS

[1] Severance, C. (2013). Eben upton: Raspberry pi. Computer, 46(10), 14-16.

[2] Frueh, Andrew. (2017). GardenBot Org. [online] GardenBot. Available at: http://www.gardenbot.

[3] Industries, A. (2017). Adafruit Industries, Unique & fun DIY electronics and kits. Adafruit.com. Retrieved

from https://www.adafruit.com/.

[4] Raspberrypi.org. (2017). GPIO: Raspberry Pi Models A and B - Raspberry Pi Documentation. [online]

Available at: https://www.raspberrypi.org/documentation/usage/gpio/ [Accessed 13 Feb. 2017].

[5] Microjpm.com. (2017). Relay SRD-05VDC-SL-C / SPDT / 5VDC :: Micro JPM. [online] Available at:

http://www.microjpm.com/products/relay-srd-05vdc-sl-c-spdt-5vdc [Accessed 13 Feb. 2017].

[6] GitHub. (2017). janheise/TSL2561. [online] Available at: https://github.com/janheise/TSL2561 [Accessed

13 Feb. 2017].

[7] GitHub. (2017). adafruit/Adafruit_Python_DHT. [online] Available at:

https://github.com/adafruit/Adafruit_Python_DHT [Accessed 13 Feb. 2017].

[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and Waldbusser, S., "Structure of

Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[9] Case, J., McCloghrie, K., Rose, M. and Waldbusser, S., "Structure of Management Information for version

2 of the Simple Network Management Protocol (SNMPv2)”, RFC1442, April 1993.

[10] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance

Statements for SMIv2", STD 58, RFC 2580, April 1999.

[11] Ilya Etingof, Pysnmp.sourceforge.net. (2017). Documentation — PySNMP. [online] Available at:

http://pysnmp.sourceforge.net/docs/tutorial.html [Accessed 13 Feb. 2017].

[12] Burger, A. (2017). Net-SNMP. [online] Net-snmp.org. Available at: http://www.net-snmp.org/ [Accessed

13 Feb. 2017].

[13] Charbonneau, Neal. “Writing an SNMP Agent With a Custom MIB Using Pysnmp”. February 2013.

(http://www.nealc.com/blog/blog/2013/02/23/writing-an-snmp-agent-with-a-custom-mib-using-pysnmp)

11

ANEXOS

Anexo A: Módulo TERRARIO-MIB

TERRARIO-MIB DEFINITIONS ::= BEGIN

IMPORTS

OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, IpAddress,

Integer32, Counter32, enterprises FROM SNMPv2-SMI

OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE FROM SNMPv2-

CONF;

terrarioproject MODULE-IDENTITY

LAST-UPDATED "201702051400Z"

ORGANIZATION "Wildlife Pi"

CONTACT-INFO "Daniel Rodriguez Leon

[email protected]

Sevilla, Espana.

Febrero, 2017."

DESCRIPTION "Este modulo MIB recoge los OIDs necesarios

para la creacion de un proyecto TFG que

desarrolla una aplicacion de

monitorizacion de un terrario.

Desarrollado por Daniel Rodriguez Leon.

Universidad de Sevilla. 2017."

REVISION "201702051400Z"

DESCRIPTION "Cuarta Version - modificada para "

REVISION "201701071600Z"

DESCRIPTION "Tercera version - completados algunos detalles."

REVISION "201612101600Z"

DESCRIPTION "Segunda version - estructura mas compleja con

ramas."

REVISION "201610041600Z"

DESCRIPTION "Primera version - estructura plana sin ramas."

::= enterprises 54321

Anexos

12

12

-- nombres de grupos

generalConfig OBJECT IDENTIFIER ::= terrarioproject 1

sensorLuzConfig OBJECT IDENTIFIER ::= terrarioproject 2

sensorTemperaturaHumedadConfig OBJECT IDENTIFIER ::= terrarioproject 3

bombillaLuzConfig OBJECT IDENTIFIER ::= terrarioproject 4

-- definicion de grupos

terrarioGroup OBJECT-GROUP

OBJECTS agenteUpTime,

localizacion,

versionSoftware,

disponibilidadSensorLuz,

disponibilidadSensorTH,

disponibilidadBombillaLuz,

resetAgente,

envioTraps,

destinoIPTraps,

destinoPortTraps,

modeloSensorLuz,

estadoSensorLuz,

luzInfrarroja,

lux,

luzVisible,

luminosidad,

modeloSensorTH,

estadoSensorTH,

temperatura,

maxTemperatura,

minTemperatura,

humedad,

maxHumedad,

minHumedad,

13


potenciaBombillaLuz,

estadoBombillaLuz,


STATUS current

DESCRIPTION "Grupo de configuracion general."


notificacionesGroup NOTIFICATION-GROUP

NOTIFICATIONS trapMaxTemperatura,

trapMinTemperatura,

trapMaxHumedad,

trapMinHumedad

STATUS current

DESCRIPTION "Grupo de notificaciones."


-- modulo de conformidad

terrarioCompliance MODULE-COMPLIANCE

STATUS current

DESCRIPTION "Modulo de conformidad del proyecto."

MODULE

MANDATORY-GROUPS terrarioGroup,

notificacionesGroup


agenteUpTime OBJECT-TYPE

SYNTAX Counter32

UNITS "Segundos"

MAX-ACCESS read-only

STATUS current

DESCRIPTION "Tiempo de funcionamiento del agente."

::= generalConfig 1

localizacion OBJECT-TYPE

SYNTAX OCTET STRING

Anexos

14

14

MAX-ACCESS read-write

STATUS current

DESCRIPTION "Lugar donde esta emplazado el terrario."

::= generalConfig 2

versionSoftware OBJECT-TYPE

SYNTAX OCTET STRING


STATUS current

DESCRIPTION "Version actual del software."

::= generalConfig 3

disponibilidadSensorLuz OBJECT-TYPE

SYNTAX Integer32 (0..1)


STATUS current

DESCRIPTION "Muestra con un '1' que el dispositivo esta

disponible o un '0' en caso contrario."

::= generalConfig 4

disponibilidadSensorTH OBJECT-TYPE



STATUS current



::= generalConfig 5

disponibilidadBombillaLuz OBJECT-TYPE



STATUS current



::= generalConfig 6

resetAgente OBJECT-TYPE



15


STATUS current

DESCRIPTION "Permite reiniciar el servicio agente snmp

poniendo el valor '1'."

::= generalConfig 7

envioTraps OBJECT-TYPE



STATUS current

DESCRIPTION "Este objeto permite indicar si se desean enviar

traps a la maquina indicada por destinoIPTraps ('1') o no se debe permitir

que se envien ('0'). Cuando esta desativado ('0'), los traps se envian

a la maquina donde esta funcionando el agente."

::= generalConfig 8

destinoIPTraps OBJECT-TYPE

SYNTAX IpAddress


STATUS current

DESCRIPTION "Indica a que maquina se deben enviar los traps.

Necesita que se pase una direccion IP correcta. Si el objeto 'envioTraps'

contiene el valor ('0'), los traps se envian a la maquina donde esta

funcionando el agente. Si no se indica ninguna direccion IP, los traps

se envian a la maquina donde esta funcionando el agente."

DEFVAL '7f000001'H -- 127.0.0.1

::= generalConfig 9

destinoPortTraps OBJECT-TYPE



STATUS current

DESCRIPTION "Indica a que puerto de la maquina se deben

enviar los traps. Necesita que se pase un puerto correcto, (1-65535)."

::= generalConfig 10

-- rama sensorLuzConfig

modeloSensorLuz OBJECT-TYPE

SYNTAX OCTET STRING


STATUS current

Anexos

16

16

DESCRIPTION "Tipo de sensor de luminosidad (referencia o

nombre)"

::= sensorLuzConfig 1

estadoSensorLuz OBJECT-TYPE



STATUS current

DESCRIPTION "Estado de funcionamiento del sensor. Se puede

indicar que se inicie '1' o que pare '0'."


luzInfrarroja OBJECT-TYPE

SYNTAX Integer32


STATUS current

DESCRIPTION "Cantidad de luz infrarroja medida por el sensor

de luminosidad."


lux OBJECT-TYPE

SYNTAX Integer32

UNITS "Lux"


STATUS current

DESCRIPTION "Cantidad de luz Lux (lumenes/m2 SI) medida por

el sensor de luminosidad."


luzVisible OBJECT-TYPE

SYNTAX Integer32


STATUS current

DESCRIPTION "Cantidad de luz visible medida por el sensor de

luminosidad."


17


luminosidad OBJECT-TYPE

SYNTAX Integer32


STATUS current

DESCRIPTION "Cantidad de luminosidad medida por el sensor de

luminosidad."


-- rama sensorTemperaturaHumedadConfig

modeloSensorTH OBJECT-TYPE

SYNTAX OCTET STRING


STATUS current

DESCRIPTION "Modelo de sensor de temperatura y humedad."

::= sensorTemperaturaHumedadConfig 1

estadoSensorTH OBJECT-TYPE



STATUS current

DESCRIPTION "Estado de funcionamiento del sensor. Se puede

indicar que se inicie '1' o que pare '0'."


temperatura OBJECT-TYPE

SYNTAX Integer32

UNITS "grados C"


STATUS current

DESCRIPTION "Temperatura medida por el sensor."


maxTemperatura OBJECT-TYPE

SYNTAX Integer32

UNITS "grados C"

Anexos

18

18


STATUS current

DESCRIPTION "Temperatura maxima aceptable. Cuando se

sobrepasa este limite se envia un Trap."


trapMaxTemperatura NOTIFICATION-TYPE

STATUS current

DESCRIPTION "Notificacion para cuando se sobrepasa la

Temperatura Max."


minTemperatura OBJECT-TYPE

SYNTAX Integer32

UNITS "grados C"


STATUS current

DESCRIPTION "Temperatura minima aceptable. Cuando se

sobrepasa este limite se envia un Trap."


trapMinTemperatura NOTIFICATION-TYPE

STATUS current

DESCRIPTION "Notificacion para cuando se sobrepasa la

Temperatura Min."


humedad OBJECT-TYPE

SYNTAX Integer32

UNITS "%"


STATUS current

DESCRIPTION "Humedad medida por el sensor."


maxHumedad OBJECT-TYPE

SYNTAX Integer32

UNITS "%"

19



STATUS current

DESCRIPTION "Humedad maxima aceptable. Cuando se sobrepasa

este limite se envia un Trap."


trapMaxHumedad NOTIFICATION-TYPE

STATUS current

DESCRIPTION "Notificacion para cuando se sobrepasa la Humedad

Max."


minHumedad OBJECT-TYPE

SYNTAX Integer32

UNITS "%"


STATUS current

DESCRIPTION "Humedad minima aceptable. Cuando se sobrepasa

este limite se envia un Trap."


trapMinHumedad NOTIFICATION-TYPE

STATUS current

DESCRIPTION "Notificacion para cuando se sobrepasa la Humedad

Min."


-- rama bombillaLuzConfig

potenciaBombillaLuz OBJECT-TYPE

SYNTAX Integer32

UNITS "W"


STATUS current

DESCRIPTION "Potencia de la bombilla en W (vatios)."

::= bombillaLuzConfig 1

estadoBombillaLuz OBJECT-TYPE


Anexos

20

20


STATUS current

DESCRIPTION "Estado de la bombilla de luz, '0' es apagado y

'1' es encendido."


temporizadorBombillaEncendida OBJECT-TYPE

SYNTAX Integer32

UNITS "Minutos"


STATUS current

DESCRIPTION "Se inicia un temporizador que mantenga la

bombilla encendida un periodo de tiempo en MINUTOS mayor que 0. Si la

bombilla estaba previamente encendida, el temporizador se inicia

igualmente y al terminar el periodo de tiempo la bombilla se apaga."


END

Anexo B: Plan de Pruebas

Las pruebas serán realizadas en dos equipos. Un equipo será el propio del agente SNMP (Equipo A). El otro

equipo, un equipo situado en la misma subred del agente SNMP, con IP 192.168.1.151 (Equipo B). En este

equipo se realizará la configuración para servidor de traps descrita en la memoria del TFG.

En el Equipo B se necesita tener el fichero TERRARIO-MIB en el directorio $HOME/.snmp/mibs y el

archivo snmptrapd.conf configurado acorde a la memoria TFG.

21


Nombre Ejecución snmpwalk. ID

Prueba

P01B

Propósito Realizar un snmpwalk sobre el agente SNMP. Espera recibir información de

todos los OIDs del módulo TERRARIO-MIB. Usa tanto la comunidad “public”

como “private” y “otra”.

Prerrequisitos En el Equipo A, ejecutar el programa del agente con el comando

sudo ./agente-snmp_pyv3-int.py

Pasos Ejecutar el comando en el Equipo B:

snmpwalk -v 2c -m +TERRARIO-MIB -c public 192.168.1.110

1.3.6.1.4.1.54321

Esperar la respuesta.

Segundo comando:

snmpwalk -v 2c -m +TERRARIO-MIB -c private 192.168.1.110

1.3.6.1.4.1.54321


Tercer comando:

snmpwalk -v 2c -m +TERRARIO-MIB -c otra 192.168.1.110 1.3.6.1.4.1.54321


Criterio Para los dos primeros comandos: el Equipo A debe responder al B y mostrar los

Anexos

22

22

OIDs del módulo, así como sus valores. El agente debe registrar las peticiones

en el log.

Para el tercer comando: el Equipo A NO debe responder al B. El agente NO debe

registrar la petición en el log.

Resultado Funciona No Funciona

Archivo de log P01B.log Archivo log de trap

Nombre snmpget con nombres de OID. ID

Prueba

P02B

Propósito Realizar una petición GetRequest con la herramienta snmpget para cada OID

individual del módulo TERRARIO-MIB. Se puede usar tanto la comunidad

“public” como “private” indiferentemente.



Pasos Tomar la siguiente lista de nombre identificadores de los OIDs del módulo:

TERRARIO-MIB::agenteUpTime.0


TERRARIO-MIB::versionSoftware.0

TERRARIO-MIB::disponibilidadSensorLuz.0

TERRARIO-MIB::disponibilidadSensorTH.0

TERRARIO-MIB::disponibilidadBombillaLuz.0

TERRARIO-MIB::resetAgente.0

TERRARIO-MIB::envioTraps.0

TERRARIO-MIB::destinoIPTraps.0

TERRARIO-MIB::destinoPortTraps.0

TERRARIO-MIB::modeloSensorLuz.0


TERRARIO-MIB::luzInfrarroja.0

TERRARIO-MIB::lux.0

TERRARIO-MIB::luzVisible.0

TERRARIO-MIB::luminosidad.0

TERRARIO-MIB::modeloSensorTH.0


TERRARIO-MIB::temperatura.0

TERRARIO-MIB::maxTemperatura.0

TERRARIO-MIB::minTemperatura.0

23


TERRARIO-MIB::humedad.0

TERRARIO-MIB::maxHumedad.0

TERRARIO-MIB::minHumedad.0

TERRARIO-MIB::potenciaBombillaLuz.0

TERRARIO-MIB::estadoBombillaLuz.0

TERRARIO-MIB::temporizadorBombillaEncendida.0

Tomar el siguiente comando con la variable <nombre>:

snmpget -v 2c -m +TERRARIO-MIB -c public 192.168.1.110 <nombre>

Ejecutar el comando anterior sustituyendo <nombre> por cada elemento de la

lista de nombres previamente dada. Esperar la respuesta del agente.

Criterio El agente responde con el valor del OID para cada caso. El agente debe registrar

las peticiones en el log.



Nombre snmpget con identificadores numéricos. ID

Prueba

P03B

Propósito Realizar una petición GetRequest con la herramienta snmpget en cada OID

individual del módulo TERRARIO-MIB en su formato numérico. Se puede usar

tanto la comunidad “public” como “private” indiferentemente.



Pasos Tomar la siguiente lista de identificadores numéricos de los OIDs del módulo:

.1.3.6.1.4.1.54321.1.1.0

.1.3.6.1.4.1.54321.1.2.0

.1.3.6.1.4.1.54321.1.3.0

.1.3.6.1.4.1.54321.1.4.0

.1.3.6.1.4.1.54321.1.5.0

.1.3.6.1.4.1.54321.1.6.0

.1.3.6.1.4.1.54321.1.7.0

.1.3.6.1.4.1.54321.1.8.0

.1.3.6.1.4.1.54321.1.9.0

.1.3.6.1.4.1.54321.1.10.0

.1.3.6.1.4.1.54321.2.1.0

Anexos

24

24

.1.3.6.1.4.1.54321.2.2.0

.1.3.6.1.4.1.54321.2.3.0

.1.3.6.1.4.1.54321.2.4.0

.1.3.6.1.4.1.54321.2.5.0

.1.3.6.1.4.1.54321.2.6.0

.1.3.6.1.4.1.54321.3.1.0

.1.3.6.1.4.1.54321.3.2.0

.1.3.6.1.4.1.54321.3.3.0

.1.3.6.1.4.1.54321.3.4.0

.1.3.6.1.4.1.54321.3.6.0

.1.3.6.1.4.1.54321.3.8.0

.1.3.6.1.4.1.54321.3.9.0

.1.3.6.1.4.1.54321.3.11.0

.1.3.6.1.4.1.54321.4.1.0

.1.3.6.1.4.1.54321.4.2.0

.1.3.6.1.4.1.54321.4.3.0


snmpget -v 2c -m +TERRARIO-MIB -c public 192.168.1.110 <identificador>

Ejecutar el comando anterior sustituyendo <identificador> por cada elemento de

la lista de identificadores previamente dada. Esperar la respuesta del agente.

Criterio El agente responde con el valor del OID. El agente debe registrar las peticiones

en el log.



Nombre snmpset con nombres de OID y comunidad public. ID

Prueba

P04B

Propósito Realizar una petición SetRequest con la herramienta snmpset en cada OID

modificable del módulo TERRARIO-MIB, con la comunidad que no permite la

modificación del valor de los OIDs.



Pasos Tomar la siguiente lista de nombre identificadores de los OIDs del módulo que

son modificables:

25



















snmpset -v 2c -m +TERRARIO-MIB -c public 192.168.1.110 <nombre>

<tipo> <valor>

O el comando del script script-test.sh

./ script-test.sh set public <nombre> <tipo> <valor>


lista de nombres previamente dada. Para modificar el valor se debe dar un valor

y un tipo adecuados a cada uno de los OIDs. La comunidad “public” no tiene

permisos de modificación para el agente.

Esperar la respuesta del agente.

Criterio El agente responde con el mensaje de error de modificación. El agente NO debe

registrar las peticiones en el log.


Archivo de log Archivo log de trap

Anexos

26

26

Nombre snmpset con nombres de OID y comunidad private. ID

Prueba

P05B

Propósito Realizar una petición SetRequest con la herramienta snmpset en cada OID

modificable del módulo TERRARIO-MIB. con la comunidad que sí permite la

modificación del valor de los OIDs.




son modificables:


















snmpset -v 2c -m +TERRARIO-MIB -c private 192.168.1.110 <nombre>

<tipo> <valor>



y un tipo adecuados a cada uno de los OIDs. La comunidad “private” sí tiene

permisos de modificación para el agente.


Criterio El agente responde con el nuevo valor del OID. El agente debe registrar las

peticiones en el log con el valor nuevo.

27




Nombre snmpset con nombres de OID de nivel read-only. ID

Prueba

P06B

Propósito Realizar una petición SetRequest con la herramienta snmpset en cada OID NO

modificable del módulo TERRARIO-MIB. En este caso, se debe comprobar con

la comunidad “private”.




NO son modificables:

TERRARIO-MIB::agenteUpTime.0

TERRARIO-MIB::versionSoftware.0

TERRARIO-MIB::sensorLuz.0

TERRARIO-MIB::sensorTemperaturaHumedad.0

TERRARIO-MIB::bombillaLuz.0

TERRARIO-MIB::luzInfrarroja.0

TERRARIO-MIB::lux.0

TERRARIO-MIB::luzVisible.0

TERRARIO-MIB::luminosidad.0

TERRARIO-MIB::temperatura.0

TERRARIO-MIB::humedad.0


snmpset -v 2c -m +TERRARIO-MIB -c private 192.168.1.110 <nombre>.0

<tipo> <valor>



y un tipo adecuados a cada uno de los OIDs.


Criterio El agente responde con el mensaje de OID no modificable. El agente NO debe

registrar las peticiones en el log.

Anexos

28

28



Nombre snmpget con OID no accesibles. ID

Prueba

P07B

Propósito Realizar una petición GetRequest a los OIDs del módulo que son no accesible

por su definición.



Pasos Tomar la lista de OIDs no accesibles del módulo:

generalConfig

dispositivosDisponibles

sensorLuzConfig

funcionalidadesSensorLuz

sensorTemperaturaHumedadConfig

funcionalidadesSensorTH

bombillaLuzConfig

terrarioGroup

terrarioCompliance

notificacionesGroup

Ejecutar el comando en el Equipo B:

snmpget -v 2c -m +TERRARIO-MIB -c public 192.168.1.110 <nombre>


lista de nombres previamente dada. Esperar la respuesta.

Criterio Al realizar la petición, la respuesta del agente debe ser “No Such Object available

on this agent at this OID”. El agente NO debe registrar las peticiones en el log.



Nombre snmpget a los elementos de tipo notificación. ID

Prueba

P08B

29


Propósito Realizar una petición GetRequest a los OIDs del módulo que son de tipo

notificación (traps). Se puede usar tanto la comunidad “public” como “private”

indiferentemente.



Pasos Tomar la lista de OIDs de traps del módulo:

trapMaxTemperatura

trapMinTemperatura

trapMaxHumedad

trapMinHumedad


snmpget -v 2c -m +TERRARIO-MIB -c private

192.168.1.110 <nombre>


lista de nombres previamente dada. Esperar la respuesta.

Criterio Al realizar la petición, la respuesta del agente debe ser “No Such Object available

on this agent at this OID”. El agente NO debe registrar las peticiones en el log.



Nombre Reiniciar el agente. ID

Prueba

P09B

Propósito Realizar una petición SetRequest con la herramienta snmpset al OID

“resetAgente” del módulo TERRARIO-MIB con tipo “i” (integer) y valor “1”. La

comunidad debe ser “private”.



Pasos Primero, ejecutar el comando en el Equipo B:


192.168.1.110 TERRARIO-MIB::agenteUpTime.0

Esperar la respuesta. Anotar el valor dado.

A continuación, proceder al reinicio del agente:


TERRARIO-MIB::resetAgente.0 i 1

Anexos

30

30

Esperar 10 segundos.

Ahora, volver a ejecutar el comando:


192.168.1.110 TERRARIO-MIB::agenteUpTime.0

Comparar con el valor anotado. Confirmar que el agente ha sido reiniciado.

Criterio El agente al reiniciarse muestra un valor de tiempo de funcionamiento menor que

el previo al reinicio.



Nombre Recepción de traps en Equipo B. ID Prueba P10B

Propósito Configurar ambos equipos A y B para el envío de traps de A hacia B y controlar el registro

de dichos sucesos mediante sus archivos de log.

Prerrequisi

tos

En el Equipo A, ejecutar el programa del agente con el comando


En el Equipo B, configurar la herramienta snmptrapd acorde a la sección 5 de la memoria

e iniciarla de la manera indicada en la misma. Para este caso, en la línea “[snmp] logOption

f ” se debe indicar un fichero en el sistema.

Pasos Primero, asegurarse que el envío de traps está activo en el Equipo A con envioTraps valor

‘1’ y que el valor de destinoIPTraps es la IP del Equipo B.


TERRARIO-MIB::envioTraps.0 i 1


TERRARIO-MIB::destinoIPTraps.0 a 192.168.1.151

Se supone que la configuración de envío de traps está por defecto en los puertos 161 para

el envío y el 162 para recepción.

Segundo, se prepara al agente para que envíe un trap de cada tipo. Para ello, se marcan unos

valores máximos y mínimos acorde con la temperatura y humedad actuales pero que

provoquen el envío de los traps. Por ejemplo, con 20 ºC y 40% humedad, se establecen:

31


TERRARIO-MIB::maxTemperatura.0 = 10

TERRARIO-MIB::minTemperatura.0 = 30

TERRARIO-MIB::maxHumedad.0 = 20

TERRARIO-MIB::minHumedad.0 = 70



TERRARIO-MIB::maxTemperatura.0 i 10 TERRARIO-

MIB::minTemperatura.0 i 30 TERRARIO-MIB::maxHumedad.0 i

20 TERRARIO-MIB::minHumedad.0 i 70

Ahora, para seguir el log del agente y el log del servidor de traps ejecutamos el siguiente

comando en ambos equipos, con sus respectivos ficheros de log sustituyendo <archivo-

log>:

tail -f < archivo-log>

Esperar la recepción de los traps en Equipo B.

Criterio El log del agente debe registrar el envío de los traps. El log del Equipo B debe registrar la



Archivo de

log

P10B.log Archivo log de trap P10B-trap.log

Nombre Recepción de traps en Equipo B y puerto diferente. ID

Prueba

P11B

Propósito Continuar la prueba anterior P10B que consistía en configurar ambos equipos A

y B para el envío de traps de A hacia B y controlar el registro de dichos sucesos

mediante sus archivos de log. En este caso, el puerto destino de los traps será

modificado en destinoPortTraps. Además, se reiniciará la herramienta snmtrapd

en Equipo B con una nueva configuración.

Prerrequisitos Realizar la prueba anterior P10B.


snmpset -v 2c -m +TERRARIO-MIB -c private

192.168.1.110 TERRARIO-MIB::envioTraps i 0

Y el comando:


192.168.1.110 TERRARIO-MIB:: destinoPortTraps i

9999

Ahora, consultar el PID de snmptrapd del log en el Equipo B y matar el proceso

Anexos

32

32

con dicho PID con sudo killall snmptrapd

Iniciar snmptrapd de la siguiente manera indiciando el nuevo puerto de

recepción:

snmptrapd -A udp:9999




Esperar la recepción de traps en el Equipo B.

Criterio El log del agente debe registrar el envío de los traps. El log del Equipo B debe

registrar la recepción de los traps indicando su tipo y valor.


Archivo de log P11B.log Archivo log de trap P11B-trap.log

Nombre Recepción de traps en Equipo B y paro del envío. ID

Prueba

P12B

Propósito El propósito es cortar el envío de traps cambiando el valor de envioTraps durante

el envío de traps.

Prerrequisitos Realizar la prueba P10B.

Pasos Dado el escenario de la prueba P10B y asumiendo que se están enviando traps

en este momento, ejecutar el comando en el Equipo B:



Esperar el cambio de comportamiento en el agente.

Criterio El log del Equipo B deja de registrar la recepción de traps y el log del Equipo A

deja de registrar el envío de los mismos.



Nombre Paro de funcionamiento de sensor luz. ID

Prueba

P13B

Propósito Parar el funcionamiento del sensor de luz, previamente funcionando,

modificando el valor de estadoSensorLuz.

33




Asegurarse que el OID estadoSensorLuz tiene el valor ‘1’.



192.168.1.110 TERRARIO-MIB::estadoSensorLuz i 0


Ahora ejecutar:


192.168.1.110 TERRARIO-MIB::estadoSensorLuz.0

Esperar la segunda respuesta del agente.

Criterio En las dos respuestas del agente, el OID estadoSensorLuz tiene el valor ‘0’.



Nombre Paro de funcionamiento de sensor luz y puesta en

funcionamiento. ID

Prueba

P14B

Propósito Continuar el escenario de la prueba anterior P13B y cambiar de nuevo el valor

de estadoSensorLuz a ‘1’.


Pasos Continuando el escenario de la prueba P13B, ejecutar el comando en el Equipo

B:


192.168.1.110 TERRARIO-MIB::estadoSensorLuz i 1


Ahora ejecutar:


192.168.1.110 TERRARIO-MIB::estadoSensorLuz.0


Criterio En las dos respuestas del agente, el OID estadoSensorLuz tiene el valor ‘1’.



Nombre Paro de funcionamiento de sensor temperatura y humedad. ID P15B

Anexos

34

34

Prueba

Propósito Parar el funcionamiento del sensor de temperatura y humedad, previamente

funcionando, modificando el valor de estadoSensorTH.



Asegurarse que el OID estadoSensorTH tiene el valor ‘1’.



192.168.1.110 TERRARIO-MIB::estadoSensorTH i 0


Ahora ejecutar:


192.168.1.110 TERRARIO-MIB::estadoSensorTH.0


Criterio En las dos respuestas del agente, el OID estadoSensorTH tiene el valor ‘0’.



Nombre Paro de funcionamiento de sensor temperatura y humedad

y puesta en funcionamiento. ID

Prueba

P16B

Propósito Continuar el escenario de la prueba anterior P15B y cambiar de nuevo el valor

de estadoSensorTH a ‘1’.


Pasos Continuando el escenario de la prueba P15B, ejecutar el comando en el Equipo

B:


192.168.1.110 TERRARIO-MIB::estadoSensorTH i 1


Ahora ejecutar:


192.168.1.110 TERRARIO-MIB::estadoSensorTH.0


Criterio En las dos respuestas del agente, el OID estadoSensorTH tiene el valor ‘1’.


35



Nombre Cambiar el valor máximo de temperatura aceptable a uno

no válido. ID

Prueba

P17B

Propósito El sensor de temperatura y humedad toma lecturas en un rango de temperaturas

de -40ºC a 80ºC. Por lo tanto, los OID que marcan la temperatura

máxima/mínima aceptable tienen que encontrarse dentro de este rango. En esta

prueba se intentarán introducir valores de temperatura fuera de este rango.





192.168.1.110 TERRARIO-MIB::maxTemperatura.0 i 90


Segundo, ejecutar este otro comando en Equipo B:


192.168.1.110 TERRARIO-MIB::maxTemperatura.0 i -60


Criterio Las respuestas, en sus valores devueltos, deben devolver el valor original que

tenía el OID como si no hubiera sido modificado.



Nombre Cambiar el valor mínimo de temperatura aceptable a uno

no válido. ID

Prueba

P18B

Propósito El sensor de temperatura y humedad toma lecturas en un rango de temperaturas

de -40ºC a 80ºC. Por lo tanto, los OID que marcan la temperatura

máxima/mínima aceptable tienen que encontrarse dentro de este rango. En esta

prueba se intentarán introducir valores de temperatura fuera de este rango.





192.168.1.110 TERRARIO-MIB::minTemperatura.0 i 90

Anexos

36

36




192.168.1.110 TERRARIO-MIB::minTemperatura.0 i -60






Nombre Cambiar el valor máximo de humedad aceptable a uno no

válido. ID

Prueba

P19B

Propósito El sensor de temperatura y humedad toma lecturas en un rango de humedad de

0% a 100%. Por lo tanto, los OID que marcan la humedad máxima/mínima

aceptable tienen que encontrarse dentro de este rango. En esta prueba se

intentarán introducir valores de humedad fuera de este rango.





192.168.1.110 TERRARIO-MIB::maxHumedad.0 i 110




192.168.1.110 TERRARIO-MIB::maxHumedad.0 i -20






37


Nombre Cambio de valor mínimo de humedad aceptable a uno no

válido. ID

Prueba

P20B

Propósito El sensor de temperatura y humedad toma lecturas en un rango de humedad de

0% a 100%. Por lo tanto, los OID que marcan la humedad máxima/mínima

aceptable tienen que encontrarse dentro de este rango. En esta prueba se

intentarán introducir valores de humedad fuera de este rango.





192.168.1.110 TERRARIO-MIB::minHumedad.0 i 110




192.168.1.110 TERRARIO-MIB::minHumedad.0 i -20






Nombre Cambar el estado de la bombilla, apagado y encendido. ID

Prueba

P21B

Propósito Hacer dos cambios de valor del OID estadoBombillaLuz que determina el estado

de la bombilla, primero apagándola y luego encendiéndola.



En el Equipo B, ejecutar


192.168.1.110 TERRARIO-MIB::estadoBombillaLuz.0 i 1

y comprobar que la bombilla está encendida.


Anexos

38

38



Esperar la respuesta. Comprobar que la bombilla se ha apagado.

Ahora, ejecutar:



Esperar la respuesta. Comprobar que la bombilla se ha vuelto a encender.

Criterio La bombilla se apaga con el primer comando y se enciende con el segundo.



Nombre Apagado de bombilla y poner temporizador a 3 minutos. ID

Prueba

P22B

Propósito



Apagar la bombilla:



Pasos Ejecutar el comando en el Equipo B para poner el temporizador a 3 minutos:


192.168.1.110 TERRARIO-

MIB::temporizadorBombillaEncendida.0 i 3

Esperar 1 minuto y consultar el temporizador y el estado de la bombilla:

snmpget -m +TERRARIO-MIB -v 2c -c private

192.168.1.110 temporizadorBombillaEncendida.0


192.168.1.110 estadoBombillaLuz.0

Esperar 2 minutos y consultar el temporizador y el estado de la bombilla:





39


Criterio La bombilla se mantiene encendida hasta que pasan 3 minutos. El temporizador

va disminuyendo su valor con cada minuto que pasa.



Nombre Poner un segundo temporizador para la bombilla. ID

Prueba

P23B

Propósito



Apagar la bombilla:



Pasos Programar un temporizador de bombilla a 3 minutos:


192.168.1.110 TERRARIO-


Comprobar que ciertamente, está encendida la bombilla y puesto el temporizador

a 3 minutos.





Programar un segundo temporizador con el actual aún activo.


192.168.1.110 TERRARIO-



Criterio La respuesta muestra los minutos restantes del primer temporizador y no el nuevo

valor dado. El agente debe registrar los sucesos en el log y se encontrará un

mensaje de advertencia “WARNING::Temporizado bombilla existente no

finalizado”.


Anexos

40

40


Nombre fichero de log P01B.log

11/02/2017 12:55:12 PM -- INFO::

11/02/2017 12:55:12 PM -- INFO::.

11/02/2017 12:55:12 PM -- INFO::..

11/02/2017 12:55:12 PM -- INFO::Fecha y hora de inicio 11-02-2017 12:55:12 PM

11/02/2017 12:55:12 PM -- INFO::

11/02/2017 12:55:12 PM -- INFO::'compruebagpio' pin 17 NO ENCONTRADO - result is 0

11/02/2017 12:55:13 PM -- INFO::'iniciagpio' pin17 EXPORTADO...



11/02/2017 12:55:15 PM -- INFO::Arrancando agente...

11/02/2017 12:55:15 PM -- INFO::Escrita Informacion Agente Disps...

11/02/2017 12:55:15 PM -- INFO::SensorLuz puesto a funcionar...

11/02/2017 12:55:19 PM -- INFO::SensorTH puesto a funcionar...

11/02/2017 12:55:19 PM -- INFO::'compruebagpio' pin17 ENCONTRADO...

11/02/2017 12:59:53 PM -- INFO:: Getting var...(1, 3, 6, 1, 4, 1, 54321, 1, 1, 0)


















41


































Anexos

42

42

































43







11/02/2017 01:49:45 PM -- INFO:: Testing var...(1, 3, 6, 1, 4, 1, 54321, 1, 2, 0)

11/02/2017 01:49:45 PM -- INFO:: Setting var...(1, 3, 6, 1, 4, 1, 54321, 1, 2, 0) - OTRO



11/02/2017 01:50:17 PM -- INFO:: Setting var...(1, 3, 6, 1, 4, 1, 54321, 1, 7, 0) - 0






11/02/2017 01:50:59 PM -- INFO:: Setting var...(1, 3, 6, 1, 4, 1, 54321, 1, 9, 0) -

11/02/2017 01:50:59 PM -- INFO::Nueva IP Introducida 1.1.1.1






11/02/2017 01:52:20 PM -- INFO:: Setting var...(1, 3, 6, 1, 4, 1, 54321, 2, 1, 0) - MODELO




11/02/2017 01:52:35 PM -- INFO::SensorLuz parado...







Anexos

44

44

11/02/2017 01:53:33 PM -- INFO:: Setting var...(1, 3, 6, 1, 4, 1, 54321, 3, 1, 0) - MODEL




11/02/2017 01:53:52 PM -- INFO::SensorTH parado...




11/02/2017 01:54:22 PM -- INFO::MAX T 50




11/02/2017 01:54:34 PM -- INFO::MIN T 45




11/02/2017 01:55:04 PM -- INFO::MAX H 80




11/02/2017 01:55:23 PM -- INFO::MIN H 10










11/02/2017 02:01:14 PM -- INFO::Iniciado el temporizador



45


11/02/2017 04:25:55 PM -- INFO::

11/02/2017 04:25:55 PM -- INFO::.

11/02/2017 04:25:55 PM -- INFO::..


11/02/2017 04:25:55 PM -- INFO::













11/02/2017 04:26:39 PM -- INFO::Reiniciando agente...



11/02/2017 04:26:39 PM -- INFO::Cerrando agente...

11/02/2017 04:26:44 PM -- INFO::

11/02/2017 04:26:44 PM -- INFO::.

11/02/2017 04:26:44 PM -- INFO::..


11/02/2017 04:26:44 PM -- INFO::










Anexos

46

46









11/02/2017 04:43:57 PM -- INFO::MAX T 10


11/02/2017 04:43:57 PM -- INFO::MIN T 30


11/02/2017 04:43:57 PM -- INFO::MAX H 20


11/02/2017 04:43:57 PM -- INFO::MIN H 70





11/02/2017 04:44:05 PM -- INFO::Enviado trap trapMaxTemperatura-21

11/02/2017 04:44:07 PM -- INFO::Enviado trap trapMinTemperatura-21

11/02/2017 04:44:08 PM -- INFO::Enviado trap trapMaxHumedad-52

11/02/2017 04:44:09 PM -- INFO::Enviado trap trapMinHumedad-52

Nombre fichero de log P10B-trap.log

NET-SNMP version 5.7.2.1 AgentX subagent connected

4880


<UNKNOWN> [UDP: [192.168.1.110]:161->[192.168.1.151]:162]: Trap , DISMAN-EVENT-

MIB::sysUpTimeInstance = Timeticks: (116764) 0:19:27.64, SNMPv2-MIB::snmpTrapOID.0 =

OID: TERRARIO-MIB::maxTemperatura.0, TERRARIO-MIB::temperatura = INTEGER: 21

47


grados C



OID: TERRARIO-MIB::minTemperatura.0, TERRARIO-MIB::temperatura = INTEGER: 21

grados C



OID: TERRARIO-MIB::maxHumedad.0, TERRARIO-MIB::humedad = INTEGER: 52 %



OID: TERRARIO-MIB::minHumedad.0, TERRARIO-MIB::humedad = INTEGER: 52 %












Nombre fichero de log P11B-trap.log

1406




OID: TERRARIO-MIB::maxTemperatura.0, TERRARIO-MIB::temperatura = INTEGER: 25

grados C



OID: TERRARIO-MIB::minTemperatura.0, TERRARIO-MIB::temperatura = INTEGER: 25

grados C



Anexos

48

48

OID: TERRARIO-MIB::maxHumedad.0, TERRARIO-MIB::humedad = INTEGER: 46 %



OID: TERRARIO-MIB::minHumedad.0, TERRARIO-MIB::humedad = INTEGER: 46 %






















49



















Sensor AM2302 listo!






Anexos

50

50

11/02/2017 07:38:56 PM -- INFO::MAX T 10



11/02/2017 07:39:33 PM -- INFO:: Setting var...(1, 3, 6, 1, 4, 1, 54321, 3, 4, 0) - -60

11/02/2017 07:39:33 PM -- INFO::MAX T 10






11/02/2017 07:43:55 PM -- INFO::MIN T 30




11/02/2017 07:44:00 PM -- INFO::MIN T 30






11/02/2017 07:50:53 PM -- INFO::MAX H 20




11/02/2017 07:51:03 PM -- INFO::MAX H 20


51






11/02/2017 07:53:23 PM -- INFO::MIN H 70




11/02/2017 07:53:28 PM -- INFO::MIN H 70

















11/02/2017 08:45:36 PM -- INFO::'controlminutos' en minuto 2



11/02/2017 08:47:36 PM -- INFO::APAGADA BOMBILLA EN TIEMPO: 1486842456.174689


Anexos

52

52








11/02/2017 08:28:31 PM -- WARNING::Temporizado bombilla existente no finalizado


Trabajo Fin de Grado -...

Documents

Transcript of Trabajo Fin de Grado -...