Muchas gracias por la confirmacion.
Todo el problema era que no habia habilitado el soporte para USB3.0 en VMware.
Estoy de acuerdo con las recomendaciones de no usar toda la potencia si se esta cerca del AP. Sin embargo eso no es condicion suficiente para colapsar un router hoy en dia.
He hecho pruebas en VMware y Virtualbox y en ambos hay que activar el soporte para USB3.0. De no hacerlo, se produciran errores intermitentes con el hardware.
Gracias
No pensaba en un problema de PA que “colapsa”: Solo en estar en condiciones para inyectar ARP.
No colapsarás (¿Desgraciadamente? 
) un PA (moderno o viejo) con una inyección de ARP o un chop-chop, estoy totalmente de acuerdo contigo.
Me alegro de que hayas encontrado la raíz del problema y estoy seguro de que tu experiencia será útil a otr@s 
… Gracias a ti por reportar la solución a tu problema. 
me sumo al post a ver lo que sale. Si está bien explicado puede ser que me salga, si no está detallado paso a paso para el dummy pues me perderé como de costumbre.
Deja ver si puedo complementar con algo para adquirir un poco de confianza.
Y si no a seguir preguntando hasta que salga.
Pongan enlaces por favor completos y detallados.
Para el asunto de la instalación te he respondido en el otro tema ( Instalación rtl8812 (Alfa AWUSO36ACH) en kali linux “rolling” 2016.2)
Por lo que es de realizar los ataques tienes manuales “paso a paso” en los foros WPA-WPS y WEP
Todo está paso a paso y para dummies así que no hay razones para que no lo logres 
[h]Arreglado bug “channel -1” en salida de airodump-ng + arreglado salida canal de iw y iwconfig [/h]
Estamos en fase “pulir los detalles”.
¡Qué gusto da ver el camino recogido estos meses! 
Los drivers de la rama “alta potencía” se han actualizado ayer.
Saludos y gracias desde aquí a gorebrau por traer su piedra al edificio con este “commit”: Added get channel function #21
Un trabajo en el fichero ** os_dep/linux/ioctl_cfg80211.c ** para que se pillen correctamente los canales con nuestras herramientas en linea de ordenes “favoritas”
https://www.wifi-libre.com/img/members/3/fix_channel_rtl8812au.jpg
Antes >>> https://www.wifi-libre.com/img/members/3/fix_channel_rtl8812au_2.jpg
Ahora >>> https://www.wifi-libre.com/img/members/3/fix_channel_rtl8812au_3.jpg
¡Hasta la próxima buena noticia!
[h]Nueva rama 5.1.5[/h]
El amigo astsam ha sacado una nueva rama basada en los drivers hechos por Tenda para su modelo Tenda U12
Me parece que el rendimiento en modo managed está mejor que con la master… Me parece que es igual que con la rama 4-3.21 con la AWUS036ACH. Me es difícil ahorita poder ver exactamente lo que hay, tendría que hacer pruebas en casa en mi red local con iperf3.
El modo monitor fucionna bien
No lleva control de potencia y nos es compatible rtl8821au (solo rtl812au)
Quizá mejora algo para los que tienen un dongle.
Rectifico lo dicho anteriormente: Parece al final que la AWUS036ACH va mejor en modo managed con la rama 4-3.21 (la que se usa en el paquete dkms disponible para kali linux), algo como 25% más rápido que con esta ultima rama- .
A ver si kernel.org se animan de una vez con los drivers “AC” , por que no veas que sequia , comprar un dispositivo ac para linux es jugarsela… hay bastantes dispositivos sin driver aun.
No tengo de estas para probar , pero gracias por decir que la rama 4 va mejor que la nueva 5.
Buenas USUARIONUEVO
Hablo aquí solo para la AWUS036ACH, es decir un adaptador "alta potencia" del chipset rtl8812au
La mayoría de los dispositivos no son adaptadores de alta potencia (ejemplo AWUS036AC los tp-link, tenda etc…).
Hay usuarios con este tipo de dispositivos que reportan mejoras gracias a la nueva rama.
Tampoco he hecho pruebas como debido… Ya sabes como es: Si estás en una red compartida en el medio de la tarde con miles de interferencias alrededor es difícil afirmar rotundamente algo. Hay que hacer esto en casa y medir la velocidad con un mini servidor dedicado en red local (con iperf3 por ejemplo)
Cosa que no voy a hacer ya que para la AWUS036ACH este driver no me va a aportar nada
Sería lo suyo probar bien a fondo con un dispositivo como la AWUS036AC o el tp-link
No tanto, no tanto…
El ath10k es ya bastante maduro
Hay mucho más soporte BCM y Intel también.
Con el dinero que sacan gracias a los anuncios en su sitio y con su tienda wifi… Ni se les ocurre a los dueños de tu sitio regalarte una maldita AWUS036AC (que les costará a ellos unos 15€ como mucho) o un puto nano dongle (les cosatrá a elos 5€) para que puedas trabajar en condiciones 
¡Qué cutres!
Hay que elegir con cabeza… …Lo de siempre más o menos… En su tiempo compré un wn722n sin que haya soporte para linux porque lo quería (era fan de los madwifi y las buenas PCI b/g/n 3000Mbps con su chipset atheros )
Estaba convencido por el hecho de que había soporte zydas y que atheros había comprado zydas que tarde o temprano se iba a tener un frimware decente con su driver.
Y sin jugarse-la hay de que elegir ya… Hay más de 50 modelos USB compatibles rtl88xxau en la wikidevi, más todo lo que no lo están.
Desde dongles a 10€ hasta adaptadores de alta potencia ac MIMO4T4R de alta prestaciones (y muchos más carros)
Para todo los bolsillos.
Rectifico lo dicho aquí: Nueva rama 5.1.5
Con la ultima kali Linux la diferencia se nota: los drivers de la rama 5.1.5 tiene un mejor rendimiento, detecta más rápido los PA, esnifa le trafico de forma más ágil.
No se nota mucha la diferencia cuando auditamos nuestro PA en condiciones ideales o is estamos conectados a el en modo managed.
Pero si nos alejamos del PA sí que se nota.
Se nota cuando estamos en modo managed también que algo fluye mejor.
A penas arranca el* Network Manager *y tengo más de una pantalla de alto de listado de redes con los niveles de señales correctos.
https://www.wifi-libre.com/img/members/3/Seleccion_484.jpg
Cosa que no sucede con la rama 4.3.21
Voy esperar un poco y hacer más pruebas perio si sigue así aconsejaré a los de Kali de pasarse a la rama 5.15.
Cierto, se pierde el control de la potencia con la rama 5.15 pero el modo monitor y el modo managed van de perla. de campeones.
De momento me quedo con ellos.
Una pequeña actualización de este hilo se impone.
Les traigo muuuuy buenas noticias.
Hace 3 semanas atrás, reporté un fallo en le trac de aircrack-ng, fallo que afecta a todos los dispositivos de doble banda cuando emplean la banda “a”
ticket 1722
Algo curioso y difícil de detectar.
Aireplay-ng no era capaz de inyectar en banda 5Ghz en un PA sobre 10.
Y no era algo aleatorio: No podía inyectar siempre en los mismos PA.
Total que mi propio PA era “imune” a las inyección: No se podía inyectar en mi PA en la red “ac”…
Por un lado estaba protegido contra las DoS… Por otro lado me daba mucha rabia no poder jugar sobre mi PA
Hay una review sobre AWUS1900 que tengo que acabar y falta el capitulo sobre inyección…
Todo esto son aguas pasadas
Saludos y gracias desde aquí a jpmv27 por haber encontrado una solución: aireplay-ng: Fix for missing APs in 5 GHz band
¡Tenemos ahora a una inyección 100% funcional en ambas bandas! 
Tanto con la AWUS036ACH (rtl8812au) que con la AWUS1900 (rtl8814au)
Estaría bueno agrupar todo lo referente a este adaptador, esta todo muy desperdigado, yo en particular lo tengo y aun no es tan versátil como los AWUS036 “veteranos” es comprensible que aun no funcionen muchas de las herramientas, el tema de la inyección lo vi días después de postear mi mensaje sobre el uso de la antena de 5.8Ghz, así que con cariño y algo de tristeza me resigne a guardarlo en el cajon sin casi nada de uso jajaja, le estoy preparando su propio alojamiento estanco (uso Wifislax y Kali), para wifislax habia un Driver (modulo) y github tambien, el problema esta en el código de los programas satélites, que están (preparados) solamente para 2.4Ghz, esperare a que se calmen un poco mas las aguas, estas semanas estuvo muy agitado todo.
Encontrarás todo lo relativo a la evolución de los drivers (de astsam) en modo monitor y inyección aquí.
Son dos paginas (ahora tres): Es consultable
Agrupar todo en un mismo tema sería lo más improductivo: Tendríamos a un mega tema infumable que no se consultaría.
¿Qué “programas”? ¿Qué herramientas? ¿Estás hablando de estos 50 scripts que hacen lo mismo para cosas que puedes hacer de forma mucha más eficiente en dos lineas de ordenes?
airodump-ng -b a y wash -5: Ya tienes soporte 5Ghz.
Buenas a todos. He subido a Github los commits de astsam en la ultima version, la https://github.com/tornado76/rtl8812au-driver-5.2.9/commits/txpower
Un saludo
¡Olé!
¡Muchas gracias por tu contribución a la revolución compañero! 
Estoy teniendo dificultades para compilarlos en kali linux con kernel 4.12
¿Te apetece intentar resolver el problema?
Bueno, primero he tenido estos tres errores
CC [M] /home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.o
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c: In function ‘cfg80211_rtw_get_channel’:
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c:4542:21: error: ‘HAL_DATA_TYPE {aka struct hal_com_data}’ has no member named ‘CurrentBandType’; did you mean ‘current_band_type’?
switch(pHalData->CurrentBandType){
^~
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c:4559:24: error: ‘HAL_DATA_TYPE {aka struct hal_com_data}’ has no member named ‘CurrentChannelBW’; did you mean ‘current_channel’?
bandWidth = pHalData->CurrentChannelBW;
^~
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c:4562:21: error: ‘HAL_DATA_TYPE {aka struct hal_com_data}’ has no member named ‘CurrentChannelBW’; did you mean ‘current_channel’?
switch(pHalData->CurrentChannelBW){
^~
/usr/src/linux-headers-4.12.0-kali1-common/scripts/Makefile.build:307: fallo en las instrucciones para el objetivo '/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.o'
make[4]: *** [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.o] Error 1
/usr/src/linux-headers-4.12.0-kali1-common/Makefile:1532: fallo en las instrucciones para el objetivo '_module_/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9'
make[3]: *** [_module_/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9] Error 2
Makefile:152: fallo en las instrucciones para el objetivo 'sub-make'
make[2]: *** [sub-make] Error 2
Makefile:8: fallo en las instrucciones para el objetivo 'all'
make[1]: *** [all] Error 2
make[1]: se sale del directorio '/usr/src/linux-headers-4.12.0-kali1-amd64'
Makefile:1805: fallo en las instrucciones para el objetivo 'modules'
make: *** [modules] Error 2
No tengo idea de C pero he cambiado los nombres por los sugeridos y he probado de nuevo
Este asunto parece estar resuelto pero el mismo fichero pita un poco más adelante con unas advertencias nuevas
[code] CC [M] /home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.o
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c: In function ‘cfg80211_rtw_get_channel’:
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c:4620:18: warning: ‘width’ may be used uninitialized in this function -Wmaybe-uninitialized]
chandef->width = width;
/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/ioctl_cfg80211.c:4621:25: warning: ‘center_freq’ may be used uninitialized in this function -Wmaybe-uninitialized]
chandef->center_freq1 = center_freq;
~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
CC [M] /home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/os_dep/linux/rtw_cfgvendor.o
[/code]
y al final de la compilación más de lo mismo:
[code] Building modules, stage 2.
MODPOST 1 modules
WARNING: "rtw_ieee80211_radiotap_iterator_init" [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko] undefined!
WARNING: "rtw_ieee80211_radiotap_iterator_next" [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko] undefined!
CC /home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.mod.o
LD [M] /home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko
make[1]: se sale del directorio '/usr/src/linux-headers-4.12.0-kali1-amd64'[/code]
Al final no me permite iniciar el modulo correctamente...
[code]sudo modprobe 8812au
modprobe: ERROR: could not insert '8812au': Unknown symbol in module, or unknown parameter (see dmesg)
[/code]
salida de **dmesg**:
[code][12866.680675] usb 1-1: Product: 802.11n NIC
[12866.680683] usb 1-1: Manufacturer: Realtek
[12866.680691] usb 1-1: SerialNumber: 123456
[12866.717088] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_next (err 0)
[12866.717581] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_init (err 0)
[12929.943906] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_next (err 0)
[12929.944357] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_init (err 0)[/code]
voy a ver dónde llego... :DHola kcdtv. No trate de compilar aun, hasta ahora y estoy viendo los errores que mencionas.
Estoy tratando de resolverlo desde ArchLinux con el kernel 4.12.13-1.
Según el dmesg parece que el error es por culta del radiotap. Ya dirás si lo has resolver tu antes que yo
Saludos
Estamos “sincronizados”. lo digo porqué con los otros drivers han surgido problemas pasando al kernel 4.12
No lo he resuelto
He visto que faltaba rtw_radiotap.c en tu repo’ así que lo he añadido antes de compilar pero el resultado es exactamente el mismo
MODPOST 1 modules
WARNING: "rtw_ieee80211_radiotap_iterator_init" [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko] undefined!
WARNING: "rtw_ieee80211_radiotap_iterator_next" [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko] undefined!
[22875.620255] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_next (err 0)
[22875.620671] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_init (err 0)
Mañana debo madrugar así que lo dejo para hoy… entonces… hasta mañana 'para otros intentos
Estamos “sincronizados”. lo digo porqué con los otros drivers han surgido problemas pasando al kernel 4.12
No lo he resuelto
He visto que faltaba rtw_radiotap.c en tu repo’ así que lo he añadido antes de compilar pero el resultado es exactamente el mismo
MODPOST 1 modules
WARNING: "rtw_ieee80211_radiotap_iterator_init" [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko] undefined!
WARNING: "rtw_ieee80211_radiotap_iterator_next" [/home/kcdtv/GitHub/RTL88XXAU/rtl8812au-driver-5.2.9/8812au.ko] undefined!
[22875.620255] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_next (err 0)
[22875.620671] 8812au: Unknown symbol rtw_ieee80211_radiotap_iterator_init (err 0)
Mañana debo madrugar así que lo dejo para hoy… entonces… hasta mañana 'para otros intentos :D[/quote]
Pues creo que ya lo tengo. Aqui el fix de la compilacion https://github.com/tornado76/rtl8812au-driver-5.2.9/commit/09cdeeb3a25f992cec3fd97b75944b7ed43ffb91
Y el Radiotap iterator from kernel 4.9 was added due to VHT field bug in k…
compilado, instalado y navegando con kernel 4.12 in debian/kali
mañana echaré un ojo al modo monitor un poco
edit:
Bueno… Tengo que mirrar más en detalles lo que haces, pensaba que habías implementado el modo monitor pero no parece ser el caso:
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
[quote=kcdtv]compilado, instalado y navegando con kernel 4.12 in debian/kali
mañana echaré un ojo al modo monitor un poco
edit:
Bueno… Tengo que mirrar más en detalles lo que haces, pensaba que habías implementado el modo monitor pero no parece ser el caso:
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
[/quote]
Ya vi lo que me falta sin embargo me crea un montón de conflictos a resolver 
y también vi un fork en el que parece ser que ya funciona el modo monitor en la ultima versión así que para estar doblando esfuerzos por solucionar un trabajo ya hecho te dejo el enlace al tal github
Edit:
Mode:Monitor Frequency:5.26 GHz Access Point: B4:EE:B4:E5:6A:0C
Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=3/100 Signal level=1/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Bueno bueno… No había visto que kim coder había puesto a los **5.2.9. **
Tampoco había visto que ha puesto los 4.3.21 (los tenía pero no compilaban issue 8)
¡Qué bien!
Aunque no he visto diferencia a primera vista, es bueno tenerlos todos para hacerse su propia idea y para poder elegir.
edit: No hay modo monitor tampoco con la rama 5.2.9 no lo ha implementado.
Si quieres seguir probando estaré por aquí… molaría tener el modo monitor con estos drivers,
Perdonad mi incompetencia, tengo instalados los drivers 4.3.21 de kimocoder, el problema es que a la hora por ejemplo de buscar dispositivos conectados a mi interfaz, en mi caso wlan0 no me encuentra nada.
Lo uso por ejemplo para ettercap, sniffar trafico y no me encuentra absolutamente nada, como si no funcionase.
Lo pongo en modo monitor y tampoco… nose que puede ser sinceramente…