Re: [bug report] wifi: mt76: mt7921: mt7925monitor-mode per-channel retune emits narrowband RF burst

[Sean Wang]

Hi John,

On Wed, May 27, 2026 at 7:24 AM John Henry <jshenry1963@xxxxxxxxx> wrote:
>
> Just a kind reminder of this issue.
>
> Please advise if this is already taken up in a separate issue I am
> unaware of, but it is not directly related to the "iw set txpower
> fixed accepted but ignored" issue.
>
> On products available in the market, e.g.  the Alfa AWUS036AXML
> consumer product and the Netgear Nighthawk A9000, in Monitor Mode
> there is RF generated when scanning through channels and we get to 5
> or more channels in succession.
> This does not seem to occur at all in managed mode.
>
> This means if we scan the 2.4GHz channel list, an RF Spectrum analyzer
> will show a narrow pulse generated on each channel as we progress
> through the channels.
> This can 100% be reproduced using standard iw set channel commands as
> shown below:
> FACE=$(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
>
> # This triggers narrowband bursts at channel center on each retune:
> while true; do
>   for f in 2412 2417 2422 2427 2432; do
>     iw dev "$IFACE" set freq "$f" HT20
>   done
> done
>

I have thought about this issue for a while. A possible workaround
would be to reset WFSYS / firmware after five consecutive `set
channel` operations in monitor mode, then restore the current monitor
channel context. The WFSYS reset may take hundreds of milliseconds to
complete, which is the cost we would need to pay.

> No special software required to reproduce.
> I have shown that this occurs on all MT7921 based products, along with
> MT7925 based products.
> It does not occur if the channel list is set to the same 4 over and
> over, no RF generated.
>
> There are no calibration channel commands going from the driver to the
> firmware, so I believe this is a firmware bug.
>
> Best Regards,
> John Henry
>
> On Sun, May 17, 2026 at 9:01 AM John Henry <jshenry1963@xxxxxxxxx> wrote:
> >
> > Just a kind reminder of this issue, has anyone been able to reproduce
> > this monitor mode issue?
> > When scanning through channels, and the list of channels is > 4, there
> > is a large transmit tick/burst coming from the MT7921u and the MT7925.
> > This can easily be seen on an RF Spectrum Analyzer.
> > Confirmed on an Alfa AWUS036AXML consumer product and the Netgear
> > Nighthawk A9000.
> > This can be reproduced with simple scripts.
> >
> > Reproduction with stock iw commands (no custom code):
> >
> > 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
> >
> > # This triggers narrowband bursts at channel center on each retune:
> > while true; do
> >   for f in 2412 2417 2422 2427 2432; do
> >     iw dev "$IFACE" set freq "$f" HT20
> >   done
> > done
> >
> > # This does NOT (only 4 frequencies):
> > while true; do
> >   for f in 2412 2422 2462 2484; do
> >     iw dev "$IFACE" set freq "$f" HT20
> >   done
> > done
> >
> > Bursts are ~800 kHz wide at the base, -30 to -50 dBm OTA at close
> > range, brief (estimated few hundred microseconds), at channel
> > frequency. tx_stats counters remain zero throughout.
> > On Mon, May 11, 2026 at 1:58 PM John Henry <jshenry1963@xxxxxxxxx> wrote:
> > >
> > > Bradley/Sean,
> > >
> > > Thank you all very much for the information.
> > > I tested this on mt7921u based Alfa AWUS unit and also an mt7925 based
> > > Netgear Nighthawk unit.
> > > I can confirm that the RF tick issue is present on both models when in
> > > Monitor Mode. I'm assuming it is in the base mt76?
> > >
> > > I attempted sudo iw dev wlxxx set txpower fixed nn where nn is the
> > > minimum value, next few values up, and then a few near the max values,
> > > and see no change in the signal strength of the RF Ticks when scanning
> > > through 5 or more channels.
> > >
> > > Please keep this in mind when attempting to resolve the known txpower
> > > 3dBm issue if possible, or please generate a new bug report for that
> > > specifically so that I can track when it is patched, or in ??? version
> > > so that I can test here locally.
> > >
> > > Incidentally, I'd appreciate it if anyone could please attempt to
> > > repeat using the scripts I had shown in the previous posts and confirm
> > > it is indeed seen by others.
> > >
> > > Thank you very much for your time and assistance
> > >
> > > John Henry
> > >
> > >
> > >
> > >
> > > From: Bradley Pizzimenti <brad.pizzimenti@xxxxxxxxx>
> > > To: linux-wireless@xxxxxxxxxxxxxxx
> > > Cc: linux-kernel@xxxxxxxxxxxxxxx, nbd@xxxxxxxx, lorenzo@xxxxxxxxxx,
> > > ryder.lee@xxxxxxxxxxxx, shayne.chen@xxxxxxxxxxxx,
> > > sean.wang@xxxxxxxxxxxx
> > > Subject: [bug report] wifi: mt76: mt7925: iw set txpower fixed
> > > accepted but ignored
> > > Date: Mon, 4 May 2026 15:04:35 -0700 [thread overview]
> > > Message-ID: <CACjnFagN9zeSkwEv3-CSPJDUENPcEcOLjKyQoLQ91Yjn=rq5ww@xxxxxxxxxxxxxx>
> > > (raw)
> > >
> > > Hi there maintainers,
> > >
> > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for any
> > > N tested, but the reported txpower never changes from a stuck value of
> > > 3.00 dBm. The kernel accepts and ignores the call silently in both
> > > directions (above and below the displayed value), and well below the
> > > regulatory ceiling.
> > >
> > > I'm aware there's prior art on the cosmetic 3.00 dBm display issue
> > > (Razvan Grigore's v2 series, Feb 2025; Ming Yen Hsieh's txpower init
> > > refactor, Sept 2025). What seems potentially distinct here is that the
> > > user-issued `iw set txpower fixed N` itself is silently no-op'd,
> > > separate from the reported-value question. Reporting as breadcrumbs
> > > in case the second observation is a separate bug rather than the same
> > > one.
> > >
> > > Hardware
> > > --------
> > > MEDIATEK MT7925 [Filogic 360], 802.11be 2x2, PCI 14c3:7925
> > > ASIC revision 0x79250000
> > > Driver in use: mt7925e (in-tree)
> > >
> > > Firmware (from dmesg at probe)
> > > ------------------------------
> > > mt7925e 0000:01:00.0: HW/SW Version: 0x8a108a10,
> > >                      Build Time: 20260106153007a
> > > mt7925e 0000:01:00.0: WM Firmware Version: ____000000,
> > >                      Build Time: 20260106153120
> > > Files: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin
> > >        mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin
> > >
> > > Kernel
> > > ------
> > > 6.18.18-1-MANJARO (close to vanilla 6.18 stable; not yet tested on
> > > wireless-next or nbd168/wireless HEAD -- happy to retest if needed,
> > > but flagging the data point in case it helps as-is).
> > >
> > > Tools: iw version 6.17
> > >
> > > Regulatory
> > > ----------
> > > $ iw reg get
> > > country US: DFS-FCC
> > >    ...
> > >    (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
> > >    ...
> > >
> > > Connection context: 5GHz channel 161 (5805 MHz), 80 MHz, VHT-MCS,
> > > NSS 1. So we are on a band with a 30 dBm regulatory cap.
> > >
> > > Observed
> > > --------
> > > $ iw dev wlp1s0 info | grep txpower
> > >         txpower 3.00 dBm
> > >
> > > $ sudo iw dev wlp1s0 set txpower fixed 100   # 1 dBm
> > > $ iw dev wlp1s0 info | grep txpower
> > >         txpower 3.00 dBm
> > >
> > > $ sudo iw dev wlp1s0 set txpower fixed 1500  # 15 dBm
> > > $ iw dev wlp1s0 info | grep txpower
> > >         txpower 3.00 dBm
> > >
> > > $ sudo iw dev wlp1s0 set txpower auto
> > > $ iw dev wlp1s0 info | grep txpower
> > >         txpower 3.00 dBm
> > >
> > > All four `set` invocations return exit code 0. The reported value
> > > never moves.
> > >
> > > Expected
> > > --------
> > > Either:
> > >   - The reported txpower follows the requested value (or, where
> > >     capped, the actual applied value with extack indicating the
> > >     cap reason), or
> > >   - The set call returns an error rather than silently ignoring the
> > >     request.
> > >
> > > Caveats
> > > -------
> > > - Not yet tested on wireless-next or nbd168/wireless HEAD. If a
> > >   reproduction on a current dev tree would be useful, I can do that.
> > > - I have not verified whether the actual radiated TX power changes
> > >   in response to `set txpower fixed`; I am reporting only the
> > >   user-visible behavior.
> > >
> > > Thanks,
> > > Bradley
> > >
> > > On Wed, May 6, 2026 at 8:12 PM Sean Wang <sean.wang@xxxxxxxxxx> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The TX power reporting issue has already been investigated by Lucid
> > > > from the Linux WiFi USB community, and there is a proposed solution.
> > > > I think we can continue checking whether there are any remaining
> > > > issues on top of that work. Please refer to the patches here:
> > > > https://lists.infradead.org/pipermail/linux-mediatek/2026-April/105726.html
> > > > Thanks everyone for reporting and raising these concerns.
> > > >
> > > > On Wed, May 6, 2026 at 3:09 PM Javier Tia <floss@xxxxxxx> wrote:
> > > > >
> > > > > On Sun May  4 22:04:48 2026 Bradley Pizzimenti wrote:
> > > > > > `iw dev <iface> set txpower fixed N` returns success on mt7925 for
> > > > > > any N tested, but the reported txpower never changes from a stuck
> > > > > > value of 3.00 dBm.
> > > > >
> > > > > Hi Bradley,
> > > > >
> > > > > The 3 dBm display bug is a known issue we have seen when using mt7927
> > > > > and a tested fix has been working well so far. The root cause is that
> > > > > mt7925_mcu_set_rate_txpower() programs the per-band SKU tables into
> > > > > firmware but never assigns phy->txpower_cur. mt76_get_txpower() then
> > > > > computes:
> > > > >
> > > > >   DIV_ROUND_UP(0 + 6, 2) = 3
> > > > >
> > > > > regardless of the actual power level. The RF output is unaffected;
> > > > > it is a display-only bug.
> > > > >
> > > > > The fix reads the effective TX power back from the rate power limits
> > > > > after programming the SKU tables and writes it to phy->txpower_cur,
> > > > > following the same pattern used by mt7996:
> > > > >
> > > > >   https://github.com/jetm/mediatek-mt7927-dkms/blob/master/mt7927-wifi-14-fix-reported-txpower-always-showing-3-db.patch
> > > > >
> > > > > This is part of a series we are targeting for wireless-next; not
> > > > > yet upstream.
> > > > >
> > > > > > What seems potentially distinct here is that the user-issued
> > > > > > `iw set txpower fixed N` itself is silently no-op'd, separate
> > > > > > from the reported-value question.
> > > > >
> > > > > Agreed those are two separate issues. Our patch addresses the
> > > > > display-only side: after applying it, iw will report the value the
> > > > > firmware is actually using based on the SKU tables, rather than
> > > > > always 3 dBm. Whether `set txpower fixed N` propagates to firmware
> > > > > to change actual output power is orthogonal and not addressed here.
> > > > >
> > > > > If you can test the patch on your MT7925 and confirm the displayed
> > > > > value reflects the correct power after association, a Tested-by
> > > > > would be appreciated.
> > > > >
> > > > > Best,
> > > > > Javier
> > > > >
> > > >