Hola a todos!
No he vuelto a escribir por que he estado fuera de casa por un tiempo... Bueno, la situación actual es que con wifiway 0.8 me funciona perfectamente, y he abierto varias claves de varias redes wep (OJO: Sólo a modo de prueba, ni tan siquiera he entrado en ellas; tengo la mía propia y me va bien). No obstante, no se exactamente cómo empezó a funcionar bien. Eso sí, siempre, siempre hago:
---- rmmod rt2075
---- ifconfig rausb0 up
---- iwpriv rfmontx 1
---- iwpriv forceprism 1
y ya va. No me hace falta hacer rmmod rt73 y luego modprobe rt73
Después de ver que puedo inyectar, me he decidido a tratar de trabajar directamente con Ubuntu 7.10 Gutsy, que es el S.O. que utilizo en mi portátil, ya que de esta manera mientras compruebo la seguridad de mi red puedo seguir trabajando en otras cosas que no tengo en wifiway.
Me he bajado el paquete rt73-k2wrlz-2.0.1.tar.bz2 del link de Hwagm y lo he compilado sin problemas. Lo mismo he hecho con la última suite de Aircrack-ng. Tampoco hay errores de compilación ni de instalación. Lo pruebo con mi ap:
* ifconfig rausb0 up
* iwpriv rausb0 rfmontx 1
(rta: en una línea aparte)
* rausb0 rfmontx: 1
* iwpriv rausb0 forceprism 1
(no hay respuesta)
* iwconfig rausb0 mode Monitor rate 1 channel 11.
Ataque A1 con opciones "6000, -o1 y -q 10" con exito.
Ataque A5 con éxito (¡ por primera vez, nunca lo había visto antes!)
Ataque A4 con éxito. Coge paquetes de 80 bytes y los reinyecta a toda velocidad. En unos 20 segundos genera el paquete .xor para pasarlo por packetforge-ng. Todo 0k.
Ahora me conecto a otro AP más distante (de algún *****) .
Cambio el canal: iwconfig rausb0 channel 6. 0bservo con iwconfig rausb0 y compruebo que el canal es el deseado. la velocidad es de 1M, y el modo Monitor. Compruebo, a lo largo de todo lo que sigue, con iwconfig, que las condiciones no cambian
Ataque A1 con exito
Ataque A5. Falla. Lo intento varias veces y al final admito que igual ese ap no responde al ataque de fragmentación. Vale
Ataque A4. Pillo un paquete de unos 326 bytes. Empieza a reenviarlo y cuando lleva 3 o 4 líneas del proceso de generar el fichero .xor, se para yempieza a reajustar la velocidad de envio, hasta que finalmente se para.
He probado a hacer la identificación falsa con y sin opciones "6000 -o 1 -q 10", y no observo ningún cambio.
¿Puede tener que ver esta situación con la diferencia en el tamaño de los paquetes?. Un dmesg me indica muchas, muchisimas líneas como la siguiente:
[ 3331.872000] ERROR!!! <7>RTUSBHardTransmit: TX RING full
¿Alguien me puede echar una mano?. ¿Alguien podría pasar esto al desarrollador del módulo parcheado?.
Gracias.
b.
