martes, 26 de febrero de 2013

Laboratorio 4

Laboratorio 4 - Quality of Service

Hola a todos, esta entrada corresponde al laboratorio 4 de la materia de telecomunicacione, el contenido de este post es referente a los aspectos que tomé en cuenta para realizar el experimento de QoS de la clase de la misma materia (http://triana-redes.blogspot.mx/2013/02/tarea-4.html).

Primero listaré los aspectos que tomé en cuenta para medir la calidad de servicio:
  • Intervalo de tiempo
  • Ancho de banda
  • Retardo
  • Variación de retardo
  • Pérdida de paquetes       
No descarto que existan otras vías para conocer la calidad de servicio de una aplicación, pero estas fueron las que yo utilicé.
Existen herramientas que nos ayudan a verificar o probar el servicio de distintas aplicaciones, unas incluso ya vienen con todas las funciones para probar distintos features de la aplicación. Yo usé un software que mide distintos parámetros, luego de ahí saqué conclusiones.

Entre los parámetros que mide mi sistema está el "ancho de banda", esto lo que nos dice es el capacidad de banda ancha que está consumiendo nuestra aplicación en el lapso de tiempo transcurrido, por ejemplo en todas las pruebas que yo corrí, lo hice con un lapso de tiempo de 10 segundos, pero eso puede ser especificado antes de comenzar la prueba.

Otro parámetro es "el retardo", obviamente entre menos retardo presente la aplicación pues mejor es el comportamiento, esto se refiere al tiempo estimado que se toma recorrer los paquetes desde su origen hasta el destino, esto lo podemos probar fácilmente con un ping, y se puede hacer a cualquier destino que nosotros queramos, en la imagen siguiente se puede ver un ping que le tiré a google:

 
Podemos ver que el tiempos van desde 35 a 36.5 ms, todos a un mismo destino, si la aplicación tiene variaciones de retardo muy considerables, entonces podemos concluir que la aplicación tenderá a fallar con en ciertos momentos, aunque esto depende también de otros factores, como ancho de banda, equipos de transporte del ISP, etc.

El parámetro de "variación de retardo" es el que les comenté anteriormente, se puede ir apreciando conforme pasan los icmp request, estos van desde el 1 hasta el que nosotros hayamos especificado. Cuando notemos que la variación de retardo es bastante considerable, también notaremos que la aplicación empezará a fallar, con algún delay, voz entrecortada (en voz IP), video congelado (en caso de videollamada), etc.
La aplicación que yo usé media el parámetros de variación en automático en un rango de tiempo de 10 segundos de prueba por default, se puede notar en la siguiente imagen:

  
Ahí se ve el Jitter = 0.463 ms, eso es la variación de retardo, vemos que es pequeño, de manera que no afecta significativamente a la llamada que estaba realizando en ese momento.

"Pérdida de paquetes". Esto también es muy significativo en las aplicaciones de telecomunicaciones, es algo a lo que le ponen mucho énfasis los creadores de softphones como Skype, el propio Linphone, etc.

Como lo he comentado en posts pasados de este blog, las aplicaciones de videoconferencias, llamadas en Voz IP, videollamadas, etc, usan el protocolo UDP, debido a que no es orientado a conexión y esto beneficia mucho los tiempos de comunicación, porque evita funciones que TCP realiza.

Peeeero, la otra cara de la moneda es que UDP no usa secuencia de paquetes, es decir en caso de que un paquete se pierda durante la comunicación, no se reenviará, incluso ni siquiera nota la pérdida de paquetes, los paquetes no llevan un número de secuencia, entonces se puede esperar que la pérdida de paquetes sea mayor que en una aplicación donde usen TCP como protocolo de transporte, aunque como lo mencioné antes, la mayoría de estas aplicaciones viajan por UDP.

En la siguiente captura de pantalla que hice cuando realizaba los experimentos en mi tablet, podemos apreciar que la pérdida de paquetes era de 0%, y para realizar esa prueba se enviaron un total de 893 datagramas. Así que felicidades para Linphone :)


