Sarabia Vargas - Repositorio Institucional de la Universidad

UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
“Redes Inalámbricas en Linux”
MONOGRAFÍA
Qué para obtener el Título de:
Licenciado en Sistemas
Computacionales Administrativos
Presenta:
Arturo Sarabia Vargas
Asesor:
M.C. Rubén Álvaro González Benítez
Coasesor:
M.E. Patricia Arieta Melgarejo
Cuerpo Académico:
Tecnologías de la Información y
Organizaciones Inteligentes en la Sociedad
del Conocimiento
Xalapa-Enríquez, Veracruz
Septiembre 2007
I
UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
“Redes Inalámbricas en Linux”
MONOGRAFÍA
Qué para obtener el Título de:
Licenciado en Sistemas
Computacionales Administrativos
Presenta:
Arturo Sarabia Vargas
Asesor:
M.C. Rubén Álvaro González Benítez
Cuerpo Académico:
Tecnologías de la Información y
Organizaciones Inteligentes en la Sociedad
del Conocimiento
Xalapa-Enríquez, Veracruz
Septiembre 2007
II
III
AGRADECIMIENTOS
QUIERO AGRADECER PRINCIPALMENTE A MI
MADRE POR HABERME DADO LA VIDA,
BRINDARME TODO SU AMOR Y ESFUERZO PARA
QUE YO LOGRARA CONCLUIR MIS SUEÑOS, POR
BUSCAR SIEMPRE MI BIENESTAR, SALUD Y
FELICIDAD A COSTA DE SACRIFICIOS, TE
QUIERO CON TODO MI CORAZÓN MAMITA,
GRACIAS.
A MI NOVIA, POR SER MI ARNÉS EN EL
MOMENTO ADECUADO, DARME UNA INMENSA
FELICIDAD DIA TRAS DIA Y POR SER LA
PERSONA MAS NOBLE QUE CONOZCO; TE AMO
CON TODO MI CORAZÓN, GRACIAS MI AMOR.
IV
ÍNDICE
Capítulo 1 LINUX
…………………………………………………………………...
5
1.1
ETIMOLOGÍA
……………………………………………………………
6
1.2
HISTORIA
……………………………………………………………
7
1.3
DISTRIBUCIONES LINUX
1.3.1
……………………………………………
Comparativa de algunas distribuciones Linux
9
……………. 11
1.4
COMO SE INSTALAN
…………………………………………………… 17
1.5
APLICACIONES DE LOS SISTEMAS LINUX ……………………………. 18
1.6
LA ESCALA DEL DESARROLLO DE "LINUX" ……………………………. 19
1.7
EN LINUX EL MERCADO ……………………………………………………. 20
1.8
GNU/LINUX COMO SISTEMA DE PROGRAMACIÓN
1.9
LINUX EN LA ADMINISTRACIÓN PÚBLICA
…………….. 21
……………………………. 22
1.10 COMO USAR UN MÓDULO PROGRAMADO PARA LINUX ……………. 23
Capítulo 2
2.1
TCP/IP EN LINUX …………………………………………………… 33
TCP/IP
…………………………………………………………………… 34
2.1.1 Niveles en la pila TCP/IP …………………………………………… 34
V
2.1.2 Familia de protocolos de Internet …………………………………… 37
2.2
TCP/IP LINUX
…………………………………………………………… 38
2.2.1 IPv4 …………………………………………………………………… 41
2.2.2 Desperdicio de direcciones
2.3
……………………………………. 41
EL SISTEMA OPERATIVO Y LA COMUNICACIÓN …………………… 42
2.3.1 Envío TCP/IP
…………………………………………………… 43
2.3.2 Recepción TCP/IP …………………………………………………… 44
2.3.3 Sockets sobre TCP/IP en Linux: Fuentes y Estructuras de Datos. 46
2.3.4 Creación de un Socket
……………………………………………. 47
2.3.5 Ubicación de las Funciones ejecutadas para enviar un mensaje a
través de Sockets en Linux
…………………………………… 73
2.3.6 Convenientes e Inconvenientes de la comunicación con TCP/IP en
Linux …………………………………………………………………... 74
Capítulo 3
3.1
LAS WIRELESS LAN EN LINUX …………..…………..………….... 75
LAS WIRELESS LAN
…………..…………..…………..…………..……. 76
VI
3.1.1 Principios de las redes WLAN
3.2
3.1.1.1
Cómo trabajan
3.1.1.2
Configuraciones de red para radiofrecuencia …….. 78
3.1.1.3
Chipset
…………..…………..……………. 77
…………..…………..…………..………… 79
LAS WIRELESS LAN EN LINUX …………..…………..…………..………… 79
3.2.1 Chipset Prism
3.2.1.1
3.3
…………..…………..……………. 77
…………..…………..…………..………………… 79
Funcionamiento
…………..…………..…………….. 80
3.2.2 Chipset Hermes
…………..…………..…………..………………… 81
3.2.3 Chipset Atheros
…………..…………..…………..………………... 81
EJEMPLO DE LA INSTALACIÓN DE UNA TARJETA INALAMBRICA EN
LINUX
…………..…………..…………..…………..…………..………………. 82
Capítulo 4
MODIFICACIONES A UN DRIVER PARA CALIDAD DE SERVICIO.
…………..…………..…………..…………..…………..…………..…………..……… 85
4.1
STATELESS WIRELESS AD HOC NETWORKS
4.1.1 Resumen
4.1.2 Introducción
…………………… 86
…………..…………..…………..……………….. 86
…………..…………..…………..…………… 87
4.1.3 ¿Qué son las redes Ad Hoc?
…………..………………... 87
4.1.4 Retos a superar en Ad Hoc.
…………..………………… 88
4.1.5 QoS en Redes Ad Hoc.
…………..…………..……………. 89
4.1.6 Características de los enlaces con QoS para esquemas de
tiempo real …………..…………..…………..…………..…………………… 90
4.1.7 Servicios diferenciados (DiffServ)
…………..………… 91
VII
4.1.8 Modelo SWAN: Service Differentiation in Stateless Wireless Ad
Hoc Networks …………..…………..…………..…………..….. 92
4.1.9 Hardware and Software requirement
4.1.10 Metodología
…………..………… 92
…………..…………..…………..…………… 93
4.1.11 Resultados y conclusiones
…………..…………..…….. 94
VIII
ÍNDICE DE IMÁGENES
Fig. 1 Linus Torvalds, creador del kernel
…………..…………..…………... 7
Fig. 2 Sharp Zaurus, un computador de bolsillo con Linux. …………..………. 10
Fig. 3 Escritorio KDE 3.4.2 corriendo sobre Gentoo Linux (2.6.13-r9) corriendo un
cliente IRC Konversation, un cliente p2p aMule y un reproductor musical Amarok.
…………..…………..…………..…………..…………..…………..…………..……… 18
Fig. 4 Richard Stallman, creador del proyecto GNU
…………..…………..….... 20
Fig. 5 Procedimientos del núcleo que interaccionan …………..……………….. 31
Fig. 6 Procedimientos del núcleo que interaccionan …………..…………..….... 32
Fig. 7 Varios algoritmos de control de congestión seleccionables al compilar Linux
(versión 2.6.17.4)
…………..…………..…………..…………..…………………... 39
Fig. 8 Pilas de protocolos …………..…………..…………..…………..…………... 42
Fig. 9 Pila de protocolos y la forma en que interactúan al enviar paquetes ….. 43
Fig. 10 Pila de protocolos y la forma en que interactúan al recibir paquetes … 44
Fig. 11 Pila de protocolos y módulos que los componen
…………………… 45
Fig. 12 Bibliotecas que se utilizan en Linux para manejar sockets …………… 46
Fig .13 Creación de estructura de datos ………………………………………….. 47
Fig. 14 Creación de un socket
………………………………………………….. 48
Fig. 15 Creación de un socket 2 ………………………………………………….. 48
Fig. 16 Estructura de un socket ………………………………………………….. 48
Fig. 17 Estructura del protocolo de transmisión …………………………………. 49
Fig. 18 Estructura de un socket ………………………………………………….. 50
Fig. 19 Estructura compuesta por una serie de operaciones para implementar los
protocolos TCP y UDP
…………………………………………………………… 51
Fig. 20 Escritura del sistema de archivos en Linux
………………………….... 52
Fig. 21 Diagrama explicativo de la interacción entre el socket, protocolo y el
sistema de archivos
…………………………………………………………… 53
Fig. 22 Uso de la memoria del sistema …………………………………………… 54
Fig. 23 Estructura de envió
…………………………………………………… 54
Fig. 24 Almacenamiento de punteros a funciones en un vector
Fig. 25 Definición de la estructura de archivos a utilizar
…………… 55
…………………… 56
IX
Fig. 26 Asociación del socket con el fichero
Fig. 27 Estructuras creadas a partir del socket
…………………………………… 56
…………………………… 57
Fig. 28 Forma de interacción entre las estructuras creadas …………………… 55
Fig. 29 Protocolo enviado con las características del paquete
……………. 58
Fig. 30 Estructura del buffer
…………..…………..…………..………………. 59
Fig. 31 Estructura del buffer.
…………..…………..…………..………………. 60
Fig. 32 Secuencia de envío
…………..…………..…………..………………. 61
Fig. 33 Estructura del proceso de envió del mensaje …………..………………. 61
Fig. 34 Rectángulo no. 5 tcp_transmit_skb
…………………………………... 62
Fig. 35 Se procede a enviar el mensaje mediante un socket
…………… 63
Fig. 36 Estructura del envió del mensaje mediante un socket
…………… 64
Fig. 37 Continuación de la figura 36
…………..…………..…………..………. 65
Fig. 38 Estructura en donde se toma la decisión de enviar o encolar el o los
paquetes…………..…………..…………..…………..…………..…………..……… 66
Fig. 39 Diagrama del proceso de salida del paquete …………..…………..…… 67
Fig. 40 ip_queue_xmit()
…………………………………………………………... 68
Fig. 41 estructura de código en la que ip_queue_xmit() construye la cabecera IP
…………..…………..…………..…………..…………..…………..…………..……... 69
Fig. 42 La rutina dev_queue_xmit() se encarga de la transmisión del sk_buff
correspondiente a cada paquete, a través de la tarjeta de red (a través de una
llamada a su controlador …………..…………..…………..…………..………….. 70
Fig. 43 La rutina dev_queue_xmit() se encarga de la transmisión del sk_buff
correspondiente a cada paquete, a través de la tarjeta de red (a través de una
llamada a su controlador …………..…………..…………..…………..………….. 71
Fig. 44 Diagrama explicativo de la interacción
…………..………………. 72
Fig. 45 Ubicación de las funciones ejecutadas para enviar un mensaje a través de
sockets en Linux
…………..…………..…………..…………..…………..……… 73
Fig. 46 Metodología del modelo aplicado
…………..…………..…………… 94
Fig. 47 Resultados obtenidos con el modulo admission control
…………… 95
Fig. 48 Resultados obtenidos con el modulo admission control
…………… 96
Fig. 49 resultados con un tráfico mayoritariamente de tiempo real …………… 96
Fig. 50 resultados con un tráfico mayoritariamente de tiempo real …………… 97
X
ÍNDICE DE TABLAS
Tabla 1. Linux
…………..…………..…………..…………..…………..……… 9
Tabla 2. Comparación general de las distribuciones de Linux
…………… 11
Tabla 3. Comparación técnica de las distribuciones de Linux.
…………… 13
Tabla 4. Datos extras de las distribuciones de Linux.
…………..……….. 15
Tabla 5. Comandos necesarios para el manejo de módulos.
……………
23
Tabla 6. Pila de protocolos modelo OSI …………………………………………...
34
Tabla 7 Una interpretación simplificada de la pila
…………………………… 35
XI
INTRODUCCION
1
Existen distintos estándares que definen distintos tipos de redes
inalámbricas. Esta variedad produce confusión en el mercado y descoordinación
en los fabricantes. Para resolver este problema, los principales vendedores de
soluciones inalámbricas (3com, Airones, Intersil, Lucent Technologies, Nokia y
Symbol Technologies) crearon en 1999 una asociación conocida como WECA
(Wireless Ethernet Compability Aliance, Alianza de Compatibilidad Ethernet
Inalámbrica) . El objetivo de esta asociación fue crear una marca que permitiese
fomentar más fácilmente la tecnología inalámbrica y asegurase la compatibilidad
de equipos.
De esta forma en abril de 2000 WECA certifica la interoperatibilidad de equipos
según la norma IEEE 802.11b bajo la marca Wi-Fi (Wíreless Fidelity, Fidelidad
Inalámbrica). Esto quiere decir que el usuario tiene la garantía de que todos los
equipos que tenga el sello Wi-Fi pueden trabajar juntos sin problemas
independientemente del fabricante de cada uno de ellos. Se puede obtener un
listado completo de equipos que tienen la cetificación Wi-Fi en Alliance - Certified
Products.
En el año 2002 eran casi 150 miembros de la asociación WECA. Como la norma
802.11b ofrece una velocidad máxima de transferencia de 11 Mbps ya existen
estándares que permiten velocidades superiores, WECA no se ha querido quedar
atrás. Por ese motivo, WECA anunció que empezaría a certificar también los
equipos IEEE 802.11a de la banda de 5 Ghz mediante la marca Wi-Fi5.
La norma IEEE.802.11 fue diseñada para sustituir a las capas físicas y MAC de la
norma 802.3 (Ethernet). Esto quiere decir que en lo único que se diferencia una
red Wi-Fi de una red Ethernet, es en la forma como los ordenadores y terminales
en general acceden a la red; el resto es idéntico. Por tanto una red local
inalámbrica 802.11 es completamente compatible con todos los servicios de las
redes locales de cable 802.3 (Ethernet).
Las Redes Inalámbricas facilitan la operación en lugares donde la computadora no
puede permanecer en un solo lugar, como en almacenes o en oficinas que se
encuentren en varios pisos.
2
No se espera que las redes inalámbricas lleguen a remplazar a las redes
cableadas. Estas ofrecen velocidades de transmisión mayores que las logradas
con la tecnología inalámbrica. Mientras que las redes inalámbricas actuales
ofrecen velocidades de 54 Mbps, las redes cableadas ofrecen velocidades de 100
Mbps y se espera que alcancen velocidades de hasta 1000 Mbps. Los sistemas de
Cable de Fibra Optica logran velocidades aún mayores.
Sin embargo se pueden mezclar las redes cableadas y las inalámbricas, y de esta
manera generar una "Red Híbrida" y poder resolver los últimos metros hacia la
estación. Se puede considerar que el sistema cableado sea la parte principal y la
inalámbrica le proporcione movilidad adicional al equipo y el operador se pueda
desplazar con facilidad dentro de un almacén o una oficina.
Las redes inalámbricas en Linux son un problema; la culpa no es Linux, si no los
fabricantes que no se preocupan por lanzar drivers para este sistema. Los
empaques de los routers, y otros dispositivos inalámbricos, no especifican el chip
que utilizan, pequeño detalle que ayudaría a los usuarios Linux, pues así pueden
adquirir fácilmente un modelo con chip compatible con Linux.
Por lo tanto la finalidad de esta monografía es proporcionar la documentación
necesaria para instalar una tarjeta de red inalámbrica en Linux, que se pueda
utilizar para su análisis, posibles mejoras mediante la implementación de código
propio y poder hacer una comparación con la propuesta de calidad de servicio
proporcionada por SWAN (Stateless Wireless Ad hoc Networks) el cual es un
proyecto encaminado a las redes inalámbricas móviles proporcionando servicios
con calidad (QoS) en redes Ad Hoc o punto a punto.
Los sistemas inalámbricos se han convertido en el segmento de mayor y más
rápido crecimiento en las telecomunicaciones, donde su principal consecuencia
han sido dotar de movilidad a los nodos de la red al liberarlos de sus conexiones
físicas, además también están empezando a ofrecer múltiples servicios con
calidad (QoS) como una conversación telefónica, la transferencia de ficheros,
acceso a la web o la realización de videoconferencia, sin restricciones de lugar y
de tiempo. Estos ejemplos de comunicación inalámbrica espontánea entre
dispositivos se denomina redes Ad Hoc, permitiendo a los dispositivos establecer
3
la comunicación, en cualquier momento y en cualquier lugar. En realidad, la
formación de redes Ad Hoc como tal no es nueva, sino lo es nuevo es la forma de
configuración y uso de sus elementos. Una aproximación para otorgar calidad de
servicio es la de diferenciar entre el conjunto de paquetes que circulan por la red
clasificando los paquetes en un número pequeño de tipos de servicios y utiliza
mecanismos de prioridad para proporcionar una calidad de servicio adecuada al
tráfico. Este estudio preliminar se realizo aplicando servicios diferenciados con el
modelo SWAN en el entorno del simulador ns2. SWAN es un modelo de red “sin
estados”, el cual usa algoritmos de control distribuidos para entregar servicios
diferenciados en MANET de una manera escalable y robusta. Estos algoritmos
aplican controles basados en retroalimentaciones para soportar servicios de
tiempo real “soft” y servicios diferenciados en redes inalámbricas Ad Hoc. El
modelo usa el rate control (rc) para trafico UDP y TCP best effort, y un admission
control (ac) para trafico UDP de tiempo real. SWAN aplica la notificación explicita
de congestionamiento (ECN) para regular dinámicamente trafico de tiempo real
admitido. El novedoso aspecto de este modelo es que no requiere de QoS en la
capa MAC.
4
CAPITULO I
LINUX
5
1.1 Etimología
Linux se refiere estrictamente al núcleo Linux, pero es comúnmente
utilizado para describir al sistema operativo tipo Unix (que implementa el estándar
POSIX), que utiliza primordialmente filosofía y metodologías libres (también
conocido como GNU/Linux) y que está formado mediante la combinación del
núcleo Linux con las bibliotecas y herramientas del proyecto GNU y de muchos
otros proyectos/grupos de software (libre o no libre). El software que suelen incluir
consta de una enorme variedad de aplicaciones, como: entornos gráficos, suites
ofimáticas, servidores web, servidores de correo, servidores FTP, etcétera.
Coloquialmente se aplica el término "Linux" a éstas. Algunas personas opinan que
es incorrecto denominarlas distribuciones Linux, y proponen llamarlas sistema
GNU/Linux. Otras personas opinan que los programas incluidos proceden de
fuentes tan variadas que proponen simplificarlo denominándolo simplemente a
"Linux".
Linux (pronunciación IPA: /lɪnʊks/) es la denominación de un sistema operativo
tipo-Unix y el nombre de un núcleo. Es uno de los paradigmas más prominentes
del software libre y del desarrollo del código abierto, cuyo código fuente está
disponible públicamente y cualquier persona puede libremente usarlo, estudiarlo,
redistribuirlo y, con los conocimientos informáticos adecuados, modificarlo.
Los primeros sistemas Linux se originaron en 1992, al combinar utilidades de
sistema y bibliotecas del proyecto GNU con el núcleo Linux, completando un
sistema también conocido como GNU/Linux. Desde fines de 1990 Linux ha
obtenido el apoyo de diversas empresas multinacionales del mundo de la
informática, tales como IBM, Sun Microsystems, Hewlett-Packard y Novell.
Linux es usado como sistema operativo en una amplia variedad de plataformas de
hardware y computadores, incluyendo los computadores de escritorio (PCs x86 y
x86-64, y Macintosh y PowerPC), servidores, supercomputadores, mainframes, y
dispositivos empotrados así como teléfonos celulares.
La marca Linux (Número de serie: 1916230) pertenece a Linus Torvalds y se
define como "un sistema operativo para computadoras que facilita su uso y
6
operación". Existen grupos de usuarios del sistema Linux en casi todas las áreas
del planeta
La pronunciación correcta (para cualquier idioma) es muy cercana a como se
pronuncia en español: /lí.nux/ o /lnəks/ (Alfabeto Fonético Internacional).
1.2 Historia
Fig. 1 Linus Torvalds, creador del kernel
La historia de Linux está fuertemente vinculada a la del proyecto GNU. El
proyecto GNU, iniciado en 1983, tiene como objetivo el desarrollo de un sistema
Unix completo compuesto enteramente de software libre. Hacia 1991, cuando la
primera versión del núcleo Linux fue liberada, el proyecto GNU había producido
varios de los componentes del sistema operativo, incluyendo un intérprete de
comandos, una biblioteca C y un compilador, pero aún no contaba con el núcleo
que permitiera completar el sistema operativo.
El núcleo creado por Linus Torvalds, quien se encontraba entonces estudiando en
la Universidad de Helsinki, llenó el hueco final que el sistema operativo GNU
exigía. Subsecuentemente, miles de programadores voluntarios alrededor del
mundo han participado en el proyecto, mejorándolo continuamente. Torvalds y
otros desarrolladores de los primeros días de Linux adaptaron los componentes de
7
GNU y de BSD, así como de otros muchos proyectos como Perl, Apache, Python,
etc. para trabajar con el núcleo Linux, creando un sistema operativo
completamente funcional procedente de muchísimas fuentes diferentes, la
mayoría libres.
8
1.3 Distribuciones Linux
Tabla 1 Linux
El logotipo oficial del núcleo Linux es el pingüino Tux
Desarrollador
Varios
Familia de S.O.
Unix-like
Modelo de desarrollo
Open source
Núcleo
Linux
Tipo de núcleo
Monolítico
Licencia
GPL/LGPL/BSD/Otras
Estado actual
En desarrollo
9
Fig. 2 Sharp Zaurus, un computador de bolsillo con Linux.
Una distribución es un conjunto de aplicaciones reunidas por un grupo, empresa o
persona para permitir instalar fácilmente un sistema Linux. Es un sabor de Linux.
En general se destacan por las herramientas para configuración y sistemas de
paquetes de software a instalar.
Existen numerosas distribuciones Linux (también conocidas como "distros"),
ensambladas por individuos, empresas y otros organismos. Cada distribución
puede incluir cualquier número de software adicional, incluyendo software que
facilite la instalación del sistema. La base del software incluido con cada
distribución incluye el núcleo Linux y las herramientas GNU, al que suelen
adicionarse también varios paquetes de software.
Las herramientas que suelen incluirse en la distribución de este sistema operativo
se obtienen de diversas fuentes, incluyendo de manera importante proyectos de
código abierto o libre, como el GNU y el BSD o el KDE. Debido a que las
herramientas de software libre que en primera instancia volvieron funcional al
núcleo de Linux provienen del proyecto GNU que desde 1983 había liberado
software que pudo ser usado en el proyecto de Linux de 1991, Richard Stallman
(fundador del proyecto GNU) pide a los usuarios que se refieran a dicho sistema
como GNU/Linux. A pesar de esto, la mayoría de los usuarios continúan llamando
al sistema simplemente "Linux" y las razones expuestas por Richard Stallman son
10
eterno motivo de controversia. La mayoría de los sistemas "Linux" incluyen
también herramientas procedentes de BSD y de muchos otros proyectos como
Mozilla, Perl, Ruby, Python, PostgreSQL, MySQL, Xorg, casi todas con licencia
GPL o compatibles con ésta (LGPL, MPL) otro aporte fundamental del proyecto
GNU.
Usualmente se utiliza la plataforma XFree86 o la X.Org para sostener interfaces
gráficas.
1.3.1 Comparativa de algunas distribuciones Linux
Existen numerosas distribuciones Linux. Cada una de ellas puede incluir
cualquier cantidad de software adicional (libre o no), como algunos que facilitan
la instalación del sistema y una enorme variedad de aplicaciones, entre ellos,
entornos gráficos, suites ofimáticas, servidores web, servidores de correo,
servidores FTP, etcétera.
La base de cada distribución incluye el núcleo Linux, con las bibliotecas y
herramientas del proyecto GNU y de muchos otros proyectos/grupos de
software, como BSD.
Tabla 2 Comparación general de las distribuciones de Linux.
Fecha de
Empresa
la
primera
Última
Predecesor
GNU/Linux
Fedora
Core
Precio (€)
Licencia
Público
País
estable
P.R.
Debian
versión
Proyecto
agosto de
Debian
1993
Proyecto
noviembre
Fedora Linux,
Fedora
de 2003
Red Hat Linux
N/A
4.0
(Etch)
Gratis
cualquier
DFSG
Ver. 7 /
Junio
2007
Desktop,
Workstation,
Server
Workstation,
Gratis
GPL
Server,
Mun
dial
EEU
U
Público
11
Gentoo
Mandriva
Linux
Fundación
marzo de
Gentoo
2002
Mandriva
julio de
1998
Enoch
Mandrake
Linux/Conectiva
y Lycoris Xls
rxart, rxart
de 2001
Linux
Pixart
Slackware
Patrick
julio de
Volkerding
1993
2006.1
Gratis
GPL
Server,
Gratis
2007.1
(edición
Spring
para
Desktop,
GPL
3.0
€16
Workstation,
Server
descargar)
GPL
11.0
Gratis
GPL
Mun
dial
Workstation,
Arge
Server
ntina
Workstation,
SLS
Mun
dial
Público
octubre
Rxart
Linux
Workstation,
Server,
EEU
U
Público
Descarga
gratuita
SUSE
Novell,
marzo de
Linux
OpenSUSE
1994
Jurix
10.3
disponible
Ed.
Workstation,
GPL
Profesional:
Server,
Mun
Desktop,
dial
Público
51,95
Ubuntu
Canonical
octubre
Ltd.
de 2004
7.04
Debian
(Feisty
Fawn)
Gratis
LiveCD
Desktop,
GPL
Workstation,
Server
Tabla 2. Comparación general de las distribuciones de Linux (continuación).
12
Mun
dial
Tabla 3. Comparación técnica de las distribuciones de Linux.
API
Sistem
Kernel
a de
fichero
s
Sistemas
de
ficheros
compatib
principal
Herramie
Arquitect
ura
les
nta de
Administra
actualizac
dor de
ión de
Paquetes
paquetes
y
lenguaje
para
Aplicacio
nes
Gráficas
API
principal
y
lenguaje
para
Aplicacio
nes CLI
x86, x8664, IA64,
Debian
GNU/Lin
ux
Linux
2.6.18
ext3
ext2, JFS,
PowerPC,
XFS,
SPARC,
FAT,
SPARC64
dpkg,
NTFS,
, Alpha,
Synaptic,
ISO 9660,
MIPS,
UDF,
ARM, PA-
NFS,
RISC,
ReiserFS
Mac/VME
APT
Adept, APT
pre-LSB
con C,
Varias
otros
(estándar
y Aptitude
POSIX)
68k,
S/390
ext2,
Linux
Fedora
Core
ReiserFS,
2.6.18
Fed.C
ext3
ore
FAT, ISO
9660,
UDF,
Verid 9
pre-LSB
x86, x86-
up2date,
64, i386,
yum, APT
PowerPC
(limitado)
con C,
RPM, yum
Varias
(estándar
POSIX)
NFS
ext2,
ReiserFS,
Rxart
Linux
2.6.34
ext3
FAT, ISO
9660,
UDF,
pre-LSB
x86, x86-
up2date,
64, i386,
net, APT
PowerPC
(limitado)
con C,
DEB, ASK
Varias
Linux
a Linux
2.6.17
ext3
otros
(estándar
POSIX)
NFS
Mandriv
otros
ext2, JFS,
x86
XFS,
(i586),
urpmi
RpmDrake
Varias
pre-LSB
con C,
13
FAT,
x86-64,
otros
NTFS,
PPC
(estándar
ISO 9660,
POSIX)
UDF,
NFS,
ReiserFS
JFS,
Linux
Reiser
Slackwa
2.4.33
FS,
re Linux
/
ext3/ex
2.6.18
t2
XFS,
FAT,
NTFS,
ISO 9660,
pre-LSB
Swaret,
x86, IA64,
Slapt-get,
installpkg y
S/390
otros no
upgradepkg
con C,
Varias
(estándar
oficiales
UDF,
otros
POSIX)
NFS
ext2,
ext3, JFS,
XFS,
openSU
SE
Linux
2.6.18.
ext3
8
YaST2
pre-LSB
con C,
FAT,
x86, IA64,
(Misma
NTFS,
x86-64,
Versión de
ISO 9660,
PowerPC
YaST
(estándar
Avanzada)
POSIX)
UDF,
RPM, YaST
Varias
otros
NFS,
Reiser4
JFS,
Ubuntu
Linux
2.6.20
XFS,
ext3
NTFS,
ISO 9660,
ReiserFS
pre-LSB
dpkg,
x86, x8664
APT
Synaptic,
APT y
Aptitude
con C,
Varias
otros
(estándar
POSIX)
Tabla 3. Comparación técnica de las distribuciones de Linux (continuación).
14
Tabla 4. Datos extras de las distribuciones de Linux.
Paquetes
Debian
GNU/Linux
18000
Instalación
Administrador de
Navegador
gráfica
archivos
web
Sí (a partir de la
4.0 "Etch")
Nautilus, Konqueror
Iceweasel,
Konqueror
Entorno
Gestor de
Tema
gráfico
ventanas
visual de
principal
principal
escritorio
GNOME
Metacity,
KWin
a elegir
Suite ofimática
OpenOffice.org,
KOffice, GNOME Office
ClearLook
Fedora
Core
Mozilla
5000
Sí
Nautilus, Konqueror
Firefox,
Epiphany
GNOME,
Metacity,
KDE
Kwin
s
(GNOME)
Bluecurve
OpenOffice.org,
KOffice, GNOME Office
(KDE)
Mandriva
Linux
Rxart
Linux
Slackware
Linux
Konqueror,
4000
Sí
Konqueror
Mozilla
KDE
KWin
la Ora
OpenOffice.org
KDE
KWin
Rxart
OpenOffice.org
varios
a elegir
a elegir
KOffice
Firefox
Konqueror,
2000
Sí
Konqueror
Mozilla
Firefox
muchos
No
Konqueror
Mozilla
Firefox,
Seamonkey
Mozilla
Firefox,
SUSE
Linux
Konqueror
12500
Sí
Nautilus
(en KDE),
Epiphany
Gnome,
KDE
Metacity
ClearLook
OpenOffice.org,
s
KOffice, GNOME Office
(en
GNOME)
Ubuntu
menos de
18000
Sí
Nautilus
Tabla 4. Datos extras de las distribuciones de Linux (continuación).
Mozilla
Firefox
GNOME
Metacity
Human
OpenOffice.org,
GNOME Office
1.4 Cómo se instala Linux
Linux en la actualidad es un sistema operativo fácil de instalar, tan solo
basta con descargar la imagen iso de una distribución como Debian, SuSE,
Ubuntu o Yellow Dog (la mayoría son gratuitas) y grabarla en un CD o DVD.
Existen versiones linux para máquinas x86 (abarca desde computadoras 386,
pentium I, celeron, hasta pentium IV), también para 64 bits (los nuevos
procesadores, aunque también trabajan con linux para x86), y para procesadores
PowerPc (ppc) de las computadoras Apple Macintosh.
El resto es tan fácil como instalar Windows, incluso algunas distribuciones
permiten entrar al escritorio linux sin necesidad de instalar el sistema operativo
(desde el CD), para luego usarlo o instalarlo desde el escritorio. Este es el caso de
Ubuntu y Kubuntu y las versiones más actualizadas, insertas el cd/dvd dentro de la
computadora, reinicias y en uno o dos minutos estás en el escritorio del sistema
operativo Linux. Estas versiones son también llamadas Live, del inglés "en vivo".
Actualmente Linux es un sistema fácil de usar. Cada distribución trae programas
seleccionados por los autores de la distribución incluidos en el cd o en el dvd, y se
pueden instalar tanto al comienzo de la instalación como luego de haber instalado
el sistema. Se puede instalar en computadoras que se consideren "obsoletas",
pero esto puede resultarle complicado a un usuario novato.
17
1.5 Aplicaciones de los sistemas Linux
Fig. 3 Escritorio KDE 3.4.2 corriendo sobre Gentoo Linux (2.6.13-r9) corriendo un cliente IRC
Konversation, un cliente p2p aMule y un reproductor musical Amarok.
Con la adopción por numerosas empresas fabricantes de PCs, muchas
computadoras son vendidas con distribuciones GNU/Linux pre-instaladas, y
"GNU/Linux" ha comenzado a tomar su lugar en el vasto mercado de las
computadoras de escritorio.
Con entornos de escritorio, "GNU/Linux" ofrece una interfaz gráfica alternativa a la
tradicional interfaz de línea de comandos de Unix. Existen en la actualidad
18
numerosas aplicaciones gráficas, ya sean libres o no, que ofrecen funcionalidad
que está permitiendo que GNU/Linux se adapte como herramienta de escritorio.
Algunas distribuciones permiten el arranque de Linux directamente desde un disco
compacto (llamados LiveCDs) sin modificar en absoluto el disco duro de la
computadora en la que se ejecuta Linux. Para este tipo de distribuciones, en
general, los archivos de imagen (archivos ISO) están disponibles en Internet para
su descarga.
Otras posibilidades incluyen iniciar el arranque desde una red (ideal para sistemas
con requerimientos mínimos) o desde un disco flexible o disquete o de unidades
de almacenamiento USB.
1.6 La escala del desarrollo de "Linux"
Un estudio sobre la distribución Red Hat 7.1 reveló que ésta en particular
posee más de 30 millones de líneas de código real. Utilizando el modelo de
cálculo de costos COCOMO, puede estimarse que esta distribución requeriría
8.000 programadores por año para su desarrollo. De haber sido desarrollado por
medios convencionales de código cerrado, hubiera costado más de mil millones de
dólares en los Estados Unidos.
La mayor parte de su código (71%) pertenecía al lenguaje C, pero fueron
utilizados muchos otros lenguajes para su desarrollo, incluyendo C++, Bash, Lisp,
Ensamblador, Perl, Fortran y Python.
Alrededor de la mitad de su código total (contado en líneas de código) fue liberado
bajo la licencia GPL en su versión 2.
El núcleo Linux contenía entonces 2,4 millones de líneas de código,
correspondiente al 8% del total, demostrando que la vasta mayoría del sistema
operativo no pertenece al núcleo del mismo.
En un estudio posterior, Counting potatoes: the size of Debian 2.2, el mismo
análisis fue hecho para Debian GNU/Linux versión 2.2. Esta distribución contiene
más de 55 millones de líneas de código fuente, y habría costado 1.900 millones de
19
dólares (año 2000) el desarrollo por medios convencionales (no libres); y el núcleo
Linux continua siendo de unas 2,5 millones de líneas.
1.7 En Linux el mercado
Fig. 4 Richard Stallman, creador del proyecto GNU
La creciente popularidad de Linux se debe a las ventajas que presenta ante
otros tipos de software. Entre otras razones se debe a su estabilidad, al acceso a
las fuentes (lo que permite personalizar el funcionamiento y auditar la seguridad y
privacidad de los datos tratados), a la independencia de proveedor, a la seguridad,
a la rapidez con que incorpora los nuevos adelantos tecnológicos (IPv6,
microprocesadores de 64 bits), a la escalabilidad (se pueden crear clusters de
cientos de computadoras), a la activa comunidad de desarrollo que hay a su
alrededor, a su interoperatibilidad y a la abundancia de documentación relativa a
los procedimientos.
Hay varias empresas que comercializan soluciones basadas en Linux: IBM, Novell,
Red Hat, Rxart, Cannonical (Ubuntu), Rxart, así como miles de PYMES que
ofrecen productos o servicios basados en esta tecnología.
Dentro del segmento de supercomputadoras, la 5ª más grande de Europa,
denominada MareNostrum, fue desarrollada por IBM y está basada en un cluster
20
Linux ([1]). Ella se encuentra alojada en Barcelona y es gestionada por la
"Universitat Politécnica de Catalunya" (UPC). A fines de 2006, de acuerdo al
TOP500.org, encargado de monitorear las 500 principales supercomputadoras del
mundo: 371 usaban una distribución basada en GNU/Linux, 81 Unix, 32 SLES
(una variante de Unix), 13 Únicos con Linux y 3 Mac. Ninguna usaba Windows.
Linux, además de tener una amplia cuota en el mercado de servidores de internet,
debido entre otras cosas a la gran cantidad de soluciones que tiene para este
segmento, tiene un creciente campo en computadoras de escritorio y portátiles.
Prueba de ello es que es el sistema base que se ha elegido para el proyecto
OLTPC, que tiene como objetivo llevar una LapTop a cada niño de países como
China, Brasil, Argentina y Uruguay y está patrocinado por la iniciativa del MIT y
firmas como AMD, Google y Sun Microsystems.
1.8 GNU/Linux como sistema de programación
La colección de utilidades para la programación de GNU es con diferencia
la familia de compiladores más utilizada en Linux. Tiene capacidad para compilar
C, C++, Java, Ada, entre otros muchos lenguajes. Además soporta diversas
arquitecturas mediante la compilación cruzada, lo que hace que sea un entorno
adecuado para desarrollos heterogéneos.
Hay varios IDEs disponibles para Linux incluyendo, Anjuta, KDevelop, NetBeans
IDE y Eclipse. Además existen editores extensibles como pueda ser Emacs que
hoy en día siguen siendo ampliamente utilizados. GNU/Linux también dispone de
capacidades para lenguajes de guión (script), aparte de los clásicos lenguajes de
programación de shell, la mayoría de las distribuciones tienen instalado Python,
Perl, PHP y Ruby.
21
1.9 Linux en la Administración Pública
Hay una serie de administraciones públicas que han mostrado su apoyo al
software libre, sea migrando total o parcialmente sus servidores y sistemas de
escritorio, sea subvencionándolo. Como ejemplos se tiene a:
Alemania pagando por el desarrollo del Kroupware. Además ciudades como
Múnich, que migró sus sistemas a SuSE Linux, una distribución alemana
especialmente orientada a KDE.
Cuba donde el gobierno ha establecido una indicación oficial para introducir de
manera progresiva el software libre y en particular GNU/Linux y en el que la red de
Salud Pública, Infomed, fue pionera en su uso.
China, con su acuerdo con Sun Microsystems para distribuir millones de Java
Desktop (una distribución de GNU/Linux basada en GNOME y especialmente bien
integrada con java)
Brasil, con una actitud generalmente positiva, y, por ejemplo, con el desarrollo de
los telecentros
En España, algunos gobiernos autonómicos están desarrollando sus propias
distribuciones no sólo para uso administrativo sino también académico. Así
tenemos LinEx en Extremadura, Augustux en Aragón, GuadaLinex en Andalucía,
LliureX en La Comunidad Valenciana, Molinux en Castilla-La Mancha, MAX en La
Comunidad de Madrid, Linkat en Cataluña y Trisquel en la Comunidad de Galicia,
por el momento. Todas estas distribuciones tienen en común el hecho de estar
basadas en Debian, o alguno de sus derivados, como Ubuntu.
Venezuela donde por decreto, se estableció el uso preferencial del software libre y
GNU/Linux en toda la administración pública, incluyendo ministerios y oficinas
gubernamentales y se está fomentando la investigación y el desarrollo de software
libre.
Chile, donde el Ministerio de Educación y la Universidad de la Frontera (ubicada
en Temuco) crearon EduLinux, una distribución que hoy está en más de 1500
escuelas chilenas y funcionando en más de un 90% de las bibliotecas chilenas.
Actualmente las Fuerzas Armadas chilenas están planificando la creación de una
22
distribución militar que interconecte a las ramas de la defensa chilena. El gobierno
de ese país aprobó el uso del software libre en la administración pública, anulando
así un contrato previo con Microsoft para el mantenimiento de las redes y de los
equipos en escuelas y bibliotecas chilenas.
República Dominicana, promociona el uso y proliferación del Software libre en el
campo educativo y científico. Dispone de dos fundaciones, una en la capital de
Santo Domingo y la otra en la ciudad de Santiago. Codigolibre.org
México el Gobierno del Distrito Federal dentro de sus políticas y lineamientos en
materia de Informática da preferencia al uso del Software Libre. La Delegación
Tlalpan crea la distribución Gobierno GDF/Linux.
1.10 Como usar un módulo programado para Linux
Después de haber leído la reseña completa sobre Linux, Supongamos que
ya he programado mi driver, ahora ¿cómo lo uso?
Para empezar diremos que sólo el superusuario puede insertar y quitar módulos
del kernel, las razones para esto son evidentes, se podria hacer un driver que se
dedicase a borrar todos los ficheros del disco duro, como este código se ejecuta
en el kernel, podemos saltarnos todas las comprobaciones de permisos de
escritura y borrar todo lo que queramos, aunque esté protegido contra escritura.
En la tabla 5 aparecen los nombres de los comandos necesarios para el manejo
de módulos (que sólo puede ejecutar root).
Tabla 5. Comandos necesarios para el manejo de módulos.
Insmod mi_modulo Inserta el módulo mi_modulo en el kernel
rmmod mi_modulo Saca del kernel el módulo mi_modulo
modinfo
Muestra información sobre el módulo.
modprobe
Automatiza/facilita la gestión de módulos.
23
depmod
Determina las dependencias entre módulos.
Muestra los módulos que están actualmente insertados en
Lsmod
el kernel, junto con algunos datos adicionales sobre el
estado de los mismos.
24
CARGAR MÓDULOS
1.
Compilar el núcleo con los parámetros de configuración que permiten trabajar
con módulos.
*
* Loadable module support
*
Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y
2.
Diseñar e implementar un manejador como módulo cargable.
2.1 Definir número mayor y menor para el dispositivo:
#define manejador_MAYOR nn
#define manejador_MINOR xx
2.2 Definir operaciones de entrada salida para el dispositivo:
static int manejador_fs_read (struct inode *inode, struct file *file,
char *buf, int nbytes );
2.3 Definir la estructura: file_operations
static struct file_operations manejador_fops =
{
NULL,
manejador_fs_read,
NULL,
NULL,
NULL,
NULL,
25
NULL,
NULL,
NULL,
NULL
};
2.4 Diseñar la función de inicialización del modulo y descarga:
int manejador_init (void)
{
.....
}
#ifdef MODULE
/* función de inicio del modulo */
int init_module (void)
{
return manejador_init ();
}
/* Función de descarga del módulo */
void cleanup_module (void)
{
unregister_chardev (mayor device, “manejador”);
printk (“manejador modulo no se puede descargar \n”);
}
#endif
2.5 Diseñar la función de lectura del manejador:
static int manejador_fs_read (struct inode *inode, struct file *file, char *buf, int
26
nbytes)
{
...
}
3.
Compilar el modulo con las directivas: D__KERNEL__ y DMODULE
4.
Crear el archivo especial para este manejador:
#mknod /dev/manejador
5.
c mayor_device menor_device
Insertarlo en el núcleo:
#insmod manejador
6.
Ver lista de módulos cargados:
#lsmod
7.
Utilizarlo:
#modprobe
8.
Quitarlo del núcleo:
#rmmod manejador
MÓDULOS DEL NÚCLEO
Hay componentes del núcleo que siempre tienen que estar en memoria como el
planificador de la CPU.
Sin embargo otros componentes solo tienen que estar en memoria cuando se
necesitan, como el manejador de un CDWriter; un sistema de ficheros Minix, NFS;
27
un manejador de protocolo PPP.
Estas partes del núcleo que pueden cargarse o descargarse dinámicamente en
memoria, mientras el núcleo se esta ejecutando se llaman MÓDULOS.
Ventajas de los módulos:
1. La incorporación de nuevos manejadores al núcleo es mas fácil, se pueden
compilar, cargar, probar, o quitar como módulos antes de integrarlos en le
núcleo.
2. Si el manejador está integrado en el núcleo, cada vez que hagamos
modificaciones en el manejador hay que recompilar todo el núcleo y
reiniciar.
3. El núcleo no ocupa tanta memoria principal, quedando libre para las
aplicaciones.
Desventajas:
1. Cada vez que se requiere o ya no se necesita un módulo hay que pagar el
coste de leer o escribir en disco.
2. El código del núcleo se incrementa con el sistema de manejo de módulos.
La opción que activa que el núcleo maneje los módulos es:
Enable loadable module suport (CONFIG_MODULES) [Y/n/?]
Si se desea instalar un componente como módulo, hay que declararlo en la
configuración del núcleo, ejemplo instalar el sistema de ficheros MSDOS.
28
DOS FAT fs support (CONFIG_FAT_FS) [M/n/y/?] M
MSDOS fs support (CONFIG_MSDOS_FS) [M/n/y/?] M
VFAT (Windows-98) fs support (CONFIG_VFAT_FS) [m/n/y/?] M
Una vez compilado el núcleo se compilan los módulos, la secuencia puede ser:
make config
make dep
make clean
make zImage
make modules
make modules_install
Finalizado este proceso, los módulos se encuentran el /lib/modules.
Los módulos se compilan como cualquier programa pero son enlazados como
imágenes recargables, esto es no están asociadas a ninguna dirección.
Podemos ver los símbolos exportados por el núcleo en /proc/ksyms o utilizando el
comando ksyms.
Cada módulo debe contener unos procedimientos que los manejan, incluyendo
uno de inicialización cuando se carga el módulo y otro de borrado cuando se quita
del núcleo.
Los comandos del súper usuario para manejar manualmente los módulos son:
•
insmod – instalar un módulo
•
lsmod – lee el contenido de /proc/modules y muestra los módulos cargados
en memoria, (nombre, número de páginas del módulo y procesos que los
utilizan).
29
ejemplo de listado al ejecutar lsmod
Module:
•
#pages:
Used by:
msdos
2
1 (autoclean)
vfat
4
1 (autoclean)
fat
6
[vfat msdos] 2 (autoclean)
rmmod – quitar un módulo
Carga automática de módulos por demanda del núcleo
Cuando se monta un sistema de ficheros que no está integrado en el núcleo, el
núcleo solicita al programa kerneld que cargue los módulos necesarios para este
sistema de ficheros montado.
La carga dinámica y automática de módulos precisa que se compile el núcleo con
la opción CONFIG_KERNELD y los IPC System V.
Se precisa al arrancar el sistema lanzar el programa demonio kerneld, que lee las
peticiones del núcleo y realiza la carga o descarga de los módulos necesarios. Se
ejecuta como un proceso de usuario y establece un canal de comunicación
basado en mensajes (IPC) con el núcleo, por el cual el núcleo solicita mediante
mensajes un modulo al programa modprobe. Se utilizan los programas depmod y
modprobe.
DEPMOD, genera un archivo de dependencias de los símbolos encontrados en los
módulos.
MODPROBE, es el programa para manejo de módulos, requiere privilegios de
root.
30
Los procedimientos del núcleo que interaccionan con modprobe y la estructura de
datos principal, (se encuentran en include/linux/module.h y kernel/module.c) son:
•
request_module
Es la función llamada por el núcleo cuando este percibe, por la solicitud de
un proceso, la necesidad de cargar un módulo.
•
exec_modprobe
Es el programa que añade el módulo solicitado al núcleo, es llamado por
kerneld.
•
struct module
module
module_list
module
next
next
ref
ref
symtab
symtab
name
name
size
size
symbol_table
symbol_table
size
size
n_symbols
n_symbols
n_refs
n_refs
Fig. 5 Procedimientos del núcleo que interaccionan
31
módulo
Núcleo
Núcleo
request_module (módulo)
kerneld
disco
modprobe (módulo)
módulo
Fig. 6 Procedimientos del núcleo que interaccionan
Los ficheros que tratan con los módulos son:
incluye/linux/module.h
kernel/module.c
contienen la estructura struc module
y las llamadas al sistema utilizadas por modprobe y los comandos insmod, lsmod
y rmmod son:
sys_create_module
sys_init_module
sys_delete_module
sys_get_kernel_syms
32
CAPITULO II
TCP/IP EN LINUX
33
2.1 TCP/IP
2.1.1 Niveles en la pila TCP/IP
Hay algunas discusiones sobre como encaja el modelo TCP/IP dentro del
modelo OSI. Como TCP/IP y modelo OSI no están delimitados con precisión no
hay una respuesta que sea la correcta.
El modelo OSI no está lo suficientemente dotado en los niveles inferiores como
para detallar la auténtica estratificación en niveles: necesitaría tener una capa
extra (el nivel de Interred) entre los niveles de transporte y red. Protocolos
específicos de un tipo concreto de red, que se sitúan por encima del marco de
hardware básico, pertenecen al nivel de red, pero sin serlo. Ejemplos de estos
protocolos son el ARP (Protocolo de resolución de direcciones) y el STP
(Spanning Tree Protocol). De todas formas, estos son protocolos locales, y
trabajan por debajo de las capas de Interred. Cierto es que situar ambos grupos
(sin mencionar los protocolos que forman parte del nivel de Interred pero se sitúan
por encima de los protocolos de Interred, como ICMP) todos en la misma capa
puede producir confusión, pero el modelo OSI no llega a ese nivel de complejidad
para ser más útil como modelo de referencia.
La siguiente Tabla intenta mostrar la pila TCP/IP y otros protocolos relacionados
con el modelo OSI original:
Tabla 6. Pila de protocolos modelo OSI
7 Aplicación
ej. HTTP, DNS, SMTP, SNMP, FTP, Telnet, SSH y SCP, NFS,
RTSP, Feed, Webcal
6 Presentación
ej. XDR, ASN.1, SMB, AFP
5 Sesión
ej. TLS, SSH, ISO 8327 / CCITT X.225, RPC, NetBIOS
4 Transporte
ej. TCP, UDP, RTP, SCTP, SPX
3 Red
ej. IP, ICMP, IGMP, X.25, CLNP, ARP, RARP, BGP, OSPF
34
2
Enlace
de ej. Ethernet, Token Ring, PPP, HDLC, Frame Relay, RDSI,
datos
ATM, IEEE 802.11, FDDI
1 Físico
Normalmente,
ej. cable, radio, fibra óptica
los
tres
niveles
superiores
del
modelo
OSI
(Aplicación,
Presentación y Sesión) son considerados simplemente como el nivel de aplicación
en el conjunto TCP/IP. Como TCP/IP no tiene un nivel de sesión unificado sobre el
que los niveles superiores se sostengan, estas funciones son típicamente
desempeñadas (o ignoradas) por las aplicaciones de usuario. La diferencia más
notable entre los modelos de TCP/IP y OSI es el nivel de Aplicación, en TCP/IP se
integran algunos niveles del modelo OSI en su nivel de Aplicación. Una
interpretación simplificada de la pila se muestra debajo:
Tabla 7 Una interpretación simplificada de la pila
ej.
5 Aplicación
HTTP,
FTP,
DNS
(protocolos de enrutamiento como BGP y RIP, que por varias
razones funcionen sobre TCP y UDP respectivamente, son
considerados parte del nivel de red)
ej.
TCP,
UDP,
RTP,
SCTP
4 Transporte (protocolos de enrutamiento como OSPF, que funcionen sobre IP,
son considerados parte del nivel de red)
Para
3 Interred
TCP/IP
este
es
el
Protocolo
de
Internet
(IP)
(protocolos requeridos como ICMP e IGMP funcionan sobre IP,
pero todavía se pueden considerar parte del nivel de red; ARP no
funciona sobre IP
2 Enlace
ej. Ethernet, Token Ring, etc.
1 Físico
ej. medio físico, y técnicas de codificación, T1, E1
35
Linux implementa todo lo necesario para trabajar en red con TCP/IP. Desde
administradores para las tarjetas de red más populares hasta SLIP/PPP, que
permiten acceder a una red TCP/IP por el puerto serie. También se implementan
PLIP (para comunicarse por el puerto de la impresora) y NFS (para acceso remoto
a ficheros). Y también se han portado los clientes de TCP/IP, como FTP, telnet,
NNTP y SMTP.
Linux dispone de los dos principales protocolos de red para sistemas UNIX:
TCP/IP y UUCP. TCP/IP (para los aficionados a los acrónimos, Transmission
Control Protocol/Internet Protocol) es un conjunto de protocolos de red que
permite a sistemas de todo el mundo comunicarse en una única red conocida
como Internet. Con Linux, TCP/IP y una conexión a la red, puede comunicarse con
usuarios y máquinas por toda Internet mediante correo electrónico, noticias
(USENET news), transferencias de ficheros con FTP y mucho más. Actualmente
hay muchos sistemas Linux conectados a Internet.
La mayoría de las redes TCP/IP usan Ethernet como tipo de red física de
transporte. Linux da soporte a muchas tarjetas de red Ethernet e interfaces para
ordenadores personales, incluyendo el adaptador Ethernet D-Link de bolsillo para
ordenadores portátiles.
Pero dado que no todo el mundo tiene una conexión Ethernet en casa, Linux
también proporciona SLIP (Serial Line Internet Protocol), el cual permite
conectarse a Internet a través de un módem. Para poder usar SLIP, necesitará
tener acceso a un servidor de SLIP, una máquina conectada a la red que permite
acceso de entrada por teléfono. Muchas empresas y universidades tienen
servidores SLIP disponibles. De hecho, si su sistema Linux dispone de conexión
Ethernet y de módem, puede configurarlo como servidor de SLIP para otros
usuarios.
NFS (Network File System) permite fácilmente compartir ficheros con otras
máquinas de la red. FTP (File Transfer Protocol) permite la transferencia de
ficheros entre máquinas.
Si tiene experiencia con aplicaciones TCP/IP en otros sistemas UNIX, Linux le
será muy familiar. El sistema proporciona la interface estándar de programación
por "sockets", lo que virtualmente permite que cualquier programa que use TCP/IP
36
pueda ser llevado a Linux. El servidor Linux de X también soporta TCP/IP,
permitiendo ver aplicaciones que están corriendo en otros sistemas sobre su
pantalla.
UUCP (UNIX-to-UNIX Copy) es un viejo mecanismo usado para transferir ficheros,
correo electrónico y noticias entre máquinas UNIX. Clásicamente las máquinas
UUCP conectan entre ellas mediante líneas telefónicas y módem, pero UUCP es
capaz de funcionar también sobre una red TCP/IP. Si no tiene acceso a una red
TCP/IP o a un servidor SLIP, puede configurar su sistema para enviar y recibir
ficheros y correo electrónico usando UUCP.
2.1.2 Familia de protocolos de Internet
La familia de protocolos de Internet es un conjunto de protocolos de red que
implementa la pila de protocolos en la que se basa Internet y que permiten la
transmisión de datos entre redes de computadoras. En ocasiones se la denomina
conjunto de protocolos TCP/IP, en referencia a los dos protocolos más importantes
que la componen: Protocolo de Control de Transmisión (TCP) y Protocolo de
Internet (IP), que fueron los dos primeros en definirse, y que son los más utilizados
de la familia. Existen tantos protocolos en este conjunto que llegan a ser más de
100 diferentes, entre ellos se encuentra el popular HTTP (HyperText Transfer
Protocol), que es el que se utiliza para acceder a las páginas web, además de
otros como el ARP (Address Resolution Protocol) para la resolución de
direcciones, el FTP (File Transfer Protocol) para transferencia de archivos, y el
SMTP (Simple Mail Transfer Protocol) y el POP (Post Office Protocol) para correo
electrónico, TELNET para acceder a equipos remotos, entre otros.
El TCP/IP es la base de Internet, y sirve para enlazar computadoras que utilizan
diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras
centrales sobre redes de área local (LAN) y área extensa (WAN). TCP/IP fue
desarrollado y demostrado por primera vez en 1972 por el departamento de
defensa de los Estados Unidos, ejecutándolo en ARPANET, una red de área
extensa del departamento de defensa.
37
La familia de protocolos de internet puede describirse por analogía con el modelo
OSI, que describe los niveles o capas de la pila de protocolos, aunque en la
práctica no corresponde exactamente con el modelo en Internet. En una pila de
protocolos, cada nivel soluciona una serie de problemas relacionados con la
transmisión de datos, y proporciona un servicio bien definido a los niveles más
altos. Los niveles superiores son los más cercanos al usuario y tratan con datos
más abstractos, dejando a los niveles más bajos la labor de traducir los datos de
forma que sean físicamente manipulables.
El modelo de Internet fue diseñado como la solución a un problema práctico de
ingeniería. El modelo OSI, en cambio, fue propuesto como una aproximación
teórica y también como una primera fase en la evolución de las redes de
ordenadores. Por lo tanto, el modelo OSI es más fácil de entender, pero el modelo
TCP/IP es el que realmente se usa. Sirve de ayuda entender el modelo OSI antes
de conocer TCP/IP, ya que se aplican los mismos principios, pero son más fáciles
de entender en el modelo OSI.
2.2 TCP/IP Linux
El código de TCP en Linux se escribió de forma independiente al resto de
implementaciones. Hay que tener en cuenta que, al estar bajo licencia GPL, no
podría haber usado el código de los sistemas BSD, ya que éstos usaban la
licencia BSD original (con la cláusula de publicidad), incompatible con la GPL.
Esta cláusula se quitó mucho más tarde, en 1999.
Todos los detalles de implementación de TCP en Linux están visibles y explicados
en su código fuente. La parte relacionada con TCP en IPv4 está en el directorio
net/ipv4/. Aquí se encuentran ficheros importantes, como:
tcp_ipv4.c
tcp_input.c
tcp_output.c
En net/ipv6/ está el código para implementar TCP sobre IPv6. Es una adaptación
del código para IPv4.
38
En un sistema en ejecución, varios parámetros de TCP se pueden ver y
modificar
mediante
los
ficheros
del
directorio
/proc,
por
ejemplo
/proc/sys/net/ipv4/
Existen varios libros que explican los detalles de implementación de TCP/IP en
el núcleo Linux y analizan su código. Uno de ellos, que describe hasta la
versión 2.4, es:
Wehrle, Klaus; Pahlke, Frank; Ritter, Hartmut; Muller, Daniel; Bechler,
Marc (2004), Linux Network Architecture, Prentice Hall. ISBN 0131777203.
Fig. 7 Varios algoritmos de control de congestión seleccionables al compilar Linux
(versión 2.6.17.4)
Como entrar al menú descrito en la figura 7 (at make menuconfig</menu>):
Asegúrese
que
usted
tiene
"
Prompt
para
desarrollo
y/o
código/controladores incompleto " activo
Activar:
"Networking"
->
"Networking
options"
->
"TCP:
advanced
congestion control"
Entonces entre "TCP congestion control"
The default settings are: BIC-TCP with new Reno as a fallback
39
Linux implementa muchos algoritmos de control de congestión. Por ejemplo, está
SACK, Westwood+, Reno, NewReno, FACK (forward acknowledgement), ECK, HTCP, y varios más. Desde la version 2.6.19 se usa por defecto CUBIC con
NewReno como salvaguarda.
Se puede cambiar el algoritmo usado por defecto ajustando las opciones de
compilación, tal como se ve en la imagen adjunta. Aunque al ser modular, tambien
puede
ser
cambiado
en
caliente
modificando
/proc/sys/net/ipv4/tcp_congestion_control.
Linux 2.4 usando el algoritmo SACK (acuse de recibo selectivo) consigue un
rendimiento mayor que otros sistemas que también usan SACK (como OpenBSD y
FreeBSD), según Comparando las implementaciones modernas (2004/2005), se
ve que han evolucionado por caminos distintos, pero que todas aguantan bien la
congestión de red (a diferencia de la implementación original de BSD). Según las
pruebas, Linux 2.6 el que mejor rendimiento da (de entre FreeBSD 5.3, OpenBSD
3.5, y Windows XP Service Pack 2).
Como el desarrollo de Linux es un proceso abierto al público, en Internet se
encuentran páginas que explican los problemas que daba su implementación de
TCP, y cómo se han solucionado. Por ejemplo: mejora de rendimiento en la
versión 2.0.36 (marzo 1999), problemas de TCP detectados al hacer una
comparativa (1999), ajustes para 2.4 y 2.6 (febrero 2006), problemas en los
algoritmos de TCP en Linux 2.6.16.3 (junio 2006), entre otros. Es habitual que
estos fallos se detecten cuando alguien está escribiendo un documento técnico o
comparativa. En caso de comportamiento extraño, un estudio del código fuente
sirve para confirmar las sospechas y poder corregir el error en Linux.
40
2.2.1 IPv4
IPv4 es la versión 4 del Protocolo IP (Internet Protocol). Esta fue la
primera versión del protocolo que se implementó extensamente, y forma la
base de Internet.
IPv4 usa direcciones de 32 bits, limitándola a 232 = 4.294.967.296 direcciones
únicas, muchas de las cuales están dedicadas a redes locales (LANs). Por el
crecimiento enorme que ha tenido del Internet (mucho más de lo que esperaba,
cuando se diseñó IPv4), combinado con el hecho de que hay desperdicio de
direcciones en muchos casos, ya hace varios años se vio que escaseaban las
direcciones IPv4.
Esta li|mitación ayudó a estimular el impulso hacia IPv6, que esta actualmente
en las primeras fases de implementación, y se espera que termine
reemplazando a IPv4.
2.2.2 Desperdicio de direcciones
¿El desperdicio de direcciones IPv4 se debe a varios factores. Uno de
los principales es que inicialmente no se consideró el enorme crecimiento que
iba a tener Internet; se asignaron bloques de direcciones grandes (de 16,7
millones de direcciones) a países, e incluso a empresas.
Otro motivo de desperdicio es que en la mayoría de las redes, exceptuando las
más pequeñas, resulta conveniente dividir la red en subredes. Dentro de cada
subred, la primera y la última dirección no son utilizables; de todos modos no
siempre se utilizan todas las direcciones restantes. Por ejemplo, si en una
subred se quieren acomodar 80 hosts, se necesita una subred de 128
direcciones (se tiene que redondear a la siguiente potencia de 2); en este
ejemplo, las 48 direcciones restantes ya no se utilizan.
41
2.3 El Sistema Operativo y la Comunicación
La diferencia entre los requisitos de las aplicaciones y las características
(y necesidades) del hardware de comunicación hacen necesaria la existencia
de una interfaz a través de la que las aplicaciones accedan a los servicios de
comunicación entre computadores a través de la red (network communication).
En el sistema operativo suelen incluirse los servicios que permiten la
comunicación entre computadores.
Esta comunicación se encuentra en la base de servicios de red como WWW,
ftp, rlogin, NFS, e-mail,.... y el tipo de red utilizada es irrelevante para el
usuario.
En Linux los protocolos más frecuentemente utilizados para la comunicación
son los TCP/IP. Otros:
En la figura 8 vemos que en la Capa de enlace se muestran los protocolas que
se utilizan con mayor frecuencia en Linux. SLIP (Serial Line Interface Protocol),
PLIP (Parallel Line Interface Protocol), PPP (Point to Point Protocol), AX.25
(Comunicación por radio), IPX (Protocolo desarrollado por Novell).
Fig. 8 Pilas de protocolos.
42
Linux implementa los protocolos del conjunto TCP/IP.
El acceso a los servicios de red se suele realizare a través de los sockets.
Los Sockets BSD son una interfaz de programación abstracta que se implementa
sobre la capa de sockets INET, y ésta, a su vez, sobre la capa de transporte
TCP/UDP.
2.3.1 Envío TCP/IP
Fig. 9 Pila de protocolos y la forma en que interactúan al enviar paquetes
La figura 9 ilustra el proceso que se realiza capa por capa para hacer el envío de
un paquete, desde la escritura del socket hasta que el paquete sale al medio.
43
2.3.2 Recepción TCP/IP
Fig. 10 Pila de protocolos y la forma en que interactúan al recibir paquetes
La figura 10 ilustra el proceso que se realiza capa por capa para hacer la
recepción de un paquete, desde que el paquete llega del medio, hasta que la
aplicación dispone de los datos para su uso.
44
Fig. 11 Pila de protocolos y módulos que los componen
El acceso a los servicios de red se suele realizare a través de los sockets. La
figura 11 muestra la capa de sockets y Los Sockets BSD que son una interfaz de
programación abstracta que se implementa sobre la capa de sockets INET, y ésta,
a su vez, sobre la capa de transporte TCP/UDP.
45
2.3.3 Sockets sobre TCP/IP en Linux: Fuentes y Estructuras de Datos
Fig. 12 Bibliotecas que se utilizan en Linux para manejar sockets.
La figura 12 muestra las bibliotecas empleadas en Linux para utilizar lo sockets
necesarios para el envío y recepción de paquetes necesitados por las aplicaciones
del usuario.
46
Fig .13 Creacion de estructura de datos
Tarjeta de red o NIC (Network Interface Controller, Controlador de Interfaz de Red
en español) mostrada en la figura 13, es una tarjeta de expansión que permite a
una DTE (Data Terminal Equipment) ordenador o impresora acceder a una red y
compartir recursos entre dos o más equipos (discos duros, cdrom, etc). Hay
diversos tipos de adaptadores en función del tipo de cableado o arquitectura que
se utilice en la red (coaxial fino, coaxial grueso, etc.), pero, actualmente el más
común es del tipo Ethernet utilizando un interfaz o conector RJ45.
2.3.4 Creación de un Socket
Proceso ilustrado en la figura 14:
1. Llamada a la función socket() de la biblioteca BSD
2. Se origina la llamada al sistema, sys_socket() (en net/socket.c)
3. Esta función utiliza la función sock_create() (en net/socket.c)
47
Fig. 14 Creacion de un socket
Mediante inet_create(struct socket *sock, int protocol), como se muestra en la
figura 15 (net/ipv4/af_inet.c)
•
Se asigna memoria a la estructura sock
•
Se inicializan los valores correspondientes a TCP o UDP para la estructura
proto
•
Se inicializan los valores correspondientes a familia, protocolo, etc. en la
estructura sock
Fig. 15 Creacion de un socket 2
48
Fig. 16 Estructura de un socket
En la figura 16 se muestra el bloque de código que contiene la información del
estado del socket y las estructuras hacia las que apunta.
49
Fig. 17 Estructura del protocolo de transmisión
En la figura 17 está el bloque de código para elaborar la estructura del protocolo
de transmisión, declarado proto_ops.
Fig. 18 Estructura de un socket
50
La figura 18 muestra el código correspondiente a la estructura de un socket en la
que se utilizan apuntadores que se dirigen hacia estructuras como: proto,
sk_buff_head_recive_queue, sk_buff_head_write_queue.
Fig. 19 Estructura compuesta por una serie de operaciones para implementar los protocolos TCP y
UDP
En la figura 19 se muestra el código de la estructura compuesta por apuntadores
que van a ser utilizados en los protocolos tcp y udp.
51
Fig. 20 Escritura del sistema de archivos en Linux
En informática, un inodo, nodo-i (figura 20), nodo índice o i-node en inglés
es una estructura de datos propia de los sistemas de archivos tradicionalmente
empleados en los sistemas operativos tipo UNIX como es el caso de Linux. Un
inodo contiene las características (permisos, fechas, ubicación, pero NO el
nombre) de un archivo regular, directorio, o cualquier otro objeto que pueda
contener el sistema de ficheros.
52
Fig. 21 Diagrama explicativo de la interacción entre el socket, protocolo y el sistema de archivos.
En la figura 21 se presenta la interacción existente entre las estructuras antes
creadas.
1,2 (figura 22): write(socket,data, length) llama a sys_write() componente del
VFS, que comprueba características del socket, sock_write() transfiere los
parámetros de la escritura a la estructura de mensaje y llama a sock_sendmsg()
obtiene la dirección del socket a partir de su identificador, como se muestra en la
figura 22 y 23.
53
Fig. 22 Uso de la memoria del sistema
Fig. 23 Estructura de envio
54
Fig. 24 Almacenamiento de punteros a funciones en un vector.
El descriptor de un socket es similar a un descriptor de fichero: se pueden utilizar
llamadas estándar al sistema para operar con ficheros. Los punteros utilizados
para las distintas operaciones de fichero se almacenan en un vector como se
muestra en la figura 24.
55
Fig. 25 Definición de la estructura de archivos a utilizar
En la figura 25 se muestran el código de la estructura archivo (struct file)
declarando las variables a utilizar y las estructuras con las que se va a conectar.
Fig. 26 Asociación del socket con el fichero
56
Después de crear las estructuras, file y files_struct, se busca la estructura socket
asociada con el fichero a través de la función scki_lookup(), se convierten los
parámetros a la estructura del mensaje completando la correspondiente cabecera
(msghdr) y se llama a la función sock_sendmsg() situada en la biblioteca
/net/socket.c, como se muestra en el código de la figura 26.
Fig. 27 Estructuras creadas a partir del socket
En el cuadro numero 3 de la figura 27 se utiliza inet_sendmsg() (figura 28): utiliza
sock para llamar a la función de envío según el protocolo (proto tiene un puntero a
la función de envío)
En el cuadro numero 4 de la figura 27 se utiliza tcp_sendmsg(): reserva memoria
para los paquetes, trocea en MTU, crea la estructura sk_buff, y comprueba
disponibilidad en receptor.
Al crear un socket se crean, entre otras, las estructuras de datos socket, sock,
inode, proto_ops y proto, como se muestra en la figura 27.
57
Fig. 28 Forma de interacción entre las estructuras creadas
Fig. 29 Protocolo enviado con las características del paquete
Extrae de socket el puntero que apunta a una estructura sock (socket INET)
A través de la estructura sock se llama a la función de envío de protocolo: El
campo prot de la estructura sock tiene los punteros de función para TCP (o UDP).
Es decir sk->prot->sendmsg(sk,msg,size) se traduce a tcp_sendmsg (figura 29).
58
struct sk_buff {
/* These two members must be first. */
struct sk_buff * next;
/* Next buffer in list
struct sk_buff * prev;
/* Previous buffer in list
struct sk_buff_head * list;
/* List we are on
struct sock
*sk;
/* Socket we are owned by
struct timeval stamp;
/* Time we arrived
struct net_device *dev;
/* Device we arrived on/are leaving by
/* Transport layer header */
union
{
struct tcphdr *th;
struct udphdr *uh;
struct icmphdr *icmph;
struct igmphdr *igmph;
struct iphdr *ipiph;
struct spxhdr *spxh;
unsigned char *raw;
} h;
/* Network layer header */
union
{
struct iphdr *iph;
struct ipv6hdr *ipv6h;
struct arphdr *arph;
struct ipxhdr *ipxh;
unsigned char *raw;
} nh;
*/
*/
*/
*/
*/
*/
/* Link layer header */
union
{
struct ethhdr *ethernet;
unsigned char *raw;
} mac;
struct dst_entry *dst;
/*
/*
* This is the control buffer. It is free to use for every
* layer. Please put your private variables there. If you
* want to keep them across layers you have to do a skb_clone()
* first. This is owned by whoever has the skb queued ATM.
*/
char
cb[48];
unsigned int len;
/* Length of actual data
*/
unsigned int data_len;
unsigned int csum;
/* Checksum
*/
unsigned char __unused,
/* Dead field, may be reused
*/
cloned,
/* head may be cloned (check refcnt to be sure). */
pkt_type,
/* Packet class
*/
ip_summed; /* Driver fed us an IP checksum
*/
__u32
priority;
/* Packet queueing priority
*/
atomic_t
users;
/* User count - see datagram.c,tcp.c
*/
unsigned short protocol;
/* Packet protocol from driver.
*/
unsigned short security;
/* Security level of packet
*/
unsigned int truesize;
/* Buffer size
unsigned char *head;
* Head of buffer
unsigned char *data;
/* Data head pointer
unsigned char *tail;
/* Tail pointer
unsigned char *end;
* End pointer
void
(*destructor)(struct sk_buff *);/* Destruct function
……………………………………………
*/
*/
*/
*/
*/
*/
};
Fig. 30 Estructura del buffer
59
En la figura 30 se muestra el código para crear struct sk_buff, que es la
estructura del buffer utilizado para almacenar momentáneamente los datos que
llegan y se utiliza la biblioteca /include/linux/skbuff.h.
Todos los protocolos utilizan el mismo sk_buff. Los protocolos de transporte y los
drivers crean estructuras de paquete para los datos que les llegan. Éstos se
gestionan a través de los buffers que se muestran en la figura 31.
Fig. 31 Estructura del buffer.
60
Fig. 32 Secuencia de envío
int tcp_sendmsg(struct sock *sk, struct msghdr *msg, int size)
{
struct iovec *iov;
struct tcp_opt *tp;
struct sk_buff *skb;
int iovlen, flags;
int mss_now;
int err, copied;
long timeo;
tp = &(sk->tp_pinfo.af_tcp);
lock_sock(sk);
TCP_CHECK_TIMER(sk);
flags = msg->msg_flags;
timeo = sock_sndtimeo(sk, flags&MSG_DONTWAIT);
/* Wait for a connection to finish. */
if ((1 << sk->state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT))
if((err = wait_for_tcp_connect(sk, flags, &timeo)) != 0) goto out_err;
/* This should be in poll */
clear_bit(SOCK_ASYNC_NOSPACE, &sk->socket->flags);
Fig. 33 Estructura del proceso de envio del mensaje
61
El
método
tcp_sendmsg()
mostrado
en
la
figura
32
y
visualizado
estructuralmente en la figura 33 ubicado en la biblioteca /net/ipv4/tpc.c realiza las
siguientes acciones:
•
Reserva memoria de sistema para los paquetes llamando a la la función
tcp_alloc_pskb()
•
Trocea los datos en unidades MTU y crea una estructura sk_buff para
almacenar cada MTU. Se copian los datos desde la memoria de usuario a
las estructuras sk_buff. Mediante csum_and_copy_from_user() se realiza
la copia y el cálculo del código de eror. Las estructuras sk_buff para un
mismo mensaje están enlazadas.
•
Llama a tcp_write_xmit() para controlar que el receptor tiene disponible
una ventana de recepción (según el algoritmo de control de flujo de ventana
deslizante) y cuando se tiene el visto bueno (se utiliza un timer) se llama a
tcp_transmit_skb()
Fig. 34 cuadro no. 5 tcp_transmit_skb
62
El cuadro 5 de la figura 34, corresponde a tcp_transmit_skb() que es el compone
de la cabecera TCP para cada sk_buf y contiene la información del sock (se llama
según el número de paquetes). Decide si se encolan o se envían (figura 35).
Fig. 35 Se procede a enviar el mensaje mediante un socket
63
int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb)
{
if(skb != NULL) {
struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
int tcp_header_size = tp->tcp_header_len;
struct tcphdr *th;
int sysctl_flags;
int err;
#define SYSCTL_FLAG_TSTAMPS
#define SYSCTL_FLAG_WSCALE
#define SYSCTL_FLAG_SACK
0x1
0x2
0x4
sysctl_flags = 0;
if (tcb->flags & TCPCB_FLAG_SYN) {
tcp_header_size = sizeof(struct tcphdr) + TCPOLEN_MSS;
if(sysctl_tcp_timestamps) {
tcp_header_size += TCPOLEN_TSTAMP_ALIGNED;
sysctl_flags |= SYSCTL_FLAG_TSTAMPS;
}
if(sysctl_tcp_window_scaling) {
tcp_header_size += TCPOLEN_WSCALE_ALIGNED;
sysctl_flags |= SYSCTL_FLAG_WSCALE;
}
if(sysctl_tcp_sack) {
sysctl_flags |= SYSCTL_FLAG_SACK;
if(!(sysctl_flags & SYSCTL_FLAG_TSTAMPS))
tcp_header_size += TCPOLEN_SACKPERM_ALIGNED;
}
} else if (tp->eff_sacks) {
/* A SACK is 2 pad bytes, a 2 byte header, plus
* 2 32-bit sequence numbers for each SACK block.
*/
tcp_header_size += (TCPOLEN_SACK_BASE_ALIGNED +
(tp->eff_sacks * TCPOLEN_SACK_PERBLOCK));
}
th = (struct tcphdr *) skb_push(skb, tcp_header_size);
skb->h.th = th;
skb_set_owner_w(skb, sk);
Fig. 36 Estructura del envio del mensaje mediante un socket
64
/* Build TCP header and checksum it. */
th->source
= sk->sport;
th->dest
= sk->dport;
th->seq
= htonl(tcb->seq);
th->ack_seq
= htonl(tp->rcv_nxt);
*(((__u16 *)th) + 6)
= htons(((tcp_header_size >> 2) << 12) | tcb->flags);
if (tcb->flags & TCPCB_FLAG_SYN) {
/* RFC1323: The window in SYN & SYN/ACK segments
* is never scaled.
*/
th->window = htons(tp->rcv_wnd);
} else {
th->window = htons(tcp_select_window(sk));
}
th->check
= 0;
th->urg_ptr
= 0;
if (tp->urg_mode &&
between(tp->snd_up, tcb->seq+1, tcb->seq+0xFFFF)) {
th->urg_ptr
= htons(tp->snd_up-tcb->seq);
th->urg
= 1;
}
if (tcb->flags & TCPCB_FLAG_SYN) {
tcp_syn_build_options((__u32 *)(th + 1),
tcp_advertise_mss(sk),
(sysctl_flags & SYSCTL_FLAG_TSTAMPS),
(sysctl_flags & SYSCTL_FLAG_SACK),
(sysctl_flags & SYSCTL_FLAG_WSCALE),
tp->rcv_wscale,
tcb->when,
tp->ts_recent);
} else {
tcp_build_and_update_options((__u32 *)(th + 1),
tp, tcb->when);
TCP_ECN_send(sk, tp, skb, tcp_header_size);
}
tp->af_specific->send_check(sk, th, skb->len, skb);
Fig. 37 Continuación de la figura 36
En las figuras 36 y 37 se muestra el código de la función tcp_transmit_skb(), el
cual se encuentra en la biblioteca /net(ipv4/tcp_output.c y Construye la cabecera
TCP y calcula el código de error (checksum) para cada sk_buff con la información
disponible en sock. Se llama a esta función tantas veces como paquetes existan.
65
Fig. 38 Estructura en donde se toma la decisión de enviar o encolar el o los paquetes
Función
tcp_transmit_skb()
que
se
encuentra
en
la
biblioteca
/net(ipv4/tcp_output.c, este llama a tcp_send_skb() (fig. 38) que decide si envía o
encola los paquetes añadiendo la correspondiente estructura sk_buff a la lista
enlazada (en los dos sentidos) con los paquetes pendientes de envío.
La función tcp_send_skb() también se encarga de actualizar el número de
secuencia de los paquetes (con la información disponible en sock)
Finalmente, tcp_transmit_skb() llama a ip_queue_xmit()
66
Fig. 39 Diagrama del proceso de salida del paquete
En el cuadro 6 de la figura 39 que corresponde a la función ip_queue_xmit() la
cual se encarga de poner la cabecera IP y llamar a dev_queue_xmit() para que
vaya transmitiendo cada paquete (figura 40).
En el cuadro 7 de la figura 39 que corresponde a la función dev_queue_xmit()
actúa sobre la estructuras sk_buff de los paquetes pendientes.
La rutina socket() de la biblioteca de C devuelve un descriptor de fichero, las
llamadas a las funciones del sistema de E/S read() y write() pueden utilizarse.
Cuando un proceso se comunica a través de la red utiliza las funciones que
proporciona la capa de sockets BSD. Esta capa se encarga de tareas similares a
las del sistema de ficheros virtuales y permite administrar una estructura de datos
general para los sockets.
Debajo está la capa de sockets INET que gestiona los extremos de comunicación
para los protocolos TCP y UDP. Estos se manejan a través de estructuras de
datos sock (sockets INET). Según el tipo de socket, la capa que hay debajo es la
capa TCP, UDP, o directamente la capa IP. Debajo de la capa IP están los
dispositivos, a los que la capa IP pasa los paquetes finales. Se asume que los
67
procesos que se comunican han creado sus sockets y se encuentran conectados
unos con otros a través de connect() o accept().
Fig. 40 ip_queue_xmit()
68
int ip_queue_xmit(struct sk_buff *skb)
{
struct sock *sk = skb->sk;
struct ip_options *opt = sk->protinfo.af_inet.opt;
struct rtable *rt;
struct iphdr *iph;
/* Make sure we can route this packet. */
rt = (struct rtable *)__sk_dst_check(sk, 0);
if (rt == NULL) {
u32 daddr;
/* Use correct destination address if we have options. */
daddr = sk->daddr;
if(opt && opt->srr)
daddr = opt->faddr;
/* If this fails, retransmit mechanism of transport layer will
* keep trying until route appears or the connection times itself
* out.
*/
if (ip_route_output(&rt, daddr, sk->saddr,
RT_TOS(sk->protinfo.af_inet.tos) | RTO_CONN | sk->localroute,
sk->bound_dev_if))
goto no_route;
__sk_dst_set(sk, &rt->u.dst);
sk->route_caps = rt->u.dst.dev->features;
}
skb->dst = dst_clone(&rt->u.dst);
if (opt && opt->is_strictroute && rt->rt_dst != rt->rt_gateway)
goto no_route;
/* OK, we know where to send it, allocate and build IP header. */
iph = (struct iphdr *) skb_push(skb, sizeof(struct iphdr) + (opt ? opt->optlen : 0));
*((__u16 *)iph)
= htons((4 << 12) | (5 << 8) | (sk->protinfo.af_inet.tos & 0xff));
iph->tot_len = htons(skb->len);
iph->frag_off = 0;
iph->ttl
= sk->protinfo.af_inet.ttl;
iph->protocol = sk->protocol;
iph->saddr = rt->rt_src;
iph->daddr = rt->rt_dst;
skb->nh.iph = iph;
/* Transport layer set skb->h.foo itself. */
if(opt && opt->optlen) {
iph->ihl += opt->optlen >> 2;
ip_options_build(skb, opt, sk->daddr, rt, 0);
}
return NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
ip_queue_xmit2);
no_route:
IP_INC_STATS(IpOutNoRoutes);
kfree_skb(skb);
return -EHOSTUNREACH;
}
Fig. 41 estructua de código en la que ip_queue_xmit() contruye la cabecera IP
69
En la figura 41 se enuncia el código de la función ip_queue_xmit() que se
encuentra en la biblioteca /net/ipv4/ip_output.c y construye la cabecera IP, busca
la ruta, añade el código de error (checksum), fragmenta y llama a
dev_queue_xmit() (fig. 42).
Fig. 42 La rutina dev_queue_xmit() se encarga de la transmisión del sk_buff correspondiente a
cada paquete, a través de la tarjeta de red (a través de una llamada a su controlador
70
int dev_queue_xmit(struct sk_buff *skb)
{
struct net_device *dev = skb->dev;
struct Qdisc *q;
if (skb_shinfo(skb)->frag_list &&
!(dev->features&NETIF_F_FRAGLIST) &&
skb_linearize(skb, GFP_ATOMIC) != 0) {
kfree_skb(skb);
return -ENOMEM;
}
/* Fragmented skb is linearized if device does not support SG,
* or if at least one of fragments is in highmem and device
* does not support DMA from it.
*/
if (skb_shinfo(skb)->nr_frags &&
(!(dev->features&NETIF_F_SG) || illegal_highdma(dev, skb)) &&
skb_linearize(skb, GFP_ATOMIC) != 0) {
kfree_skb(skb);
return -ENOMEM;
}
/* If packet is not checksummed and device does not support
* checksumming for this protocol, complete checksumming here.
*/
if (skb->ip_summed == CHECKSUM_HW &&
(!(dev->features&(NETIF_F_HW_CSUM|NETIF_F_NO_CSUM)) &&
(!(dev->features&NETIF_F_IP_CSUM) ||
skb->protocol != htons(ETH_P_IP)))) {
if ((skb = skb_checksum_help(skb)) == NULL)
return -ENOMEM;
}
/* Grab device queue */
spin_lock_bh(&dev->queue_lock);
q = dev->qdisc;
if (q->enqueue) {
int ret = q->enqueue(skb, q);
qdisc_run(dev);
spin_unlock_bh(&dev->queue_lock);
return ret == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : ret;
}
/* The device has no queue. Common case for software devices:
loopback, all the sorts of tunnels...
Really, it is unlikely that xmit_lock protection is necessary here.
(f.e. loopback and IP tunnels are clean ignoring statistics counters.)
However, it is possible, that they rely on protection
made by us here.
Check this and shot the lock. It is not prone from deadlocks.
Either shot noqueue qdisc, it is even simpler 8)
*/
if (dev->flags&IFF_UP) {
int cpu = smp_processor_id();
if (dev->xmit_lock_owner != cpu) {
spin_unlock(&dev->queue_lock);
spin_lock(&dev->xmit_lock);
dev->xmit_lock_owner = cpu;
Fig. 43 La rutina dev_queue_xmit() se encarga de la transmisión del sk_buff correspondiente a cada
paquete, a través de la tarjeta de red (a través de una llamada a su controlador)
71
En la figura 43 se encuentra el código de la función dev_queue_xmit() la cual se
encuentra en la biblioteca /net/core/dev.c y se encarga de:
•
La rutina dev_queue_xmit() se encarga de la transmisión del sk_buff
correspondiente a cada paquete, a través de la tarjeta de red (a través de
una llamada a su controlador.
•
La función actúa sobre las estructuras sk_buff de todos los paquetes
pendientes de envío de todas las aplicaciones que necesitan enviar a través
del mismo dispositivo.
•
Las estructuras sk_buff se encuentran enlazadas a través de una lista (en
una sola dirección) (Fig. 44).
Fig. 44 Diagrama explicativo de la interacción
72
2.3.5 Ubicación de las Funciones ejecutadas para enviar un mensaje a
través de Sockets en Linux
Fig. 45 Ubicación de las funciones ejecutadas para enviar un mensaje a través de sockets en Linux
Otras estructuras o punteros que se incluyen en esta estructura de la figura 45
son:
-
Cabecera de la cola de recibidos
-
Cabecera de la cola de enviados
-
Dirección fuente para el socket
-
Colas extras para paquetes de respaldo, erróneos, etc.
-
Opciones TCP para el socket
73
2.3.6 Convenientes e Inconvenientes de la comunicación con TCP/IP
en Linux.
Para culminar el capítulo 2 de esta monografía, voy a enlistar de las
ventajas y desventajas de la transmisión de datos mediante TCP/IP en Linux:
Ventajas:
• Ofrece interfaz de programación (API): Sockets BSD
• Transporte fiable
• Protección entre aplicaciones
• Control de flujo
• Gestión de multitarea y multiusuario
Desventajas:
• Cambios de contexto
• Transferencias de datos entre el espacio de usuario y las estructuras
utilizadas por el sistema operativo
• Tiempo que consume la ejecución de las rutinas que implementan los
protocolos.
74
CAPITULO III
LAS WIRELESS LAN EN LINUX
75
3.1 LAS WIRELESS LAN
En los últimos años se ha producido un crecimiento espectacular en lo
referente al desarrollo y aceptación de las comunicaciones móviles y en concreto
de las redes de área local (Wireless LANs). La función principal de este tipo de
redes es la proporcionar conectividad y acceso a las tradicionales redes cableadas
(Ethernet, Token Ring...), como si de una extensión de éstas últimas se tratara,
pero con la flexibilidad y movilidad que ofrecen las comunicaciones inalámbricas.
El momento decisivo para la consolidación de estos sistemas fue la conclusión del
estándar IEEE 802.11 el mes de junio de 1997. En este estándar se encuentran
las especificaciones tanto físicas como a nivel MAC que hay que tener en cuenta a
la hora de implementar una red de área local inalámbrica. Otro de los estándares
definidos y que trabajan en este mismo sentido es el ETSI HIPERLAN.
WLAN (inglés < Wireless Local Area Network) es un sistema de comunicación de
datos inalámbrico flexible muy utilizado como alternativa a las redes LAN
cableadas o como extensión de éstas. Utiliza tecnología de radiofrecuencia que
permite mayor movilidad a los usuarios al minimizar las conexiones cableadas.
Las WLAN van adquiriendo importancia en muchos campos, como almacenes o
para manufactura, en los que se transmite la información en tiempo real a una
terminal central. También son muy populares en los hogares para compartir el
acceso a Internet entre varias computadoras.
La norma 802.11 ha sufrido diferentes extensiones sobre la norma para obtener
modificaciones
y
mejoras.
De
esta
manera,
tenemos
las
siguientes
especificaciones:
802.11 Especificación para 1-2 Mbps en la banda de los 2.4 GHz, usando salto de
frecuencias( FHSS) o secuencia directa (DSSS).
802.11b Extensión de 802.11 para proporcionar 11Mbps usando DSSS.
76
Wi-Fi (Wireless Fidelity) Promulgado por el WECA para certificar productos
802.11b capaces de interoperar con los de otros fabricantes.
802.11a Extensión de 802.11 para proporcionar 54Mbps usando OFDM.
802.11g Extensión de 802.11 para proporcionar 20-54Mbps usando DSSS y
OFDM. Es compatible hacia atrás con 802.11b. Tiene mayor alcance y menor
consumo de potencia que 802.11a.
3.1.1 Principios de las redes WLAN
3.1.1.1
Cómo trabajan
Se utilizan ondas de radio para llevar la información de un punto a otro
sin necesidad de un medio físico guiado. Al hablar de ondas de radio nos
referimos normalmente a portadoras de radio, sobre las que va la información,
ya que realizan la función de llevar la energía a un receptor remoto. Los datos
a transmitir se superponen a la portadora de radio y de este modo pueden ser
extraídos exactamente en el receptor final.
A este proceso se le llama modulación de la portadora por la información que
está siendo transmitida. Si las ondas son transmitidas a distintas frecuencias
de radio, varias portadoras pueden existir en igual tiempo y espacio sin
interferir entre ellas. Para extraer los datos el receptor se sitúa en una
determinada frecuencia, frecuencia portadora, ignorando el resto. En una
configuración típica de LAN sin cable los puntos de acceso (transceiver)
conectan la red cableada de un lugar fijo mediante cableado normalizado. El
punto de acceso recibe la información, la almacena y la transmite entre la
WLAN y la LAN cableada. Un único punto de acceso puede soportar un
pequeño grupo de usuarios y puede funcionar en un rango de al menos treinta
metros y hasta varios cientos. El punto de acceso (o la antena conectada al
punto de acceso) es normalmente colocado en alto pero podría colocarse en
cualquier lugar en que se obtenga la cobertura de radio deseada. El usuario
final accede a la red WLAN a través de adaptadores. Estos proporcionan una
77
interfaz entre el sistema de operación de red del cliente (NOS: Network
Operating System) y las ondas, mediante una antena.
3.1.1.2
Configuraciones de red para radiofrecuencia
Pueden ser de muy diversos tipos y tan simples o complejas como sea
necesario. La más básica se da entre dos ordenadores equipados con tarjetas
adaptadoras para WLAN, de modo que pueden poner en funcionamiento una red
independiente siempre que estén dentro del área que cubre cada uno. Esto es
llamado red de igual a igual (peer to peer). Cada cliente tendría únicamente
acceso a los recursos del otro cliente pero no a un servidor central. Este tipo de
redes no requiere administración o preconfiguración.
Instalando un Punto de Acceso se puede doblar la distancia a la cuál los
dispositivos pueden comunicarse, ya que estos actúan como repetidores. Desde
que el punto de acceso se conecta a la red cableada cualquier cliente tiene acceso
a los recursos del servidor y además gestionan el tráfico de la red entre los
terminales más próximos. Cada punto de acceso puede servir a varias máquinas,
según el tipo y el número de transmisiones que tienen lugar. Existen muchas
aplicaciones en el mundo real con un rango de 15 a 50 dispositivos cliente con un
solo punto de acceso.
Los puntos de acceso tienen un alcance finito, del orden de 150 m en lugares u
zonas abiertas. En zonas grandes como por ejemplo un campus universitario o un
edificio es probablemente necesario más de un punto de acceso. La meta es
cubrir el área con células que solapen sus áreas de modo que los clientes puedan
moverse sin cortes entre un grupo de puntos de acceso. Esto es llamado roaming.
iuparticulares de topologías, el diseñador de la red puede elegir usar un Punto de
Extensión (EPs) para aumentar el número de puntos de acceso a la red, de modo
que funcionan como tales pero no están enganchados a la red cableada como los
puntos de acceso. Los puntos de extensión funcionan como su nombre indica:
extienden el alcance de la red retransmitiendo las señales de un cliente a un punto
78
de acceso o a otro punto de extensión. Los puntos de extensión pueden
encadenarse para pasar mensajes entre un punto de acceso y clientes lejanos de
modo que se construye un puente entre ambos.
Uno de los últimos componentes a considerar en el equipo de una WLAN es la
antena direccional. Por ejemplo: si se quiere una Lan sin cable a otro edificio a 1
km de distancia. Una solución puede ser instalar una antena en cada edificio con
línea de visión directa. La antena del primer edificio está conectada a la red
cableada mediante un punto de acceso. Igualmente en el segundo edificio se
conecta un punto de acceso, lo cual permite una conexión sin cable en esta
aplicación.
3.1.1.3
Chipset
El Circuito Integrado Auxiliar o Chipset es un conjunto de circuitos integrados que
se encarga de realizar las funciones que el microprocesador delega en ellos.
Chipset traducido literalmente del inglés significa conjunto de circuitos integrados.
Se designa circuito integrado auxiliar al circuito integrado que es periférico a un
sistema pero necesario para el funcionamiento del mismo. La mayoría de los
sistemas necesitan más de un circuito integrado auxiliar.
Contiene todas las instrucciones necesarias para operar la tarjeta inalámbrica.
3.2 LAS WIRELESS LAN EN LINUX
3.2.1 Chipset Prism
El chipset Prism es un circuito auxiliar integrado de los más antiguos en el
mercado, desde que en el año 1998 la empresa Intersil lo creó ha ido
evolucionando hasta convertirse en uno de los más potentes chipsets en el medio.
El chipset Prism es uno de los más usados por usuarios de GNU/Linux así como
BSD gracias a la integración a la que goza este chipset ya que todos los
documentos del comité de evaluación; notas, diseños de referencia, informes y
79
resúmenes técnicos sobre el chipset se pueden conseguir de forma gratuita en la
página web de Intersil
3.2.1.1
Funcionamiento
Tomemos el esquema de la primera versión del Chipset Prism para explicar su
funcionamiento:
La controladora MAC(situada a la derecha en el esquema) ya que realiza la mayor
parte de las operaciones básicas del protocolo 802,11 es la encargada de
determinar si se puede utilizar la tarjeta en modo monitor (RFMON) y de la
inserción y manipulación de marcos en los paquetes así como indicar si la tarjeta
puede cumplir la función de punto de acceso
La controladora MAC de los chipsets Prism 2,0 o superior posee un motor WEP
que agiliza el trabajo con este tipo de criptografía ahorrando ciclos de CPU al
ordenador.
Prism I
---- 802,11 original
Prism II ---- 802,11b
Prism III ---- 802,11a/b
Prism Indigo - 802,11ª
Prism GT ---- 802,11b/g
Prism Duette - 802,11a/b
Prism Nitro -- red IEEE 802.11g mejorada
Prism World Radio --802,11a, b, d, g, h, i y j
80
3.2.2 Chipset Hermes
El Chipset Hermes está desarrollado por Lucent. Es un chipset de código cerrado,
no obstante Lucent publicó una parte del código fuente necesario para controlar
las funciones básicas de las tarjetas ORiNOCO, a partir del cual se creó el
controlador wvlan_cs. Actualmente el controlador wvlan_cs ha sido reemplazado
por el orinoco_cs.
Gran parte de las tarjetas con chipset Hermes poseen un conector de antena
superior a los MMCX de los chipset Prism o Aironet lo que hace que los problemas
de conexión antena/tarjeta sean casi nulos.
ORiNOCO® 11a/b/g ComboCard
ORiNOCO® 11a/b/g PCI Card
3.2.3 Chipset Atheros
Atheros WLAN chipsets destaca tecnologías de punta para ampliar la gama y
reducir el consumo de electricidad de redes inalámbricas 802.11. Cuando son
incorporados en dispositivos WLAN, los chipsets Atheros ofrecen a los usuarios
finales una amplia gama, una mayor duración de la pila, e instrumentos de
dirección de red que la ayudan a reducir el costo, funcionamiento y posesión de
redes inalámbricas.
81
3.3 EJEMPLO DE LA INSTALACIÓN DE UNA TARJETA
INALAMBRICA EN LINUX
Hardware
Tarjeta SMC2335W, EZ Connect 2.4Ghz/5Ghz Universal Wireless Cardbus
Adapter
Software
Módulo MadWifi para el núcleo Linux para la tarjeta con chipset Atheros
Situandote en el directorio /usr/src, crea un directorio para el módulo madwifi y
situate dentro de él:
$md madwifi
$cd madwifi
Para obtener el módulo de madwifi, como no hay en este momento una versión
publicada fuera del cvs, hay que utilizar este repositorio para obtener la versión en
curso, con el comando:
cvs -z3 -d:pserver:[email protected]:/cvsroot/madwifi co madwifi
Preparando los fuentes del núcleo antes de compilar madwifi. Para compilar un
módulo necesitas los ficheros de cabeceras del nucleo instalados en tu equipo.
Supón que tienes instalado el núcleo 2.4.25 para Intel Pentium II, III y superiores
en Debian del paquete que viene ya listo para instalar, verás que tienes instalado
el paquete:
kernel-image-2.4.25-1-686
Baja el paquete con las fuentes de esa versión del nucleo y descomprimelo:
$cd /usr/src
$apt-get install kernel-source-2.4.25
$tar jxvf kernel-source-2.4.25.tar.bz2
Además, deja el fichero de opciones de compilación con el que se esta trabajando
en el directorio del nucleo descomprimido, como si lo hubieras usado realmente
para compilar el nucleo... esto te deja este directorio del nucleo practicamente
igual que si hubieras hecho una compilación del nucleo (pero sin los ficheros
temporales y sin el resultado final de la compilación, claro):
82
cp /boot/config-2.4.25-1-686 /usr/src/kernel-image-2.4.25/.config
modificar /etc/kernel-pkg.conf e incluir en el "do_clean := No"
recompilar el nucleo: make-kpkg --revision=custom.1.0 kernel_image
Enlaza ahora el directorio donde está el nucleo con el directorio build del directorio
de modulos que están en uso en tu actual nucleo:
ln -s /usr/src/kernel-source-2.4.25 /lib/modules/2.4.25-1-586tsc/build
Compilando el módulo madwifi
Ponte en el directorio donde lo descomprimiste antes, y ejecuta make:
cd /usr/src/madwifi
make
make install
Ya está listo el módulo.
Asegurate de que está conectada la tarjeta (conectala y si usas pcmcia_cs verás
algo como lo siguiente en tu syslog):
May 14 00:32:10 gordon kernel: cs: cb_alloc(bus 1): vendor 0x168c, device
0x0012
May 14 00:32:10 gordon kernel: PCI: Enabling device 01:00.0 (0000 -> 0002)
May 14 00:32:10 gordon cardmgr [419] : socket 0: ?CardBus hotplug device
Ya que pcmcia_cs no conoce nada sobre tu tarjeta, no carga el modulo, así que lo
cargas a mano:
modprobe ath_pci
y el syslog reflejará algo como esto:
May 14 00:32:33 gordon kernel: ath_hal: 0.9.8.6
May 14 00:32:34 gordon kernel: wlan: 0.7.3.1 BETA
May 14 00:32:34 gordon kernel: ath_pci: 0.8.5.4 BETA
May 14 00:32:34 gordon kernel: ath_pci: cache line size not set; forcing 8
May 14 00:32:34 gordon kernel: Setup queue (0) for WME_AC_BK
May 14 00:32:34 gordon kernel: Setup queue (1) for WME_AC_BE
May 14 00:32:34 gordon kernel: Setup queue (2) for WME_AC_VI
May 14 00:32:34 gordon kernel: Setup queue (3) for WME_AC_VO
May 14 00:32:34 gordon kernel: ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio
2.3
83
May 14 00:32:34 gordon kernel: ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps
May 14 00:32:34 gordon kernel: ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
May 14 00:32:34 gordon kernel: ath0: turbo rates: 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps
May 14 00:32:34 gordon kernel: ath0: 802.11 address: 00:01:24:60:0d:6d
May 14 00:32:34 gordon kernel: ath0: Atheros 5211: mem=0x10400000, irq=11
Si quieres que el módulo se cargue siempre al arrancar (por simplificar, no podrás
quitar y poner la tarjeta como lo haces habitualmente con una pcmcia que si esté
contemplada por pcmcia_cs), añade este módulo en /etc/modules:
ath_pci
Configurar la interface ath0 (ojo, no eth con e, si no con a)
Manualmente:
iwconfig ath0 essid redlibre mode managed rate auto
pump -i ath0
(necesitas tener instalado pump, claro, para obtener una direccion ip
automaticamente de tu servidor dhcp), o bien:
ifconfig ath0 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
En el fichero /etc/network/interfaces:
auto ath0
iface ath0 inet static
address 10.0.0.1
network 10.0.0.0
netmask 255.255.255.0
broadcast 10.0.0.255
#mode 3 para 802.11g, 2 para 802.11b y 1 para 802.11a
#mode no es necesario, la tarjeta chequea en buscando un ap por todos los
canales
#up /sbin/iwpriv ath0 mode 3
up /sbin/iwconfig ath0 essid "redlibre" mode managed rate auto
84
CAPITULO 4
MODIFICACIONES A UN DRIVER
PARA CALIDAD DE SERVICIO.
SWAN
(Stateless Wireless Ad hoc Networks)
85
4.1 Stateless Wireless Ad hoc Networks
4.1.1 Resumen
Los sistemas inalámbricos se han convertido en el segmento de mayor y
más rápido
crecimiento
en
las
telecomunicaciones,
donde
su
principal
consecuencia han sido dotar de movilidad a los nodos de la red al liberarlos de sus
conexiones físicas, además también están empezando a ofrecer múltiples
servicios con calidad (QoS) como una conversación telefónica, la transferencia de
ficheros, acceso a la web o la realización de videoconferencia, sin restricciones de
lugar y de tiempo. Estos ejemplos de comunicación inalámbrica espontánea entre
dispositivos se denomina redes Ad Hoc, permitiendo a los dispositivos establecer
la comunicación, en cualquier momento y en cualquier lugar. En realidad, la
formación de redes Ad Hoc como tal no es nueva, sino lo es nuevo es la forma de
configuración y uso de sus elementos [6]. Una aproximación para otorgar calidad
de servicio es la de diferenciar entre el conjunto de paquetes que circulan por la
red clasificando los paquetes en un número pequeño de tipos de servicios y utiliza
mecanismos de prioridad para proporcionar una calidad de servicio adecuada al
tráfico. Este estudio preliminar se realizo aplicando servicios diferenciados con el
modelo SWAN [1] en el entorno del simulador ns2. SWAN es un modelo de red
“sin estados”, el cual usa algoritmos de control distribuidos para entregar servicios
diferenciados en MANET de una manera escalable y robusta. Estos algoritmos
aplican controles basados en retroalimentaciones para soportar servicios de
tiempo real “soft” y servicios diferenciados en redes inalámbricas Ad Hoc. El
modelo usa el rate control (rc) para trafico UDP y TCP best effort, y un admission
control (ac) para trafico UDP de tiempo real. SWAN aplica la notificación explicita
de congestionamiento (ECN) para regular dinámicamente trafico de tiempo real
admitido. El novedoso aspecto de este modelo es que no requiere de QoS en la
capa MAC.
86
4.1.2 Introducción
Los sistemas inalámbricos han capturado la atención y la imaginación del publico,
y se han convertido en el segmento de mayor y más rápido crecimiento en las
telecomunicaciones, donde su principal consecuencia han sido dotar de movilidad a los
nodos de la red al liberarlos de sus conexiones físicas (cableado), dichos nodos pueden
funcionar de encaminadores y de anfitriones (Host).
Los sistemas inalámbricos también están empezando a ofrecer múltiples servicios con
calidad (Quality of Service –QoS-) como una conversación telefónica, la transferencia de
ficheros, acceso a la web o la realización de videoconferencia, sin restricciones de lugar y
de tiempo. Estos ejemplos de comunicación inalámbrica espontánea entre dispositivos o
nodos podría ser definido de manera informal como un esquema, al que a menudo se
denomina formación de redes Ad Hoc, que permite a los dispositivos establecer la
comunicación, en cualquier momento y en cualquier lugar. En realidad, la formación de
redes Ad Hoc como tal no es nueva, sino lo es nuevo es la forma de configuración, de uso
y de sus elementos. [6]
4.1.3 ¿Qué son las redes Ad Hoc?
Las redes Ad Hoc consisten en nodos móviles interconectados con enlaces
de comunicación inalámbricos multisaltos que a diferencia de las redes
inalámbricas convencionales, las redes Ad Hoc no tienen una infraestructura fija
de red o administración central, donde la topología de estas redes cambia
dinámicamente con nodos móviles entrando o saliendo de la red, y con
consecuencias de que algunos enlaces de comunicación llegan a ser inválidos [4],
por ello uno de los principales objetivos en este tipo de redes es encontrar una
trayectoria que tenga suficientes recursos para satisfacer las limitaciones del
retardo, ancho de banda, calidad de los datos multimedia (video, audio, etc) y/o
otras métricas [5] enviando paquetes hacia otros nodos y ejecutar las aplicaciones
del usuario, adicionalmente también todos los nodos pueden ser móviles
dinámicamente, creando una red inalámbrica auto-creciente, auto-organizada y
auto-administrada. [6] Por lo tanto, las comunicaciones en estas redes se crearían
únicamente por interacciones entre sus nodos móviles inalámbricos, usando esas
87
interacciones para proporcionar el control de flujo necesario y funciones de
administración, [4] pero siendo la comunicación degradada en alguno casos por la
movilidad de sus nodos. Es decir, los nodos pueden entrar y salir de áreas de
mayor interferencia, o alejarse repentinamente de una zona de cobertura de otro
nodo con el cual establecía una comunicación. Además, contrariamente a las
redes cableadas, el número de integrantes en una red de nodos móviles, puede
variar bastante dinámicamente, al punto de saturar dicha red.
4.1.4 Retos a superar en Ad Hoc.
De una forma resumida y no por orden de importancia, son numerosos los
retos que deben superarse para alcanzar los beneficios prácticos de las redes Ad
Hoc inalámbricas, tales como:
•
Encaminamiento efectivo (Throughput alto, perdida nula o baja de
paquetes, etc.)
•
Métodos de control de acceso al medio ( o canal)
•
Administración móvil
•
Seguridad
•
La calidad de servicio (QoS) de las aplicaciones multimedia, que es
afectada principalmente por el retardo y por la administración del disponible
ancho de banda, entre otros factores. [4]
•
Conseguir elementos / equipos con potencia extremadamente baja para
evitar tener que recargar frecuentemente la batería.
•
Dispositivos de poco peso debido a que son portátiles y deben poder
llevarse encima (wearable).
•
Conseguir bajos costos en el mercado
•
Resolver el problema de las interferencias.
88
•
Conseguir interoperabilidad entre los diferentes equipos que están
moviéndose dentro en la red, a través de un eficiente modelo y protocolo de
encaminamiento.
•
Creación de contenidos.
•
Los factores ambientales juegan un papel muy importante, no solo
limitando la distancia entre dos nodos, sino agregándole ruido, interferencia
y variedad de terrenos que obstruyen la señal. [6]
4.1.5 QoS en Redes Ad Hoc
El concepto de calidad de servicio (QoS) ha sido propuesto para evaluar las
prestaciones cuantitativas y cualitativas de un conjunto de requerimientos de
servicio que serán encontrados, otorgados y mantenidos por la red mientras
transporta un paquete desde el origen al destino, siendo una función de la red
satisfacer ese grupo de requerimientos en términos de retardo estático extremo a
extremo (end-to-end), disponibilidad de ancho de banda, probabilidad de pérdidas
de paquetes en una conexión.[3]. Por ejemplo en multimedia esto puede incluir
calidad de imágenes, o tiempo de respuesta, al hecho que una imagen fue
producida o fue una respuesta a un estimulo ocurrido. La QoS puede estar
delimitada por un conjunto de condiciones, las cuales pueden ser:
•
Link constraints: especifican la restricción en el uso de los enlaces, p.e.
tener ancho de banda disponible para cierta aplicación.
•
Path constraints: especifica los requerimientos QoS extremo a extremo en
una simple trayectoria.
•
Tree constraints: especifica los requerimientos para un árbol multicast. [8]
El costo de transporte y el rendimiento total de la red pueden ser incluidos como
parámetros. El costo generalmente se describe en términos monetarios por
proceso o en término de tiempo usado en un proceso. Es frecuentemente el caso
de que el costo será usado para poner los límites superiores e inferiores a las
89
otras características. El costo de un enlace también puede ser en función de la
utilización del buffer o ancho de banda. El costo total de una ruta (árbol) es el total
del costo de todos los enlaces en la trayectoria. La optimización del problema es
encontrar la trayectoria con menor costo entre todas las rutas factibles.
Obviamente que los recursos en la red de deben estar disponibles durante la
invocación del servicio para la garantía QoS. La primera tarea esencial es
encontrar una adecuada ruta a través de la red, entre el origen y el destino que
tendrá los recursos necesarios disponibles para encontrar las características de
QoS para el servicio deseado. La tarea de reservación recursos (pedir, identificar y
terminar) es el otro ingrediente indispensable de QoS. [4]
4.1.6 Características de los enlaces con QoS para esquemas de
tiempo real
Para tener tráfico en tiempo real como voz, video en vivo, debe mantenerse
bajo cierto límites el retardo total y la varianza del retardo, el cual se puede lograr
reduciendo hasta donde sea posible el número de saltos, o encaminadores
intermedios en el camino. Con cambios potencialmente impredecibles de topología
en una red Ad Hoc este objetivo es difícil de lograr.
Aunque existen aplicaciones en tiempo real “Blandas” (soft) presentan cierta
tolerancia en cuanto a que los mensajes lleguen después de su deadline.
Muchas de las aplicaciones multimedia están en esta categoría. Pero las
aplicaciones de Tiempo Real “Duras” (hard) permiten imponer cualquier restricción
para establecer la comunicación, pero una vez establecida no se permite que
ningún mensaje llegue después de su deadline y mucho menos que se pierda
mensajes. En esta categoría están las aplicaciones industriales por ejemplo que
controlan robots o sistemas de seguridad.
Una aproximación para otorgar calidad de servicio es diferenciar entre el conjunto
de paquetes que circulan por la red. Cuando se desarrolló el concepto de
conmutación de paquetes, se aplicó un servicio de mejor esfuerzo, el cual trata los
paquetes sin hacer ninguna diferenciación entre los diferentes tipos de flujos.
90
Todos los paquetes reciben la misma prioridad al momento de ser procesados por
el planificador de paquetes el cual se encarga de decidir cual paquete es el que va
a pasar primero al enlace. De esta manera, los paquetes son más sensibles a los
retardos.
Una manera de mejorar este esquema del mejor esfuerzo, es tratar a los paquetes
de manera diferente, tomando la decisión de cómo procesarlo dependiendo del
contenido del encabezado del paquete. Los campos que son de utilidad en el
encabezado para el manejo del paquete son los campos de dirección fuente y
destino, el puerto de origen y destino, tipo de servicio (ToS) y el protocolo. El
encaminador basándose en estos datos puede tomar una decisión de cómo
procesar el paquete. Sin embargo, cuando la cantidad de paquetes es muy grande
–varios cientos o miles de paquetes por segundo- esto puede repercutir en el
rendimiento del encaminador.
Si existen similitudes entre diferentes paquetes, es posible clasificar los paquetes
en grupos y tomar decisiones de cómo procesar los paquetes dependiendo del
grupo al que pertenezca un paquete. Este mecanismo se logra reservando ciertos
bits en el encabezado del paquete –de hecho el campo de tipo de servicio del
protocolo Ipv4 estaba reservado para este propósito- y definir en él, el tipo de
servicio que se le debe aplicar al paquete de acuerdo a las políticas que se hayan
especificado para ese propósito. [7]
4.1.7 Servicios diferenciados (DiffServ)
El modelo de Servicios Diferenciados se basa en tráfico sin reservación.
Este modelo clasifica los paquetes en un número pequeño de tipos de servicios y
utiliza mecanismos de prioridad para proporcionar una calidad de servicio
adecuada al tráfico. El objetivo principal de este mecanismo es asignar el ancho
de banda a diferentes usuarios en una forma controlada durante periodos de
congestión. Este mecanismo se aplica igualmente a aplicaciones tradicionales
basadas sobre TCP, tales como transferencia de archivos, accesos a bases de
datos o Servidores de Web, y nuevas clases de aplicaciones tales como audio o
video en tiempo real. [9] Los Servicios Diferenciados pueden proveer a los
91
usuarios, una expectativa predecible del servicio que las redes le proveerá en
tiempos de congestión, y permite que diferentes usuarios obtengan diferentes
niveles de servicio de la red. [3]
4.1.8 Modelo SWAN: Service Differentiation in Stateless Wireless Ad
Hoc Networks
El objetivo de este punto es realizar estudios preliminares aplicando
servicios diferenciados con el modelo SWAN [1] en el entorno del simulador ns2.
SWAN es un modelo de red “sin estados”, el cual usa algoritmos de control
distribuidos para entregar servicios diferenciados en MANET de una manera
escalable
y
robusta.
Estos
algoritmos
aplican
controles
basados
en
retroalimentaciones para soportar servicios de tiempo real “soft” y servicios
diferenciados en redes inalámbricas Ad Hoc. El modelo usa el rate control (rc)
para trafico UDP y TCP best effort, y un admission control (ac) para trafico UDP de
tiempo real. SWAN aplica la notificación explicita de congestionamiento (ECN)
para regular dinámicamente trafico de tiempo real admitido. El novedoso aspecto
de este modelo es que no requiere de QoS en la capa MAC. [2]
A continuación se presenta la configuración de la pc en la que fueron realizdas las
pruebas:
4.1.9 Hardware and Software requirement
•
Laptops/mini-laptops
At least Three Laptops: One for Server (source node), Intermediate node,
Client (destination node) with Intel Pentium or higher.
•
Wireless Adapter Card
For SWAN Admission Controller, D-Link Wireless Adapter Card (IEEE
802.11) is needed Wireless Adapter Card should be configured to AdHoc
mode. Linksys or Orinoco card may work as well.
For SWAN Rate Controller, Aironet Wireless Adapter Card (IEEE 802.11) is
needed.
92
•
Operating System
SWAN Project Testbed runs on Linux Kernel version 2.2.18. (RedHat Linux
7.3)
•
Complier
The SWAN Testbed is compiled by gcc compiler. Tcl/Tk 8.x is also needed.
•
Others
The libpcap package is needed. If /usr/include/pcap doesn't exist, you
should install it. (For download and installation, see 2.)
MpegTv is used
for streaming video at destination node for SWAN Admission Controller.
4.1.10
Metodología
El modelo se aplico en un entorno de simulación MANET con protocolo
AODV (Fig. 46), evaluando los parámetros de: Throughput, Retardo medio y
Paquetes perdidos.
El entorno de simulación considera los siguientes escenarios:
• Fuentes de video: 1 y 19 (Trafico de tiempo real)
• Fuentes de FTP: 1 y 19 (Trafico de tiempo no real)
• Área de simulación: 500x2500 mts.
• 100 nodos
• Tiempo de simulación de 100 seg.
• Tiempo de pausa de 20 seg.
• Movimiento Random Waypoint (RWP)
93
Fig. 46 Metodología del modelo aplicado
4.1.11
Resultados y conclusiones
a) 19 Fuentes de tiempo real (video) y 1 de tiempo no real (FTP)
Se observa que cuando esta activado el admission control (ac), el
throughput de tiempo real aumenta debido a que se le da prioridad, y por lo tanto
su retado medio y cantidad de paquetes perdidos disminuyen. Fig. 47
94
Fig. 47 Resultados obtenidos con el modulo admission control
95
Fig. 48 Resultados obtenidos con el modulo admission control
b) Fuente de tiempo real (video) y 19 de tiempo no real (FTP).
Se puede observar que aquí también al igual que el punto anterior, el aplicar la
diferenciación de servicio mejora o disminuye las prestaciones evaluadas con un
trafico
mayoritariamente
de
tiempo
no
real.
Fig.
49.
Fig. 49 resultados con un trafico mayoritariamente de tiempo real
96
Fig. 50 resultados con un tráfico mayoritariamente de tiempo real
97
CONCLUSIÓN
98
Con las WLANs la red, por sí misma, es móvil y elimina la necesidad de
usar cables y establece nuevas aplicaciones añadiendo flexibilidad a la red, y lo
más importante incrementa la productividad y eficiencia en las empresas donde
está instalada. Un usuario dentro de una red WLAN puede transmitir y recibir voz,
datos y vídeo dentro de edificios, entre edificios o campus universitarios e inclusive
sobre áreas metropolitanas a velocidades de 11 Mbit/s, o superiores.
Pero no solamente encuentran aplicación en las empresas, sino que su extensión
a ambientes públicos, en áreas metropolitanas, como medio de acceso a Internet
o para cubrir zonas de alta densidad de usuarios (hot spots) en las próximas redes
de tercera generación (3G) se ven como las aplicaciones de más interés durante
los próximos años Muchos de los fabricantes de ordenadores y equipos de
comunicaciones como son los PDAs (Personal Digital Assistants), módems,
terminales de punto de venta y otros dispositivos están introduciendo aplicaciones
soportadas en las comunicaciones inalámbricas.
Las nuevas posibilidades que ofrecen las WLANs son: permitir una fácil
incorporación de nuevos usuarios a la red, ofrecer una alternativa de bajo costo a
los sistemas cableados, además de la posibilidad para acceder a cualquier base
de datos o cualquier aplicación localizada dentro de la red.
Dentro del enorme horizonte de las comunicaciones inalámbricas y la computación
móvil, las redes inalámbricas van ganando adeptos como una tecnología madura y
robusta que permite resolver varios de los inconvenientes del uso del cable como
medio físico de enlace en las comunicaciones, muchas de ellas de vital
importancia en el trabajo cotidiano.
La tecnología WLAN es una tecnología madura perfectamente aplicable y
funcional hoy en día a un coste asequible pero haciendo especial hincapié, en que
si se decide implantar, se deben tomar medidas de seguridad.
Entre las medidas de seguridad que se deben tomar, las más básicas son una
correcta configuración de la red para impedir el acceso a la misma de usuarios no
autorizados y hacer que la información circule de forma cifrada. Los dos ámbitos
de aplicación son en la empresa como sustitución a las redes cableadas y en la
otra cara de la moneda está el surgimiento incipiente de las redes ciudadanas, que
se apoyan en esta tecnología y en el software libre.
99
Realizando una profunda comparación de la gama de redes inalámbricas con las
LANs
cableadas,
se
llega
a
la
conclusión
que
ambos
sistemas
de
telecomunicación no son en absoluto excluyentes sino complementarios, ya que
es el sistema inalámbrico el que funciona con el usuario final, pero este sistema se
basa en los sistemas alámbricos.
Con las redes inalámbricas se ofrece como gran prestación el ahorro del costoso
cableado del edificio. Como punto negativo se tiene que comentar el inconveniente
de transmitir por un medio que cuenta con interferencias y otros factores no
propicios, lo que dificulta poder alcanzar velocidades comparables con las de las
redes alámbricas.
En un futuro se puede prever la integración de las dos tecnologías, es decir la
tecnología alámbrica y la inalámbrica, de manera que se aplique la que mejor
resultado tenga en cada uno de los casos que se presenten.
Para redes inalámbricas móviles, las prestaciones de los protocolos de
encaminamiento son afectadas por muchos factores, como la tecnología
empleada, el comportamiento del nivel de enlace, movilidad, dispersión y
velocidad de los nodos, etc. Por otro lado el modelo SWAN tuvo buenas
prestaciones al tener baja tasa de paquetes perdidos, pero mostró un incremento
en el retardo medio y jitter debido a su naturaleza reactiva con tamaño de
paquetes de 512 bytes. Sus prestaciones se mantuvieron mas estables y
eficientes en los escenarios altamente dinámicos. También se observo que la
aplicación de servicios diferenciados en MANET, mejora las prestaciones del
trafico en tiempo real, teniendo una mejor calidad de servicio extremo – extremo.
Como resultados se espera que el lector de este trabajo haya sido capaz de
instalar el sistema operativo Linux, así como también, de instalar su tarjeta de red
inalámbrica para poder realizar sus pruebas y, basándose en los resultados aquí
mostrados, tener un punto de referencia con el que pueda comparar sus propios
datos.
Los resultados mostrados en el último capítulo esta basados en un experimento
mediante un simulador de redes y una configuración punto a punto (Ad Hoc), y se
espera que en el futuro se implementen algoritmos que provean de calidad de
servicio a las redes de tipo infraestructura con salida a internet, alcanzando, con
100
esto, evitar al máximo perdida de información y por lo tanto optimizar la
transmisión de datos.
101
BIBLIOGRAFIA
Instant Byte S.L., http://www.instantbyte.com , ejemplo de Linux, 20 de julio de
2007.
http://sopa.dis.ulpgc.es/ii-aso/portal_aso/practicas/modulo.htm, 28 de agosto de
2007.
http://es.wikipedia.org/wiki/Linux, 15 de marzo de 2007
[1] G-S. Ahn, T. Campbell, A. Veres and L. Sun, “Stateless Wireless Ad Hoc
Networks (SWAN)”. http://www.comet.columbia.edu/swan/draft-ahn-swan-manet00.txt. Columbia University, October 2002.
[2] G-S. Ahn, T. Campbell, A. Veres and L. Sun, “SWAN: Service Differentiation in
Stateless Wireless Ad Hoc Networks”, Proc. IEEE INFOCOM'2002, New York,
New York, 2002.
[3] S. Andreozzi, “DiffServ simulations using the Network Simulator: Requirements,
Issues and Solutions”, Master’s Thesis, University of Pisa, 2001
[4] S. Chakrabarti and A. Mishra, “QoS issues in Ad Hoc Wireless Networks”, IEEE
Communication Magazine, February 2001.
[5] S. Chen and K. Nahrstedt, “Distributed QoS routing with imprecise state
information”, In 7th Int. Conf. on Computer Communications and Networks (IC3N),
October 1998, Urbana ,IL
[6] M. Fording, P. Johansson and P. Larsson, “Wireless Ad Hoc Networking –The
Art of Networking without a network ”, Ericsson Review Num 4, 2000
[7] P. Pieda, J. Ethridge, M. Baines and F. Shallwani, “A Network Simulator
Differentiated Services Implementation”, Open IP, Nortel Networks, July 26, 2002.
[8] A .Qayyum, L. Viennot and A. Laouiti, “Multipoint relaying: An efficient
technique for flooding in mobile wireless networks”, 35th Annual Hawaii
International Conference on System Sciences (HICSS'2002).
[9] V. Rexhepi, G. Karagiannis and G. Heijenk, "A Framework for QoS and Mobility
in the Internet Next Generation”, EUNICE 2000 proceedings, September 2000.
Beck, M., et al.:”Linux Kernel Programming”. Tercera Edición. Addison Wesley,
2002.
102
Herbert, T.F.:”The Linux TCP/IP Stack: Networking for Embedded Systems”.
Charles River Media, 2004 (Capítulo 6)
103