INTRODUCCION

 

 

 

Calcular el consumo de ancho de banda de un canal, permite a los administradores de red tomar decisiones que permitan optimizar el enlace y a los usuarios establecer la cantidad de ancho de banda que realmente requieren y por la que deberían pagar al proveedor del servicio. Por ejemplo, muchos usuarios de redes de “banda ancha” ya sean ADSL, Frame Relay, RDSI, etc; emplean simultáneamente la misma conexión para realizar varias tareas a la vez o para permitir la conexión de varias personas a través de ellas en el caso de redes con reuso del enlace. Con frecuencia las aplicaciones no interactivas consumen la mayor parte del ancho de banda, dicho de otra forma, la navegación o la lectura del correo deben competir contra una descarga cualquiera.

 

Una aplicación que permita determinar la cantidad de ancho de banda consumida en un enlace en tiempo real, permitiría una mejor administración de dicho enlace, asignando a cada fuente la cantidad de canal que realmente requiere en un momento dado.  Esta aplicación, propósito de este proyecto, fue desarrollado con herramientas de software libre la cual tiene una licencia GPL[1], por lo que es un aporte a la comunidad de desarrolladores de software libre, como a diferentes investigadores que deseen aportar mejoras a la misma. La aplicación utiliza la librería PCAP que permite capturar paquetes de la red y analizarlos para realizar los cálculos de ancho de banda esperados. Para la evaluación de la aplicación se utiliza un generador de tráfico denominado MGEN.

 

El trabajo comprende aspectos relacionados con el efecto del encapsulamiento, filtrado de paquetes, mecanismos de generación de tráfico, sniffers, ingeniería de software, Metodología y desarrollo del sistema, Arquitectura general del sistema, herramienta desarrollada, análisis de resultados, conclusiones y recomendaciones.

 

El desarrollo de este proyecto permite además, profundizar en diferentes conceptos relacionados con  la transmisión de datos, implementación y uso de plataformas hardware y software de experimentación, así como la filosofía del software libre.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


1.      ANTECEDENTES

 

 

 

El proyecto de investigación está enmarcado y apoyado por la línea de investigación de Redes y tecnologías Web del Grupo de Tecnologías de Información (GTI), de la Maestría en Software libre de la Universidad Oberta de Cataluña (UOC) y la Universidad Autónoma de Bucaramanga (UNAB).

 

Este proyecto está enmarcado dentro de la investigación realizada por el director en el área de estimación de ancho de banda disponible en redes de comunicaciones.

 

El proyecto estudia, experimenta y aplica diferentes herramientas de software libre para la adecuada medición y administración de anchos de banda en un enlace en donde la aplicación desarrollada, tiene una licencia de  tipo GPL cumpliendo con las libertades que dicta la Free Software Foundation, orientándolo a la comunidad académica y empresarial.

 

 

 


2.    OBJETIVOS

 

 

 

          2.1 OBJETIVO GENERAL

 

Desarrollar una herramienta de software bajo licencia GPL que mediante captura y análisis de paquetes, permita estimar la utilización en bits por segundo de un enlace de red.

 

           2.2 OBJETIVOS ESPECIFICOS

 

1.   Estudiar e identificar las estructuras de la librería Libpcap para capturar y analizar paquetes en sistemas Linux.

 

2.   Determinar los criterios de selección y establecer el lenguaje de programación en  el cual se va a implementar la aplicación.

 

3.   Establecer un testbed que permita de manera controlada generar tráfico de un host  hacia un enlace para que sea leído y analizado en otro host dentro del mismo enlace.

 


3.                  MARCO TEORICO

 

El análisis en tiempo real del ancho de banda, tiene como función brindar algunas herramientas, que permitan medir la cantidad de bits por segundo que pasan por un canal de transmisión durante un periodo de tiempo especificado (del orden de milisegundos). Generalmente cuando se va a realizar este tipo de pruebas, es necesario que no existan aplicaciones innecesarias en ejecución. Es importante anotar que el propósito de este proyecto no es medir el throughput de la conexión, que es determinado por la cantidad de bits que el protocolo de transporte coloca en el canal, dependiendo de la congestión existente en el mismo. El objetivo es medir el tráfico proveniente de cualquier conexión que pase por un canal en un periodo de tiempo.

 

Actualmente existen diferentes herramientas que permiten analizar los paquetes que viajan por la red y proporcionan información de tiempos y longitud de paquete que posibilitan el cálculo del consumo de ancho de banda a través de scripts generados por ejemplo por awk. Sin embargo, una herramienta que genere exclusivamente trazas de consumo ancho de banda sin necesidad de post-procesamiento, está aún por desarrollar y constituye la motivación del presente proyecto. 

 

La gran mayoría de herramientas que hacen análisis de encabezados de paquetes, utilizan un API (Application Programming Interface) denominado PCAP generalmente basado en el lenguaje de programación C, que permite a las aplicaciones desarrolladas capturar, hacer rastreo de paquetes y/o enviar los paquetes a la red.  Según sea la aplicación, existe una versión del API para Java llamada Jpcap, así como otra para plataforma Windows denominado winpcap. En Linux se denomina libpcap. (Cartens. 2002). Entre las principales herramientas y aplicaciones (Skwarek:45) que emplean la librería PCAP están: nmap, wireshark, ethereal, tcpdump, snort, p0f y natdet.

La estimación en tiempo real del consumo de ancho de banda en un enlace, implica por una parte  establecer la longitud exacta de los paquetes que viajan a través del enlace físico. Para ello es necesario conocer con exactitud la arquitectura de capas de Internet y la cantidad de bits que son adicionados al paquete de datos original por efectos de lo que se denomina encapsulamiento. Por otra parte, es necesario conocer la manera en que se puede realizar filtrado de paquetes que se capturan del canal de transmisión para poder extractar de su información de encabezado el valor exacto de longitud de paquete y tiempo requerido para su transmisión. Finalmente, y para efectos de experimentación en una red real, es necesario establecer un mecanismo de generación de tráfico sintético que permita evaluar la funcionalidad del estimador. El presente capitulo aborda los tres conceptos que se acaban de mencionar.

 

3.1  ENCAPSULAMIENTO TCP/IP

 

La arquitectura de Internet ubica protocolos de comunicaciones en cuatro capas [7]: aplicación, transporte, red y de enlace. Cada capa tiene funciones específicas que posibilitan el viaje de datos de una máquina origen a una destino a lo largo de diferentes sistemas de comunicaciones. Como se observa en la Figura 1, el proceso de encapsulamiento consiste en adicionar información correspondiente a la funcionalidad de cada capa. Esto implica que la información que originalmente se desea transmitir, va a ser incrementada en 54 bytes para el caso de paquetes TCP: 20 bytes de encabezado TCP, 20 bytes de encabezado IP y 14 bytes de encabezado Ethernet. Si el paquete es UDP en lugar de 20 bytes en la capa de transporte, se sustituye por 8 bytes para un total de 42 bytes. Estos valores se especifican a continuación para cada una de las capas.

 

 

 

 

 

 

Figura 1. Encapsulamiento de datos en TCP/IP.

Fuente: El Autor

 

3.1.1  Trama Ethernet

 

La cantidad de información que finalmente viaja por el canal de comunicaciones es determinada por la capa de enlace,  que se encarga de determinar la manera en que se va a accesar al medio de transmisión. El protocolo de enlace más común a nivel LAN es Ethernet. Este protocolo establecido en el estándar IEEE 802.3, tiene versiones según su velocidad de transmisión como Fast Ethernet (100 Mbps) y GigaEthernet (1/10 Gbps).

 

Mediante Ethernet, se debe tener en cuenta que existe un envió de tramas en un medio compartido, por lo que es necesario establecer mecanismos especiales de acceso al medio definidos como MAC (Control de Acceso al Medio), que según Ordinas [2], se pueden clasificar en tres grandes grupos: Control de acceso al medio estático, Control de acceso al medio dinámico y control de acceso al medio aleatorios. Pero según el tipo de topología que se use, se aplica uno u otro. Por ejemplo, en redes con topología en anillo, se usa uno de control dinámico distribuido conocido como Token Passing, si es una red con topología en bus se usa uno de tipo aleatorio como CSMA/CD (Acceso múltiple por detección de portadora / detección de colisiones), y en redes inalámbricas en entornos LAN se utilizaría uno que combina el control estático y el aleatorio. 

 

En la Figura 2, se observa el formato de la trama  siguiendo el estándar IEEE 802.3 que contiene los siguientes campos [1][3]:

 

Preámbulo (7 bytes): Permite establecer la sincronización entre el emisor y el receptor.

Delimitador del comienzo de Trama SFD (1 byte): Indica el comienzo real de la trama y permite al receptor localizar el primer bit del resto de la trama.

Dirección MAC de destino (6 bytes): Especifica la estación o estaciones a las que  va dirigida la trama.

Dirección MAC de Origen (6 bytes): Especifica la estación que envió  la trama.

Longitud (2 bytes): Contiene la longitud del campo de datos LLC (control lógico de enlace) o el campo tipo Ethernet.

Datos LLC (Variable): Es la unidad de datos proporcionado por el LLC.

Relleno: Son octetos que se añaden para asegurar que la trama sea lo suficientemente larga de manera ,  que la técnica de detección de colisiones CD funcione correctamente.

Secuencia de Comprobación de trama FCS (4 bytes): Comprobación redundante cíclica de 32 bits que se calcula desde el preámbulo, el SFD y el FCS.

 

Figura 2.  Contenido de la Trama Ethernet

 

Fuente: El autor

 


3.1.2  Protocolo IP

 

En la capa de red se encuentra el protocolo de Internet o IP. Este protocolo se encarga de determinar la ruta que van a seguir los datos del origen al destino. Este no realiza control de errores ni de flujo de datos. Es un protocolo no orientado a conexión, que intenta que la información llegue a su destino de la mejor forma posible en lo que se conoce como estrategia del mejor esfuerzo. El encabezado IP tal como se presenta en la Figura 3, tiene una longitud de 20 bytes definidos de la siguiente manera [10]:

 

Versión (4 bits): Indica el número de la versión. Su valor es 4

Longitud de Cabecera (4 bits): Es la longitud de la palabra de la cabecera llamado también IHL.

Tipo de servicio (8 bits): Esta definido en el RFC 1349, y sirve de orientación a los módulos IP de los sistemas finales y a los encaminadores existentes a lo largo de la ruta de los datagramas.

Longitud Total (16 bits): Es la longitud del fragmento

Identificación (16 bits): Es un número de secuencia que se une con la dirección origen, destino y el protocolo del usuario, para identificar un datagrama.

Banderas (3 bits): Cuando se fragmenta un datagrama, el bit indica si este es el único fragmento del datagrama original, en cambio el bit no fragmentar prohíbe la fragmentación si esta activo.

Desplazamiento de Fragmento (13 bits): Indica a que parte del datagrama original pertenece este fragmento.

Tiempo de Vida (8 bits): Indica el tiempo en segundos que se le permite a un datagrama permanecer en la interred.

Protocolo (8 bits): Indica el siguiente protocolo de alto nivel que recibirá el campo de datos en el destino.

Suma de verificación del encabezado (16 bits): Es el código de corrección de errores y se calcula en cada router.

Dirección IP de Origen (32 bits): Especifica la dirección de origen y varía según su tipo de dirección IP.

Dirección IP de Destino (32 bits): Especifica la dirección de destino y varía según su tipo de dirección IP.

Opciones (variable): Codifica las opciones requeridas por el usuario emisor.

Relleno (Variable): Garantiza que la cabecera del datagrama tiene una longitud múltiplo de 32 bits.

• Datos (Variable): El campo de datos debe tener una longitud que sea múltiplo entero de 8 bits, donde la longitud máxima del datagrama es de 65535 octetos.

 

Figura 3.  Estructura de un paquete IP

Fuente: El autor

 

La mayoría de protocolos de nivel de enlace [2], fijan una longitud máxima de datos a transmitir en una trama, que se conoce con el nombre de MTU (Maximum Transfer Unit). En el caso de Ethernet el MTU es de 1500 bytes. Cuando una estación transmite un paquete IP, conoce la MTU de su interfaz de red y esta restringida a transmitir paquetes IP cuya longitud sea inferior o igual a esta MTU. Caso contrario, el paquete debe fragmentarse. Una descripción más detallada de este protocolo se encuentra en [7]; en cuanto a los protocolos de la capa de transporte de TCP/IP, existen básicamente dos protocolos gobernantes. TCP y UDP.

 

3.1.3  Protocolo TCP

 

TCP es un protocolo orientado a la conexión que permite el intercambio fiable de información entre dos extremos de la aplicación.

 

Este protocolo esta definido con los RFC 793 [1][32],1122,1323,2018 y 2581. La cabecera TCP tiene un tamaño de 20 bytes, y a diferencia del datagrama UDP, es más complejo (ver Figura 4). A continuación se presenta los campos de los que se compone [1]:

 

Número de Puerto Origen (16 bits): Identifica la aplicación en la terminal origen

Número de Puerto Destino (16 bits): Identifica la aplicación en la terminal destino.

Número de Secuencia (32 bits): Identifica el primer byte del campo de datos que envía el segmento.

Número de ACK (32 bits)

Longitud de Cabecera (4 bits): Es la longitud de la cabecera que puede ser variable. Si se usa el campo opciones la longitud puede crecer hasta 60 bytes.

Reservado (6 bits): Es un campo reservado y se inicializa en cero.

Control o Flags (6 bits): Tiene 6 indicadores cada uno con una función especifica entre los que están: URG: Segmento urgente. Salta otros segmentos en cola. ACK: Cuando hay acuse de recibido el campo Número de ACK, indica el byte siguiente que espera recibir la conexión TCP. PHS: Los datos deben ser pasados al receptor lo antes posible. Es decir que se le indica a la pila TCP que limpie todos los buferes y transmita cualquier dato pendiente o reenvié aquellos datos a la aplicación apropiada. RST: Restaura la conexión. SYN: Sincroniza los números de secuencia para iniciar una conexión. FIN: El emisor ha terminado el envió de todos los datos [17].

Tamaño de la Ventana (16 bits): Indica cuantos bytes componen la ventana de transmisión del protocolo de control de flujo por ventana deslizante. Hay que recordar que en TCP la ventana es variable.

Checksum (16 bits): Esta operación sirve para detectar errores, y la realiza el emisor y la verifica el receptor.

Puntero de segmento urgente (16 bits): Es usado cuando la bandera URG esta activado, y se usa para hacer que todos los segmentos urgentes salten todas las colas que se puedan formar tanto en el origen como en el destino.

Opciones TCP (32 bits): Opciones especiales como marcar el timestamp, aumentar el tamaño de la ventana e indicar el tamaño máximo del segmento MSS.

 

 

Figura 4. Estructura paquete TCP

Fuente: El autor

 

Cuando se transmiten datos por el protocolo TCP, es necesario identificar dos tipos de tráfico principales, los cuales se denominan Tráfico Interactivo y tráfico Masivo según Menendez [14], “ por un lado existe un trafico caracterizado por el envió de unidades lógicas de información, cada una de las cuales esta incluida íntegramente en un segmento. Además un segmento sólo contiene una unidad de información y con una relación: tiempo de envío/tiempo no envío baja. A este tipo de tráfico se le denomina interactivo y es propio de las sesiones telnet, rexec, rlogin. El caso contrario es el tráfico Masivo, que se caracteriza por unidades de información dividida en varios segmentos, y una relación  tiempo de envío / tiempo no envío alta, es decir alto consumo del ancho de banda del medio de transmisión.  Estudios realizados sobre el tráfico TCP dan cuenta de que aproximadamente un 50% de los segmentos TCP son interactivos y el otro 50% es masivo. Pero si se cuenta el número de octetos transmitidos, las estadísticas dicen que el 90% de los octetos que viajan por una red son de tráfico masivo y el resto, es decir el 10% de tráfico interactivo.”

 

3.1.4  Protocolo UDP

 

El otro protocolo a nivel de transporte especificado en el RFC 768 [6] es UDP (User Datagram Protocol). Según Stalling [4], “este protocolo es básicamente un servicio no seguro en el que la entrega y la protección contra duplicados no están garantizadas. En contrapartida se reduce la información suplementaria del protocolo, lo que puede ser adecuado en muchos casos”.

 

Estos casos son generalmente la transmisión de datos en tiempo real como  la voz y el video, así como aplicaciones que transmiten información en modo multicast o broadcast. Kurose [1], menciona la poca sobrecarga debida a cabeceras dado que UDP solo añade 8 bytes. UDP omite parámetros como búferes de envío y recepción, control de congestión y el número de secuencia y reconocimiento de paquetes. El encabezado UDP tal como se presenta en la Figura 5, esta definido de la siguiente manera:

 

Puerto Origen y destino (16 bits): Identifica las aplicaciones en los terminales origen y destino.

Longitud (16 bits): Indica la longitud en bytes del datagrama UDP incluyendo su cabecera. La longitud máxima de un datagrama UDP es de 65515 bytes.

Checksum (16 bits): Es opcional y protege tanto la cabecera como los datos UDP. En caso de algún error se descarta el datagrama y no lo entrega a ninguna aplicación.

Figura 5. Estructura de Datagrama UDP

 

Fuente: El autor

 

3.2 TAMAÑO DE LOS PAQUETES

 

El protocolo IP permite fragmentar los paquetes si estos exceden el máximo tamaño de transmisión de un enlace, aunque esta situación no siempre es deseable, y puede generar cierta degradación en el rendimiento o inclusive problemas en la transmisión.

 

Generalmente se utiliza un mecanismo que permite controlar esta situación en el envío de información entre hosts que se denomina MTU (Unidad Máxima de Transferencia). Este fue inicialmente propuesto en el RFC1063 en 1988, y tuvo una actualización en el RFC1191 en el año de 1993[2].  El MTU funciona cuando se envían paquetes y verifica si esta activo el Flag (DF) o do not fragment, cuando el MTU es muy grande el receptor retorna un mensaje de error ICMP (Tipo 3 Código 4)[3], que indica que el paquete requiere de fragmentación, por lo tanto el emisor reduce el tamaño del MTU y retransmite el paquete al host destino para que lo acepte.

 

 

Tener un optimo MTU no es solo importante en la transmisión de paquetes sin fragmentación, también en enlaces pequeños estos pueden generar un mayor impacto en el rendimiento de la red. El MTU por defecto utilizado por los hosts es de 576 bytes[4].

 

