Rogue Access Point (AP)


Dispositivo

El dispositivo/antena a usar para hacer nuestro AP es el siguiente:

TP-Link Archer T3U Plus (chipset RTL88x2BU)

en modo Access Point (AP) tipo Rogue.

Es una antena que conectamos en el puerto USB de nuestro PC.

Driver

Para el driver voy a usar esta source en GitHub: https://github.com/lwfinger/rtw88

  • Este repo es para drivers Realtek
  • Estaré usando el driver RTL8822BU

Este AP lo vamos a hacer funcionar con el Kernel 6.12; luego de una actualización de Kali, el kernel es 6.18 y el ya no funciona bien. Si lo tenías funcionando en 6.12 e hiciste un upgrade de Kali, te va a tocar hacer unos cambios para que funcione. Esto lo detallo más abajo en: Regresión del Kernel 6.18 en Kali: Fallo USB con Realtek RTL8822BU (TP-Link Archer T3U).

Como adelanto, una vez que quede instalado el Driver del dispositivo, vamos a ver estos resultados:

┌──(kali㉿kali)-[~]
└─$ readlink /sys/class/net/wlan0/device/driver
../../../../../../../bus/usb/drivers/rtw_8822bu

┌──(kali㉿kali)-[~]
└─$ dkms status
rtw88/0.6, 6.12.20-amd64, x86_64: installed

┌──(kali㉿kali)-[~]
└─$ lsmod | grep rtw
rtw_8822bu             12288  0
rtw_usb                32768  1 rtw_8822bu
rtw_8822b             233472  1 rtw_8822bu
rtw_core              315392  2 rtw_usb,rtw_8822b
mac80211             1445888  2 rtw_usb,rtw_core
cfg80211             1392640  2 rtw_core,mac80211
usbcore               409600  8 rtw_usb,ehci_pci,usbhid,btmtk,rtw_8822bu,ehci_hcd,btusb,uhci_hcd

┌──(kali㉿kali)-[~]
└─$ lsmod | grep rtw
rtw_8822bu 12288 0
rtw_usb 32768 1 rtw_8822bu
rtw_8822b 233472 1 rtw_8822bu
rtw_core 315392 2 rtw_usb,rtw_8822b
mac80211 1445888 2 rtw_usb,rtw_core
cfg80211 1392640 2 rtw_core,mac80211
usbcore 409600 8 rtw_usb,ehci_pci,usbhid,btmtk,rtw_8822bu,ehci_hcd,btusb,uhci_hcd

Instalando desde el repo de GitHub

Prerequisitos

Actualizar e instalar:

sudo apt update && sudo apt upgrade
sudo apt install linux-headers-$(uname -r) build-essential git

Seguimos con los pasos recomendados en el GitHub.

Paso 1: Instalamos dkms

  • DKMS (Dynamic Kernel Module Support) permite que el módulo se recompile automáticamente cada vez que se actualiza el kernel.

  • Sin dkms, tendría que recompilar el módulo manualmente tras cada actualización del kernel.

Instalamos:

sudo apt install -y dkms

Paso 2: no es necesario en mi caso, se puede omitir pues:

⚠️ Nota sobre UEFI y Secure Boot: Los pasos 2.1 a 2.4 (generar llave, certificado y registrarlo con mokutil) solo son necesarios si estás instalando el driver en un sistema con UEFI + Secure Boot habilitado., una característica de seguridad que impide cargar módulos del kernel no firmados.

Esto aplica principalmente a sistemas físicos modernos con UEFI y Secure Boot habilitado, como laptops o PCs que vienen con Windows preinstalado de fábrica.

🖥️ En máquinas virtuales (VMs), como las que se usan en VMware o VirtualBox, Secure Boot generalmente está deshabilitado o no disponible por defecto, por lo que no es necesario realizar estos pasos, normalmente usan arranque BIOS (Legacy) sin Secure Boot.
Puedes verificar si tu sistema usa UEFI ejecutando:

[ -d /sys/firmware/efi ] && echo "Modo UEFI" || echo "Modo BIOS (Legacy)"

En mi caso estoy en Modo BIOS, por lo que si ejecuto lo que indica el Paso 2.4 veré:

└─$ mokutil --list-enrolled
EFI variables are not supported on this system

Paso 3 al 7: Clonamos el repo en /usr/src y agregamos e instalamos el rtw88 al dkms