Esto es todo por mi parte.
Ya saben, como siempre. Cualquier duda o aclaración pueden dejarla en comentarios.

Saludos a todos!

     
 

Tarea 4

Tarea 4 - Experimentos de calidad de servicio (QoS)

Hola, esta entrada corresponde a la tarea número cuatro de la clase de Telecomunicaciones y consiste en elegir una aplicación en la cual la QoS juega un papel importante. Luego diseñar, realizar, documentar y analizar un experimento para comparar la QoS.


Linphone


Bien, la aplicación que yo usé para realizar el experimento es Linphone, este es un software para realizar llamadas por internet, trabaja con el protocolo SIP y es del gran grupo de software llamados softphone. 
Linphone es multiplataforma inclusive con los dispositivos móviles, aunque es más estable en Linux, es compatible hasta con una lata de verduras, yo lo instalé en un ipod, una tablet y un ubuntu y funcionó a la perfección.

Como la mayoría de los sofphones, este trabaja en el puerto 5060, en ubuntu te da la posibilidad de cambiar de puerto si así lo deseas, en los móviles no vi esa opción.

Los aspectos más relevantes por los que se preocupan los creadores de este tipo de software son el ancho de banda consumido, el retardo que presenta la información que se envía, la variación de retardo (jitter) y la pérdida de paquetes. Estos son los pilares sobre los cuales trabaja este tipo de tecnologías ya que son las principales variables que influyen en la calidad del servicio. Si alguno de ellos falla se pueden presentar errores como voz entrecortada, robotizada, conexiónes sin establecer por exceso de información en buffer o por problemas de socket, etc.

Para realizar la actividad existe bastante diversidad de herramientas (como todo en la informática), sin embargo, hay muchas que no dicen aspectos como la pérdida de paquetes por aplicación (es muy importante que sea por aplicación, sino el experimento está mal hecho), retardo, etc. Para obtener esos datos se realizan estudios de combinación de herramientas, donde se necesita un buen respaldo de teoría de redes y de conocimiento técnico, por ejemplo el autor de un trabajo de fin de carrera (liga al trabajo: upcommons.upc.edu/pfc/bitstream/2099.1/3768/1/54630-1.pdf) menciona que es necesario capturar cada uno de los paquetes, luego desenvolverlo para checar los headers de cada paquete, luego verificar en cada header los tiempos, luego apartir de ahí calcular retardos (esto como quiera se puede realizar con ping), jitter y pérdidas.

Iperf




Yo encontré un muy buen software que realiza estos procedimientos de una manera más sencilla. El programa se llama iperf, iperf se usa para realizar test o pruebas de redes informáticas, y funciona creando flujos de datos ya sea de protocolo TCP o UDP luego mide el rendimiento.

El programa consta de 2 modalidades, una es de server y la otra de client. Existen diversos parámetros para poder realizar pruebas a aplicaciones de puertos en específico, por ejemplo yo hice las pruebas correspondientes al puerto 5060, porque como mencioné antes Linphone trabaja con ese puerto por default.

Por si esto fuera poco, iperf también es compatible con Android.

La siguiente imagen es la pantalla de inicio de Linphone:


Lo relevante de esta imagen es el SIP address, esa la creas en la página de Linphone para poder comunicarte con otro dispositivo.

Yo creé 2 direcciones SIP una para usar mi Linphone en la computadora y otra para realizar las pruebas en una tablet.
Después de instalar Linphone e iperf lo siguiente que hice fue realizar llamadas entre mis dispositivos para probar el servicio y la verdad que la calidad es muy buena.
Lo siguiente a realizar fue poner iperf en la tablet en modo servidor, la manera de realizar esto es muy sencillo, lo pueden hacer con el siguiente comando :

-s -p 5060 -u