Este MTU puede variar dependiendo del tipo de enlace a utilizar, además para poder obtener una alta tasa de throughput posible, el MTU debe ser configurado con un valor grande, típicamente de 1500 bytes, en enlaces Ethernet o en enlaces Dialup por Modems. La desventaja es que la latencia se incrementa generando sobrecarga al momento de encapsular el paquete, por lo tanto es un factor a tener en cuenta en cualquier tipo de red.  En el RFC2923  se puede encontrar varios problemas y las soluciones posibles para tener un MTU óptimo.

 

3.3 ENVIO DE DATOS EN LINUX

 

Las comunicaciones entre redes se realizan mediante el uso de modelos estructurados en capas (OSI o Modelo TCP/IP), pero desde el punto de vista de una aplicación, la comunicación se realiza mediante el uso de sockets, los cuales definen los dos extremos de una comunicación y permiten el intercambio de información entre estos dos extremos. Para permitir el uso de la red a una aplicación, Linux ofrece la interfaz BSD socket interface (Berkeley Sockets). La interfaz BSD Socket ofrece a los procesos las funciones necesarias para la comunicación vía red por medio del uso de varias primitivas.  Generalmente los sockets son puntos de conexión lógicos, los cuales pueden tener asociado un puerto generalmente definido en el RFC1700.

 

Debajo de la Interfaz BSD Socket se encuentra la capa INET Socket, que maneja los puntos extremos de la comunicación para los protocolos TCP y UDP. Esta capa se encuentra representada por la estructura de datos sock. A los sockets de la capa INET Socket se les conoce como INET Sockets.  La capa que se encuentra debajo de la Capa INET Socket viene determinada por el tipo de socket que se haya utilizado en la Capa INET Socket.

 

Concretamente se pueden encontrar las capas TCP, UDP o la capa IP directamente. La capa TCP implementa el Protocolo TCP, la capa UDP hace lo propio con el Protocolo UDP y en la capa IP se encuentra el código del Protocolo IP. En la Capa IP confluyen todos los flujos de comunicación de las capas superiores.

 

Por debajo de la Capa IP se encuentran los dispositivos de red, a los cuales la Capa IP les pasa los paquetes. Estos dispositivos son los que se encargan del transporte físico de la información. En la figura 6  puede verse que existen diferentes protocolos de nivel 2 en función del tipo de red a la que quiera conectarse. El dibujo muestra protocolos y dispositivos físicos para los Puertos Serie y Paralelo y para Redes Ethernet. Existen numerosos tipos de redes a las que Linux es capaz de conectarse, ya que implementa los protocolos de nivel 2 necesarios para utilizar estas redes y existen drivers para manejar los dispositivos físicos que permiten la conexión a estas redes. Algunos de estos tipos de redes son IEEE 802.11x, también llamadas redes WiFi (Wireless Fidelity), Fibra Óptica (FDDI), Infrarrojos (IrDa), Bluetooth, etc.

 

Figura 6.  Estructura de capas desde el punto de vista de Linux. 

 

Fuente:  M. Beck, H. Böme, M. Dziadzka, U Kunitz, R. Magnus, D. Verworner. Linux Kernel Internals 2nd Ed., Addison-Wesley Eds., pp. 1-379. (1997).

3.4  FILTRADO DE PAQUETES

 

Para realizar la captura de paquetes del canal de comunicaciones se utiliza una librería denominada PCAP. Esta es una API (Application Programming Interface) bajo licencia open source que permite a las aplicaciones desarrolladas capturar, hacer rastreo de paquetes y/o enviar los paquetes a la red. Según sea la aplicación existe una versión del API para Java llamada Jpcap, así como otra para plataforma Windows denominado winpcap. En Linux se conoce como libpcap. Esta librería desarrollada en lenguaje C permite la captura de los siguientes tipos de paquetes: Ethernet, IPv4, IPv6, ARP/RARP, TCP, UDP, e ICMPv4 sin importar el sistema operativo. Ella captura los paquetes directamente desde la tarjeta de red utilizando métodos como los descritos en BPF (Berkeley Packet Filter) [8], DLPI (Data Link Provider Interface) y SOCKET_PACKET type sockets (Solamente en Linux).

 

En Libpcap la captura real de datos tiene lugar en las capas más bajas del sistema operativo, en la llamada zona Kernel (Kernel area) [26], por lo tanto debe existir un mecanismo capaz de traspasar esta frontera, y hacerlo además de un modo eficiente y seguro, ya que cualquier fallo en capas tan profundas degradará el rendimiento de todo el sistema.  Por ejemplo si se programa una aplicación capaz de monitorizar la red en tiempo real en busca de paquetes cuyo puerto TCP origen sea el 135, si no existiese ningún mecanismo de filtrado, el Kernel no sabría cuales son los paquetes en los que esta interesada la aplicación, por lo que tendría que traspasar la frontera Kernel - User space por cada paquete que transite por la red.  La solución es que la aplicación establezca un filtro en la zona Kernel y que sólo deje pasar los paquetes cuyo puerto TCP destino sea el 135. Esta es la principal labor de un Packet/Socket Filter.

 

Para entender el funcionamiento de PCAP, [20]  indica 5 pasos esenciales para el desarrollo de cualquier aplicación:

 

 

1. Se debe empezar por determinar cual seria la interfaz que se activará para el modo sniffer, esta debe estar en modo promiscuo para facilitar la captura de los paquetes. En Linux se identificaría con algo parecido a eth0, en sistemas BSD con xl1, etc. Es además necesario definir el dispositivo en un string o dar el nombre de la Interfaz durante su ejecución.

 

2. Se debe iniciar pcap. Cuando se ingresa el identificador de la NIC, se abre un archivo que leería o escribiría los datos durante el escaneo.

 

3. Si solo se busca la captura de un tráfico especifico (e.g.: Solo paquetes TCP/IP, solo un Puerto especifico, etc) se debe crear un set de reglas, compilarlas y aplicarlas durante la ejecución. Las reglas se deben mantener en un string y estas serían convertidas en un formato que pcap pueda leer. También se leerían desde una función dentro del programa.

 

4. Cuando pcap entre en el ciclo de ejecución primario, la aplicación recibiría los paquetes de la red cada cierto tiempo. Después se llamara una función que analizara el paquete y lo mostrara al usuario, el cual podrá guardarlo o no.

5. Después de que ya se haya realizado el sniffing se cerrara la sesión.

 

Resumiendo Lopez Mongue [26] indica la esquematización (Ver Figura 7 ) que cualquier programa basado en pcap debería tener: Inicialización, Configuración de Filtros, Bucle de captura, Extracción de datos, procesado de datos y Terminación o salida, cada una con sus propias funciones y parámetros especiales.


Figura 7 . Esquematización de un programa con Libpcap [26]

Fuente: LOPEZ MONGE, Alejandro. Aprendiendo a Programar con Libpap. 2005

 

3.4.1  Funciones Principales de Libpcap

 

3.4.1.1  Selección de la Interfaz de Red. 

 

El primer paso necesario es la selección de la interfaz por la que se desean capturar los paquetes.  Para esto se emplea la función char *pcap_lookupdev(char * errbuf), la cual, encuentra la primer interfaz de red y la devuelve en forma de caracteres. El argumento errbuf es un bufer donde se almacena en caso de fallo el error cuando no falla la función.

 

Si se desea determinar los parámetros de la tarjeta de red como la dirección IP o la máscara de red se requiere de la estructura struct in_addr  addr; y después se utiliza la función int pcap_lookupnet(const char
*dev, bpf_u_int32 *net, bpf_u_int32 *mask, char *errbuf)
  que devolverá dichos valores. El primer argumento corresponde  a la cadena de la interfaz de red, el segundo y tercer parámetro son índices que respectivamente serán la dirección IP y la máscara de red. El último argumento es el índice del búfer del eventual error. En caso de falta de éxito de la función llamada, allí se introducirá el mensaje. En tal caso la función devuelve el valor exec (-1).

 

3.4.1.2  Funciones para Sniffing y Captura [16]

 

Para poder escuchar la información que circula por una red, se deben de reunir, como mínimo, dos requisitos. El primero es que la red sea de tipo broadcast. El segundo es que la tarjeta de red del usuario que quiera realizar la escucha se encuentre en modo promiscuo.

 

En la figura 8 puede observarse un escenario que cumple las dos condiciones anteriores. Por un lado la red de la figura es un medio broadcast ya que todas las máquinas conectadas reciben la trama de información enviada y sólo la máquina destinataria de la trama la procesa. Por otro lado, la máquina que está monitorizando el tráfico puede recibir tramas que no van dirigidas a ella ya que trabaja en modo promiscuo.

 

Figura 8.  Red en la que un Host monitoriza el tráfico que fluye por esta

 

Fuente: El autor.

Cuando una máquina recibe una trama Ethernet, ésta se procesa y se entrega a las capas superiores hasta llegar a la capa de aplicación. A partir de esta capa, la aplicación correspondiente procesa los datos recibidos. En el caso de un monitor de red, la información que éste procesa no sólo son los datos de aplicación, sino todos los datos recibidos incluyendo las cabeceras de las capas de Enlace, Red, Transporte y Aplicación. De esta manera se puede obtener información sobre quien envía datos en una red, de que tipo son, a que puertos van dirigidos, etc.

 

Para iniciar la sesión de captura y rastreo de paquetes, es necesario emplear la función pcap_t *pcap_open_live(char *device, int snaplen, int promisc, int to_ms, char*errbuf). La misma devuelve el índice a la estructura pcap_t. El primer argumento de la función se encarga de usar el  dispositivo de red. El siguiente parámetro, es el tamaño máximo del paquete capturado, expresado en bytes. El tercer argumento cuando es 1 indicará a la tarjeta de red que funcione en modo promiscuo, es decir, que capture todos los paquetes de la red disponibles (lo cual hace un sniffer), cuando es igual a 0 la interfaz de red simplemente funcionará en forma estándar. El cuarto parámetro indica el tiempo de espera de los paquetes en milisegundos. Finalmente, el último argumento, es un puntero al búfer del eventual error en caso de cualquier falla, el mensaje se introducirá allí.

 

3.4.1.3   Filtrado de paquetes en Libpcap

 

 

En la mayoría de aplicaciones que utilizan la librería pcap, se requiere del filtrado especial de paquetes de acuerdo a algún criterio del usuario. Para esto se utiliza generalmente la función int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask).

 

Su primer parámetro es el puntero de la interfaz, el segundo argumento, es el índice del filtro, el tercer parámetro es el filtro (en forma de título) guardado por convención de la aplicación tcpdump, por ejemplo: puerto 80 o IP host 192.168.0.1. Si en el cuarto argumento se da el valor 1 la expresión será optimizada, en caso de introducir 0 solamente se compilará. El último parámetro es la máscara de red de la interfaz .  La función devuelve -1 en caso de error.  Ahora se procede a enlazar el filtro dado con el puntero del dispositivo de red, por lo cual es útil la función int pcap _ setfilter(pcap _ t *p, struct bpf _ program *fp). Su primer argumento es el puntero hacia la interfaz y el siguiente es el índice del filtro (el mismo que el empleado como segundo argumento de la función int pcap_compile( ). La función devuelve -1 en caso de error.

 

3.4.1.4  Rastreo de paquetes

 

Según Skwarek [16] y Lopez Mongue [26] para el rastro de paquetes se dispone de dos formas:

 

• Rastrear paquetes individuales por medio de la función u_char *pcap_next(pcap_t *p, struct pcap _ pkthdr *h). Esta función lee un único paquete y devuelve un puntero a u_char con su contenido sin necesidad de declarar ninguna función Callback y devuelve el índice del contenido del paquete rastreado. El primer argumento es el puntero a la interfaz de red y el segundo es el índice de la estructura pcap_pkthdr. Esta estructura incluye tres campos: tiempo, cuando el paquete ha sido rastreado, su tamaño total y duración de una porción concreta rastreada. A continuación se presenta esta estructura:

 

 

struct pcap pkthdr {

struct timeval ts; // time stamp (marca de tiempo)

bpf u int32 caplen; // tamaño del paquete al ser capturado

bpf u int32 len; // tamaño real del paquete en el fichero;

};

 

 

• Rastreo de paquetes en el nudo, por ejemplo, por medio de la función int pcap_ loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user).  El primer argumento es el puntero del dispositivo de red, el siguiente parámetro es la cantidad de paquetes que se desea rastrear (el valor negativo significará un rastreo infinito). El tercero es la función callback, la cual se llama cuando el paquete dado coincide con el filtro. La función devuelve -1 en caso de error.

 

Generalmente la función callback se programa según el prototipo:

 

void my_callback(u_char *args, const struct pcap_pkthdr *header, const u_char *packet)

 

En donde el primer argumento se da en NULL, el siguiente es el índice de la estructura pcap_pkthdr, explicada antes, y el último parámetro, es el índice del contenido del paquete rastreado.

 

3.4.1.5  Extracción de la Información

 

Cuando ya se termine el proceso de recolección y captura de paquetes, se debe proceder a su respectivo análisis para lo cual se requiere del uso de estructuras especiales, así como el entendimiento de los diferentes RFC (Request For Comment)[5] mas importantes como el RFC 793 para TCP, RCF 791 para IP, RFC 768 para UDP, RFC 826 para ARP y el RFC 792 para ICMP.  En los sistemas Linux las estructuras están ubicadas en los directorios /usr/include/netinet/ y en /usr/include/net/, los cuales se presentan en la figura 9.

 

 


Figura 9.  Principales estructuras de red contenidas en Linux

Fuente: El autor

 

3.4.1.5.1   Cabecera Ethernet

 

Para poder hacer la captura de las tramas Ethernet y su posterior análisis es necesario entender el contenido del header Ethernet.h ubicado en el directorio /usr/include/net/ el cual tiene el siguiente contenido:

 

#ifndef __NET_ETHERNET_H

#define __NET_ETHERNET_H 1

#include <sys/cdefs.h>

#include <sys/types.h>

#include <linux/if_ether.h>     /* IEEE 802.3 Ethernet constants */

__BEGIN_DECLS

/* This is a name for the 48 bit ethernet address available on many

   systems.  */

struct ether_addr

{

  u_int8_t ether_addr_octet[ETH_ALEN];

} __attribute__ ((__packed__));

 

/* 10Mb/s ethernet header */

struct ether_header

{

  u_int8_t  ether_dhost[ETH_ALEN];           /* destination eth addr            */

  u_int8_t  ether_shost[ETH_ALEN];           /* source ether addr   */

  u_int16_t ether_type;                               /* packet type ID field    */

} __attribute__ ((__packed__));

 

/* Ethernet protocol ID's */

#define            ETHERTYPE_PUP               0x0200          /* Xerox PUP */

#define            ETHERTYPE_IP                   0x0800                        /* IP */

#define            ETHERTYPE_ARP               0x0806            /* Address resolution */

#define            ETHERTYPE_REVARP        0x8035                        /* Reverse ARP */

#define            ETHER_ADDR_LEN            ETH_ALEN     /* size of ethernet addr */

#define            ETHER_TYPE_LEN  2                        /* bytes in type field */

#define            ETHER_CRC_LEN   4                        /* bytes in CRC field */

#define            ETHER_HDR_LEN   ETH_HLEN                 /* total octets in header */

#define            ETHER_MIN_LEN    (ETH_ZLEN + ETHER_CRC_LEN) /* min packet length */

#define            ETHER_MAX_LEN   (ETH_FRAME_LEN + ETHER_CRC_LEN) /* max packet length */

 

/* make sure ethenet length is valid */

#define            ETHER_IS_VALID_LEN(foo)          \

            ((foo) >= ETHER_MIN_LEN && (foo) <= ETHER_MAX_LEN)

/*

 * The ETHERTYPE_NTRAILER packet types starting at ETHERTYPE_TRAIL have

 * (type-ETHERTYPE_TRAIL)*512 bytes of data followed

 * by an ETHER type (as given above) and then the (variable-length) header.

 */

#define            ETHERTYPE_TRAIL                        0x1000                        /* Trailer packet */

#define            ETHERTYPE_NTRAILER    16

#define            ETHERMTU  ETH_DATA_LEN

#define            ETHERMIN    (ETHER_MIN_LEN - ETHER_HDR_LEN - ETHER_CRC_LEN)

__END_DECLS

#endif  /* net/ethernet.h */

 

Se puede observar que la estructura que contiene las cabeceras Ethernet es ether_header que contiene la dirección Ethernet de origen (ether_shost), la dirección Ethernet de destino (ether_dhost) y el tipo que puede ser los siguientes[6]:

 

ETHERTYPE_PUP    Xerox PUP

ETHERTYPE_IP        Es un paquete de tipo IP

ETHERTYPE_ARP    Es un paquete de tipo ARP (traducción de direcciones ethernet a IP)

ETHERTYPE_RARP Es un paquete de tipo RARP (traducción de direcciones IP a ethernet)

 

 

Las cabeceras ethernet tienen un tamaño de 14 bytes que se calculan con la rutina int size_eth = sizeof (struct eth_hdr); y los siguientes dependen del tamaño que tome el campo ether_type.  A continuación se realiza la siguiente asignación ethernet = (struct eth_hdr*)(packet)) y se tendrá acceso a la dirección MAC mediante la estructura Ethernet del remitente y del destinatario y el tipo del paquete.

 

3.5  GENERADORES DE TRÁFICO

 

Existen herramientas de software libre que permiten generar tráfico UPD o TCP  utilizando distribuciones de probabilidad tipo Poisson, Normal, Uniforme, Exponencial, entre otras. Algunos de estos generadores son [22]:

 

Distributed Internet Traffic Generator (D-ITG): Utiliza distribución constante, uniforme, exponencial, pareto, cauchy, normal, poisson, y Gamma.

Poisson Generator: Utiliza Poisson

Self-similar Generator: Genera tráfico self-similar

MGEN: Utiliza periódica, poisson, y a ráfagas (bursty)

Traffic Generator: Trafico UDP y TCP / constante, uniforme, exponencial y utiliza cadenas de Markov.

Harpoon: Genera flujos usando parámetros distribuidos, sacados de trazas de Netflow.

Tcpreply: Genera tráfico desde trazas generadas con tcpdump.

 

3.5.1 Mgen (NRL Multi-Generator)

 

