2012-02-13 16 views
9

En realidad, tengo dos preguntas relacionadas.¿Cómo enviar paquetes de más de 1500 bytes por pcap_sendpacket?

estoy capturando el tráfico de red filtrada por libpcap en Debian. Entonces necesito volver a reproducir este tráfico en el servidor Win2k3. A veces capturo paquetes, tanto TCP como UDP, mucho más grandes que 1500 bytes (tamaño de MTU predeterminado para Ethernet). Por ejemplo, 2000+ bytes. No hice cambios específicos en el tamaño de la MTU en ese Linux. Así que la pregunta # 1:

¿Cuál es la razón de estos paquetes mucho más grandes que MTU por defecto?Jumbo frames? Este artículo de Wikipedia afirma que "las tarjetas de interfaz de red capaces de marcos jumbo requieren una configuración explícita para utilizar marcos jumbo", pero no estoy al tanto de ninguna configuración de este tipo. También ifconfig me muestra "MTU: 1500". ¿Se puede relacionar de alguna manera con la técnica de "combinación de interrupción" (o "interrupción de fusión" como en this article)? ¿Puedo suprimir tales paquetes?

Entonces, la pregunta # 2:

¿Cómo puedo enviar dichos paquetes por pcap_sendpacket en Windows? Recibo el mensaje de error "Error de envío: Falló PacketSendPacket" solo para paquetes de más de 1500 bytes. Parece que no puedo usar marcos jumbo porque estoy enviando datos a un "toque de red" directamente conectado como una tarjeta pci y no estoy seguro de poder configurar su NIC. ¿Qué más? ¿Debería fragmentar estos paquetes de acuerdo con las reglas del protocolo?

EDIT:

cuadros fragmentación por NIC como Guy Harris sugirió:

~# ethtool -k eth0 
Offload parameters for eth0: 
rx-checksumming: on 
tx-checksumming: on 
scatter-gather: on 
tcp-segmentation-offload: off 
udp-fragmentation-offload: off 
generic-segmentation-offload: off 
generic-receive-offload: off 
large-receive-offload: off 
ntuple-filters: off 
receive-hashing: off 

Lo mismo para eth1 y br0 - puente de red entre eth0 y eth1 la que estoy oliendo.

Y aún recibo grandes paquetes UDP.

+0

pcap es probable que pegue datagramas fragmentados juntos en un solo trozo de los paquetes de cables para usted. Compruebe si puede pedirle que le proporcione marcos de Ethernet y no paquetes de transporte. –

+0

@NikolaiNFetissov: Estoy recibiendo marcos de Ethernet –

Respuesta

4

¿Estás utilizando el wireshark para capturar?

Es importante porque de forma predeterminada wireshark vuelve a ensamblar los datagramas IP fragmentados (y los almacena en un archivo pcap como paquetes únicos vueltos a ensamblar MTU-higger sin fragmentación). Para desactivar:

Editar-> Preferencias> Protocols-> IPv4> y desmarca "Vuelva a ensamblar los datagramas IPv4 fragmentados".

+0

Estoy capturando por libpcap (el núcleo de Wireshark). ¿Alguna información sobre cómo deshabilitar esto en libpcap? –

+1

Libpcap no tiene esta característica en sí misma, a menos que el paquete que utiliza haya aplicado este parche -> http://seclists.org/tcpdump/2007/q2/112 Puede verificar su versión de libpcap o descargar la versión oficial en lugar de usar el proporcionado por la distribución (a veces aplican parches extraños ...) –

+0

+1. Para la información, construí el último libpcap de las fuentes, ahora solo veo paquetes un poco más grandes que MTU, 1518 bytes. Parece por el trailer de Ethernet. Pero todavía no puedo enviar estos paquetes por 'pcap_sendpacket'. ¿Debo modificarlos quitando ese avance? –

6

El adaptador de red está probablemente haciendo segmentación TCP/descarga de desegmentación y fragmentación IP/descarga de montaje, por lo que:

  • paquetes UDP que son enviados por la máquina que son más grandes de los que caben en una trama Ethernet solo están siendo entregado al adaptador de red sin estar fragmentado, con el adaptador de red haciendo la fragmentación, y esos también se entregan a libpcap antes de ser fragmentados;
  • fragmentos UDP siendo recibidas por el adaptador de red que son más grandes que quepa en una trama de Ethernet única están siendo vuelto a montar por el adaptador de red antes de ser entregado al huésped, y están siendo entregado a Libpcap después de haber sido vuelto a montar;
  • trozos de datos de la secuencia TCP enviados por la máquina que son demasiado grandes para caber en una trama Ethernet solo están siendo entregados al adaptador de red, con el adaptador de red romper los trozos en segmentos TCP más pequeños, y el trozo completo es siendo entregado a libpcap;
  • segmentos TCP recibidos por el adaptador de red están siendo vuelven a montar en trozos más grandes de datos de TCP y los trozos están siendo entregados al host y luego a libpcap;

así que lo que está viendo son libpcap no paquetes Ethernet y son no limitado al tamaño de trama Ethernet.

(Es decir, Nikolai Fetissov era probablemente correcta; lo que estás recibiendo fuerza mirada como tramas Ethernet, pero eso es debido a que el adaptador de red y el controlador que se vean de esa manera Ellos son, de hecho, las tramas no Ethernet transmiten. en o recibido de Ethernet.)

Solo puede suprimirlos desactivando cualquier forma de segmentación/desegmentación/fragmentación/reensamblaje que se realice en su adaptador de red utilizando el comando ethtool; desactive las opciones como Descarga de Segementación TCP, Descarga de Fragmentación UDP, Descarga de Segmentación General, Descarga de Recepción Grande y Descarga de Recepción Genérica.

Una vez que haya desactivado esas opciones, ya no debería tener esos paquetes grandes, y por lo tanto debería poder reproducirlos sin ningún problema. Hay es, no es una forma fácil de reproducir los paquetes reensamblados/no fragmentados o segmentados que ha capturado hasta ahora; tendría que escribir su propio código para fragmentarlos, y no hay garantía de que sean re -fragmentados/re-segmentados de la misma manera que fueron originalmente fragmentados/segmentados en el cable.

+1

+1: thx para la información, revisando ... –

+0

pls vea la publicación editada –

Cuestiones relacionadas