Hola a todos,
ando de vacaciones por ahí y no puedo probar nada, pero os comento lo que pienso acerca de vuestras dudas y os explico un poco lo que yo he visto por si os sirve de ayuda.

Funcionamiento de wlaninject,
primero debemos  autenticarnos y asociarnos con la red elegida, se utiliza una clave incorrecta, por lo que no podremos comunicarnos con la red, pero estamos asociados y autenticados con el AP.
¿Esto tiene sentido? El tema depende del tipo de autenticación utilizada por el AP, en el estándar 802.11 se definen dos tipos de autenticación, Open System authentication, y Shared Key authentication, esta información aparece en campo authentication algorithm de las tramas de administración. Simplificando, en la autenticación abierta con proporcionarle un SSID válido, puedes autenticarte en la red.
El segundo método requiere que el AP envie una trama con un "nonce" en texto claro, que la estación debe devolverle correctamente cifrado con la clave WEP.
Podeis consultarlo todo en más profundidad en el documento del estándar 802.11, que es de dónde os expongo esta información.
http://standards.ieee.org/getieee802/download/802.11b-1999.pdf

Nota : Como vereis esta segunda opción, nos ofrece el texto claro y el texto cifrado ( si lo capturamos ). Por lo que utilizando ese paquete y el texto claro podemos obtener el stream, y con ese stream cifrar cualquier paquete que tengamos y poder inyectar tráfico a medida en la red. En esto se basan herramientas como wepweidge ( un clásico ) o los ataques de fragmentación.

Por lo tanto, si tenemos la tarjeta asociada y autenticada con el AP, ahora lo que hacemos es, asignarle una IP.
Si ahora hicieramos un ping a una IP de la misma subred de la IP asignada, se intentará enviar por esa interfaz ( suponiendo que no teneis otra interfaz con ese rango de IP etc.. )
y deberían aparecer datos en el aire, cifrados con la key falsa metida al principio. Podéis hacer la prueba poniendo una tarjeta en modo monitor, diferente, a la que teneis autenticada y asociada y escuchar el tráfico en el aire generado por la otra tarjeta.
¿El programa qué hace?
Cambia esa clave falsa 65 y pico mil veces y envia una petición ARP en cada cambio. Si no usaras una mac de alguien conectado, ignoraría esas tramas y no serviria.

Notas sobre divers/tarjetas que funcionan :
En las pruebas que hice, con el driver acx100 en una tarjeta con chipset texas instruments ni con el driver hostap ( no recuerdo que versión ) y tarjeta prism2 ( no recuerdo que version del firmware ) no podia enviar la petición ARP, me enviaba tramas probe request constamente en vez de enviar las tramas de datos ARP.
Con el driver Madwifi y la tarjeta atheros, me enviaba los paquetes perfectamente.
Probad vosotros y me comentais
Por lo que yo sé, los drivers madwifi están bastante más avanzados en estos aspectos, y no me extraña que funcionen bien, os remito al ataque 1 en la documentación de aircrack, en el que se menciona que es el único driver que puede inyectar y estar en modo managed a la vez. Aunque en teoría, de este modo deberían funcionar todas ya que en realidad sí estás conectado a una red. No sé, haced pruebas si os interesa, yo tampoco tengo demasiado interés.

Solución para los que no les funciona?
Habría que tener 2 tarjetas, con una te asocias, y con la otra inyectas tráfico, pero este programa no sirve, hace falta cifrar el paquete "desnudo" con la clave wep e inyectarlo por una interfaz en modo monitor, algo como lo que se hace con las herramientas de la suite aircrack.

Errores :

Unknow Physcal layer XXX:
Seguramente es porque la tarjeta no está en su modo "normal",
quizás porque la hayais puesto en modo monitor.
No hace falta poner la tarjeta en modo monitor, las respuestas del AP que nos interesan son de tipo Dato y se deberian poder escuchar cuando la tarjeta está en Modo Managed, si se quiere poner en modo monitor probablemente sólo sea posible con Madwifi y su interfaz raw,
aunque en teoría para esto no sería  necesario.


Un Saludo y espero que os sirva de ayuda

Hola nilp0inter,