En este proyecto, se utilizo MGEN [19] y [28], por ser uno de los generadores de tráfico más conocidos y utilizados en el ámbito científico. Esta es una herramienta de software libre basada en comandos desarrollada por el Laboratorio de Investigación Naval de Estados Unidos, el cual fue concebido por el grupo PROTEAN (PROTocol Engineering Advanced Networking), que permite hacer mediciones y pruebas de rendimiento sobre una red IP, utilizando tráfico UDP/IP. La herramienta puede generar patrones de tráfico en tiempo real que se pueden usar en variedad de formas. Es posible usar archivos de scripts especiales para cargar dichos patrones en el tiempo. También permite emular patrones de tráfico en aplicaciones de tipo unicast o multicast usando los protocolos UDP/IP; permite además soporte a IPv6, inclusive en ambientes de simulación de redes como OPNET y ns-2.  El log de datos de MGEN se puede usar para calcular tasas de pérdida de paquetes, estadísticas de rendimiento, retardos en la comunicación entre otras. MGEN que actualmente esta en la versión 4.2, tiene otra ventaja y es que funciona en variedad de sistemas operativos de red como sistemas basados en UNIX, MacOS X y plataformas Windows.

 

3.6    SNIFFERS

 

Estas aplicaciones se encargan de capturar e interpretar tramas y datagramas en entornos de red basados en difusión, conocidos como escuchas de red o sniffers, en donde es posible hacer un análisis de la información contenida en los paquetes TCP/IP que se interceptan, para poder extraer todo tipo de información.

 

La información a obtener puede ser de todo tipo, desde el contenido de las cabeceras de los paquetes hasta el payload (datos de los paquetes).   Estas herramientas permiten  además la captura de diferentes tipos de protocolos de red como ARP,RARP, UDP, ICMP, HTTP, etc, lo cual permite a los administradores de red obtener información valiosa y  útil.

 

Según Gontt [12], “para poder capturar paquetes, el sistema en el cual se está ejecutando el sniffer debe tener acceso a aquellos paquetes que se desean capturar. Esto implica que dicho sistema deberá estar en alguna de las redes a través de las cuales dichos paquetes circulan. En el caso de las redes de Área Local (LAN) que utilizan tecnología Ethernet, generalmente se construyen utilizando alguno de estos equipos: HUBs (concentradores) o switches (conmutadores). Los Hubs básicamente enviaran aquellos paquetes enviados por un equipo, a todos los demás equipos conectados al hub. Así cualquier sistema conectado a un hub tiene acceso a todos los paquetes transferidos a través de dicha LAN. Los switches, por el contrario, al recibir  un paquete, envían el mismo solamente al equipo destinatario….”

 

3.6.1        Desactivación de Filtro MAC

 

Una de las técnicas más usadas por la mayoría de sniffers de redes Ethernet, se basa en la posibilidad de configurar la interfaz de red, para que desactive su filtro MAC poniendo la tarjeta de red en modo promiscuo, es decir que se pueda capturar tanto los paquetes destinados a la máquina como el resto de tráfico de la misma red.

 

Con el uso adecuado de expresiones regulares y otros filtros de texto, se podrá visualizar o almacenar únicamente la información que más interesa.  El entorno en el que suele ser más efectivo este tipo de escuchas son las redes LAN configuradas con una topología en bus.  En este tipo de redes, todos los equipos están conectados a un mismo cable. Esto implica que todo el tráfico transmitido y recibido por los equipos de la red pasa por este medio común.  Debido a esto, lo más recomendable por seguridad es que el administrador realice una segmentación de la red y de los equipos haciendo uso de switches, con esto se minimizarán algunos peligros.

 

3.6.2        Herramientas para hacer Sniffing

 

Ettercap, que  funciona desde consola,  ofrece un entorno más interactivo y muestra conexiones accesibles desde la máquina donde se encuentra instalado y que permite seleccionar cualquiera de ellas para la captura de paquetes. 

 

Otra herramienta es Ethereal  (Actualmente se llama Wireshark), que es un analizador de protocolos (soporta 480 protocolos) utilizado para realizar análisis y solucionar problemas en redes de comunicaciones para desarrollo de software y protocolos, y como una herramienta didáctica para educación.

La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. 

 

Para el desarrollo de este proyecto se utilizo TCPDUMP, la cual se explica a continuación:

 

3.6.3  Tcpdump 

 

Esta herramienta es una de las más utilizadas por administradores de red, es tipo open source y además es multiplataforma. Es un sniffer (simplemente captura el tráfico que circula por las redes a las cuales se encuentra conectado y decodifica dicha información para que sea inteligible al usuario) fue escrito por: Van Jacobson, Craig Leres y Steven McCanne, todos ellos del Lawrence Berkeley Laboratory de la UCLA. Esta herramienta ha sido utilizada desde hace varios años para obtener los registros de los paquetes incluidos en los protocolos TCP y UDP. Esta herramienta funciona en modo consola y se basa en una serie de comandos muy completos (Menendez: 69-76) y (Gont.[7]: 44). 

 

3.6.3.1  Sintaxis de TCPDUMP

 

Este programa se lanza mediante una Shell de comandos y la sintaxis general de tcpdump es la siguiente:

 

tcpdump opciones expresión

 

Las opciones determinaran como será la salida, es decir, que campos se mostrarán, con que formato, el número de puerto, etc, y la expresión indica cuales son los paquetes que se desean capturar, por ejemplo, los paquetes de un determinado protocolo o con un determinado contenido, etc.  Es importante anotar que dependiendo del protocolo elegido la salida será diferente y con campos específicos.

Un parámetro importante para especificarle a tcpdump es la interfaz en la que se desea capturar los paquetes. Para esto se utiliza la opción –i y el nombre de la interfaz. El comando es el siguiente:   tcpdump – i  <interfaz de red>

 

  Figura 10.  Salida estándar de TCPDUMP

Fuente:  El Autor

 

En la anterior salida cada línea representa un paquete, en donde el primer campo indica la hora, el segundo la dirección IP, luego viene un carácter que representa gráficamente el sentido de los datos, seguido por la dirección IP. A continuación aparecen flags que pueden tener distintos valores de acuerdo al tipo de protocolo.

Por defecto tcpdump intentará convertir las direcciones IP de los sistemas origen y destino a nombres de dominio, si no es posible hacerlo mostrará solo las direcciones IP tal como fueron encontradas en los paquetes capturados. Si se utiliza la opción –n se le puede indicar que no realice la conversión de direcciones IP a nombres de dominio.

 


A continuación se presenta el uso del comando con un ejemplo:

 

tcpdump –i eth0 –n icmp

 

Este comando indica que capture tráfico ICMP por la interfaz eth0 pero sin hacer la conversión de las direcciones IP de Origen y Destino.

 

3.6.3.2  Información extendida

 

Tcpdump siempre mostrará aquella información de los paquetes capturados que supone imprescindible para poder entender el tráfico en cuestión. Sin embargo en ocasiones es necesario tener más información para su respectivo análisis, por lo que esta herramienta trae una opción que permite al usuario que tcpdump muestre información extendida sobre los paquetes capturados. Esta opción se conoce como verbose y para esto se utiliza la opción –v.

 

Por ejemplo si se utiliza el comando tcpdump –i eth0 –n –v icmp se obtendría la  siguiente salida:

 

 

 

 

 

 


Figura 11.  Salida de TCPDUMP con Verbose

Fuente: El Autor

 

En esta salida se puede observar información adicional como el número de identificación del paquete ICMP (que corresponde al número del proceso PID de la instancia del ping en cuestión), el número de secuencia del paquete (utilizado para identificar las distintas peticiones y respuestas), el TTL (time to live) y el ID o número de identificación de cada uno de los paquetes IP.  Además es posible utilizar la opción

vv que mostraría información aun más detallada.

 

3.6.3.3  Salida del Sniffer

 

Tcpdump soporta la opción –w que permite especificar un archivo en el cual se guardaran los paquetes capturados. Esto permitirá al usuario tener a disposición los paquetes originales, por si en un futuro se desea analizar el contenido de los mismos. El siguiente es un ejemplo del uso de esta opción:

tcpdump –i eth0 –w archivo.extension icmp

 

Una vez realizado este procedimiento se puede indicar a tcpdump que decodifique los paquetes almacenados en dicho archivo mediante la opción –r así:

 

tcpdump –r archivo.extension

 

3.6.3.4  Direcciones de la capa de enlace

 

Cuando se desean transferir paquetes de información mediante tecnologías de red, en las cuales todas las estaciones comparten el mismo medio de enlace (como por ejemplo Ethernet, Token Ring, etc), se utilizan direcciones de red en la capa de enlace, para identificar el origen y el destino de dichos paquetes. La opción –e  de la herramienta tcpdump permite especificar que se desea visualizar las direcciones de capa de enlace que fueron utilizadas para la transmisión de los paquetes capturados. A continuación se presenta un ejemplo de este caso:

 

tcpdump –i eth0 –e  <protocolo>

 

Por defecto tcpdump, no captura la totalidad de los paquetes recibidos, sino que captura solamente los primeros 96 bytes[7]. Esto permite que se utilice menos memoria para almacenar los paquetes capturados, permitiéndose igualmente la decodificación de los mismos. Sin embargo, si el protocolo a decodificar utilizara información mas allá de los primeros 96 bytes del paquete capturado, o bien si se desea tener acceso a la totalidad del mismo, es necesario  utilizar la opción –s que permite especificarle a tcpdump la máxima cantidad de bytes que se desea capturar por cada paquete. Para especificarle a tcpdump que capture un MTU típico de una trama Ethernet es decir 1500 bytes se utilizaría el siguiente comando:

tcpdump –i eth0 –s 1500

 

Figura 12.  Salida de TCPDUMP con Snaplength

Fuente: El Autor

 

3.6.3.5   Filtros con TCPDUMP[8]

 

Un filtro es una expresión especial que permite seleccionar los paquetes que se están buscando. En ausencia de ésta, tcpdump volcará todo el tráfico que vea el adaptador de red seleccionado.

 

La expresión que se usa para definir el filtro tiene una serie de primitivas y tres posibles modificadores a las mismas. Esta expresión será verdadera o falsa y hará que se imprima o no el paquete de datos.

 

Los 3 modificadores posibles son:

 

3.7  INGENIERÍA DE SOFTWARE

 

La Ingeniería del Software se podría definir como el establecimiento y la aplicación de principios de ingeniería para obtener software, teniendo en cuenta factores tan importantes como el factor económico, la fiabilidad del sistema y un funcionamiento que satisfaga las necesidades del usuario. [9]

 

 

En el desarrollo de un proyecto intervienen diferentes etapas que se interrelacionan y complementan con la finalidad de alcanzar los objetivos iníciales. Estas etapas pueden variar dependiendo del ciclo de vida que se haya decidido para el sistema, pero las principales fases son el análisis de requerimientos, la especificación, el diseño, el desarrollo e implementación y por último el mantenimiento.

 

Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniería tradicional en la naturaleza lógica del producto software.

 

Recordemos que “el software se desarrolla, no se fabrica en un sentido clásico”. En todos los  proyectos de ingeniería la buena calidad se adquiere mediante un buen diseño, pero en el caso del software, la etapa de construcción poco incide en su calidad, no así en la construcción de hardware o de una obra civil. Otra diferencia es que el “software no se estropea[10], el paso del tiempo o males del entorno no inciden en el aumento de la tasa de fallas. Así, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricación.

 

En la actualidad el desarrollo del software exige aplicaciones que cuenten con toda la calidad posible, y esta depende de la forma en la que el mismo desarrollo se lleve a cabo. Por lo cual la Ingeniería de Software se encarga de tener un seguimiento de todo el ciclo de vida del mismo, con el fin de garantizar dicha calidad a un costo accesible.

 

Fairley define a la ingeniería de software : “La ingeniería de software se define como la disciplina técnica preocupada de la producción sistemática y del mantenimiento de los productos de software que son desarrollados y modificados en tiempo y dentro de un presupuesto definido” [11].

 

La ingeniería de software cuenta con tres elementos importantes:

 

·         Los métodos comprenden la parte de la planificación, análisis de los requisitos del sistema, diseño de estructuras de datos, procedimientos, algoritmos, codificación, pruebas y mantenimiento, es decir, “indican como construir técnicamente el software”

 

·         Las herramientas  suministran el soporte automático o semiautomático para cada uno de los métodos. “Cuando se integran las herramientas de forma que la información creada por  una herramienta pueda ser utilizada por otra, se establece un sistema para el soporte del desarrollo del Software, llamado Ingeniería del Software Asistida por Computadora (en inglés, CASE) [12]

 

·         Los procedimientos definen la secuencia en la que se aplican los métodos, las entregas que se requieren y las herramientas que se deben utilizar, los controles que se deben tener y  los controles que ayudan a asegurar la calidad, o sea, las directrices para llevar a término el proceso.

 

3.7.1 Objetivos de la Ingeniería De Software

 

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática es la que se encarga de aportar estos recursos sobre los que se apoya la ingeniería de software.  Dentro de los objetivos que podemos enunciar tenemos:

 

·         Mejorar la calidad de los productos de software

·         Aumentar la productividad y trabajo de los ingenieros del software.

·         Facilitar el control del proceso de desarrollo de software.

·         Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

·         Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

 

 3.7.2 Planificación de un Proyecto de Ingeniería De Software.

 

La planificación involucra la especificación de objetivos y metas para un proyecto y las estrategias, políticas, planes y procedimientos para alcanzarlos.

Todo proyecto de ingeniería de software debe partir con un buen plan. La planificación es necesaria por la existencia de pocas certezas sobre el ambiente del proyecto software y sobre fuentes externas. La planificación enfoca su atención en las metas del proyecto, riesgos potenciales y problemas que puedan interferir con el cumplimiento de esas metas.

 

Los principales problemas en la planificación de un proyecto de ingeniería de software incluyen los siguientes:

 

• Requerimientos incorrectos e incompletos.

• Muchas especificaciones de requerimientos son inestables y sujetas a cambios mayores.

• La planificación no se lleva a cabo por la creencia errónea de que es una pérdida de tiempo y los planes cambiarán de todos modos.

• La planificación de costos y plazos no es actualizada y se basa en necesidades de mercadeo y no de los requerimientos del sistema.

• Es difícil estimar el tamaño y complejidad del proyecto de software de modo de realizar una estimación de costos y plazos realista.

• Los costos y plazos no son estimados cuando los requerimientos del sistema o el ambiente de desarrollo cambian.

• No se manejan factores de riesgo.

• La mayoría de las organizaciones de desarrollo de software no recolectan datos de proyectos pasados.

• Las compañías no establecen políticas o procesos de desarrollo de software.

 

Las actividades que se derivan de la planificación son:

 

• Fijar los objetivos y metas

• Desarrollar estrategias

• Anticipar futuras situaciones

• Conducir un establecimiento de riesgos

• Determinar posibles cursos de acción

• Tomar decisiones de planificación

• Fijar procedimientos y reglas

• Desarrollar los planes del proyecto

• Preparar presupuestos

• Documentar los planes del proyecto.

 

3.7.3  Organización de un Proyecto De Ingeniería de Software

 

Involucra desarrollar una estructura organizacional efectiva y eficiente para asignar y completar las tareas del proyecto y establecer las relaciones de autoridad y responsabilidad entre las tareas.

 

Las actividades que se deben tener en cuenta en la organización son:

 

 

• Identificar y agrupar las funciones, actividades y tareas del proyecto.

• Seleccionar estructuras organizacionales

• Crear posiciones organizacionales

• Definir responsabilidades y autoridades.

• Establecer el perfil de cada puesto

• Documentar las decisiones organizacionales

 

“La ingeniería del software está compuesta por una serie de pasos que abarcan  los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería del software. La elección de un paradigma para la ingeniería del software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y los controles y entregas requeridos” [13]

 

 3.7.4  Modelo de Desarrollo Incremental

 

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo es un proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

 

El desarrollo incremental es 100% compatible con el modelo cascada y no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura 13 y 14.

 

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

 

• Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

 

• Al ir desarrollando parte de las funcionalidades,  es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

 

• Si un error importante es detectado, sólo la última iteración necesita ser descartada.

 

• Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.

 

• Si un error importante es detectado, el incremento previo puede ser usado.

 

• Los errores de desarrollo detectados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

 

Figura 13. Modelo de Desarrollo Incremental

 

 

 

 

 

 

 


Fuente: El autor

Figura 14. Modelo de Desarrollo Incremental con desarrollo en cascada de los incrementos

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Fuente: El autor

 

 


4.        METODOLOGIA DE LA INVESTIGACION

 

 

 

Este proyecto se realizo combinando los diferentes paradigmas usados en la Ingeniería de Software, e incluye etapas como el análisis y diseño, desarrollo, y pruebas.

 

Para el software, se utilizo una metodología de desarrollo incremental con sucesivas iteraciones en cada etapa hasta llegar a la versión final de la herramienta. Esta metodología permite que el software sea probado por el usuario por etapas refinadas sucesivamente a lo largo del proyecto, de manera que se sabe exactamente que es lo que se va a construir realizando mejoras o correcciones al sistema en un menor tiempo.

 

Se escogió esta metodología para el desarrollo de este proyecto, porque es importante que la entrega de la herramienta no se haga hasta el final del proyecto; reduciendo así el riesgo de hacer modificaciones después de tener el software terminado.

 

Se desarrollaron inicialmente 5 etapas las cuales se describen a continuación:

 

4.1   CONCEPTUALIZACION

 

-          Conocer y estudiar las herramientas de software empleadas para el desarrollo del proyecto.

-          Conocer los estándares de desarrollo que se pueden aplicar al proyecto

-          Establecer los requerimientos de hardware necesarios para el sistema.

-          Estudiar el funcionamiento y arquitectura de los protocolos de red TCP, ARP, IP, ICMP y UDP.

 

Producto: Identificación de los requerimientos del sistema.

 

4.2 ANÁLISIS DE REQUERIMIENTOS Y DISEÑO

 

-          Establecer  la arquitectura del software.

-          Redactar y acordar los requerimientos del sistema.

-          Diseñar el ambiente de pruebas (testbed)

-          Modelar el software por medio de los diferentes diagramas de UML.

 

Producto: Documento de requerimientos establecidos para el sistema.

 

4.3  CODIFICACIÓN, DEPURACIÓN Y PRUEBAS (INCREMENTO 1)

 

-          Instalación y configuración de las herramientas de Software a utilizar

-          Codificación de la herramienta según el análisis y el diseño realizados.

-          Realizar las validaciones necesarias para la herramienta.

-          Refinar y documentar el código.

-          Configurar el testbed.

-          Hacer pruebas al prototipo inicial.

-          Realizar las correcciones necesarias al prototipo inicial.

-          Documentación de la herramienta, elaborando los manuales necesarios.

 

Producto: prototipo Beta de la herramienta.

 

4.4 CODIFICACIÓN, DEPURACIÓN Y PRUEBAS (INCREMENTO 2)

 

-          Evaluación del prototipo.

-          Mejora y optimización del código

