Auto Secure LoginPlatform
SignalLab engineering note

Running MT7612U and MT7921U Wi-Fi adapters together in WSL2

A tested dual-radio path for Windows 11 and Ubuntu 24.04 on WSL2, including what worked, what recovered, and the stability claim we are not making.

Bottom line

An Alfa AWUS036ACM (MediaTek MT7612U, mt76x2u) and an Alfa AWUS036AXML (MediaTek MT7921U, mt7921u) can be attached to the same Ubuntu 24.04 WSL2 environment through usbipd-win. Both reached monitor mode, passive capture worked, and bounded synthetic-frame tests passed on a purpose-built 6.18.33.2 WSL2 kernel. The MT7612U still has a long-duration USB/IP reliability limit that must be planned around.

01

The hardware and software path

The tested workstation used Windows 11, Ubuntu 24.04 under WSL2, usbipd-win, and an exact 6.18.33.2 custom WSL2 kernel containing the required MediaTek USB Wi-Fi drivers. The two adapters were the Alfa AWUS036ACM, based on MT7612U, and the Alfa AWUS036AXML, based on MT7921U.

That distinction matters. Similar retail names do not imply the same chipset, driver, firmware, or behavior. The setup guide identifies each radio by USB ID and Linux driver before changing interface state.

02

What we actually verified

Both adapters attached to one running WSL2 instance at the same time. Linux enumerated each radio under its expected driver. Monitor mode and passive capture were verified for both, followed by bounded synthetic-frame validation inside an authorized lab workflow.

Verified on the bench

  • Simultaneous MT7612U and MT7921U USB/IP attachment
  • Correct driver and interface identification
  • Monitor mode and passive 802.11 capture
  • Bounded synthetic-frame tests under a signed lab plan
  • Software detach and reattach recovery after a USB/IP failure
03

The remaining MT7612U limitation

The MT7612U path completed short bounded tests, but one longer USB/IP session failed after roughly eleven minutes. A software reattach restored the radio without a workstation restart. That is useful recovery behavior, but it is not unattended stability.

For that reason, the documented workflow includes a health check and recovery procedure and keeps duration-sensitive work supervised. A direct Linux host or native USB passthrough remains the better choice when long-duration reliability is more important than keeping the executor inside WSL2.

04

Why SignalLab separates governance from execution

The public SignalLab application creates and verifies signed authorization records; it does not transmit. Hardware execution lives in a separate local RF Executor and is bounded by the signed plan, containment, interface identity, and operator checks.

This separation keeps the public tool useful for authorization and evidence while leaving radio access inside a controlled lab environment. The setup guide covers one- and two-adapter configurations, kernel selection, USB/IP attachment, troubleshooting, and the recovery boundary.

Set up the tested configuration

Read the Alfa WSL2 RF Executor guide →

05

Primary references

This engineering note reports a specific tested configuration. It is not a claim that every USB controller, cable, WSL kernel, firmware revision, or long-duration workload will behave identically. RF work must stay authorized, contained, and compliant with applicable law.