He hecho unas pruebas con tu progama sin ningún router de imagenio, asi que no puedo probar su eficacia. Sin embargo, he analizado un poco su comportamiento.
En el modo que tú denominas fast mode, no haces ninguna pausa entre el envio de cada paquete, en el modo normal, en concreto realizas una pausa teórica de 1us ( digo teórica, porque normalmente no se cumple,siendo bastante mayor ).

Pese a que comentabas métodos para realizar más rápido el envío, el cuello de botella está en la tarjeta y en el medio inalámbrico, esto es, la tarjeta en modo fast ya está más que sobrecargada y la tarjeta no envia todas las tramas que el programa especifica porque le llenas los buffers al ir demasiado deprisa y las descarta. Además, puede haber varios AP en el mismo canal o estaciones emitiendo que harían que las tramas colisionaran, o cuando menos ocurriera algun retardo en la emisión.
Por otro lado, con pausas mediante la función usleep en cada paquete probablemente estemos desaprovechando mucho tiempo.

Para ver el tiempo desaprovechado, realice la prueba de capturar la cantidad de tramas que se llegaban a emitir en fast mode, y me salian unas 10000, muy alejadas de las 65536 que deberían aparecer. Fijándome en los tiempos entre trama, eran de aproximadamente 0.4us. Lo cual quería decir que se podia enviar una trama esperando como mínimo 0.4us, sin embargo lograr esta precisión programando ( pese a que existe la función nanosleep ) es harto difícil, así que probé un pequeño hack, cutre, que se basa en llenar el buffer de envio y esperar 1 us, haciendo asi un envío a ráfagas.

Por ejemplo, si especificamos el factor 10, cada 10 paquetes se espera 1us, con lo que nos tarda aprox 30s en total, y nos envia 50 y pico mil tramas, no todas, pero casi todas, aumentando la probabilidad de exito muchisimo más que con 10 mil y aumentando tambien mucho la velocidad porque esperamos cada 10 tramas, con este valor podeis jugar lo que querais.
Resumiendo, cuanto mayor es el factor, menos tramas se envian pero más rápido lo realiza. No es un avance tampoco muy grande, porque esperando con cada trama se tardan los 4 minutos que no es mucho tiempo.
Ejemplo :
wlaninject -e WLAN_35 -b 00:60:B3:XX:XX:XX -i ath0 -f 10
wlaninject -e WLAN_35 -b 00:60:B3:XX:XX:XX -i ath0 -f 25
wlaninject -e WLAN_35 -b 00:60:B3:XX:XX:XX -i ath0

sin -f  es que pare en cada paquete, es equivalente a
wlaninject -e WLAN_35 -b 00:60:B3:XX:XX:XX -i ath0 -f 1

Tengo el parche en diff unificado, simplemente copiarlo en el directorio del programa y aplicarlo con patch -i parche_factor.diff
Lo postearia aquí, pero no tengo ni idea de si tengo privilegios o cómo hacerlo, estos foros con tantos dibujitos me descolocan. Así que te lo envío al correo y tú verás si te interesa agregarlo o no.

nilp0inter sobre el código,
te he quitado algunos warning molestos de algunas guarrerias un poco graves, pero deberias compilarlo con la opción -Wall y quitarlos todos, al menos para dejarlo un poco más decente, sin variables que no tienen uso etc... Simplemente he agregado un contador de tramas, diviéndolo por el factor y comrpobando que el resto sea cero y si es cero entonces esperar. La ayuda y demas,  la he modificado levemente para lo del factor, un apaño que deberias poner bien.

Un Saludo y espero que te sirva de ayuda

Mi pequeña clasificación, de un documento que hice hace ya bastante, por si vosotros conoceis alguna más.

1.5.1. Ataques WEP

1.5.1.1. Ataque construcción del alfabeto
1.5.1.2. Ataque fuerza bruta
   1.5.1.2.1. Ataque fuerza bruta mejorado
1.5.1.3. Ataques estadísticos
   1.5.1.3.1. Ataque FMS clásico
   1.5.1.3.2. Ataque FMS mejorado ( H1kari )
   1.5.1.3.3. Ataques estadísticos Korek