De esa manera le estamos diciendo a iPerf que trabaje de modo servidor en el puerto 5060 con el protocolo UDP, al introducir esa instrucción quedará en modo de espera hasta que un client haga un request de información,  la siguiente imagen ilustra esto que acabo de decir (incluso se puede apreciar el iconillo de Linphone en naranja, en la esquina inferior derecha).




Luego en ubuntu puse iPerf en modo cliente, obviamente con los datos que pusimos anteriormente en el iPerf de la tablet.

Todo esto se realiza obviamente haciendo la llamada primero.

La impresión que nos genera iPerf es la siguiente:



El primer intento que ven en pantalla no es exitoso, porque se ve que dice connection refused, es porque no se especificó el protocolo de transporte correcto en el servidor de iPerf, es decir, mientras que los paquetes de Linphone viajan por UDP yo quería escuchar por TCP, lo que hice fue especificar en la tablet (server) que escuchara por el puerto UDP, luego el segundo intento que ven en la imagen ya es exitoso. Con el parámetro -u estamos diciendo que realice la prueba en UDP, la -c quiere decir que seremos el cliente y la dirección IP que vemos es la que pertenece al server (en este caso a la tablet).

Bueno lo relevante que nos dice aquí es el ancho de banda, que nos dice que es 1.05 Mbits/sec, los datagramas enviados, que fueron 893 (esto también es personalizable), esto con el motivo de calcular la pérdida de paquetes, iPerf también nos dice la variación de retardo (Jitter), en este caso es 0.463 ms y por último nos dice la pérdida de paquetes en porcentaje y en datagramas, nosotros podemos apreciar que nos dice que se perdieron 0 y llegaron 893 (los mismos que se enviaron) osea que el porcentaje de pérdida de paquetes es 0.

A continuación les muestro la respuesta que nos entregó el servidor (tablet):




El log final es el bueno, los anteriores que se ven son intentos fallidos, pueden ver que dice listen on TCP port, por eso nunca recibia el request del cliente, para que funcionara solo agregué el parámetro -u al comando y ya se puso a escuchar por el UDP.
Lo relevante es que al final nos dice los mismos datos que le llegaron al cliente: el intervalo de tiempo de prueba (10 segundos), la cantidad transferida (1.25 MBytes), el ancho de banda (1.05 Mbits/sec), jitter (0.463ms) y la pérdida en datagramas y porcentaje(0/893 0%).

Conclusiones:

En general es una aplicación bastante buena, el ancho de banda que consume (1.05MB/s) es lo normal en este tipo de aplicaciones, y cuando se agrega la función de video podría aumentar al doble o triple, me tocó que cuando inicié la llamada si se notó un tanto lento la navegación entre páginas, disminuyó cuando quité la funcionalidad de video. 
La variación de retardo (0.462 ms) que presenta es bastante baja, incluso puede compararse con la variación de retardo de un simple ping a Google.


Acá vemos variaciones de retardo de 1.5 ms osea 3 veces más grandes que en la aplicación Linphone, pero hay que tomar en cuenta que en Linphone se le corrió la prueba en un lapso de 10 segundos, osea hay muchos factores en este tipo de pruebas, puede que durante esos 10 segundos el SO consumía recursos de red que no los consumía cuando tiré el ping, bueno ustedes ya entienden.

Y en el apartado de los paquetes perdidos si me sorprendí, en el lapso transcurrido de la prueba no hubo ningún paquete perdido, se enviaron 893 datagramas y regresaron los mismos, dando un porcentaje de pérdida de paquetes de 0%, como se aprecia en la siguiente imagen (el último dato, de izquierda a derecha, de arriba hacia abajo).



Esto es todo por mi parte.

Bibliografía:


Cualquier duda o aclaración pueden dejarla en comentarios.

Salud a todos!

lunes, 18 de febrero de 2013

Tarea 3

Tarea 3 - Telnet Sniffing

