El lenguaje de desarrollo debe ser lenguaje C sobre sistema
operativo Linux y debe funcionar en los ordenadores de los
laboratorios docentes de Ingeniería Telemática, donde se realizará
la corrección presencial (véanse detalles sobre máquinas disponibles más abajo).
Es obligatorio utilizar el parámetro -Wall de gcc en todas las compilaciones. Las prácticas deben compilar sin ningún warning ó error.
Las prácticas no deben tener fugas de memoria (se utilizará valgrind para comprobarlo).
Las instrucciones de entrega se enviarán antes del examen, básicamente deberán incluir la entrega del código fuente (sólo ficheros .c y .h),
un fichero Makefile que lo compile y un fichero README con detalles como el nombre, email y número de grupo. No se corregirán prácticas que no cumplan con lo anterior, es decir, no se corregirán prácticas que contengan fugas de memoria, warnings ó errores durante la compilación.
En la práctica se va a implementar una versión simplificada de la RFC. Las
simplicaciones están indicadas más abajo. La RFC completa está accesible
desde el siguiente enlace: RFC 2131.
El estándar RFC 2131 define tanto el funcionamiento del cliente como del servidor para la obtención
de parámetros de arranque y autoconfiguración. Sin embargo, para la realización
de la práctica sólo se exige implementar el cliente.
Debido a que es necesario ser root para la implementación de la práctica, se va a suministrar
un entorno de pruebas con todo el software ya instalado, incluído un servidor DHCP básico.
- Funcionamiento básico::
A continuación se explica el funcionamiento básico del protocolo DHCP, junto con algún ejemplo. No es objetivo de este
enunciado el explicar el protocolo en profundidad: debe ser el alumno, a través de la lectura de la RFC
quien complete los detalles necesarios para la correcta implementación de la práctica.
El protocolo DHCP maneja distintos tipos de paquetes de los cuales es obligatorio implementar/reconocer estos seis:
DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNACK, DHCPRELEASE y DHCPDECLINE.
DHCP funciona sobre UDP exclusivamente, y es uno de los pocos protocolos que usa puertos específicos
tanto para servidor (puerto 67) como para cliente (puerto 68).
DHCP permite obtener diversos parámetros, como dirección IP, máscara de subred, fichero de arrranque, DNS, servidor de impresión, etc...
Como ejemplo, para obtener una dirección IP, un cliente debe intercambiar los siguientes mensajes con el servidor (véase figura):
- DHCPDISCOVER, enviado por el cliente. Se trata de un mensaje UDP multicast que es recibido por los servidores DHCP.
- DHCPOFFER, enviado por el/los servidores, donde ofertan varias direcciones IP, sobre las que el cliente debe escoger.
- DHCPREQUEST, enviado por el cliente, que es un mensaje UDP (puede ser unicast ó multicast) para solicitar una dirección específica.
- DHCPACK, enviado por el servidor, confirmando esa IP.
Existen otros mensajes como DHCPNACK, DHCPRELEASE y DHCPDECLINE, no mostrados en la figura anterior, que son también obligatorios implementar/reconocer.
DHCPDECLINE se envía por el cliente para rechazar una dirección IP ofertada (por ejemplo, por estar ya en uso).
La implementación obligatoria es por tanto, la de un cliente DHCP, el cual debe implementarse
con las consideraciones siguientes:
- Ejecutable y parámetros: véase página de manual de dhcpcl.
- Ejemplos y formatos de entrada/salida:véase página de manual de dhcpcl.
- Trazas: véase página de manual de dhcpcl.
- Notas:
- Todos los mensajes deben mostrarse por la salida estándar, excepto los mensajes de error, que deben mostrarse por la salida de error estándar.
- Una vez recibidos los parámetros del servidor, el cliente, después de comprobar que la dirección IP no está en uso en otra máquina, sólo tendrá que configurar la dirección IP, la máscara de subred y el gateway (router). El resto de datos que puede mandarnos el servidor DHCP pueden ser ignorados por el cliente.
- Modificaciones obligatorias para Septiembre:
-
Es obligatorio la implementación de los estados REBINDING y RENEWING, y también
el uso de los temporizadores T1, T2 (véase Figura 5 de la RFC). Según la RFC,
una vez que el cliente esté en estado BOUND, existen tres temporizadores (T1 < T2 < leasetime) que se activan y que producen la transición hacia otros estados y el envío de diversos mensajes.
- Si expira T1, el cliente entra en estado RENEWING y envía un DHCPREQUEST unicast pidiendo que se le extienda el tiempo de arriendo.
- Si expira T2 sin recibir DHCPACK, el cliente entra en estado REBINDING y envía un DHCPREQUEST broadcast.
- En esta práctica, desde los estados BOUND, REBINDING y RENEWING, se saldrá del programa mediante SIGUSR2.
- Es imprescindible que el cliente compruebe la IP recibida mediante ARP.
- No se permiten el uso de scripts de ningún tipo durante el examen.
- Es obligatorio una compilación sin errores ni avisos, y utilizar la opción -Wall con gcc
- Se utilizará valgrind para detectar fugas de memoria en una
ejecución báasica con un servidor y terminando el comando con SIGUSR2
o con SIGINT (Ctrl+C). Es obligatorio indicar las opciones -q y
--leak-check=full
- Simplificaciones a la RFC:
- No es necesaria la implementación del mensaje DHCPINFORM.
- No es necesaria ninguna implementación relativa a multi-homed hosts.
- El único nivel de enlace obligatorio que debe soportarse es Ethernet.
- Si el cliente recibe múltiples respuestas de varios servidores, el cliente debe elegir una de ellas. Se deja a libre elección el procedimiento para elegirla.
- Todo lo que aparezca reflejado en la RFC como MAY ó SHOULD es opcional. Todo lo que aparezca como MUST es obligatorio de implementar.
- Consideraciones sobre temporizadores y timeouts: se
utilizarán siempre los valores RECOMMENDED de la RFC.
- Consideraciones sobre sockets: es obligatorio usar sockets UDP siempre que se pueda (pej: DHCPRELEASE, DHCPDECLINE). Cuando no sea posible (DHCPDISCOVER, DHCPREQUEST, ARP) se usarán raw sockets ó packet sockets.
Es decir, la implementación del cliente deberá llevar obligatoriamente una mezcla de los dos tipos de sockets.
- Acceso remoto a las máquinas del laboratorio:
- Desde casa, hay que conectarse a una de las siguientes máquinas de los laboratorios 7.0.J02, 7.0.J03, 4.1B01, 1.1A16, cuyo FQDN es el siguiente:
- jbit101.lab.it.uc3m.es - jbit156.lab.it.uc3m.es
- it001.lab.it.uc3m.es - it020.lab.it.uc3m.es
- lm001.lab.it.uc3m.es - lm010.lab.it.uc3m.es
- ctel001.lab.it.uc3m.es - ctel018.lab.it.uc3m.es
- Dichas máquinas están encendidas durante el día y se apagan a las 23:00.
Los fines de semana permanecen apagadas.
.
- Para conectarse a dichas máquinas hay que utilizar ssh (con opción -X). El acceso
ssh a dichas maquinas está filtrado desde fuera de la universidad, por
lo que desde fuera de la universidad hay que conectarse previamente a alguna de las siguientes:
:
- monitor01.lab.it.uc3m.es
- monitor02.lab.it.uc3m.es
- monitor03.lab.it.uc3m.es
- La firma RSA para muchas de las máquinas anteriores es:
dc:a9:3e:f6:51:98:54:dc:56:61:0e:96:c6:7a:70:a5
(en caso contrario, compruébese con los técnicos del laboratorio).
-
No se recomienda el uso de monitor0x para el desarrollo de la práctica, debido a que algunas de ellas
todavía corren un kernel preemptivo.
Para comprobar si el kernel es preemptivo, se puede usar el comando uname -a:
Linux monitor02 2.6.26 #3 SMP PREEMPT Fri Jul 18 12:07:07 CEST 2008
i686 GNU/Linux
Se ha creado una página de manual para la implementanción propuesta en
esta práctica de dhcp, que resume la información de formatos de entrada y
salida y trazas. También se puede descargar en formato HTML,
PDF, ó
TXT.
|
