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.
if ( (packet_counter % factor) == 0)
usleep(1);
Un Saludo y espero que te sirva de ayuda
Autor
En línea
me vas a zumbar por dar tanto por culo jejeje joder es que era todo con iwconfig y me extraño lo de ifconfig
