2012-02-19 17 views
7

Al utilizar pcap_open_live para oler desde una interfaz, he visto un montón de ejemplos utilizando varios números SNAPLEN valor, que van desde BUFSIZ (<stdio.h>) a los "números mágicos".óptima para snaplen PCAP captura en vivo

¿No tendría más sentido establecer como SNAPLEN la MTU de la interfaz desde la que estamos capturando? De esta manera, podríamos incluir más paquetes a la vez en el búfer PCAP. ¿Es seguro asumir que el MRU es igual al MTU?

De lo contrario, ¿hay alguna forma no exótica de establecer el valor de SNAPLEN?

Gracias

Respuesta

6

La MTU es la mayor carga útil tamaño que pudiera ser entregado a la capa de enlace; no incluye ningún encabezado de capa de enlace, por lo que, por ejemplo, en Ethernet sería 1500, no 1514 o 1518, y no sería lo suficientemente grande como para capturar un paquete de Ethernet de tamaño completo.

Además, no incluye ningún encabezado de metadatos como el encabezado del radiotap para información de radio 802.11.

Y si el adaptador realiza alguna forma de descarga de fragmentación/segmentación/reensamblado, los paquetes entregados al adaptador o recibidos desde el adaptador podrían no estar aún fragmentados o segmentados, o podrían haberse reensamblado, y, como tal, podría ser mucho más grande que el MTU.

En cuanto a la instalación de más paquetes en el búfer PCAP, eso solo se aplica a los mecanismos de captura TPACKET_V1 y TPACKET_V2 mapeados en memoria en Linux, que tienen ranuras de paquetes de tamaño fijo; otros mecanismos de captura no reservan una ranura de máximo tamaño para cada paquete, por lo que una longitud de captura más corta no tendrá importancia. Para TPACKET_V1 y TPACKET_V2, una longitud de instantánea más pequeña podría marcar la diferencia, aunque, al menos para Ethernet, libpcap 1.2.1 intenta, lo mejor que puede, elegir un tamaño de ranura de almacenamiento adecuado para Ethernet. (TPACKET_V3 no parece tener las ranuras de tamaño fijo por paquete, en cuyo caso no tendría este problema, pero solo apareció recientemente en kernels lanzados oficialmente, y todavía no existe soporte para ello en libpcap).

+0

bien, así que tengo que "adivinar" un tamaño máximo probable para el tráfico que voy a controlar. – ziu

+2

* Si * está usando Linux con una versión moderna de libpcap, y la versión no es 1.2.1 o posterior o no está capturando en Ethernet (o está capturando en Ethernet con descarga de fragmentación/segmentación/reensamblado) , * y * no desea asignar un gran búfer de memoria compartida (usando 'pcap_create()'/'pcap_set_buffer_size()'/'pcap_activate()'), y quiere evitar la caída de paquetes, tendrá que adivine un tamaño máximo probable para paquetes entregados a libpcap. –

+0

Bien, mi problema es doble, ya que no analizo cada paquete antes de obtener el nuevo, por lo tanto, también debo almacenar el buffer en el nivel de aplicación del usuario. Es por eso que estoy tratando de recortar el uso de memoria. – ziu

Cuestiones relacionadas