Buenas,
Visto que tanto en el foro como en los monitoreos hemos visto algunos errores y dudas bastante frecuentes, van una lista de aclaraciones.
Además, al final del mensaje se comentan unos cambios subidos al git para solucionar algunos posibles errores en la parte 2.
Parte 1
1) Manejo de ICMP
a) la solución de los docentes contenida en el binario sr_solution tiene un “bug” por el cual falla el ping desde el cliente a algunas de las interfaces internas de los routers R2 y R3 de la topología. Estos pings, al igual que todos los demás a direcciones válidas, deben funcionar correctamente (se debe generar un echo reply).
b) Uso de los cabezales:
El cabezal sr_icmp_hdr se usa para los echo request/reply.
El cabezal sr_icmp_t3_hdr se usa para los mensajes de error.
c) si se recibe un paquete con TTL 1 y la IP destino es alguna de las interfaces del nodo en cuestión, no se debe decrementar y generar un error sino procesar el paquete y responder si corresponde.
2) Manejo de ARP
a) ARP permite conocer la dirección MAC (Capa 2) correspondiente a una dirección IP (Capa 3). Cuando el proceso LPM devuelve un gateway gw y una interfaz if, se debe hacer la consulta ARP en la interfaz if preguntando por la MAC de gw; es INCORRECTO hacerlo por todas las interfaces.
b) Cuando un destino está directamente conectado, esto se representa en la tabla con un gw con dirección “0.0.0.0”. Naturalmente ES INCORRECTO hacer una consulta ARP por esa dirección, se debe hacer directamente por la dirección IP destino, ya que está directamente conectada.
Parte 2
1) Manejo de timers para envío de HELLOs.
Notar que cada interfaz tiene un contador/timer helloint, se debe enviar el HELLO cuando se vence este contador. Notar que send_hellos() se ejecuta cada un segundo.
2) pwospf_neighbors.c
Acá se encuentra todo el mantenimiento de la tabla de vecinos: altas, bajas y actualizaciones.
3) Para el envío de LSUs, notar que cada interfaz tiene un campo neighbor_id que es distinto de cero cuando existe un vecino del otro lado. La gestión del vecino conectado a cada interfaz del router (campo neighbor_id) debe ser implementada como parte de la solución a entregar.
4) Manejo de los números de secuencia y LSUs.
Éstos se generan consecutivos, se puede asumir que no va a haber overflow.
En cuanto a los números de secuencia recibidos, hay que recordar solo el último recibido por cada router, la especificación dice lo siguiente: "If the sequence number matches that of the last packet received from the sending host, the packet is dropped". (Para esto se debe usar la estructura de topología entregada que cuenta con funciones para este chequeo)
5) En sr_handle_pwospf_hello_packet hay un comentario que dice "Chequeo checksum". Sin embargo, el checksum de los paquetes PWOSPF ya se hace en is_packet_valid.
6) No es necesario enviar LSUs cuando se da de baja un vecino o una entrada de la topología.
7) Hace unos días se actualizó el código del repositorio git con las siguientes modificaciones:
Se corrigió warning en utils.c
Se modificó el código que chequea los vecinos para que devuelva una lista de los vecinos eliminados. Esto es útil para la gestión local que se debe hacer de los vecinos en las interfaces
Se agregó una condición para no procesar paquetes hasta que no termine la inicialización de ospf en el router
Se mejoró la llamada al hilo que procesa los LSU para evitar algunos casos ‘raros’ de error
Saludos