How to get Wi-Fi CSI data from a GL-MT6000 router (256 subcarriers, no extra hardware)

By Wu Jun · Updated 2026-11-02 · 6 min read

This is the full reproduction route for a GL-MT6000 (MT7986) router: 80 MHz, 256 subcarriers, no extra NICs. Every step below was executed on real hardware — including the failures.

Every performance number here is a reproducible first-party measurement (grade E) — the raw capture, scripts and SHA-256 are published ^{[1] [2]}. The mt76 driver and its CSI patch come from the upstream open-source repository ^[3].

The actual GL-MT6000 used for these measurements.

Results first

Requirements and risk

⚠️ Flashing has risk. GL-MT6000 has a U-Boot recovery path, but rehearse the rollback first and keep the stock firmware plus a config backup. Research use only.

Rear panel: DC 12 V input, 2.5 GbE WAN and LAN1–LAN3.

Prepare a rollback-capable lab session

Do not begin with Wi-Fi. Begin with a way back to the stock system. Keep the vendor image, its separately downloaded checksum, the generated OpenWrt sysupgrade image and a copy of the current configuration in one local directory. Label each file; two binaries with similar names are not an evidence trail.

Use a wired computer whose route to the router can be selected explicitly. A common failure during recovery is a laptop that still has Wi-Fi on 192.168.1.0/24: the browser appears to open the U-Boot page, but the request leaves through the wrong interface. Temporarily disable that Wi-Fi route or bind the recovery command to the Ethernet NIC. For this project the management subnet was moved away from the upstream LAN after first boot, and the U-Boot recovery page was rehearsed before any firmware upload.

Record four values before the flash:

1. the GL-MT6000 board identifier reported by the image;
2. the SHA-256 of the sysupgrade container;
3. the locally recomputed SHA-256 of the stock rollback image;
4. the expected mt7986_wm.bin build identifier.

The exact commands and rejection rules are in the six-point firmware preflight. If any value is missing, stop; a successful boot does not compensate for an unidentified image.

Build notes (mt76 CSI patch)

CSI needs three parts together:

All three are built on top of OpenWrt's open-source mt76 driver ^[3].

Before flashing any image, follow the six-point pre-flight audit: board identifier, sysupgrade hash, stock rollback hash, Wi-Fi firmware, CSI kernel symbols and userspace autostart.

Firmware version matters. On MT7986 you need the 2026-05-15 Wi-Fi firmware — with older builds the CSI reporting path has no caller, which looks like "enable succeeds but no data ever arrives".

# on the router
md5sum /lib/firmware/mediatek/mt7986_wm.bin   # expect 3ce21edabe201608e7bec0dd16898019
dmesg | grep -i "WM Firmware"                 # expect Build Time: 20260515…

Enabling CSI (the step everyone gets wrong)

Two conditions must hold at the same time, otherwise nothing is ever captured:

# 1) frame-type filter — without it the firmware reports nothing
mt76-vendor <iface> set csi ctrl=1,0,0,34

# 2) add the target station MAC (only filtered stations are reported)
mt76-vendor <iface> set csi ctrl=1,0,0,0 macaddr=<client-mac>

# verify
cat /sys/kernel/debug/ieee80211/phy1/mt76/csi_stats

Notes: the first argument is the interface name (e.g. csi0), not the phy name; CSI is a receive-side measurement, so the client must keep generating traffic; use a dedicated AP interface so your normal Wi-Fi stays clean.

First boot: change one layer at a time

After flashing, connect through Ethernet and finish only the minimum system work: confirm the image boots, set a non-conflicting management subnet, create one test AP interface, and verify that the intended client can associate. Do not migrate the previous router configuration wholesale. Wireless, firewall and interface names from another system make it difficult to tell whether a later failure belongs to the CSI path or to restored state.

When the AP path works, enable CSI on the dedicated interface and watch both sides of the transfer:

# capture host
tcpdump -ni any udp port 8888

# router
cat /sys/kernel/debug/ieee80211/phy1/mt76/csi_stats

Run a 10-second capture before a long one. A non-empty file is not enough: check that records are increasing, that subcarriers and chains match the configured mode, and that a real transaction is producing receive traffic. Stop and fix the first failing layer rather than extending the run.

UDP record format

Host byte order (little endian on the target):

Validate and stabilise

scripts/csi_capture_session.sh 10     # quick check
scripts/csi_capture_session.sh 600    # 10-minute stability run

Pass criteria used here: stable frame rate, no >5 s gaps, complete chains, flat daemon RSS (~5.2 MB) — verified against the 57,293-record capture ^[1].

Read failures in the right order

This ordering matters because “no data”, “invalid data” and “sparse data” require different experiments. The browser capture quality checker performs the container-level checks locally, without uploading a capture. It can reject a malformed stream, but it cannot prove what a person was doing during the recording.

The five must-know pitfalls

1. Missing frame-type filter → zero data (most common);
2. Missing MAC filter → nothing, or the wrong device;
3. Wrong firmware version → enable succeeds, no reports;
4. CSI interfering with your normal SSID → Wi-Fi suddenly slow (see the troubleshooting article);
5. Testing against a public server → not reproducible; use a LAN traffic source.

Next

• Exclusive troubleshooting: why Wi-Fi slows down after enabling CSI
• Tools and the 10-minute dataset: tools
• Lab log: what we ran and what failed
• Dataset parsing walkthrough: eight parts to a heatmap