cd /usr/src && sudo git clone [https://github.com/lwfinger/rtw88.git](https://github.com/lwfinger/rtw88.git) rtw88-0.6
sudo dkms add -m rtw88 -v 0.6
sudo dkms build -m rtw88 -v 0.6
sudo dkms install -m rtw88 -v 0.6
dkms status

Verificar el PowerManagement del wifi

Previo: asegurarnos de que hemos conectado el dispositivo TP-link USB y que está disponible (conectado) a la Virtual Machine.

Antes, por las dudas, verificar que el screensaver no haga el bloqueo de la pantalla:

Esto es por recomendación, a mi me daba problemas cuando se bloqueaba.

En cuanto al PowerManagement del dispositivo Wifi USB:

Si el "power save" está en On lo pondremos en Off

La siguiente configuración no va a funcionar, y debajo dejo el por qué:

sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

Contenido del archivo

[connection]
wifi.powersave = 2

Lo verificamos desde consola:

└─$ iw dev wlan0 get power_save
Power save: on

“El archivo /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf solo afecta conexiones gestionadas por NetworkManager (como perfiles de red que levantás con nmcli o la interfaz gráfica). Pero si estás montando un Rogue AP o usando hostapd, airbase-ng, o iw directamente, no pasa por NetworkManager, y entonces ese ajuste no tiene efecto.”

Este sí hace efecto:

iw dev wlan0 set power_save off

Esto funciona de inmediato porque estás hablando directamente con el kernel y la interfaz; pero es temporal: se resetea al reiniciar o reiniciar la interfaz, por lo que lo voy a poner en el script que tengo que levanta lo necesario para el Rogue AP.

Editamos entonces el script del Rogue AP

sudo nano rogue_hostapd3.sh

Agregamos estas lineas:

# Desactivar el PowerManagement / Disable WiFi Power Save
iw dev wlan0 set power_save off

En un .conf también seteamos que el NetworkManager no “toque” este dispositivo wlan0

sudo nano /etc/NetworkManager/conf.d/unmanaged.conf

Contenido del archivo:

[keyfile]
unmanaged-devices=interface-name:wlan0

Verificaciones

Estas son verificaciones que podemos hacer cuando el AP está en funcionamiento.

Verificamos mensajes de log en dmesg

Ejecutamos en una terminal:

dmesg -w

Verificar los equipos conectados al rogue AP

Ejecutamos en una terminal:

iw dev wlan0 station dump

Ejecutando el script

Ejecutamos el script (que ya le dí previamente los permisos de ejecución con chmod)

└─$ sudo ./rogue_hostapd3.sh
[*] Cerrando instancia previa de dnsmasq si existe...
[*] Activando IP forwarding...
[*] Configurando wlan0 con IP 192.168.69.1...
[*] Limpiando reglas iptables previas...
[*] Configurando iptables para NAT...
[*] Generando configuración de hostapd...
[*] Generando configuración de dnsmasq...
[*] Iniciando dnsmasq...
[*] Iniciando hostapd...
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED

y al conectarse el móvil vemos algo así:

wlan0: STA 4a:d6:01:b5:f2:ff IEEE 802.11: authenticated
wlan0: STA 4a:d6:01:b5:f2:ff IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 4a:d6:01:b5:f2:ff
wlan0: STA 4a:d6:01:b5:f2:ff RADIUS: starting accounting session A10F5F2FFA3CB549

Script para levantar el AP

#!/bin/bash

# Rogue AP. Version 3
# Author: Maximiliano Belino (m4xth0r)
# Author website: https://belino.com
# Date: 11 de Abril 2025

# Variables
IFACE="wlan0"
ESSID="superv4"
CHANNEL=6
NETPREFIX="192.168.69"
GATEWAY="$NETPREFIX.1"
RANGE_START="$NETPREFIX.2"
RANGE_END="$NETPREFIX.30"
NETMASK="255.255.255.0"
CONF_DIR="/tmp/rogue_ap"
mkdir -p "$CONF_DIR"

# Desactivar el PowerManagement
# Disable WiFi Power Save
iw dev wlan0 set power_save off

# Matamos dnsmasq solo si ya corre (evitamos matar la shell)
echo "[*] Cerrando instancia previa de dnsmasq si existe..."
pgrep dnsmasq && sudo killall dnsmasq

# Activamos IP forwarding
echo "[*] Activando IP forwarding..."
echo 1 > /proc/sys/net/ipv4/ip_forward

# Configurar interfaz
echo "[*] Configurando $IFACE con IP $GATEWAY..."
ip addr flush dev "$IFACE"
ip link set "$IFACE" up
ip addr add "$GATEWAY/24" dev "$IFACE"

# Limpiamos reglas iptables previas
echo "[*] Limpiando reglas iptables previas..."
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

# Configurar NAT
echo "[*] Configurando iptables para NAT..."
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o "$IFACE" -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i "$IFACE" -o eth0 -j ACCEPT

# Archivo hostapd.conf
echo "[*] Generando configuración de hostapd..."
cat <<EOF > "$CONF_DIR/hostapd.conf"
interface=$IFACE
driver=nl80211
ssid=$ESSID
hw_mode=g
channel=$CHANNEL
auth_algs=1
ignore_broadcast_ssid=0
EOF

# Archivo dnsmasq.conf
echo "[*] Generando configuración de dnsmasq..."
cat <<EOF > "$CONF_DIR/dnsmasq.conf"
interface=$IFACE
dhcp-range=$RANGE_START,$RANGE_END,12h
dhcp-option=3,$GATEWAY
dhcp-option=6,$GATEWAY
log-queries
log-dhcp
EOF

# Iniciamos dnsmasq (en background)
echo "[*] Iniciando dnsmasq..."
dnsmasq -C "$CONF_DIR/dnsmasq.conf" &

# Iniciamos hostapd
echo "[*] Iniciando hostapd..."
hostapd "$CONF_DIR/hostapd.conf"

echo "[+] Rogue AP '$ESSID' operativo."

Regresión del Kernel 6.18 en Kali: Fallo USB con Realtek RTL8822BU (TP-Link Archer T3U)

Contexto

Después de ejecutar un sudo apt upgrade en Kali Linux Rolling, el adaptador WiFi USB dejó de funcionar.

Dispositivo afectado:

  • TP-Link Archer T3U
  • Chipset: Realtek RTL8822BU (USB 2.0)
  • Driver funcional previo: rtw_8822bu (DKMS)
  • Kernel estable: 6.12.x
  • Kernel problemático: 6.18.x

Síntomas

Tras la actualización del kernel:

  • La interfaz WiFi desaparece o se desconecta constantemente.
  • En dmesg aparecen errores como:

Invalid ep0 maxpacket: 9 rtw_usb_reg_sec: usb write fail, status: -110 USB disconnect

El dispositivo se conecta, intenta inicializar firmware y luego el kernel lo desconecta.

Análisis Técnico

Cambio de driver

En kernel 6.12 se cargaba el módulo DKMS:

rtw_8822bu rtw_core rtw_usb

En kernel 6.18 se prioriza el driver mainline:

rtw88_8822bu rtw88_usb rtw88_core

El stack rtw88 fue diseñado originalmente para PCIe. El soporte USB es más reciente y presenta inestabilidades con ciertos controladores EHCI.

El error:

rtw88_8822bu: disagrees about version of symbol

Confirma que el módulo DKMS (rtw_8822bu) y el mainline (rtw88) están compitiendo.

En 6.12 gana el DKMS → funciona.
En 6.18 gana el rtw88 → falla USB.

Error crítico: Invalid ep0 maxpacket

Durante la enumeración USB:

  • El host solicita el descriptor del endpoint 0.
  • El dispositivo responde con un tamaño inválido.
  • El controlador EHCI rechaza la negociación.
  • Se produce un reset del puerto.

Este error ocurre antes de que la capa WiFi esté operativa.

Timeout -110 (ETIMEDOUT)

El driver intenta escribir en un registro interno:

reg 0x4e0

Pero la transacción USB no responde → timeout → el kernel desconecta el dispositivo.

No es fallo de firmware ni de hardware físico. Es un problema de interacción entre:

  • Stack USB EHCI del kernel 6.18
  • Gestión de energía
  • Driver rtw88 en modo USB
  • Chipset RTL8822BU (muy sensible a timing)

Causa Raíz

Regresión en el kernel 6.18 en el stack USB (EHCI), que afecta la enumeración y estabilidad de dispositivos Realtek RTL8822BU.

El hardware está sano. El problema es puramente de software.

Diagnóstico

Arranquemos con el kernel anterior, 6.12

En el momento de arranque de Kali, usamos la opción del menú para elegir el kernel 6.12. Una vez que ya arrancó Kali, podemos ejecutar estos comandos en consola para saber si soluciona el problema:

iw dev sudo iw dev wlan0 scan

Si escanea redes correctamente → el problema era el kernel nuevo.

Solución Recomendada

Congelar el kernel estable:

sudo apt-mark hold linux-image-amd64 linux-headers-amd64

Verificamos:

apt-mark showhold