Hola,
Voy a comentar algunas dudas que surgieron en los monitoreos y que pueden ser útiles para todos:
1) el código que les entregamos hace la validación del paquete recibido y funciona correctamente. esto quiere decir que solo deben preocuparse de implementar los procedimientos:
sr_handle_ip_packet
y
sr_send_icmp_error_packet
asumiendo que reciben un paquete "sano".
2) en esta struct,
struct sr_icmp_t3_hdr {
uint8_t icmp_type;
uint8_t icmp_code;
uint16_t icmp_sum;
uint16_t unused;
uint16_t next_mtu;
uint8_t data[ICMP_DATA_SIZE];
} __attribute__ ((packed)) ;
typedef struct sr_icmp_t3_hdr sr_icmp_t3_hdr_t;
no es necesario "hace nada" con los campos "unused" y "next_mtu", están para que el largo del cabezal ICMP esté correcto.
3) algunos han tenido problemas para castear la MAC (unsigned char vs. uint8_t).
lo probamos y no hay problema, revisen el código.
4) los únicos ethertypes que manejamos son ARP e IP:
enum sr_ethertype {
ethertype_arp = 0x0806,
ethertype_ip = 0x0800,
};
a los efectos de la solución, siempre van a enviar paquetes IP, ya sea por forwarding o ICMP.
5) cuando la MAC del next-hop no está en la ARP cache, hay que hacer lo que dice el pseudo-código de la letra:
/*si no está*/
/*agrego el paquete a la cola de hasta que se resuelva el ARP y obtengo el request*/
req = sr_arpcache_queuereq(next_hop_ip, packet, len)
/* paso el request a la función que decide cuando se debe enviar */
handle_arpreq(req)
el manejo de ARP que sigue (en la letra) ya se los dimos resuelto.
6) finalmente, había dudas de cómo se llama el binario que se genera al compilar con su código de sr_router.c.
mirando el Makefile, se llama "sr".
Saludos,
Eduardo