[DRAFT] Issue: Interface "Blindness" (0 Targets) using --kill flag with RTL8814AU in VirtualBox

[c0dew3ll]

Status: Under Investigation / Workaround Identified

Description

When running Wifite2 inside a VirtualBox VM with an external RTL8814AU USB adapter, the --kill flag consistently results in a "blind" interface. While Wifite reports that the interface has successfully entered monitor mode and changed the MAC address, the scan phase fails to discover any networks (Targets: 0) indefinitely.

The Problem

There appears to be a race condition or a driver-lock issue when Wifite manages the process termination internally:

• With --kill: The interface wlan0 (or wlan0mon) is created, but no packets are captured. The card seems to "hang" at the radio level.
• The Workaround: If the user manually runs sudo airmon-ng check kill prior to launching Wifite, and then runs Wifite without the --kill flag, the tool functions perfectly and discovers targets immediately.

Environment & Hardware details

• Wifite Version: 2.9.9b0
• OS: Kali GNU/Linux Rolling
• Kernel: 6.18.12+kali-amd64 (2026-02-25)
• Virtualization: VirtualBox (USB 3.0 xHCI controller enabled)
• USB Chipset: Realtek Semiconductor Corp. RTL8814AU 802.11a/b/g/n/ac (ID 0bda:8813)
• Driver: rtl8814au

Steps to Reproduce

1. Attach the RTL8814AU adapter to a VirtualBox VM via USB passthrough.
2. Run sudo wifite --kill.
3. Observe the scan phase: Targets: 0 remains constant despite being in a WiFi-dense environment.
4. Restart the VM/Interface and run sudo airmon-ng check kill manually.
5. Run sudo wifite (omitting the kill flag).
6. Observe the scan phase: Targets are populated immediately.

Supporting Data

• ethtool -i wlan0 reports driver rtl8814au.
• lsusb confirms device ID 0bda:8813.
• Manual airodump-ng works fine after manual airmon-ng check kill, suggesting the issue lies in the timing of how Wifite's internal --kill interacts with this specific driver's initialization.

[kimocoder]

Which driver specific is used? is it RTL8814AU from aircrack-ng ?
@c0dew3ll

[claude]

Claude finished @kimocoder's task in 1m 24s —— View job

---

Context on the Driver Question

@kimocoder is asking @c0dew3ll to clarify which specific RTL8814AU driver implementation is installed — specifically whether it's the aircrack-ng maintained fork (aircrack-ng/rtl8814au) or another variant (e.g. morrownr/8814au, vendor-provided, etc.).

---

@c0dew3ll, to identify which driver implementation you have, run:

modinfo rtl8814au | grep -E 'filename|version|description|author'
dkms status 2>/dev/null | grep -i 8814

The aircrack-ng fork is typically installed via DKMS and will show up in dkms status. Its module filename path usually contains something like updates/dkms/ rather than a standard kernel path.

---

Why This Matters

The distinction is relevant because the race condition described in this issue (--kill causing 0 targets) interacts with how the driver releases/re-acquires the interface after conflicting processes are killed.

Looking at the relevant code in wifite/tools/airmon.py:403-447 and wifite/tools/airmon.py:127-154:

1. --kill calls terminate_conflicting_processes(), which uses SIGKILL on processes like NetworkManager or systemctl stop NetworkManager
2. Then Airmon.start_monitor() brings the interface down → sets monitor mode → brings it up, with only time.sleep(0.5) before verifying

The RTL8814AU in a VirtualBox USB passthrough environment adds latency to device re-initialization. After NetworkManager loses the device, the USB stack and driver need time to reset state. 0.5 seconds is likely too short for this driver+VM combination, which is why a manual airmon-ng check kill (done ahead of time, well before wifite starts) avoids the problem entirely.

The aircrack-ng fork has specific patches for monitor mode transitions; other forks may need longer settling times. That's why knowing the exact driver fork helps determine the right fix.

---

Potential fix: Increase the post-kill sleep or add a driver-specific delay when RTL8814AU is detected. Happy to implement this if confirmed.

[kimocoder]

We'lll @claude, there is a difference between the old stack and the latest mac80211 from mainline at;

https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtek/rtw88

The old aircrack-ng drivers is deprecated

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.