-          Creación de archivo INSTALL y Makefile

 

Producto: Prototipo final de la herramienta.

4.5  ENTREGA DEL SISTEMA

 

-          Análisis de Resultados

-          Realizar la entrega formal de la herramienta.

-          Redacción e impresión del documento final

 

Producto: Herramienta de estimación en tiempo real de consumo de ancho de banda con licencia GPL.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


5.      DESARROLLO DEL SISTEMA

 

 

 

5.1  REQUERIMIENTOS GENERALES

 

Los requerimientos generales del sistema se desglosan a partir de la identificación y definición de  datos y la estructura de la información en la que se va a componer la herramienta.

 

A continuación se presentan los principales requisitos establecidos en el proyecto:

 

q  La herramienta tiene licencia GPL (General Public License), por lo cual respetará las libertades que da la Free Software Foundation.

q  La herramienta funciona bajo plataforma GNU/Linux

q  Es necesario el uso de la librería libpcap para la captura de tráfico.

q  Será utilizada por línea de comandos.

q  La herramienta se desarrollará con el lenguaje de programación C, para lo cual se empleo el compilador gcc (GNU Compiler C)

q  El usuario puede seleccionar la tarjeta de red que desea.

q  El sistema será utilizado siguiendo el esquema Cliente / Servidor.

q  Se considera la reutilización de código.

q  Se requiere la captura del timestamp de los paquetes enviados, la longitud de la trama Ethernet y por último el ancho de banda calculado.

q  La herramienta tendrá un proceso de instalación típico de las herramientas libres bajo sistemas *NIX, como el uso de un MakeFile.

q  El usuario podrá cancelar la captura de tráfico en cualquier momento.

q  El software deberá sincronizarse contra el tráfico generado por MGEN

q  La herramienta generada deberá tener su correspondiente documentación.

 

5.2   ANÁLISIS

 

En primera instancia el modelo utilizado fue el desarrollo incremental. Este modelo permitió un control total para el desarrollo del sistema, desde su conceptualización,  pasando por la recolección de requerimientos iníciales, los que fueron complementados mediante asesorías realizadas en el transcurso del desarrollo del sistema por parte del director del mismo; además facilitó los cambios, permitiendo la entrega de los distintos avances a través de versiones y prototipos, que se evaluaron y aprobaron a satisfacción. 

 

Es importante destacar que la herramienta desarrollada realizará tres etapas importantes que son, la captura, el análisis de los paquetes y la presentación de resultados.

 

5.2.1  Casos De Uso

 

Para un mejor análisis se han generado varios casos de uso generales los cuales se explicarán a continuación:

 

Figura 15.  Caso de Uso Envío y Captura de Tráfico

Diagramedecasodeuso1

Fuente: El autor

 

En la herramienta se utilizarán dos Actores denominados Sender y Receiver, los cuales tendrán las siguientes funciones:

 

Sender: Será el encargado de generar tráfico UDP o TCP a la red, el cual llegará al Receiver para posterior análisis. Esta máquina será ejecutada bajo ambiente Linux.

 

Receiver: Será el encargado de capturar el tráfico generado por el Sender y realizará por medio de la herramienta desarrollada el respectivo análisis y generación de la salida deseada. Esta máquina será ejecutada bajo ambiente Linux.

 

Figura 16. Caso de Uso  Generación de tráfico por el Sender.

Diagramedecasodeuso2

Fuente: El autor

 

Para uso del equipo sender (el cual genera el tráfico a analizar); se tiene instalada la aplicación MGEN, en la cual como se describió anteriormente se deberá configurar un script especial, así como elegir el tipo de tráfico a generar como Poisson, Bursty (Ráfaga) o periodic, y por último ejecutar el demonio del aplicativo. Luego se enviará todo el tráfico a la dirección IP del Receiver escogido.

 

 

 

 

Figura 17:  Caso de Uso Captura y Análisis de paquetes en el Receiver

Diagramedecasodeuso3

Fuente: El autor

 

En la figura 17 el  receiver apenas recibe y captura el paquete (debe hacerse en un loop y con la tarjeta de red en modo promiscuo), procede a realizar el respectivo análisis, para generar la salida deseada al usuario final. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figura 18. Caso de Uso Análisis de Tráfico

 

Diagramedecasodeuso4

Fuente: El autor

 

Como resultado de las especificaciones, la información gira en torno a los paquetes que se capturan en tiempo real especialmente los que vienen de la capa 2 del modelo OSI. Cuando el kernel de Linux vea el paquete y tome del encabezado de capa 2 la longitud del campo de datos que corresponde a la longitud del paquete en capa 3 que tiene encapsulado a su vez los headers de la capa de  transporte más el payload.

 

Para el análisis de tráfico en el receiver se procede una vez capturado cada paquete a identificar su  Timestamp esto con el fin de poder calcular la diferencia de envío entre paquetes para calcular el ancho de banda. Además se requiere capturar la longitud del paquete en bytes.  

 

Es importante tener en cuenta que durante el proceso de captura y dependiendo del tipo de trafico se pueden almacenar una gran cantidad de datos, sobre todo en redes de alta velocidad, por lo que en tiempos de medición cortos se podrían tener datos de un  de cercano a los GigaBytes.

 

Antes de continuar es necesario revisar cual es el procedimiento para el cálculo de los anchos de banda.   Las bases para esto se pueden encontrar en el RFC1323[14], en un documento denominado “TCP: Extensions for High Performance”, en el cual se indica que el rendimiento de una conexión TCP está dada por el retardo (latencia) entre el envió de dos paquetes medida en segundos y el cual se rige por la siguiente fórmula:

 

Bandwidth (bits/sec) x delay(second)= data (bits)

 

El resultado de este cálculo será el tamaño total de datos que se transmitirán en un determinado tiempo por la red.

 

El campo Bandwidth se calcula en bps, por lo que se requerirá de la siguiente fórmula:

 

Bandwidth=(longitud Packet (bytes)* 8) / (diferencia de tiempos entre paquete n+1  y paquete n)

 

Para ilustrar el proceso, se utilizará en el siguiente ejemplo el comando

 

tcpdump -s 0 -eNi  eth0

 

en donde la opción –s 0 imprime la longitud requerida de los paquetes, -e imprime la información de las cabeceras de la capa de enlace, -N no imprime el nombre del dominio y – i permite elegir la interfaz por la cual se capturarán los paquetes que será la eth0.  

 

La siguiente es una salida típica de este comando:

 