1.5.1.4. Ataques Inductivos
   1.5.1.4.1. Ataque Arbaugh
   1.5.1.4.2. Ataque inductivo inverso, Korek chopchop
1.5.1.5. Ataque de fragmentación
1.5.1.6. Ataques de generación de tráfico

Un Saludo,

Para facilitar la independencia del código de las aplicaciones y aumentar la velocidad los motores de BBDD implementan un lenguaje específico suyo, por ejemplo en Oracle es PL/SQL, que permite programar directamente en la BBDD ciertas operaciones complejas.
Las ventajas que suelen tener, esque si tienes que pedir 30 datos, realizar operaciones con ellos, y coger el resultado, ganas en rendimiento, porque si simplemente haces la petición a un procedimiento almacenado, se hace de manera local en la BBDD y tú obtienes directamente el resultado. También si accedes desde diversas aplicaciones, tener las funciones creadas en el servidor te permite aislarte de la lógica de la BBDD. Aunque bueno, la desventaja es que si cambias de tipo de BBDD, tendrias que reahacer las funciones, porque los lenguajes no suelen ser demasiado compatibles.

Ejemplo cutre :
programa1

nombre = pedir_nombre(dni); /* lo pedimos a la BBDD con una sentencia SQL, tenemos que saber en que tabla, y que campo se encuentra, SELECT nombre FROM tabla WHERE dni = tal */

programa2

nombre = pedir_nombre(dni); /* Se pide el dni a una función de la BBDD, por ejemplo BBDD_GET_NAME(int dni ), solo tenemos que utilizar ese nombre de función, y se encapsula el resto en el procedimiento */

Es algo sencillo si lo ves, pero explicado quizás resulte un poco lioso,no sé si me habré explicado bien.

Yo aquí te pongo una función, los procedimientos son similares.
Por ejemplo, la función BBDD_GET_NAME nos devolveria el nombre de alguien dando su dni, en PL/SQL ( hecho de memoria y con fallos de sintaxis supongo ) :

CREATE OR REPLACE FUNCTION BBDD_GET_NAME (dni IN NUMBER) RETURN VARCHAR AS
BEGIN
varchar name(30);

IF dni<0 THEN
    Return -1;
END IF;

BEGIN

  SELECT nombre
  INTO name
  FROM tabla
  WHERE dni = dni

END
return name
END BBDD_GET_NAMEl;
/



Lo comento, porque en Oracle por ejemplo no se puede, lo cual dificulta mucho el poder alterar los datos, ya que por ejemplo no puedes realizar un UPDATE y un SELECT separados por ; a través del string ODBC.
También tendrás que tener en cuenta, que quizás el usuario de la BBDD con la que se ejecute esa sentencia no tenga privilegios suficientes para alterar la tabla.

Un Saludo,

Hola nilp0inter,
soy nuevo por estos lares y no conocía tu herramienta, es increíble como gente cacharrera saca estas cosas. No he leído los post del hilo, pero me he bajado el código directamente para echarle un vistazo. Madre mía! el objetivo era que funcionara como fuera eh?

Un pequeño error de despiste,
Así a ojo, sin haber usado el programa te comento que la inicialización de libinit siempre la realizas sobre la interfaz "ath0", ignorando el valor posterior de optarg en getopt. Así que deberias parsear los valores de linea de comandos antes de la  inicialización. Supongo que tú habrás usado siempre la interfaz ath0 y por eso no habrás tenido problemas.
El método este me ha picado la curiosidad y mañana haré unas pruebas analizando el tráfico generado por tu herramienta, ya te comentaré lo que vea.

Un Saludo,

Por lo que veo, la BBDD parece una IBM DB2, también parece que la sentencia SQL se ejecuta dentro de algún bloque o quizás un procedimiento almacenado, como el caracter ';' se utiliza para la terminación de estos, cuando existe una sentencia SQL es necesario especificar un caracter de terminación diferente para diferenciarlos, usualmente se utiliza '@' pero puede ser cualquier otro, prueba y me cuentas.

Por cierto, DB2 permite ejecutar múltiples sentencias mediante ODBC?, no tiene que ver con el post, pero por curiosidad.

Un Saludo,