mt7921u: monitor-mode per-channel retune emits narrowband RF burst

[John Henry]

Hello,

We have isolated a reproducible RF emission from MT7921U (MT7961
silicon) that occurs only when the device is in monitor mode and
being retuned across >= 5 distinct frequencies. The same chip in
managed mode, retuned across the same frequencies via the kernel's
scan API, produces no such emission. The behavior is reproducible
using only stock iw commands - no custom code is required.


Environment
-----------

- Adapter: multiple mt7921au-based adapters tested (custom in-house
  board and retail ALFA AWUS036AXML); identical behavior on both
- Chipset: MT7921AU, ASIC revision 0x79610010
- Kernel: 6.1.0-40-amd64 (Debian)
- Driver: in-tree mt76 (mt7921u.ko), module timestamp 2025-09-20
- Firmware:
    WIFI_MT7961_patch_mcu_1_2_hdr.bin
    WIFI_RAM_CODE_MT7961_1.bin
  HW/SW Version: 0x8a108a10, Build Time: 20241106151007a
  WM Firmware Version: ____010000, Build Time: 20241106151045
- Regulatory domain: US
- runtime-pm = 0, deep-sleep = 0


Reproduction
------------

Setup (monitor mode):

    IFACE=$(iw dev | awk '/Interface wl/ {print $2; exit}')
    iw reg set US ; sleep 1
    ip link set "$IFACE" down
    iw dev "$IFACE" set type monitor
    ip link set "$IFACE" up

Reproduction loop (this triggers the emission):

    FREQS=(2412 2417 2422 2427 2432)   # five 2.4 GHz frequencies
    while true; do
        for f in "${FREQS[@]}"; do
            iw dev "$IFACE" set freq "$f" HT20
        done
    done

With a fast spectrum analyzer (real-time / FFT-based), a narrowband
RF burst appears at the tuned channel on each retune. There appear
to be several bursts around the channel of varying strength.

The same loop with four frequencies (any subset) produces NO emission:

    FREQS=(2412 2422 2462 2484)        # four frequencies
    # ... same loop ...                 # no emission observed


Emission characteristics
------------------------

- Narrowband peak, ~800 kHz wide at the base, with skirts that
  fall off toward the noise floor and reach approximately the
  full 20 MHz channel width.
- Amplitude: -30 to -50 dBm measured over-the-air at close range
  with a fast real-time spectrum analyzer. Most around -40 dBm.
  Sometimes stronger. Usually stronger than normal WiFi signals
  from other standard WiFi connected devices within feet.
- Brief, on the order of hundreds of microseconds (not precisely
  measured). Too short for full OFDM spectral shape to resolve
  on our analyzer.
- Appears in 2.4 / 5 / 6 GHz, with band-dependent amplitude
  consistent with per-band PA characteristics.
- One or more burst per retune. Tick rate scales with retune rate;
  presence/absence is independent of dwell time (50 ms to 5 s
  tested).
- Independent of which specific frequencies are chosen: any 5
  distinct frequencies reproduce the behavior; any 4 do not.
- Reproduced in an RF-quiet shielded environment with no other
  802.11 / Bluetooth devices present.
- Identical behavior on multiple adapters (custom board and several
  retail ALFA AWUS036AXML), ruling out board-specific layout effects.


Mode dependence
---------------

The emission is monitor-mode-specific. We tested multiple paths:

  monitor mode + per-channel "iw set freq"  -> emission present
  monitor mode + SIOCSIWFREQ ioctl          -> emission present (same)
  managed mode + "iw dev scan freq ..."     -> emission absent
  managed mode + "iw dev scan ... passive"  -> emission absent

The kernel-driven offloaded scan path (NL80211_CMD_TRIGGER_SCAN)
on a managed interface does NOT exhibit the emission, even when
sweeping the same set of >= 5 frequencies repeatedly. This
strongly suggests that the firmware's scan path is using
different RF logic than the per-channel-set path used in
monitor mode.


What we have ruled out
----------------------

- Not transmitted as a 802.11 frame: a second mt7921u in monitor
  mode placed nearby does not capture any frame from the test
  adapter's MAC during the emission.
- /sys/kernel/debug/ieee80211/phy0/mt76/tx_stats counters all
  remain zero during both 4-frequency and 5-frequency monitor
  mode sweeps.
- fw_debug=1 produces no mt76-related dmesg output on our build;
  the firmware does not log this event via the standard debug
  path.
- Not active monitor / ACK behavior: explicit "iw dev set monitor
  none" does not suppress the emission.
- Not a USB transport issue: the only USB-related dmesg activity
  during testing is unrelated xhci_hcd HCI errors that are
  present whether or not the test is running.
- Not active scan probe TX: "iw scan ... passive" with managed-
  mode interface produces no emission, confirming the absence of
  managed-mode scan emission is not just probe-request elision.


Hypothesis
----------

Given that the emission is real PA output (visible amplitude on
external instruments, not visible to driver counters or peer
captures), is monitor-mode-specific, scales with retune count
rather than dwell, and triggers only above a small fixed
threshold of distinct frequencies, our best guess is that the
monitor-mode per-channel retune path triggers a per-channel
firmware operation - possibly a TX or PA calibration/trim
sequence - which is suppressed or differently scheduled in the
offloaded scan path.

The threshold of exactly 5 (any 4 channels are silent, any 5+
emit) suggests a firmware-internal cache of size 4 with cache
miss triggering recalibration on revisit. We have no direct
evidence of this; it is an inference from external behavior.


Questions
---------

1. Can anyone confirm what firmware operation is triggered by
   the monitor-mode per-channel retune path that the offloaded
   scan path avoids?

2. Is there an MCU command, debugfs knob, or driver flag that
   can suppress this firmware operation when the chip is being
   used as a passive sniffer?

3. Could the monitor-mode channel-set path be modified in mt76
   to use whatever optimized firmware operation the scan path
   uses?


Why this matters
----------------

For passive RF survey and security-assessment use cases, a
sweeper that emits anything during a sweep contaminates the
environment it is supposed to be measuring. At present this
limits practical mt7921u-based sweepers to <= 4 channels per
list, which is impractical for full-spectrum work and is a
significant usability problem we'd like to address in a clean
way.

We are happy to provide further diagnostics, additional test
results, or test any patches that might help isolate or
suppress the behavior.

Thanks,
John Henry