21:01:11.591329 00:00:0c:13:dd:ff (oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374 > China172.commplex-link: UDP, length 1024

21:01:11.592928 00:00:0c:13:dd:ff (oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374 > China172.commplex-link: UDP, length 1024

21:01:11.594528 00:00:0c:13:dd:ff (oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374 > China172.commplex-link: UDP, length 1024

21:01:11.596224 00:00:0c:13:dd:ff (oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374 > NChina172.commplex-link: UDP, length 1024

 

En la anterior salida se observa primero el Timestamp, luego la MAC Address de origen, la MAC Address de destino, el tipo de paquete ETHERTYPE que en este caso es 0x0800 lo que indica que es de tipo IP y la longitud del paquete en bytes.

 

Ahora el primer paquete fue capturado a las 21:01:11.591329 el cual tiene una longitud de 1066 bytes y el segundo fue capturado 21:01:11.592928, esto indica que en 0.001599 segundos o 1,599 milisegundos se transmitió un paquete de 1066 bytes. Aplicando la fórmula se tendría que:

 

BW=(1066 bytes * 8) / 0.001599seg = 5333333,33 bits/seg

 

Este resultado indica que el ancho de banda calculado es de aproximadamente 5Mbps. Ahora se presenta cual es el proceso con MGEN.

 

En el equipo "Receiver" se coloca el PC a “escuchar” tráfico en un puerto definido por el usuario por ejemplo el puerto 5001 (El uso de los puertos debe corresponderse con el estándar RFC 1700 y no se pueden utilizar los puertos entre 1 y 1024):

 

Figura 19. Apertura de Puerto 5001 desde MGEN en PC Receiver.

Fuente: El Autor

 

En la anterior figura se observa el uso del comando ./mgen event “listen udp 5001” output listen.log & el cual indica  que se debe activar el evento de escuchar de tráfico UDP por el puerto asignado y generar la salida en el archivo listen.log. El símbolo & en sistemas UNIX indica que se ejecute el comando en background.

 

Para comprobar que se ha activado el puerto 5001 se utiliza el comando netstat de la siguiente forma:

 

Figura 20.  Puerto UDP/5001 abierto por MGEN

Fuente: El Autor

 

A continuación se ejecuta tcpdump y se le indica que todo el tráfico capturado se almacene en el archivo traza.txt, utilizando la siguiente instrucción:

tcpdump -s 0 -eNi eth0 > traza.txt

 

En el equipo "Sender" ahora se procede a crear un archivo especial el cual se llamará  xtraf.txt con el siguiente contenido:

 

0.0 ON 1 UDP DST 192.168.1.1/5001 PERIODIC [1000 1024] INTERFACE eth0

 

Para entender el contenido del archivo es necesario comprender su estructura.  El formato general es el siguiente [28]:


[<eventTime>] <eventType> <parameters ...> [<options ...>]

 

El parámetro eventTime permite definir en formato de segundos el inicio del evento, cuando su valor es 0.0 significa que se ejecute inmediatamente. El segundo valor se denomina eventos de transmisión, este formato utiliza un identificador de flujo de tipo numérico que indica un hilo de generación de tráfico de MGEN.  Esta herramienta puede utilizar 3 tipos de eventos los cuales se denominan ON, MOD y OFF.

 

El evento ON tiene la siguiente sintaxis:

 

<eventTime> ON <flowId><protocol> DST <addr>/<port> <pattern [params]> [<options ...>]

Este evento es utilizado para iniciar un nuevo flujo según el tiempo dado en eventTime.  El cuarto campo indica el protocolo de transporte a utilizar, generalmente MGEN utiliza el protocolo UDP el cual encapsula los mensajes generados por MGEN en el paquetes de tipo UDP/IP que se transmiten a la red.  A continuación se presenta un ejemplo

0.0  ON 1 UDP DST 127.0.0.1/5000 PERIODIC [1.0 1024]

Esta línea indica que se origine a la interfaz loopback un flujo de tráfico UDP por el puerto 5000 el cual comienza inmediatamente apenas se ejecute el script.  El mensaje en este caso será de tipo Periódico y se generará mensajes de 1024 bytes a una taza de 1 por segundo.

Las direcciones de destino del flujo que se especifican para los eventos ON pueden ser alteradas por el evento MOD.  Las direcciones además pueden ser de tipo IPv4 o IPv6 además de que se pueden configurar como unicast o multicast.  A continuación se presenta un ejemplo:

#Inicia el flujo  hacia una interfaz loopback por el Puerto 5000
0.0 ON 1 UDP DST 127.0.0.1/5000 PERIODIC [1.0 1024]
#Modifica el flujo 1 a un puerto de destino diferente
0.0 MOD 1 DST 127.0.0.1/5001

 

5.2.2  Patrones de Generación de Tráfico (Periódico, Poisson, Ráfaga)

 

El tráfico generado por MGEN consiste en una serie de mensajes con secuencias numeradas. Los mensajes generados pueden variar en tamaño y frecuencia de transmisión hacia la red. El patrón de generación se especifica mediante los eventos ON aunque puede alterarse con eventos MOD. MGEN soporta tres tipos de patrones que se crean a través de múltiples flujos.

 

5.2.2.1  Patrón Periódico

 

Este tipo de patrón genera mensajes de un tamaño fijo en bytes a una tasa regular medida en mensajes/segundo. El tamaño del campo puede ser mayor o igual al mínimo del tamaño de los mensajes de MGEN y menor o igual al máximo del tamaño de los mensajes UDP que son de 8192 bytes.

 


La sintaxis es la siguiente:  PERIODIC [<rate> <size>]

A continuación se presenta un ejemplo del uso de este tipo de patrón:

#Inicia el envío de mensajes de 1024 byte a una taza de 10 por segundo
0.0 ON 1 UDP DST 127.0.0.1/5000 PERIODIC [10.0 1024]

5.2.2.2   Patrón Poisson

Este patrón genera mensajes de tamaño fijo en bytes utilizando una variación estadística de promedios de los intervalos de mensajes enviados a una taza medida en mensajes/segundo.  

La sintaxis es la siguiente:


POISSON [<aveRate (msg/sec)> <size (bytes)>]

El ejemplo que se presenta a continuación ilustra este patrón:




#Inicia el envío de mensajes de 1024 bytes a una tasa promedio de 10.0 por segundo
0.0 ON 1 UDP DST 127.0.0.1/5000 POISSON [10.0 1024]

5.2.2.3 
Patrón Ráfaga (BURST)


Este patrón genera ráfagas de tráfico de otros tipos de patrones en intervalos promedios. La sintaxis es la siguiente:

 

BURST [REGULAR|RANDOM <aveInterval (sec)> <patternType> [<patternParams>] FIXED|EXPONENTIAL <aveDuration (sec)>]

 

El primer parámetro se denomina REGULAR y resulta en ráfagas periódicas uniformemente distribuidas en el tiempo dado por el valor <aveInterval> , o RANDOM (Aleatorio) con distribución exponencialmente distribuida  La característica de los mensajes generados durante las ráfagas se obtienen del parámetro <patternType> y de <patternParams>.  El tipo de parámetro puede ser cualquiera (PERIODIC, POISSON, o BURST).   Cuando la generación de ráfagas ocurre, se puede configurar la duración a través de 2 valores denominados FIXED y EXPONENTIAL, si se escoge el primero se obtiene el valor dado en  <aveDuration> y si es el segundo la duración varia aleatoriamente.

 

Una vez entendido el método de funcionamiento general de MGEN, ahora se procede a ejecutar el siguiente comando: ./mgen ipv4 input xtraf.txt interface eth0

 

Su ejecución indica que se utilice el script creado en el archivo xtraf.txt y que genere el tráfico por la interfaz eth0 del sender.

 

5.3  TESTBED

 

Para la implantación de la herramienta se realizaron varias actividades que comprendieron la puesta a punto (instalación y configuración) del equipo Sender y del Receiver, esto incluyo  la utilización de la distribución GNU/ Linux Knoppix 5.0.1,  que es basada en Debian, y es el CD-Live más utilizado en la actualidad. Además se realizaron pruebas utilizando la distribución BackTrack y Ubuntu. 

 

 5.3.1  Arquitectura General Del Sistema

 

El Sistema cuenta con dos entornos físicos: el sender  y el receiver, para el primero se dispone de un equipo portátil Dell Inspiron 6000 Pentium Centrino  de 1.3 GHz con 512 MB de memoria RAM y 1 DD de 40 GB, el receiver es un Portatil Dell Inspiron 1525 con procesador Pentium Dual Core de 1.6GHz con 2 GB de memoria RAM y Disco Duro de 120 GB. Ambos tienen una tarjeta de red FastEtherent de 100Mbps.  Los equipos fueron conectados por medio de un conjunto de Switches , Hubs y un Router Cisco 2514 realizar las respectivas pruebas. 

 

El software que se instaló y configuró en la infraestructura antes mencionada se distribuyó de la siguiente forma:

 

 

 

 

Tabla 1 :  Software utilizado

SENDER

RECEIVER

Generador de Trafico MGEN Ver 4.2

TCPDUMP Sniffer

TCPDUMP Sniffer

Librería libpcap

ETHEREAL Sniffer

Compilador GCC 4.1.2

IPTRAF

IPTRAF

Fuente: El Autor

 

5.3.1.1  Configuración del Sender

 

Para configurar el PC sender se realizaron los siguientes pasos:

 

  1. Se descarga el archivo src-mgen-4.2b6.tgz  del generador de tráfico MGEN  desde la página web http://cs.itd.nrl.navy.mil/work/mgen/index.php

 

  1. A continuación se procede a configurar la interfaz de red. La configuración de las tarjetas Ethernet consiste básicamente en cargar el driver apropiado para la tarjeta o tarjetas de que se dispongan. Los drivers de las tarjetas de red se cargan como cualquier otro módulo del kernel .  En el caso de tarjetas Ethernet, cada módulo cargado asignará un nombre de dispositivo a la tarjeta, empezando por eth0 y siguiendo con eth1, etc.

 

 


En la siguiente figura se muestra el entorno de pruebas del proyecto:

 

Figura 21.  Entorno de pruebas para el Testbed

 

  Fuente: El Autor.

 

Como se observa en la figura 21 el esquema de direccionamiento privado es de Clase B (172.16.X.Y), por lo que la máscara que se utiliza por default es 255.255.0.0 (16 bits). En el ejemplo se supondrá que el equipo tiene una tarjeta de red interna tipo 10/100 Mbps. En Linux está identificada como eth0. 

 

El comando más importante es el ifconfig (Figura 22) el cual retorna inicialmente la información sólo de la interfaz Loopback (127.0.0.1), identificada como lo, esto indica que está configurada las funciones iníciales TCP/IP dentro de la máquina. 

 

 

 

Figura 22. Comando Ifconfig

Fuente: El Autor

 

A continuación se configura y sube la tarjeta  para el equipo Sender de esta forma:

ifconfig  interface   dirección_IP   netmask   mascara_subred     up.  

Luego como se ve en la siguiente gráfica quedo configurada la interfaz eth2.

 

 Figura 23. Parámetros para la Tarjeta de Red

Fuente: El Autor

 

 

A continuación se comprueba con el comando ping que la interfaz de red eth2 está respondiendo:

 

Figura 24.  Ejecución del comando Ping

Fuente: El Autor

 

Los mismos pasos se realizan para el equipo Receiver. 

 

Ahora se procede a instalar el generador de tráfico MGEN siguiendo los siguientes pasos.

 

  1. Se accede al Shell de root con el comando su –

 

  1. Se procede a desempaquetar el archivo con el comando

tar –xzvf  src-mgen-4.2b6.tgz

 

  1. Ahora se accede al directorio /mgen-4.2b6/unix y se compila los fuentes con el comando make –f Makefile.linux mgen como se observa en la figura 25:

 

Figura 25.  Proceso de instalación de MGEN

Fuente: El Autor

 

  1. Ahora se procede a probar el binario compilado con el comando ./mgen y debe aparecer la siguiente salida:

 

Figura 26.  Ejecución inicial de MGEN 

           

          Fuente: El Autor

 

5.3.1.2   Configuración del Receiver

 

Para configurar el PC receiver se realizaron los siguientes pasos:

 

  1. Se descarga la librería PCAP (Archivo libpcap-0.9.8.tar.gz)  para Linux, desde la página web http://www.tcpdump.org/release/

 

  1. Se procede a desempaquetar el archivo con el comando tar –xzvf libpcap-0.9.8.tar.gz

 

  1. Se accede al directorio /libpcap-0.9.8 y a continuación se realizar los siguientes pasos:

 

  1. Se ejecuta el comando ./configure

 

  1. Se ejecuta el comando make

 

  1. Se ejecuta el comando make install

 

  1. A continuación se comprueba la versión y las dependencias instaladas del compilador GCC

 

Figura 27.  Comprobación de Dependencias de GCC

   Fuente: El Autor.

 


6.        TESTBW

 

 

6.1    DESCRIPCION

 

La herramienta desarrollada fue denominada TESTBW, el cual funciona mediante la shell de comandos de Linux, y permite la captura y el cálculo de anchos de banda medidos en bps, de un enlace de red. Esta herramienta posee licencia GPL, y está desarrollada en su totalidad en lenguaje C. 

 

Testbw, captura la información de la trama Ethernet, la cual analiza y genera información como el Timestamp (Formato Segundos . microsegundos), la longitud del paquete medido en bytes, y el ancho de banda calculado que resulta del retardo entre el par de paquetes capturados en un intervalo de tiempo.

 

6.1.1        Log De Cambios

 

En el desarrollo de la herramienta se han realizado desde la creación del primer binario (Versión 0.0.1), varios cambios importantes que han permitido cumplir con los requerimientos iníciales del software.  A continuación se presentan los principales cambios que ha sufrido la herramienta, presentando su evolución en los diferentes incrementos desarrollados hasta el momento (Versión 0.0.5):

 

0.0.5:

  2008/06/22: Se Genera Makefile inicial y documentación para instalación.

  2008/06/20: Se modifica la manera de realizar el cálculo de los retardos en el tiempo.

  2008/06/19: Se Agrega en la salida el campo Bandwidth.

  2008/06/09: Se cambia la salida de las direcciones de origen y destino a direcciones IP

  2008/06/05: Se agrega lectura de interfaces de red con la opción -l i

0.0.4:

  2008/06/02: Se cambia la forma de ejecución del programa agregando -i para lectura

                    de la interfaz

  2008/05/26: Compilación bajo Backtrack Ver 3 y Ubuntu 7

 

0.0.3:

  2008/05/17: Se Modifica formato de salida del Timestamp a HH:MM:SS

  2008/05/10: Se agrega cabecera IP_hdr. Compilación bajo Knoppix 5.0.1

 

0.0.2:

  2008/04/28: Lectura de direcciones MAC desde cabecera Ethernet

  2008/04/25: Compilación bajo Knoppix 3.9

 

0.0.1:

  2008/04/18: Implementación de librerías inet.h e if_ether.h

  2000/04/10: Compilación inicial bajo Knoppix 3.8

 

6.1.2        Plataformas Probadas

 

La herramienta se probó con el último binario compilado en las siguientes plataformas Linux y Unix, de forma exitosa:

 

   * Knoppix 5.0.1

   * Knoppix 3.9

   * Knoppix 3.8

   * Ubuntu 8

   * Backtrack 3

   * SuSe Linux 10.1

   * FreeBSD

Lo anterior indica que podría funcionar sobre otras plataformas como, CentOS, Red Hat o Fedora.

 

6.2    INSTALACION

 

Antes de instalar Testbw se requiere que esté previamente instalado en la máquina receiver la librería PCAP[15].  Además es deseable la siguiente configuración de hardware y software mínima:

 

Tabla 2. Requerimientos mínimos para la instalación de la herramienta

Componente

Especificación mínima

Procesador

Pentium II de 450 MHz

Memoria RAM

256 MB

Disco Duro

80 GB

Tarjetas de Red

10/100 Mbps FastEthernet

Sistema Operativo

GNU/Linux (Deseable Debian, Ubuntu, Knoppix)

Librería

libpcap Ver 0.9.8

Compilador

GCC Ver 4.1.2 o superior

Generador de Tráfico

MGEN Ver 3.0 o Superior

            Fuente: El Autor

 

Para realizar la instalación de la herramienta es necesario descomprimir y desempaquetar el archivo testbw-0.0.5.tar.gz utilizando el comando tar-xzvf testbw-0.0.5.tar.gz estando previamente ubicado en el directorio de instalación del usuario por ejemplo /home/dbotia/.

 

 

Al momento de descomprimir la herramienta, entrar al directorio testbw-0.0.5 y en este se encontrará la estructura mostrada en la siguiente figura 28:

 

Figura 28. Estructura del Programa Testbw

Fuente: El Autor

 

A continuación se describe su principal contenido:

 

 

El siguiente paso se divide en 3 partes mostradas en la figura 29:

 

    1. Se ejecuta el comando make clean el cual limpia las dependencias existentes

 

    1. Luego se ejecuta el comando make que compila los fuentes

 

    1. Por último se ejecuta ahora el comando make install

 


Figura 29. Instalación de Testbw

Fuente: El Autor

 

A continuación se verifica la existencia del binario testbw dentro del directorio src, el cual se muestra en la  figura 30:

 

Figura 30. Verificación del Binario compilado

Fuente: El Autor

 


6.3   EJECUCION DE LA HERRAMIENTA

 

 

La herramienta una vez instalada, se ejecutará desde el Shell de comandos del usuario de la siguiente forma:

 

1.      La herramienta tiene como sintaxis esta forma:

 

a.       ./testbw –i <interfaz>  donde interfaz debe ser un nombre de NIC valido. Ejemplo eth0 o eth1.

 

b.      ./testbw –l  i  Este comando permite ver el listado de las interfaces de red detectadas por la herramienta.

 

2.      Una vez se ejecute la herramienta aparecerá el siguiente mensaje:

 

Figura 31: Ejecución Inicial de Testbw

Fuente: El Autor

 

3.      Para comprobar su correcta ejecución se procede a realizar un ping (enviando tráfico ICMP), desde el sender. A continuación se presenta la captura de los paquetes ICMP enviados hacia el equipo receiver utilizando IPTRAF:

 


Figura 32: Captura con IPTRAF

Fuente: El Autor

 

4.      A continuación aparece la salida de una captura realizada por la herramienta:

 

Figura 33. Captura de tráfico con testbw

Fuente: El Autor

 

En la Figura 33, se presenta la salida con el Timestamp, la longitud del paquete IP (bytes)  y el Bandwidth (bps) calculado. 

 

 

Es indispensable que se verifique previamente que el equipo tenga conexión a la red y que este correctamente configuradas las NICs como se mostro en la sección 5.3.1.1.

 

 

 

 

 

 

 

 

 

 

 

 


7.    ANALISIS DE RESULTADOS

 

 

 

Mediante el Testbed desarrollado, se procedió a generar tráfico desde MGEN (De tipo Periódico y Poisson) primero de un 30% (Aproximadamente 381 paquetes/seg) y luego de un 60% (Aproximadamente 742 paquetes/seg) del total del canal, el cual tiene un Ancho de Banda de 10 Mbps (Canal disponible de la red LAN probada).

 

Para el primer caso utilizando tráfico periódico desde MGEN por el puerto 5001; se procedió a ejecutar el siguiente comando desde Ubuntu:

 

./mgen event "ON 1 UDP DST 172.16.2.2/5001 PERIODIC [381 982]"

./mgen event "ON 1 UDP DST 172.16.2.2/5001 PERIODIC [742 982]"

 

A continuación se presenta la respectiva salida:

 

Figura 34: Generación de Tráfico Periódico al 30% y 60% del tamaño del canal

Fuente: El Autor

 

En el primer comando se enviaría un tráfico promedio de 2.993.136 bits es decir 3 Mbps.  En el segundo comando se enviaría un tráfico de 5.829.152 bits es decir 5.8 Mbps.

 

Es importante tener en cuenta que la variable dependiente (Bandwidth), fue generada en una escala de x106 es decir en el orden de los Mbps, mientras que la variable independiente (tiempo) se generó en segundos como unidad de medida principal.

 

A continuación se presentan gráficamente los resultados generados por la traza del tráfico Periódico del primer comando durante un tiempo de 10 Segundos, para 1892 paquetes capturados (Ver anexo3): 

 

Figura 35.  Bandwidth calculado del 30% del canal usando distribución Periodic

Fuente: El Autor

La anterior salida indica que durante un periodo de captura de 10 Segundos, el ancho de banda se mantuvo estable como se esperaba, es decir, alrededor de los 3 Mbps, también se puede apreciar la gran cantidad de paquetes que se recibieron entre cada segundo, lo cual, podría ser más visible en redes multiprotocolo del orden de Gbps.  Se presenta una captura en un lapso de 10 segundos, para presentar de forma más clara los datos. 

 

En la figura 36 se aprecia durante el mismo tiempo, la captura del bandwidth usando el 60% de la capacidad del canal (Ver Anexo 4):

 

Figura 36: Bandwidth calculado del 60% del canal usando distribución Periodic

Fuente: El autor

 

En la anterior figura, el rango del ancho de banda comparado con la Figura 35, es un poco más separado, el cual esta aproximadamente entre 5.8 Mbps y 6.2 Mbps. 

Aunque existen más puntos dispersos, son tráficos mínimos y no afectan los cálculos globales, mientras que los puntos ubicados cerca a la abscisa de cero Mbps, representan tráfico normal de control entre los Host.  Otra característica importante es que entre cada segundo se realizo una mayor captura de paquetes que en el caso de la Figura 35, lo cual indica que en cada segundo se incrementa sensiblemente el tráfico, ocupando más el canal, por lo que se requeriría un manejo adecuado del QoS (Calidad de Servicio) en la red y más cuando se puedan tener cientos o miles de usuarios concurrentes en ella. 

 

El segundo caso fue utilizando tráfico con patrón Poisson desde MGEN por el puerto 5001; para lo cual se procedió a ejecutar el siguiente comando desde Ubuntu:

./mgen event "ON 1 UDP DST 172.16.2.2/5001 POISSON [381 982]"

./mgen event "ON 1 UDP DST 172.16.2.2/5001 POISSON [742 982]"

 

A continuación se presenta la respectiva salida:

 

Figura 37: Generación de Tráfico Poisson al 30% y 60% del tamaño del canal

Fuente: El Autor

 

Cuando se realiza la gráfica con la traza de tráfico capturado del 30% de la ocupación del canal (Ver Anexo 5), se obtiene lo siguiente:

 

 

 

Figura 38: Bandwidth calculado del 30% del canal usando distribución Poisson

Fuente: El Autor

 

La anterior gráfica presenta datos dispersos, debido a que el planificador de procesos del Sistema operativo está dando mayor prioridad a otros procesos y el Kernel puede no haber capturado algunos paquetes durante el filtrado de datos. Otra posible razón es debido al tiempo de tránsito entre los switches hacia el router utilizado, o a errores de configuración de los IOS de estos equipos. En este caso como se observa en la figura la mayor cantidad de datos se encuentra aproximadamente entre 1 Mbps y los 3Mbps.

 

En la figura 39 se presenta, la captura del bandwidth usando el 60% de la capacidad del canal (Ver Anexo 6):

 

Figura 39.  Bandwidth calculado del 60% del canal usando distribución Poisson

Fuente: El Autor

 

Al igual que en el caso anterior en esta figura se observa que la mayor cantidad de tráfico se encuentra entre los 3 Mbps y los 5 Mbps. Aunque el ancho de banda es disperso, también podría indicar que se ha presentado mayor consumo de canal en las aplicaciones en tiempo real con respecto a otras aplicaciones que consumen menos ancho de banda.

 

En el Siguiente capítulo se analizará estadísticamente estas mediciones, para confirmar los resultados.

 

 

8. ANÁLISIS ESTADÍSTICO

 

 

 

El análisis estadístico permite recopilar, manejar, interpretar, analizar, agrupar, y presentar datos en cuadros o gráficas para su interpretación. En este trabajo, para las mediciones obtenidas de tráfico en la red, se realizaron a través de los métodos de distribución estadísticos Periódicos y Poisson. Los resultados logrados muestran que a un mayor nivel de tráfico, se obtiene mayor número de muestras del ancho de banda utilizado. No obstante, el análisis de error de los datos, se realizará estimando los errores medios, absolutos, relativos y cuadráticos, para encontrar un error total de las medidas. Lo anterior permite comprender los siguientes puntos: Qué porcentaje de tráfico es o no permisible de error?, Cuál método estadístico proporciona menor y/o mayor error?, Qué tan exacto y preciso son los datos?, Se está aprovechando o desperdiciando ancho de banda?.

 

Para resolver estas incógnitas se utilizarán herramientas computacionales como Microsoft Excel 2007 para los cálculos de error, y Matlab 7.1.0.256 para representar los gráficos de las funciones de Gauss empleando la función stem (gráficos discretos secuenciales), como estrategia para observar la campana de Gauss en forma de histograma.

 

A continuación, se realizará el análisis respectivo a cada uno, siguiendo un procedimiento estricto y riguroso.

 

 

 

 

 

 

8.1 DISTRIBUCIÓN PERIÓDICA

 

 

8.1.1 DISTRIBUCIÓN PERIÓDICA PARA EL 30% DE ANCHO DE BANDA DEL ENLACE DE RED

 

De acuerdo a los datos adquiridos del ancho de banda con respecto al tiempo, se realizó un seguimiento en tiempo real de su comportamiento, entre 0 y 10 s. Se obtuvieron alrededor de 1891 muestras con un tiempo de muestreo promedio de 0,0052493 s o 5,2493 ms.

 

Siguiendo una serie de pasos para el análisis estadístico de estos datos, se calculan en primer lugar la media aritmética o media, la mediana y la moda.

 

Según Spiegel [36], la media aritmética es un valor representativo de un conjunto de datos, el cual suele situarse en el centro del conjunto de datos. Por lo general, la media se conoce habitualmente como el promedio de tendencia central, cuya expresión matemática está dada por:

                                                                                                       (1)

 

Por otro lado, la mediana es el valor central más próximo a la media, o la media que divide en dos partes la distribución de los datos. Su expresión matemática está dada por:

 

 

Como se aprecia en la ecuación (2), L es el límite inferior de los datos, n es el número de muestras, Σf es la suma de datos, fmediana es el valor de la clase de la mediana o la frecuencia de la clase de la mediana y c es el ancho del intervalo de los datos (límite superior – límite inferior).  Según Lind, Marchal y Mason [37], la moda es el valor de la observación que aparece con más frecuencia, el cual cumple la siguiente ecuación matemática:

                                          

                                                                                            (3)

 

 

De acuerdo a la ecuación (3), Δ1 y Δ2 son los excesos de los datos inferior y superior con respecto a la media, respectivamente. Teniendo en cuenta las ecuaciones (1), (2) y (3), por medio del Microsoft Excel 2007 se realizaron los respectivos cálculos. Los resultados que se encontraron son: Media = 3.02743037 Mbps, Mediana = 3.154409 Mbps y Moda = 3.155624 Mbps.

 

Teniendo en cuenta estos valores calculados, el siguiente punto es calcular los errores generados en la adquisición de datos durante los 10 s de muestreo en tiempo real. Estos errores se explican de acuerdo a las desviaciones de los datos con respecto a la media, y las variaciones mismas.

 

Según Creuss [38], el error es la diferencia algebraica entre el valor leído o transmitido y el valor real de la variable medida. Esta suma suele tomarse como un error total de las mediciones, como la raíz cuadrada de la suma algebraica de los cuadrados de los errores presentados en la medición. Matemáticamente se expresa como:

 

                                                                                    (4)

 

Los errores más comunes que se desarrolla en este tipo de mediciones son variadas, pero se van a considerar tres fundamentales, muy comunes para este tipo de adquisición de información. Según Creuss [38], el error medio o em es la media aritmética de los errores en cada punto de la medida determinados para valores crecientes y decrecientes de la variable medida. Esta clase de error es también llamado error promedio, que suele generarse para este caso por pérdidas de la línea de transmisión (UTP-5), retardos en el envío y recepción de datos, velocidad de procesamiento de los datos, variaciones pequeñas del ancho de banda, entre otras posibles causas. Este error, debido a su complejidad matemática, se calcula con una función especial de estadística de Microsoft Excel 2007 llamada ERROR.TIPICO.XY.

 

Según Spiegel [36], el error absoluto o desviación media es la variación de los datos con respecto a la media, como un valor absoluto de la resta de ambos valores. Por lo general, se expresa en términos de sumatoria de todas las restas, cuya ecuación característica es:

                                                                                                          (5)

 

Este tipo de error va a representar como el máximo error de las mediciones en el peor de los casos. Por último, el error relativo es el mínimo error de las mediciones obviando algunas consideraciones, que en algunos casos, suele llamarse zona muerta o campo de valores de la variable que no se puede variar o no produce una medición fija, que es muy pequeña pero significante para el cálculo de errores. Según Cooper y Helfrick [39], el error relativo se expresa como una desviación promedio para indicar la precisión de los datos con respecto a la media. Su expresión matemática así:

 

                                                                                                                        (6)

 

 

A partir de las ecuaciones (5) y (6), y empleando el software mencionado, los resultados de los errores son las siguientes: em = 2,866397361% o 0,028663974 bps, MD = 0,67000066 bps o 0,0067000066 % y D = 0,00035431 bps o 0,03543102%. Con base a estos errores, se calcula el error total de la ecuación (4), cuyo resultado es 0,670613628 bps o 0,00670613628%. Este error total es muy bajo, lo cual satisface las condiciones deseadas con un 30% de tráfico de la red.

 

Existe una clase de error muy utilizado denominado error cuadrático o desviación estándar, empleado para analizar los posibles errores aleatorios de la medida. Según Cooper – Helfrick [39], la desviación estándar de un número infinito de datos es la raíz cuadrada de la suma de todas las desviaciones cuadradas individuales, divididas entre el número de lecturas. Sin embargo, en la práctica, el número posible de datos es finito, lo cual está dado por:

                                                                                                (7)

 

 

Según Spiegel [36], cuando el número de muestras son mayores a 30, se debe considerar un número de muestras (n – 1) para una mejor estimación de los cálculos. La ecuación (7), debido a la anterior aclaración es llamada habitualmente desviación típica. Por lo tanto, al dividir la desviación típica por la raíz cuadrada del número de muestras, se encuentra la desviación estándar con estimación, para grandes cantidades de muestras, cuya ecuación característica es la siguiente:

 

                                                                                     (8)

 

 

Teniendo en cuenta las ecuaciones (7) y (8), los resultados obtenidos con el software mencionado son las siguientes: σn-1 =  607554,4968 bps y σx = 13971,38548 bps. En la tabla 3 se presenta el resumen de los resultados de cálculos estadísticos que se obtuvieron.

 

Tabla 3. Resultados de cálculos estadísticos para, distribución periódica del 30% de ancho de banda de enlace de red

Media

3027430,37 bps

Mediana

3154409 bps

Moda

3155624 bps

Error Medio

0,028663974 bps (2,8663974 %)

Error Absoluto

0,670000664 bps (0,00670000664%)

Error Relativo

0,00035431 bps (3,5431x10-6 %)

ERROR TOTAL

0,670613628 bps (0,00670613628 %)

Desviación Típica

607554,4968 bps

Desviación Estándar

13971,38548 bps

Fuente: El  Autor

 

Para poder observar el efecto de la desviación estándar en las mediciones obtenidas, se realiza una grafica de la función de Gauss o distribución normal en forma de un histograma o diagramas de bloques. Según Spiegel [36], la función de distribución normal o gaussiana esta expresado en términos de la desviación estándar y la media, como se muestra a continuación:

 

                                                                              (9)

 

 

Teniendo en cuenta que los valores de x son del ancho de banda en cada lapso de tiempo, reemplazamos los valores en la ecuación (9).  Por medio de Matlab, se obtiene una gráfica de Función Gaussiana vs Ancho de Banda, como se observa a continuación:

 

 

 

 

 

Figura 40. Distribución periódica para un 30% de ancho de banda del enlace de red

Fuente: Autor

 

En la figura 40, la media está muy cercana al ancho de banda de 3 Mbps que se realizó para las mediciones respectivas. Debido a lo anterior, se puede decir que tiene una buena exactitud y precisión, por lo cual, la media está muy próxima al valor verdadero o real del ancho de banda; esto muestra que el margen de error es muy pequeño.

 

En la siguiente tabla, se observa el comportamiento de las distribuciones normales de la figura 40.

 

Tabla 4. Distribuciones Normales para 30% de ancho de banda de enlace de red

Media - Desviación Estándar

3013458,984 bps

Media + Desviación Estándar

3041401,755 bps

Media - Doble Desviación Estándar

2999487,599 bps

Media + Doble Desviación Estándar

3055373,141 bps

Media - Triple Desviación Estándar

2985516,213 bps

Media + Triple Desviación Estándar

3069344,526 bps

Fuente: El Autor

 

Cuando se muestra la media +/- desviación estándar, se está considerando al 68,27 % del área de la campana de Gauss; entre la media +/- doble de la desviación estándar se considera al 95,45 %; entre la media +/- triple de la desviación estándar se considera el 99,73%. Al observar la tabla, se puede apreciar que el ancho de la campana es muy pequeño, porque los valores están muy próximos a la media, en los casos que se analizaron. Además el error total (0,00670613628 %) es muy pequeño.

 

 

8.1.2 DISTRIBUCIÓN PERIÓDICA PARA EL 60% DE ANCHO DE BANDA DEL  ENLACE DE RED

 

Siguiendo los mismos pasos del anterior caso, se analiza los datos con 3701 muestras, tomada en un tiempo de muestreo aproximado de 0,0027027 s o 2,7027 ms. De acuerdo a los cálculos realizados en Microsoft Excel 2007, se determinaron cada uno de los valores que se explicaron anteriormente, que se resume en la siguiente tabla:

 

Tabla 5. Resultados de cálculos estadísticos para distribución periódica, del 60% de ancho de banda de enlace de red.

Media

8478187,494 bps

8,478187494x106 bps

0,008478187494x109 bps

Mediana

5872401 bps

Moda

5859800 bps

Error Medio

0,028804878 bps  (2,880487817 %)

Error Absoluto

0,706084177 bps  (0,00706084177 %)

Error Relativo

0,000190782 bps  (1,90782x10-6 %)

ERROR TOTAL

0,706671509 bps o (0,007066715 %)

Desviación Típica

79132798,33 bps

Desviación Estándar

1300759,424 bps

Fuente: El Autor

 

De acuerdo a la anterior tabla, el error total de las mediciones es mayor que el error total calculado para el 30% del ancho de banda. Sin embargo, un error total de 0,007066715% se considera pequeño.  Una de las razones por el cual el error total es muy bajo se debe a que la mediana (5,872401 Mbps)  y la moda (5,8598 Mbps) están muy próximas al valor verdadero (6 Mbps).

 

En la figura 41, se muestra la gráfica obtenida en Matlab.

 

Figura 41. Distribución Periódica para 60% de ancho de banda del enlace de red, ( Media = 0,008478187494x109 bps).

Fuente: Autor

 

En la figura 42, se muestra la gráfica para la media, moda y mediana, en escala x106 bps para ancho de banda.


Figura 42. Distribución Periódica para 60% de ancho de banda de enlace de red, (en escala x106 bps para ancho de banda)

Fuente: El Autor

 

Aunque la media está por encima del valor real de 6 Mbps, el ancho de la distribución es muy estrecho, garantizando de esta manera una aceptable exactitud y buena precisión de los datos.

 

En la tabla 6, se aprecia la distribución normal para 60% de ancho de banda.

 

Tabla 6. Distribuciones Normales para 60% del ancho de banda del enlace de red

Media - Desviación Estándar

7177428,07 bps

Media + Desviación Estándar

9778946,919 bps

Media - Doble Desviación Estándar

5876668,646 bps (≈5,88Mbps)

Media + Doble Desviación Estándar

11079706,34 bps

Media - Triple Desviación Estándar

4575909,221 bps

Media + Triple Desviación Estándar

12380465,77 bps

Fuente: El Autor

 

 

La mejor aproximación es la región comprendida entre la media – doble de la desviación estándar porque su valor está muy próximo al valor real del ancho de banda de 6 Mbps.

 

8.2 DISTRIBUCIÓN DE POISSON

 

 

8.2.1 Distribución de Poisson Para 30% de Ancho de Banda de Enlace de Red

 

 

Siguiendo el mismo procedimiento explicado anteriormente, se obtuvo 1864 muestras; el tiempo de muestreo que se desarrollo para obtener está cantidad de muestras es aproximadamente 0,0053673 s o 5,3673 ms.

 

En la tabla 7, se muestra los cálculos estadísticos obtenidos a través de Microsoft Excel 2007.

 

Tabla 7. Resultados de cálculos estadísticos para distribución de Poisson, para 30% de ancho de banda del enlace de red.

Media

6976918,399 bps

6,976918399x106 bps

0,006976918399x109 bps

Mediana

5126408 bps

Moda

10252816 bps

Error Medio

0,028778007 bps (2,877800667%)

Error Absoluto

0,263975117 bps (0,00263975117 %)

Error Relativo

0,000141618 bps (1,41618x10-6 %)

ERROR TOTAL

0,26553918 bps (0,002655392 %)

Desviación Típica

63219272,31 bps

Desviación Estándar

1464288,119 bps

Fuente: Autor

 

El error total de las mediciones para una distribución de Poisson para el 30% de ancho de banda, es más pequeño que los obtenidos para la distribución periódica para 30% y 60% de ancho de banda.

 

En la figura 43, se muestra la gráfica obtenida en Matlab, para una distribución de Poisson, para 30% de ancho de banda.

 

Figura 43. Distribución de Poisson para 30% de ancho de banda de enlace de red (Media = 0,006976918399x109 bps).

Fuente: El Autor

 

En la figura 44, se muestra la gráfica para la media, la moda y mediana en escala x106 bps para ancho de banda.

 

 

 

 

 

 

Figura 44. Distribución de Poisson para 30% de ancho de banda de enlace de red, ( en escala x106 bps para ancho de banda)

Fuente: El Autor

 

Al analizar el comportamiento de la campana de Gauss, se puede apreciar que esta sesgada a la izquierda (el sesgo es el grado de asimetría de una distribución o cuánto se aparta de la simetría). Para comprobar la anterior afirmación, según Spiegel [36], el sesgo se define matemáticamente como la resta entre la media y la moda, dividido por la desviación típica.

 

                                                                                              (10)

 

Reemplazando los valores de la tabla, el sesgo calculado es -0,0518 que es un sesgo negativo muy pequeño, lo cual indica que esta algo corrida la media hacia la izquierda con respecto a la moda. Por esta razón, existen algunos valores dispersos en la función de distribución de Poisson durante la adquisición de datos del ancho de banda.

 

En la tabla 8, se muestra la distribución de Poisson para un 30% de ancho de banda.

 

 

Tabla 8. Distribución de Poisson, para 30% de ancho de banda del enlace de red.

Media - Desviación Estándar

5512630,28 bps

Media + Desviación Estándar

8441206,518 bps

Media - Doble Desviación Estándar

4048342,162 bps

Media + Doble Desviación Estándar

9905494,637 bps

Media - Triple Desviación Estándar

2584054,043 bps (≈2,584 Mbps)

Media + Triple Desviación Estándar

11369782,76 bps

Fuente: El Autor

 

La mejor aproximación es la región comprendida entre la media – triple de la desviación estándar, porque su valor es próximo al valor real de ancho de banda de 3 Mbps.

 

8.2.2 Distribución de Poisson Para el 60% de Ancho de Banda de Enlace de Red

 

Para este último caso, se obtuvieron cerca de 3800 muestras con tiempo de muestreo del ancho de banda aproximado de 0,00263219 s o 2,63219 ms. En la tabla 9, se muestran los cálculos estadísticos obtenidos con Microsoft Excel 2007.

 

Tabla 9. Resultados de cálculos estadísticos para distribución de Poisson, para 60% de ancho de banda del enlace de red

Media

8497384,581 bps

8,447384581x106 bps

0,008497384581x109 bps

Mediana

9112347 bps

Moda

10252816 bps

Error Medio

0,02880327 bps (2,880327%)

Error Absoluto

0,800044119 bps (0,00800044119%)

Error Relativo

0,000210538 bps o (2,10538x10-6 %)

ERROR TOTAL

0,800562468 bps (0,0080562468 %)

Desviación Típica

44296999,66 bps

Desviación Estándar

718592,2237 bps

Fuente: El Autor

 

El valor de error total (0,0080562468 %), es relativamente más alto comparado con los resultados obtenidos para los tres casos anteriores. Sin embargo, el error total sigue considerándose pequeño y aceptable.

 

En la figura 45, se muestra la gráfica obtenida en Matlab, para una distribución de Poisson, para 60% de ancho de banda.

 

Figura 45. Distribución de Poisson para 60% de ancho de banda del enlace de red (Media = 0,008497384581x109 bps).

Fuente: El Autor

 

En la figura 46, se muestra la gráfica para la media, moda y mediana, en escala x106 bps para ancho de banda.

 

 

 

 

 

Figura 46. Distribución de Poisson para 60% de ancho de banda del enlace de red, ( en escala x106 bps para ancho de banda)

Fuente: El Autor

 

Aplicando la ecuación (10), el sesgo calculado es -0,396 que es un sesgo negativo pequeño, lo cual, indica que la media esta corrida a la izquierda con respecto a la moda y que existen algunos valores dispersos.

 

En la tabla 10, se muestra la distribución de Poisson para un 60% de ancho de banda.

 

Tabla 10. Distribución de Poisson, para 60% de ancho de banda del enlace de red

Media - Desviación Estándar

7778792,357 bps

Media + Desviación Estándar

9215976,804 bps

Media - Doble Desviación Estándar

7060200,133 bps

Media + Doble Desviación Estándar

9934569,028 bps

Media - Triple Desviación Estándar

6341607,91 bps (≈6,34 Mbps)

Media + Triple Desviación Estándar

10653161,25 bps

Fuente: Autor

Como en el caso de la distribución de Poisson, para 30% de ancho de banda de enlace, la mejor aproximación es la región comprendida entre la media – triple de la desviación estándar, porque su valor es próximo al real de ancho de banda de 6 Mbps.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


  1. CONCLUSIONES

 

 

 

Gracias al uso del software libre, se generan aplicaciones realmente interesantes además de que permite la reutilización de código para adaptar los aplicativos a las necesidades del programador y esto se comprobó en el desarrollo del proyecto.

 

La librerías PCAP son fundamentales para el desarrollo de software para redes en ambientes multiplataforma que lo hacen necesario para el éxito de este tipo de proyectos.

 

Se puso en práctica todos los conocimientos y teorías dadas en la maestría, lo cual hizo que los objetivos propuestos en el proyecto se alcanzaran con éxito.

 

La medición de Anchos de Banda en un enlace de red en tiempo real, permite optimizar los canales de transmisión, así como permiten determinar cuáles Host pueden generar mayor saturación de tráfico en una red.

 

El ancho de banda calculado mediante la distribución de Poisson, genera valores dispersos, los cuales se deben a diferentes causas entre las que se destacan, la planificación de procesos en el kernel, tiempos de retardo pequeños entre los nodos de transito, configuración del IOS del router o switches utilizados, entre otros.

 

El uso del lenguaje C permite el desarrollo de aplicaciones flexibles, las cuales pueden aprovechar las características del Kernel de Linux.

 

Se comprobó cómo se puede procesar de una mejor forma las Tramas Ethernet, analizando y entendiendo su cabecera, para deducir la información que se deseaba generar.

 

El análisis de los datos de salida calculados, indican que a menor retardo entre  paquetes, mayor ancho de banda se consume. 

 

Las gráficas indican la importancia de la configuración de prioridades de tráfico, sobre todo en servicios no orientados a la conexión (Ejem: UDP, RTP, SIP, etc), en donde la transmisión de Voz y Video son muy sensibles tanto a los retardos como a los Jitters que se puedan encontrar en la Red.

 

Los errores de medición se deben a pérdidas de las líneas de transmisión, latencia, velocidad de procesamiento de datos, y variaciones pequeñas de ancho de banda, entre otras, que contribuyen a la dispersión de datos.

 

Según el análisis estadístico, los errores totales de las mediciones son relativamente pequeños para la distribución periódica y de Poisson, para 30% y 60% de ancho de banda del enlace de red, lo cual, índica la exactitud y precisión de las mediciones con respecto al valor real de 3 Mbps y 6 Mbps.

 

Para la distribución de Poisson, para 30% y 60% de ancho de banda de enlace de red, los sesgos calculados son negativos, pero pequeños, lo cual, muestra que existen valores dispersos, aunque muchos valores están muy cerca al valor real.

 

Un parámetro que caracteriza la dispersión de los datos es la incertidumbre que generan los errores, debido a las imperfecciones naturales de la medida, el principio, método y procedimiento de las mediciones del ancho de banda, y a la baja repetibilidad de la lectura de los valores

El uso de Generadores de Tráfico especializados, facilita el análisis de la información, por parte de la herramienta desarrollada.

 

El campo de estimación de Anchos de Banda es muy amplio y pueden generarse muchos proyectos de investigación interesantes, relacionados con la optimización del enlace y el ancho de banda realmente requerido.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


  1.  RECOMENDACIONES  Y TRABAJOS FUTUROS

 

 

 

Profundizar en el estudio de las mediciones de anchos de banda especialmente aplicando teoría de colas.

 

Actualización continúa de los avances en el desarrollo de nuevos protocolos de red.

 

Tener conocimientos del sistema operativo Linux y en el uso del API Libpcap

 

Realizar mediciones de Anchos de Banda por medio de redes VPN y / o redes WAN.

 

Mejorar la función de captura de los timestamps de los paquetes enviados para el tráfico con patrón Poisson.

 

Aplicar modificaciones a la herramienta para la medición de anchos de banda sobre redes WLAN (Utilizando estándar IEEE 803.11).

 

Generar soporte hacia el Protocolo IPv6.

 

Generar compatibilidad de la herramienta con Sistemas Operativos Windows por medio de la librería WinPap.

 

Adaptar la herramienta a un entorno gráfico utilizando el lenguaje de programación JAVA por medio del API JPCAP. 

 

Generar mediciones a dispositivos activos como Access Points y Routers

11.  BIBLIOGRAFÍA

 

11.1  LIBROS

 

[1] KUROSE, James F. ROSS, Keith. Redes de Computadores. Un Enfoque descendente basado en Internet. Segunda Edición. Ed Pearson. 2004. Madrid - España. 739p.

[2] ORDINAS, José Maria. Otros.  Redes de Computadores. Ed. UOC. Master Software Libre. Barcelona – España. 2004.  351p.

[3] STALLING, William. Comunicaciones y redes de computadores, sexta edición. Editorial Prentice Hall, Madrid - España, 2001.

[4] ___________,_______. Redes e Internet de alta Velocidad: Rendimiento y Calidad de Servicios. Segunda Edición. Ed Pearson Educación. Madrid - España. 2004. 729p.

[5] TANENBAUM, Andrew S. Redes de Computadoras, Cuarta edición. Editorial Pearson, México, 2003. 891p

[6] ALFARO, Joaquin. PERRAMAN TORNIL, Xavier. Aspectos avanzados de seguridad en Redes. Ed. UOC. Master Software Libre. Barcelona – España. 2004.  410p.

[7] R. Braden. Rfc 1122: Requirements for internet hosts - communication layers info. Technical report, Internet Engineering Task Force, October 1989.

[8] C. S. McCane and V. Jacobson. The bsd packet filter: A new architecture for user-level packet capture. In Proceedings of the Winter USENIX Conference, volume 93, pages 259–269, San Diego, California, 1993

[9] J. Postel. Rfc 768: User datagram protocol. Technical report, August 28 1980.

[10]  _______. Rfc 791: Internet protocol. Technical report, September 1981.

[11] _______. Rfc 793: Transmission control protocol. Information Sciences Institute, University of Southern California, page 91, 1981.

 

 

11.2   REVISTAS

 

[12] GONT, Fernando. Sniffeando redes con tcpdump. Revista @rroba. Nro 104. Año IX. Pag 44-50. ISSN: 1138-1655.  España. Mayo de 2006.

[13] GONT, Fernando. Sniffeando redes con tcpdump II. Revista @rroba. Nro 108. Año IX. Pag 14-19. ISSN: 1138-1655.  España. Septiembre de 2006.

[14] MENENDEZ, Juan Manuel. Estudio Práctico del TCP. Revista Solo Programadores. Nro 54. Año VI. Pag 68-77. ISSN: 1134-4892. España. Mayo de 1999. 

[15] PALAZZOLI, Pierpaolo. Utilizando Snort-inline. Revista Haking9. Nro 19. Pag 30-43. ISSN: 1731-2930. Varsovia, Polonia. Diciembre 2006.

[16] SKWAREK, Lujasz. Descifrando los paquetes de Jabber – librería PCAP. Revista Haking9. Nro 19. Pag 44-49. ISSN: 1731-2930. Varsovia, Polonia. Diciembre 2006.

[17] WEGENER, Christoph. DOLLE, Wilhelm. Entendiendo y Evitando los Ataques TCP. TCP Hijacking. Revista Linux Magazine. Nro 11. Pag 71-76. ISSN: 1576-4079. España. 2004.

 

11.3   INVESTIGACIONES

 

[18] Information Systems Laboratory. [on-line] http://www.csee.usf.edu/islab/ . Department of Computer Science and Engineering.  University of South Florida. 2007

 


11.4   INFOGRAFIA

 

[19]   B . Adamson . S. Gallavan. Mgen tool [online], 1997.

[20] CARSTENS, Tim. Programming with pcap. [on-line]. http://www.tcpdump.org/pcap.htm. 2002.

[21] CERT ADVISORY CA-2001-09. Statistical Weaknesses in TCP/IP Initial Sequence Numbers. [on-line] http://www.cert.org/advisories/CA-2001-09.html. Septiembre de 2001.

[22] GUERRERO, Cesar. Herramientas para Generación de Trafico TCP y UDP. [on-line]. http://www.csee.usf.edu/~guerrerc/links/traf_gen.htm. University of South Florida. 2007

[23] IPTRAF. descripción de la herramienta IPTraf. [on-line] http://es.wikIPedia.org/wiki/IPTraf.  Febrero 2007

[24] JACOBSON, Van. LERES, Craig. McCANNE, Steven. pcap - Packet Capture library. [on-line] http://www.tcpdump.org/pcap3_man.html Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. 27 February 2004

[25] JONCHERAY, Laurent. Simple Active Attack Against TCP. [on-line]. http://www.usenix.org/publications/library/proceedings/security95/full_papers/joncheray.ps.

[26] LOPEZ MONGE, Alejandro. Aprendiendo a programar con Libpcap. [On-line].  http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf.  20 de Febrero de 2005

[27]  NMAP. Descripción de la herramienta NMAP. [on-line]. http://es.wikIPedia.org/wiki/Nmap. 28 de  Octubre 2007

[28] NRL. Naval Research Laboratory. Multi Generator MGEN. [on-line] http://cs.itd.nrl.navy.mil/work/mgen/index.php. 2007

[29] M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, S. Mascolo, "TCP Westwood: Congestion Window Control Using Bandwidth Estimation", [on-line]. http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_papers/TCPWGlobecomBasicPaperFinalDraft.pdf. In Proceedings of IEEE Globecom 2001, Volume: 3, pp 1698-1702, San Antonio, Texas, USA, November 25-29, 2001

[30] MRTG. Herramienta MRTG. [on-line]. http://es.wikIPedia.org/wiki/MRTG. Septiembre de 2007

[31] Packet Capture With libpcap and other Low Level Network Tricks. [on-line]. http://www.cet.nau.edu/~mc8/Socket/Tutorials/section1.html. NAU's Computer Systems Engineering.  2006

[32] RFC 793. Transmission Control Protocol. [on-line] http://rfc.net/rfc793.html.

[33]. TCPDUMP: the Protocol Packet Capture and Dumper Program.. [on-line]. http://es.wikIPedia.org/wiki/Tcpdump. 4 Septiembre 2007.

[34] WARREN, Paul. Herramienta IFTOP. [on-line] http://ex-parrot.com/~pdw/iftop/. Febrero de 2006.

[29] WIRESHARK. Description Wireshark network tool. [on-line] http://en.wikIPedia.org/wiki/Wireshark.  21 de Septiembre de  2007).

[35] ZALEWSKI, Michal. Herramienta p0f. [on-line]. http://www.stearns.org/p0f/README. 2004

 

 

11.5  BIBLIOGRAFÍA PARA ANÁLISIS ESTADÍSTICO

 

[36] SPIEGEL, Murray R. Estadística, Editorial McGraw-Hill. 2°Edición, España, 1991, p. 60-64 y 91-93.

 

[37] LIND, Douglas A; MARCHAL, William G; MASON, Robert D. Estadística para Administración y Economía, Editorial Alfaomega, 11°Edición, Colombia, 2004, p. 74.

 

[38] CREUS, Antonio. Instrumentación Industrial, Editorial Alfaomega, 6°Edición, Colombia, 1998, p 4-5.

 

[39] COOPER, William D; HELFRICK, Albert D. Instrumentación Electrónica Moderna y Técnicas de Medición, Editorial Prentice Hall, Primera Edición, México, 1996, p. 11-12. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ANEXOS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ANEXO 1.  CÓDIGO FUENTE DE LA HERRAMIENTA TESTBW

 

 

/*

    Este archivo es parte de Testbw.

 

    Copyright (C) 2008 DIEGO BOTIA

Este programa es software libre; puede redistribuirse y/o ser modificado

bajo los términos de la Licencia Pública General de GNU tal como es

 publicada por la Free Software Foundation; ya sea por la versión 3 de la Licencia,

 o(a su elección) cualquier versión posterior.

 

Este programa se distribuye; aún sin la garantía implícita de

COMERCIABILIDAD o IDONEIDAD PARA UN FIN DETERMINADO.  Vea la

Licencia Pública General de GNU para más detalles.

 

Debió haber recibido una copia de la Licencia Pública General de GNU

junto con este programa; si no es así, escriba a la Free Software Foundation,

Inc., 51 Franklin Street, Quinto Piso, Boston, MA  02110-1301, USA.

http://www.gnu.org/licenses/

 

*/

 

/*=============================================== file = testbw.c ===========

Estimador de Anchos de Banda. Este programa permite estimar a traves de la

captura de las cabeceras ethernet el ancho de banda en bps de un enlace.

=============================================================================

Creacion                    : 10-Abr-2008

Ultima Modificacion  : 22-Jun-2008

Version              : 0.0.5

Licencia             : Gplv3

-----------------------------------------------------------------------------

Modo de ejecucion:

Para capturar paquetes en una interfaz de red:

   ./testbw -i <Interfaz de Red>

Para detectar las interfaces de red existentes en el equipo:

   ./testbw -l I

-----------------------------------------------------------------------------

Salida:

El programa genera 5 columnas con la siguiente informacion:

<tiempo> <longitud del paquete IP> <bandwidth> <IP origen> <IP destino>

-----------------------------------------------------------------------------

Autor:  : Diego Jose Luis Botia Valderrama

          Maestria En Software Libre

          Universidad Autonoma De Bucaramanga (Colombia)

          Universidad Oberta De Catalunya (España)

Asesor Y Director   : Ph.D.(c)  Cesar Dario Guerrero Santander                                   

-----------------------------------------------------------------------------

Nota: Este programa es software libre. para mejoras, correcciones de bugs, o

      recomendaciones favor enviar un email a su autor: diego.botia@gmail.com

===========================================================================*/

 

//----- Seccion Include y Define --------------------------------------------

//DEFINICION DE LIBRERIAS

#include <stdlib.h>            // exit

#include <unistd.h>            // exit

#include <pcap.h>              // Libreria para la captura de paquetes

#include <arpa/inet.h>         // Sirve para inet_ntoa NETWORK TO ADDRESS

                               // Funciones de conversion de direcciones

#include <stdio.h>             // Entrada salida Estandar de C

#include <time.h>              // Funciones de Tiempo

#include <errno.h>             // Para manejo de errores

#include <netinet/in.h>        // Estructuras de las direcciones de red

#include <sys/socket.h>        // Funciones de sockets para networking

#include <netinet/if_ether.h>  // ETHER_ADDR_LEN

#define ETHERTYPE_IP  0x0800   // Define si el tipo de paquete ETHERNET es IP con 0x0800.

                               // Revisar el archivo/usr/includes/net/ethernet.h

 

//----- Prototipos de functiones ---------------------------------------------

int mostrar_interfaces_disponibles(void);

void pcap_handler2(u_char *args, const struct pcap_pkthdr *header,

  const u_char *packet);

double timeval_diff(const struct timeval *t_now, const struct timeval *t_prev);

 

//----- Variables globales ---------------------------------------------------

int* first_pck; // para indicar si se capturo el primer paquete   

pcap_t* handler; // enlaza el objeto pcap

 // Estructura de la cabecera Ethernet

 struct eth_hdr {

  u_char ether_dhost[ETHER_ADDR_LEN]; // Direccion de destino

  u_char ether_shost[ETHER_ADDR_LEN]; // Direccion de origen 

  u_short ether_type; // Tipo de paquete

};

//Estructura de la cabecera IP --->>>> RFC791

struct ip_hdr{

  #if __BYTE_ORDER==__LITTLE_ENDIAN  // Estandar POSIX manejo por arquitecturas

              unsigned int ip_hl:4; //Longitud de la cabecera

              unsigned int ip_v:4; //Version

  #endif

  #if __BYTE_ORDER==__BIG_ENDIAN

              unsigned int ip_v:4;  //Version

  unsigned int ip_hl:4;  //Longitud de la cabecera

  #endif

  u_int8_t ip_tos;  //Tipo de Servicio

  u_short ip_len; //Longitud Total     

  u_short ip_id; //Identificacion

  u_short ip_off;  //Fragment Offset Field

  #define IP_RF 0x8000  //Bandera para Fragmento reservado

  #define IP_DF 0x4000 //Bandera No Fragmente

  #define IP_MF 0x2000 //Bandera de Mas fragmentos

  #define IP_OFFMASK 0x1fff //Mascara para fragmentacion de Bits

  u_int8_t ip_ttl; //Tiempo de Vida

  u_int8_t ip_p; //Protocolo

  u_short ip_sum; //Checksum

  struct in_addr ip_src,ip_dst; //Direccion de origen y destino

};

 

/*=============================================================

Programa principal

=============================================================*/

int main(int argc,char **argv)

{

  const u_char *packet;

  char *DEVICE; //Para la captura de la interfaz de red

  struct pcap_pkthdr hdr; //Llamado a la estructura header de pcap

  struct pcap *handle; // enlaza el objeto pcap

  char errbuf[PCAP_ERRBUF_SIZE]; // pcap coloca los mensajes de error aca por medio de un arreglo

  bpf_u_int32 mask, net; //Mascara de red y direccion IP de la interfaz

 

  if(argc <= 2){

    fprintf(stderr,

      "Sintaxis:\n\t%s -i <interfaz de red>\n\t%s -l i <Solo -l i lista de interfaces>\n",

      argv[0],argv[0]);

    return -1;

  }

 

  switch(argv[1][1]){

    case 'i': if(argc>=3) {

      DEVICE=argv[2]; // Interfaz de red entrada por el usuario

      printf("dispositivo seleccionado: %s\n", DEVICE); 

      /*pcap_lookupnet determina los parametros de la tarjeta de red:        

      Argumentos: primero es la interfaz de red, el segundo es la

                                   direccion IP, el tercero la mascara de red y el último es el

                                   índice del búfer del eventual error. */

      if (pcap_lookupnet(DEVICE, &net, &mask, errbuf) == -1){

        fprintf(stderr,

          "Error de lectura de datos del dispositivo %s: %s\n",

          DEVICE,errbuf);

        return 1;

      }

      /* Con pcap_open_live se inicia la captura y rastreo de paquetes.

      Argumentos:

                                   1. Dispositivo de red.

                                   2. Tamaño máximo del paquete capturado, expresado en bytes.

                                   3. Es igual a 1 para que la NIC funcione en modo promiscuo

                                      Es igual a 0 para que la NIC funcione en modo estándar.

                                   4. Tiempo de espera de los paquetes en milisegundos.

                                   5. Puntero al búfer del eventual error en caso de cualquier falla*/

      if ((handler = pcap_open_live(DEVICE, 8096, 1, 1000, errbuf)) == NULL) {

        perror("Error: No se puede abrir el dispositivo\n");

        _exit(0);

      }

      //Mensaje de salida  antes de iniciar captura

      printf("\n** Activo para recibir paquetes, ctrl-c para exit **\n");

      //Llamado a pcap_loop pasando por parametro la funcion callback.

      first_pck = malloc(sizeof(int));

      *first_pck=1;

      while (1) {

 pcap_loop(handler, -1, pcap_handler2, NULL); // callback pcap_handler2 on new packet

        usleep(1);

      }

    }

    break;  //Termina primer case

  case 'l': 

    if(argc>=3) return mostrar_interfaces_disponibles();

    break;

  default:   //Si no es ningun case entonces opcion invalida

    fprintf(stderr,"Error: opción -%c no válida.\n",argv[1][1]);

    return 1;

    break;

  }   //Fin del Switch

  return 0;

} //Fin del Main

 

/*===========================================================================

Definicion de funciones

===========================================================================*/

 

//---------------------------------------------------------------------------

// Funcion callback

//---------------------------------------------------------------------------

 

void pcap_handler2(u_char *args, const struct pcap_pkthdr *header,

  const u_char *packet)

{

  u_char *ptr; // Imprime informacion de cabecera para las direcciones del HW

  struct pcap_pkthdr hdr; // Llamado a estructura pcap_pkthdr

  const struct ip_hdr *ip; // Puntero a mi estructura IP

  const struct eth_hdr *ethernet; // Almacena los headers de Ethernet

  struct timeval tstamp, inistamp; // Timestamp Actual para calculo de intervalos de tiempo

  double Bps;  // Almacena el resultado del calculo de los Anchos de Banda

  double sec_acum, sec_diff; // Tiempos en segundos

  double period=0.050; // Periodicidad de la estimacion

 

  // Definir posicion de los datos

  packet=pcap_next(handler,&hdr);

  if(packet==NULL){

    printf("No puede tomar el paquete\n");

    exit(1);

  }

  //Determina el header del paquete capturado

  ethernet = (struct eth_hdr *)(packet);

  if (*first_pck==1) {

    *first_pck=0;

    sec_acum=0;

    tstamp=header->ts;

    inistamp=header->ts;

  }

  sec_diff=timeval_diff(&header->ts, &tstamp);

  sec_acum+=sec_diff;

  printf("%11.6f\t",sec_acum); //Se imprime la estructura del tiempo...

  printf("%8d\t",hdr.len); // Imprime numero de bits observados cada period

  Bps=(hdr.len*8)/(sec_diff); // Calculo del BandWidth

  printf("%10.0f\n",Bps); //Bandwidth por cada paquete en bps

  tstamp=header->ts; //Asigna el contenido de la estructura a tstamp....para un nuevo paquete

} //Fin de funcion callback

 

//---------------------------------------------------------------------------

// Muestra las interfaces de red disponibles

//---------------------------------------------------------------------------

int mostrar_interfaces_disponibles(void){

  int i; // contador

  int n_interfaces=0; // Me cuenta el numero de interfaces detectadas

  pcap_if_t *nics;    // Permite extraer informacion de las interfaces

  pcap_if_t *d;      // Para la lista enlazada.....

 

  char errbuf[PCAP_ERRBUF_SIZE]; // Buffer de almacenamiento de error

 

  if(pcap_findalldevs(&nics,errbuf)==-1){

    printf("Error en la captura de las NICs %s\n",errbuf);

    exit(-1);

  }

  printf("Las NICs encontradas son:\n\n");

  for(i=0,d=nics;d;d=d->next,i++) //d->next permite que vaya a la siguiente definicion de la interfaz

  {

    printf("\t- [%s]", d->name); //Me imprime el nombre de la interfaz

    if (d->description) //Si hay datos Imprime la descripcion de la interfaz si existe

      printf(" (%s)\n", d->description);

    else

      printf(" (No hay descripción disponible)\n");

  }

  if(i==0) //En caso de no encontrar dispositivos

  {

    printf("\nNo se encontraron dispositivos válidos. Asegurese que este instalado Libpcap\n");

    return;

  }

  return n_interfaces;

}

 

 

//---------------------------------------------------------------------------

// Calcula la diferencia en segundos estre dos valotes timeval

//---------------------------------------------------------------------------

double timeval_diff(const struct timeval *t_now, const struct timeval *t_prev)

{

            double usecs_now;

           

            if (t_prev->tv_sec == 0 && t_prev->tv_usec == 0) return 0;

  usecs_now = (t_now->tv_sec - t_prev->tv_sec) * 1000000;

  usecs_now += (t_now->tv_usec - t_prev->tv_usec);

  return (double)usecs_now/(double)1000000.0;

}

ANEXO 2.  LICENCIA GPL

 

 

GNU GENERAL PUBLIC LICENSE

                       Version 3, 29 June 2007

 

 Copyright (C) 2007 Free Software Foundation, Inc. http://fsf.org/  Everyone is permitted to copy and distribute verbatim copies  of this license document, but changing it is not allowed.

 

                            Preamble

 

  The GNU General Public License is a free, copyleft license for software and other kinds of works.

 

  The licenses for most software and other practical works are designed to take away your freedom to share and change the works.  By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users.  We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to  any other work released this way by its authors.  You can apply it to your programs, too.

 

  When we speak of free software, we are referring to freedom, not price.  Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you  want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

 

  To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights.  Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

 

  For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received.  You must make sure that they, too, receive or can get the source code.  And you must show them these terms so they know their rights.

 

  Developers that use the GNU GPL protect your rights with two steps:

(1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

 

  For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software.  For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

 

  Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so.  This is fundamentally incompatible with the aim of protecting users' freedom to change the software.  The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable.  Therefore, we have designed this version of the GPL to prohibit the practice for those products.  If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

 

  Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary.  To prevent this, the GPL assures that patents cannot be used to render the program non-free.

 

  The precise terms and conditions for copying, distribution and modification follow.

 

                       TERMS AND CONDITIONS

 

  0. Definitions.

 

  "This License" refers to version 3 of the GNU General Public License.

 

  "Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

 

  "The Program" refers to any copyrightable work licensed under this License.  Each licensee is addressed as "you".  "Licensees" and "recipients" may be individuals or organizations.

 

  To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy.  The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.

 

  A "covered work" means either the unmodified Program or a work based on the Program.

 

  To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy.  Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

 

  To "convey" a work means any kind of propagation that enables other parties to make or receive copies.  Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

  An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License.  If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.

 

  1. Source Code.

 

  The "source code" for a work means the preferred form of the work for making modifications to it.  "Object code" means any non-source form of a work.

 

  A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

 

  The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an

implementation is available to the public in source code form.  A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

 

  The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.  However, it does not include the work's System Libraries, or general-purpose tools or generally available free

programs which are used unmodified in performing those activities but which are not part of the work.  For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

 

  The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

 

  The Corresponding Source for a work in source code form is that same work.

 

  2. Basic Permissions.

 

  All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met.  This License explicitly affirms your unlimited permission to run the unmodified Program.  The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.  This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

 

  You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.  You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright.  Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

 

  Conveying under any other circumstances is permitted solely under the conditions stated below.  Sublicensing is not allowed; section 10 makes it unnecessary.

 

  3. Protecting Users' Legal Rights From Anti-Circumvention Law.

 

  No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

 

  When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

 

  4. Conveying Verbatim Copies.

 

  You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any

non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

 

  You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

 

  5. Conveying Modified Source Versions.

 

  You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

 

    a) The work must carry prominent notices stating that you modified     it, and giving a relevant date.

 

    b) The work must carry prominent notices stating that it is  released under this License and any conditions added under section

    7.  This requirement modifies the requirement in section 4 to "keep intact all notices".

 

    c) You must license the entire work, as a whole, under this  License to anyone who comes into possession of a copy.  This  License will therefore apply, along with any applicable section 7  additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.  This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

 

    d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your  work need not make them do so.

 

  A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.  Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

 

  6. Conveying Non-Source Forms.

 

  You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

 

    a) Convey the object code in, or embodied in, a physical product including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium  customarily used for software interchange.

 

    b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the  Corresponding Source from a network server at no charge.

 

    c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source.  This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord

    with subsection 6b.

 

    d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge.  You need not require recipients to copy the  Corresponding Source along with the object code.  If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party)  that supports equivalent copying facilities, provided you maintain