Hola, esta actividad consiste sobre experimentos de monitoreos Wi-Fi, el ataque que yo elegí fue el de telnet sniffing.

Este ataque en concreto es el que se realiza para obtener información como contraseñas para accesar a ciertos equipos, además ya realizada la conexión también se puede escuchar toda la información que se transmite por el medio, ya que la comunicación de este protocolo se envía en texto plano (es decir, sin ningún nivel de seguridad).


La herramienta que utilicé para realizar este experimento se llama netcat, esta herramienta es muy usada por administradores de redes y demás personas interesadas en el monitoreo de su red.

Yo descargué la versión para Windows 7 y es muy fácil de usar (al menos para lo que lo usé yo). Lo primero es saber bien en donde se descargó el netcat, porque apartir de ahí ejecutaremos la herramienta mediante la línea de comandos. Por ejemplo yo descargué netcat en la siguiente ruta: C:\Users\triana\Desktop\visionClase

entonces lo que hice fue dirigirme hacia esa ubicación en el cmd, apartir de ahí el comando para estar a la escucha del puerto 23 es el siguiente:


Con el parámetro -L le decimos que escuché siempre independientemente si se corta la sesión telnet entre el server y el client. Si pusieramos -l, la acción de escuchar solo estaría vigente hasta que la sesión termine.

Como se puede observar en la imagen, debemos poner obviamente la ip a la que se estará escuchando (en mi experimento puse la dirección loopback: 127.0.0.1 para escuchar la sesión realizada en mi propia PC), seguido de la ip también debemos poner el puerto que escucharemos, en este caso el 23.





Para realizar la sesión telnet, usé un programa llamado Putty, este lo he usado bajo Ubuntu y también en Windows (XP y 7). Este programa es usado para establecer conexiones y comunicaciones mediante diversas tecnologías, como: Serial, telnet, SSH, etc.
Así es como se ve la pantalla de inicio de Putty:



Para realizar la conexión solo ponemos la dirección IP destino, osea a la que queremos conectarnos, también elegimos el puerto, luego elegimos el protocolo de comunicación que usaremos.

Como lo comenté anteriormente yo hice telnet a mi dirección loopback, entonces la configuración queda de la siguiente manera:




Antes de realizar la conexión podemos poner a escuchar netcat con el comando que les mostré anteriormente, solo cambiamos la dirección IP a 127.0.0.1 (a la que nos conectaremos).

Quedaría así:




Luego de que netcat esté esuchando ahora sí vamos a establecer la sesión telnet. De la siguiente imagen, evidentemente la ventanda de la izquierda corresponde al programa putty con la sesión ya levantada, envié 3 líneas y como se puede apreciar en la ventana de la derecha se encuentra el cmd ejecutando netcat, y está escuchando la información que estamos comunicando al amigo 127.0.0.1.

En el netcat se puede notar que cuando se estableció la conexión telnet, rápidamente puso la dirección IP a la que nos conectamos, además puso la PC origen, es decir, desde la que nos conectamos, seguido de eso se muestran símbolos que corresponden al inicio de la sesión (quiero suponer que son propios del protocolo). Después de esos símbolos ahora si nos muestra todas las líneas que está escuchando. 


(Hacer click sobre la imagen para ampliarla)



Además de este servicio, netcat también ofrece la posibilidad de guardar en un archivo de texto, toda la conversación que se escuchó. 

Esto puede usado para sniffear contraseñas de equipos de red, como routers, switches u otras PC's, etc. Además de que también podría ser usado para obtener la información que se le va configurando a dichos equipos, de manera que se podría saber las listas de acceso, firewalls, clientes y demás datos.
Podemos concluir que es mejor usar protocolos que ofrezcan un buen nivel de seguridad, como SSH que lleva un cifrado en la transmisión

Este experimento se realizó con fines didácticos y no se recomienda practicarlo con equipo de terceros sin su consentimiento.

Cualquier duda o aclaración pueden dejarla en comentarios.

Saludos a todos!