2010-05-12 5 views
7

Recientemente he estado tratando de familiarizarme con la pila de conexión de red de Linux y los controladores de dispositivos (los dos tienen nombres similares a los de O'Reilly) con el objetivo final de descargar UDP. Ya he implementado UDP en la NIC, pero ahora la parte difícil ...Pila de red de Linux: agregando protocolos con un LKM y dev_add_pack

En lugar de pedir ayuda sobre este objetivo más grande, esperaba que alguien pudiera aclararme un fragmento en particular que encontré que es parte de un LKM que registra un nuevo protocolo (OTP) que actúa como un filtro entre el controlador del dispositivo y la pila de red.

http://www.phrack.org/archives/55/p55_0x0c_Building%20Into%20The%20Linux%20Network%20Layer_by_lifeline%20&%20kossak.txt

(Nota: este artículo PHRACK contiene tres módulos diferentes, el código para la OTP es en la parte inferior de la página)

En la función init de su ejemplo que tiene:

otp_proto.type = htons(ETH_P_ALL); 
    otp_proto.func = otp_func; 
    dev_add_pack(&otp_proto); 

que (si entiendo correctamente) debe registrar otp_proto como un sniffer de paquetes y ponerlo en la estructura de datos ptype_all. Mi pregunta es sobre dev_add_pack.

¿Es el caso que el protocolo que se está registrando como filtro siempre se colocará en esta capa entre L2 y el controlador del dispositivo? O, por ejemplo, ¿podría hacer que ocurriera tal filtrado entre la aplicación y las capas de transporte (analice los parámetros del socket) usando el mismo proceso?

Pido disculpas si esto es confuso. Estoy teniendo algunos problemas para pensar en una visión más amplia cuando se trata de módulos que alteran la funcionalidad de la pila del kernel.

Gracias

+0

Buena pregunta, pero no estoy lo suficientemente familiarizado con esta parte del núcleo para ayudarte.Si no obtiene una respuesta, pruebe lkml o kernel-newbies –

+0

¿Alguna vez echó un vistazo a http://linuxwarrior.wordpress.com/2008/12/02/add-a-new-protocol-to-linux -núcleo/ ? Explica cómo agregar un protocolo a la capa 4. Sin embargo, nunca lo he probado antes, así que no sé si funciona para kernels posteriores. – Fred

Respuesta

1

¿Es el caso de que el protocolo que está siendo registrada como un filtro será siempre ser colocado en esta capa entre L2 y el controlador de dispositivo? O bien, por ejemplo, ¿podría hacer que se produzca dicho filtrado entre la aplicación y las capas de transporte (analizar los parámetros del socket) usando el mismo proceso ?

Sí. .func() del tipo de paquete que ha registrado se llama en __netif_receive_skb(), antes de que el controlador de rx del dispositivo lo maneje.

1

Cuando registra un manejador de protocolo con dev_add_pack, se llamará a la función de devolución de llamada del manejador cuando llegue un paquete. Así es como funciona el controlador de protocolo IP. De inet_init:

static int __init inet_init(void) 
{ 
    ... 
    rc = proto_register(&tcp_prot, 1); 
    ... 
    rc = proto_register(&udp_prot, 1); 
    ... 
    dev_add_pack(&ip_packet_type); 
    .... 

Cuando una interrupción se eleva por el NIC para un paquete que llega, el NIC manejador de interrupción se ejecutará, lo que va a terminar llamando netif_rx (o __napi_schedule), lo que elevará softirq net_rx_action. Esto terminará llamando a deliver_skb para cada manejador de protocolo registrado. De __netif_receive_skb_core

static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc) 
{ 
    ... 
    list_for_each_entry_rcu(ptype, &ptype_all, list) { 
     if (pt_prev) 
      ret = deliver_skb(skb, pt_prev, orig_dev); 
     pt_prev = ptype; 
    } 

Así que sí, la función de devolución de llamada controlador de protocolo se llamará en L2, junto con ip_rcv para el controlador de protocolo IP.

Puede registrar un controlador de protocolo en L3 con 'proto_register', si desea que se le llame en esa capa.

Cuestiones relacionadas