clear directions next to the object code saying where to find the  Corresponding Source.  Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

 

    e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

 

  A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

 

  A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.  In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage.  For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product.  A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

 

  "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source.  The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

 

  If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information.  But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

 

  The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed.  Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

 

  Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

 

  7. Additional Terms.

 

  "Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law.  If additional permissions

apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

 

  When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it.  (Additional permissions may be written to require their own removal in certain cases when you modify the work.)  You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

 

  Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

 

    a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or

 

    b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal  Notices displayed by works containing it; or

 

    c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in  reasonable ways as different from the original version; or

 

    d) Limiting the use for publicity purposes of names of licensors or  authors of the material; or

 

    e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or

    f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on  those licensors and authors.

 

  All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10.  If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.  If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

 

  If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

 

  Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

 

  8. Termination.

 

  You may not propagate or modify a covered work except as expressly provided under this License.  Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

 

  However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

 

  Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that

copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

 

  Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License.  If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.

  9. Acceptance Not Required for Having Copies.

 

  You are not required to accept this License in order to receive or run a copy of the Program.  Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance.  However, nothing other than this License grants you permission to propagate or modify any covered work.  These actions infringe copyright if you do not accept this License.  Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

 

  10. Automatic Licensing of Downstream Recipients.

 

  Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License.  You are not responsible for enforcing compliance by third parties with this License.

 

  An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations.  If propagation of a covered work results from an entity transaction, each party to that

transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

 

  You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.  For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

 

  11. Patents.

 

  A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based.  The work thus licensed is called the contributor's "contributor version".

  A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version.  For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

 

  Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

 

  In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement).  To "grant" such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

 

  If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients.  "Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

 

  If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

 

  A patent license is "discriminatory" if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License.  You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

 

  Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.

 

  12. No Surrender of Others' Freedom.

 

  If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License.  If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all.  For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey

the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

  13. Use with the GNU Affero General Public License.

 

  Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work.  The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

 

  14. Revised Versions of this License.

 

  The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time.  Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

 

  Each version is given a distinguishing version number.  If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation.  If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.

 

   If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

 

  Later license versions may give you additional or different permissions.  However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

 

  15. Disclaimer of Warranty.

 

  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR

PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

 

  16. Limitation of Liability.

 

  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

 

  17. Interpretation of Sections 15 and 16.

 

  If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the

Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

 

                     END OF TERMS AND CONDITIONS

 

            How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.   To do so, attach the following notices to the program.  It is safest o attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.

 

    <one line to give the program's name and a brief idea of what it does.>

    Copyright (C) <year>  <name of author>

 

    This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or  (at your option) any later version.

 

    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

 

    You should have received a copy of the GNU General Public License along with this program.  If not, see <http://www.gnu.org/licenses/>.

 

