What our sandbox result tells you
Our run on September 25, 2026, at commit d2cf284 recorded successful install and build steps, followed by a failed test command. The matching sandbox record identifies a Python 3.12 Debian Bookworm image with 3 CPUs and 8 GB of memory. Installation took 16 seconds, the build step took 3 seconds, and the test command returned exit code 1 after 11 seconds. Those outcomes support a limited conclusion: the recorded installation and build commands completed in our sandbox.
Our harness stores each step's success flag, exit code, elapsed time, timeout status, and output tail, alongside parsed test counts. The MrKeyoor testing methodology explains this reporting approach and its limits. That page is provenance context, not evidence that its current procedure was used unchanged for this older run. This correction uses the existing record; no new execution occurred.
The stored parser summaries report 827 passed, 155 failed, 45 errors, and a total of 1,027. These are recorded parser summaries, not verified exhaustive counts of unique tests. The raw footer separately reports 15 deselected tests, 11 expected failures, and 64 warnings. Neither deselection nor an expected failure should be relabeled as a failed test.
The raw tail includes tests/chips/rt2800usb/test_ack_detect.py::test_tap_counts_ack_to_our_mac with the message "async def functions are not natively supported." Similar messages appear across several driver suites, and the tail names an error in tests/chips/rtl8188eus_dkms/test_powertrack.py::test_thermal_tick_arms_then_runs. The output establishes that the test command failed in this environment; it does not establish the cause of every failure or a defect in physical radio operation.
Pip-audit recorded zero advisories. Scan coverage is unknown because the supplied record has no scannedPackages value; the packages field of zero does not establish coverage of the 42 installed packages. This was not a security review.
Why evaluate its USB approach?
The project describes wifit3 as a standalone USB Wi-Fi auditor for Linux, Windows, and macOS that requires a supported USB adapter. Its commit-pinned README explains that Python driver ports control devices through USB bulk and control transfers, bypassing the operating system's native Wi-Fi stack.
The documented capabilities include scanning access points and clients, collecting WPA/WPA2 handshakes and PMKIDs, exporting captures, and conducting WPS, WEP, and Evil Twin operations. These are project claims, not hardware capabilities verified by our sandbox. Use them only on equipment you own or are explicitly authorized to audit.
Start with the supported-hardware table for the version you intend to use. Match the device and revision, then verify scanning and capture on an authorized lab target. Our record does not document a physical adapter test, reception, injection, capture reliability, or successful application operation on Windows or macOS.
Driver setup needs a recovery plan
The pinned README documents source startup with uv sync followed by uv run wifit3, plus prebuilt executables for the three desktop platforms. Completing dependency installation does not complete device setup.
On Linux, the application requests elevation to write udev permissions and blocklists under /etc/modprobe.d/. Windows setup installs WinUSB for the adapter. macOS asks the user to authorize access. The documented uninstall flow selects the adapter, removes the application's device configuration, and requires a physical unplug and reconnect. Preserve another network connection while evaluating that process.
Later evidence adds a specific caution. In issue 60, the maintainer reproduced an empty scanner involving an ALFA AXML passed from Windows into a Kali VirtualBox guest. The maintainer attributed it to firmware loaded by the host driver and documented USB Filters before physically reconnecting the adapter. The reporter subsequently confirmed a working workaround, and the issue was closed on September 28, 2026. It should not remain described as an unresolved generic scanning report.
The maintainer also reported a composite-device WinUSB uninstall problem in that discussion. This qualifies the README's simple restoration instructions for affected Windows devices; the supplied evidence does not establish a later resolution. These comments postdate our run and do not change its measurements.
Which alternative fits your workflow?
Wifite runs existing wireless-auditing tools for you. Its README lists Linux distributions, monitor-mode hardware, root access, and external tools among its requirements. Choose it when you want an automated workflow around those tools and can maintain that environment. It is a replacement workflow to evaluate, rather than evidence that wifit3's USB drivers will work with your adapter.
Aircrack-ng provides command-line tools for Wi-Fi monitoring, injection, card testing, and WEP/WPA PSK cracking. Its README says it works primarily on Linux and also lists other operating systems. Choose it when you want to script individual tools or inspect separate capture and injection steps. It can replace the overall workflow or complement an evaluation with separate card-capability checks, subject to its own hardware and driver requirements.
Neither alternative was tested in our wifit3 run, and these sources do not establish comparative speed or reliability.
How to read the scores
The editorial scale is 1 for major documented obstacles, 2 for substantial limitations, 3 for a usable path with material caveats, 4 for clear supporting evidence with limited gaps, and 5 for unusually complete evidence across the assessed dimension. These are judgments about the supplied evidence, not benchmarks or adoption measurements.
Setup ease is 3 because installation completed but device configuration requires care. Documentation is 4 because the README covers hardware, installation, architecture, and restoration, though the later Windows caveat matters. Community is 3 for the concrete maintainer and reporter troubleshooting exchange, without claiming a measured response rate or broad adoption. Maturity is 2 because v0.3.3 is labeled beta and our recorded test command failed. The release label refers to v0.3.3, not a claim that it remains the latest release.