Also add information on how to contact you by electronic and paper mail.

 

  If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:

 

    <program>  Copyright (C) <year>  <name of author>

    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.     This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.

 

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License.  Of course, your program's commands might be different; for a GUI interface, you would use an "about box".

 

  You should also get your employer (if you work as a programmer) or school, if any, to sign a "copyright disclaimer" for the program, if necessary.

For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>.

 

  The GNU General Public License does not permit incorporating your program into proprietary programs.  If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library.  If this is what you want to do, use the GNU Lesser General Public License instead of this License.  But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.

ANEXO 3.  MUESTRA DE CAPTURA DE TRAFICO PERIODICO DEL 30% DEL CANAL

 

    0.000000         1024                   inf

   0.081377          1024                100667

   0.083973          1024               3155624

   0.086569          1024               3155624

   0.089266          1024               3037449

   0.091862          1024               3155624

   0.094458          1024               3155624

   0.097055          1024               3154409

   0.099751          1024               3038576

   0.102348          1024               3154409

   0.104943          1024               3156840

   0.107540          1024               3154409

   0.110237          1024               3037449

   0.112833          1024               3155624

   0.115429          1024               3155624

   0.118126          1024               3037449

   0.120722          1024               3155624

   0.123318          1024               3155624

   0.125914          1024               3155624

   0.128610          1024               3038576

   0.131207          1024               3154409

   0.133803          1024               3155624

    0.136500         1024               3037449

   0.139096          1024               3155624

   0.141695          1024               3151982

   0.144290          1024               3156840

   0.146988          1024               3036323

   0.149582          1024               3158057

   0.152178          1024               3155624

   0.154874          1024               3038576

   0.157470          1024               3155624

   0.238857          1024                100655

   0.241454          1024               3154409

   0.244050          1024               3155624

   0.246747          1024               3037449

   0.249343          1024               3155624

   0.251942          1024               3151982

   0.254536          1024               3158057

   0.257232          1024               3038576

   0.259828          1024               3155624

   0.262425          1024               3154409

   0.265121          1024               3038576

   0.267717          1024               3155624

   0.270314          1024               3154409

   0.272910          1024               3155624

   0.275606          1024               3038576

   0.278202          1024               3155624

  0.280799           1024               3154409

   0.283397          1024               3153195

   0.286094          1024               3037449

   0.288689          1024               3156840

   0.291285          1024               3155624

   0.293881          1024               3155624

   0.296577          1024               3038576

   0.299173          1024               3155624

   0.301870          1024               3037449

   0.304466          1024               3155624

   0.307062          1024               3155624

   0.309659          1024               3154409

   0.312754          1024               2646850

   0.314952          1024               3727025

   0.396339          1024                100655

   0.398935          1024               3155624

   0.401531          1024               3155624

   0.404127          1024               3155624

   0.406824          1024               3037449

   0.409420          1024               3155624

   0.412017          1024               3154409

   0.414713          1024               3038576

   0.417309          1024               3155624

   0.419906          1024               3154409

   0.422501          1024               3156840

   0.425198          1024               3037449

   0.427798          1024               3150769

   0.430391          1024               3159275

   0.433087          1024               3038576

   0.435684          1024               3154409

   0.438380          1024               3038576

   0.440877          1024               3280737

   0.443573          1024               3038576

   0.446169          1024               3155624

   0.448765          1024               3155624

   0.451461          1024               3038576

   0.454058          1024               3154409

   0.456654          1024               3155624

   0.459251          1024               3154409

   0.461947          1024               3038576

   0.464544          1024               3154409

   0.467145          1024               3149558

   0.469836          1024               3044221

   0.472432          1024               3155624

   0.553819          1024                100655

    0.556416         1024               3154409

    0.559012         1024               3155624

ANEXO 4. MUESTRA DE CAPTURA DE TRAFICO PERIODICO DEL 60% DEL CANAL

 

    0.000000         1024                   inf

   0.041837          1024                195808

   0.043137          1024               6301538

   0.044533          1024               5868195

   0.045831          1024               6311248

   0.047129         1024               6311248

   0.048527          1024               5859800

   0.049925          1024               5859800

   0.051223          1024               6311248

   0.052621          1024               5859800

   0.053920          1024               6306390

   0.055318          1024               5859800

   0.056616          1024               6311248

   0.058014         1024               5859800

   0.059312          1024               6311248

   0.060710          1024               5859800

   0.062008          1024               6311248

   0.063406          1024               5859800

   0.064704          1024               6311248

   0.066003          1024               6306390

   0.067400          1024               5863994

   0.068699         1024               6306390

   0.070097          1024               5859800

   0.071395          1024               6311248

   0.072793          1024               5859800

   0.074193          1024               5851429

   0.075493          1024               6301538

   0.076890          1024               5863994

   0.078186          1024               6320988

   0.079484         1024               6311248

   0.080883          1024               5855611

   0.122624          1024                196258

   0.124022          1024               5859800

   0.125320          1024               6311248

   0.126718          1024               5859800

   0.128017          1024               6306390

   0.129414          1024               5863994

   0.130713         1024               6306390

   0.132111          1024               5859800

   0.133409          1024               6311248

   0.134807          1024               5859800

   0.136105          1024               6311248

   0.137503          1024               5859800

   0.138802          1024               6306390

   0.140200          1024               5859800

   0.141497         1024               6316114

   0.142896          1024               5855611

   0.144193          1024               6316114

   0.145592          1024               5855611   

   0.146894          1024               6291859

   0.148288          1024               5876614

   0.149587          1024               6306390

   0.150985          1024               5859800

   0.152283          1024               6311248

   0.153681          1024               5859800

   0.154979          1024               6311248

   0.156377          1024               5859800

   0.157675          1024               6311248

   0.159073          1024               5859800

   0.160371          1024               6311248

   0.161770          1024               5855611

   0.203511          1024                196258

   0.204909          1024               5859800

   0.206208          1024               6306390

   0.207605          1024               5863994

   0.208904          1024               6306390

   0.210302          1024               5859800

   0.211600          1024               6311248

   0.212998          1024               5859800

   0.216693          1024               2217050

   0.217494          1024              10227216

   0.218391          1024               9132664

   0.219191          1024              10240000

   0.219989          1024              10265664

   0.221087          1024               7460838

   0.222385          1024               6311248

   0.223683          1024               6311248

   0.225081          1024               5859800

   0.226479          1024               5859800

   0.227777          1024               6311248

   0.229076          1024               6306390

   0.230473          1024               5863994

   0.231772          1024               6306390

   0.233170          1024               5859800

   0.234568          1024               5859800

   0.235866          1024               6311248

   0.237164          1024               6311248

   0.238562          1024               5859800

   0.239861          1024               6306390

   0.241259          1024               5859800

   0.242557          1024               6311248

   0.284399          1024                195784

   0.285697          1024               6311248

   0.287095          1024               5859800

ANEXO 5.  MUESTRA DE CAPTURA DE TRAFICO POISSON DEL 30% DEL CANAL

 

 

   0.000000          1024                   inf

   0.079780          1024                102682

   0.080579          1024              10252816

   0.081378          1024              10252816

   0.082376          1024               8208417

   0.089966          1024               1079315

   0.095658          1024               1439213

   0.097159          1024               5457695

   0.105145          1024               1025795

   0.109539          1024               1864360

   0.110637          1024               7460838

   0.112235          1024               5126408

   0.113034          1024              10252816

   0.119725          1024               1224331

   0.120823          1024               7460838

   0.121921          1024               7460838

   0.129311          1024               1108525

   0.130609          1024               6311248

   0.133011          1024               3410491

   0.134504          1024               5486939

   0.140096          1024               1464950

   0.142992          1024               2828729

   0.144889          1024               4318397

   0.147985          1024               2645995

   0.150981          1024               2734312

   0.151780          1024              10252816

   0.166860          1024                543236

   0.168858          1024               4100100

   0.169955          1024               7467639

   0.170754          1024              10252816

   0.171952          1024               6838063

   0.257233          1024                 96059

   0.259630          1024               3417605

   0.260429          1024              10252816

   0.261328          1024               9112347

   0.262126          1024              10265664

   0.265022          1024               2828729

   0.265921          1024               9112347

   0.270515          1024               1783195

   0.274109          1024               2279354

   0.283696          1024                854490

   0.285094          1024               5859800

   0.286792          1024               4824499

   0.299475          1024                645904

   0.300273          1024              10265664

   0.301671          1024               5859800

   0.302470          1024              10252816

   0.303968          1024               5468625  

   0.315253          1024                725919

   0.316051          1024              10265664

   0.317649          1024               5126408

   0.318548          1024               9112347

   0.319446          1024               9122494

   0.320245          1024              10252816

   0.324040          1024               2158630

   0.325738          1024               4824499

   0.334626          1024                921692

   0.335524          1024               9122494

   0.337621          1024               3906533

   0.341616          1024               2050563

   0.342515          1024               9112347

   0.417414          1024                109374

   0.418314          1024               9102222

   0.423003          1024               1747068

   0.423801          1024              10265664

   0.424700          1024               9112347

   0.425499          1024              10252816

   0.426598          1024               7454049

   0.431691          1024               1608482

   0.432888          1024               6843776

   0.434387          1024               5464977

   0.437182          1024               2930948

   0.441976          1024               1708803

   0.444472          1024               3282051

   0.445571          1024               7454049

   0.446569          1024               8208417

   0.449969          1024               2409412

   0.450863          1024               9163311

   0.451963          1024               7447273

   0.455956          1024               2051590

   0.457555          1024               5123202

   0.462347          1024               1709516

   0.463246          1024               9112347

   0.465343          1024               3906533

   0.466142          1024              10252816

   0.468938          1024               2929900

   0.469837          1024               9112347

   0.470637          1024              10240000

   0.471435          1024              10265664

   0.472333          1024               9122494

   0.473132          1024              10252816

   0.583679          1024                 74104

ANEXO 6.  MUESTRA CAPTURA DE TRAFICO POISSON DEL 60% DEL CANAL

 

 

   0.000000          1024                   inf

   0.034742          1024                235795

   0.035540          1024              10265664

   0.036439          1024               9112347

   0.041232          1024               1709159

   0.043130          1024               4316122

   0.043929          1024              10252816

   0.048323          1024               1864360

   0.049820          1024               5472278

   0.052120          1024               3561739

   0.053618          1024               5468625

   0.054418          1024              10240000

   0.055313          1024               9153073

   0.056113          1024              10240000

   0.057011          1024               9122494

   0.057811          1024              10240000

   0.058711          1024               9102222

   0.059507          1024              10291457

   0.060306          1024              10252816

   0.061205          1024               9112347

   0.066198          1024               1640697

   0.067097          1024               9112347

   0.067895          1024              10265664

   0.070492          1024               3154409

   0.071291          1024              10252816

   0.072189          1024               9122494

   0.072988          1024              10252816

   0.075385          1024               3417605

   0.076284          1024               9112347

   0.077083          1024              10252816

   0.077981          1024               9122494

   0.112134          1024                239862

   0.112932          1024              10265664

   0.116628          1024               2216450

   0.117526          1024               9122494

   0.120422          1024               2828729

   0.121520          1024               7460838

   0.122419          1024               9112347

   0.123219          1024              10240000

   0.124719          1024               5461333

   0.126116          1024               5863994

   0.127013          1024               9132664

   0.128911          1024               4316122

   0.131308          1024               3417605

   0.132206          1024               9122494

   0.133005          1024              10252816

   0.133905          1024               9102222

   0.135002          1024               7467639  

   0.135801          1024              10252816

   0.136700          1024               9112347

   0.141393          1024               1745579

   0.142192          1024              10252816

   0.143090          1024               9122494

   0.143889          1024              10252816

   0.144788          1024               9112347

   0.146785          1024               4102153

   0.147584          1024              10252816

   0.148983          1024               5855611

   0.149881          1024               9122494

   0.150680          1024              10252816

   0.151479          1024              10252816

   0.184034          1024                251636

   0.184833          1024              10252816

   0.185731          1024               9122494

   0.186530          1024              10252816

   0.187429          1024               9112347

   0.188228          1024              10252816

   0.189026          1024              10265664

   0.189925          1024               9112347

   0.192821          1024               2828729

   0.195817          1024               2734312

   0.197715          1024               4316122

   0.200012          1024               3566391

   0.200812          1024              10240000

   0.201609          1024              10278545

   0.202508          1024               9112347

   0.203307          1024              10252816

   0.204206          1024               9112347

   0.205005          1024              10252816

   0.205903          1024               9122494

   0.206702          1024              10252816

   0.207501          1024              10252816

   0.208400          1024               9112347

   0.209897          1024               5472278

   0.212794          1024               2827753

   0.214791          1024               4102153

   0.216888          1024               3906533

   0.217787          1024               9112347

   0.219184          1024               5863994

   0.221182          1024               4100100

 



[1] General Public License. [online] http://en.wikIPedia.org/wiki/Gpl

[2] MOGUL, J., AND DEERING, S. RFC1191: Path MTU discovery. Internet RFC, Nov. 1990.

[3] STEVENS, W. TCP/IP Illustrated: The Protocols, Vol. I. Ed. Addison-Wesley, Jan. 1994.

[4] BRADEN, R. RFC1122: Requirements for Internet Hosts – Communication Layers. Internet RFC, IETF, Oct. 1989. Editor, Standard.

[5] PANIAGUA. Javier Gonzalo. Documentos RFC en Español. [online] http://www.rfc-es.org/  Ultima Actualización: 14 Febrero de 2008.

[6] LOPEZ MONGE, Alejandro. Aprendiendo a programar con Libpcap. [On-line]. Pag 27. http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf.  20 de Febrero de 2005

 

[7] Tutorial de Tcpdump y WinDump. [online] http://www.arrakis.es/~terron/tcpdump.html. 2007

[8] WIKILEARNING. Pequeño tutorial de TCPdump. [online] http://www.wikilearning.com/tutorial/pequeno_tutorial_de_tcpdump-filtros/6424-8. Última Actualización: 27 de Octubre de 2005.

[9]  Microsoft Corp [on line] <Http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/default.asp>

[10] Pressman Roger S. 1994. Ingeniería del Software un enfoque Práctico. Editorial McGraw Hill. Tercera Edición. Pág 11 y 25.

[11] Ingeniería de software [on line] http://www.itcg.edu.mx/ingsoft/diseno.htm

[12] Ibid, p.p. 25

[13] Ibid, pp 26

[14] JACOBSON, V., BRADEN, R., AND BORMAN, D. RFC1323: TCP Extensions for High Performance. Internet RFC, May 1992.

[15] LIBRERÍA LIBPCAP [online]. http://www.tcpdump.org/release/  2008