GL-MT6000 CSI lab log: what we ran and what failed in October

By Wu Jun · Updated 2026-10-31 · Wi-Fi CSI, lab log, GL-MT6000, MT7986, OpenWrt · 10 min read

This is a record of what Router CSI Lab actually did in October 2026: creating a rollback-capable image, obtaining the first CSI, accepting a ten-minute capture, debugging performance failures and turning the result into a public, verifiable dataset. It is an engineering log rather than a success story. All numbers come from project measurements; the capture, scripts and DOI are public ^{[1] [2] [3]}.

Goal and hardware

The goal was concrete: obtain stable, long-running Wi-Fi CSI on a consumer router and check whether it can support real sensing experiments.

• Device: GL.iNet GL-MT6000 (MT7986A + MT7976)
• System: OpenWrt SNAPSHOT (Linux 6.18) with the mt76 CSI patch
• Radio: 5 GHz, HE80, channel 44, 256 subcarriers, 2 Tx × 4 Rx (8 chains)

The retail GL-MT6000 used in this log. This photo proves the hardware source; the CSI conclusions still depend on the raw capture, parser and commands cited below.

Build the rollback path first

A successful flash is not the same as a maintainable experiment. The build produced three evidence chains:

1. source from the community CSI OpenWrt branch and the current mt76 upstream ^{[4] [5]};
2. a preflight unpack that checks the final image for CSI symbols in mt7915e, the daemon, init script and LuCI;
3. a separately downloaded GL.iNet stock image with a locally recomputed hash, not just a remembered download URL ^[6].

No vendor configuration was carried across the flash. Keeping LAN, WAN, wireless and firewall state from a different system would make both networking and rollback harder to reason about. The checks and rollback path are documented in the GL-MT6000 firmware preflight.

Timeline

Seeing CSI once is not capture acceptance

The first end-to-end test ran for only 60 seconds. Its purpose was to prove the device, firmware, driver and capture host were connected, not to train a sensing model. It produced 2,777 CSI chain records, all with 256 subcarriers and complete I/Q. That established that the CSI path worked on real MT7986 hardware.

Only then did the experiment move to a 600-second run:

This is why the project later added a capture-quality audit and a timestamp-gap spectral sensitivity analysis. A plausible-looking heatmap does not prove that grouping and the time axis are correct.

Fault injection: does the daemon recover?

Long-run testing is not complete when the process simply avoids crashing. On 2026-10-11 the CSI daemon was deliberately terminated:

• procd started a new process in about five seconds;
• the client remained associated and the daemon resumed tracking the interface;
• debugfs returned to CSI enable: 1, and the REST frame counter began increasing;
• frames_total restarted at zero, which is expected for an in-process counter and does not mean recorded data was lost.

The watchdog also checks the process, CSI interface and debugfs enable state. Zero frames with no associated client must not be treated as failure: CSI is produced only when a client and useful traffic are present.

Media provenance and privacy review

The unboxing photos and videos are treated as provenance evidence, not as measurements. They can show that a retail unit exists and help a reader identify the ports, but they cannot demonstrate subcarrier count, sampling rate, packet loss or sensing accuracy.

The source material included precise location metadata, a private workspace, hands, ordinary household objects and one close-up of the device label. The label image contains a QR code, MAC address, serial number and default Wi-Fi information, so it was excluded completely. A thin blur or crop around only one field would still leave a device identity risk.

The safe derivative images are re-encoded so camera and location metadata do not carry into the site. The clip appears only in this provenance section, not in the reproduction guide, and it does not autoplay. It cannot prove a CSI result and would be unrelated media weight in the technical procedure. The player starts with the poster and media metadata; the clip body is loaded after a reader presses play. Bilingual captions and a complete transcript are available. The original files remain outside the Git repository.

This review is part of the evidence chain, not decoration. A reader can compare the published photo with the hardware table, then verify the capture with the public checksums and parser. The failed experiments below are kept for the same reason: a credible lab record includes what did not work.

The "100 Mbps WAN" was the wrong link

The first suspicion after flashing was that the WAN link had fallen from gigabit to 100 Mbps. The measurements showed:

• the optical modem-to-MT6000 WAN link had remained at 1000 Mbps full duplex, with zero RX/TX errors;
• a router-local multi-thread download reached about 391 Mbps while the CPU was still roughly 87% idle;
• the actual 100 Mbps link was a LAN port to the build machine whose NIC advertised only 100baseT/Full;
• the wireless slowdown was a separate problem and could not be explained by the wired negotiation result.

The lesson is to separate at least six layers: WAN negotiation, router forwarding, LAN link, wireless PHY, client power state and airtime. The full commands and byte accounting are in Wi-Fi slow after CSI.

Two real traps

Trap 1: firmware ATF blocks rate recovery

Symptom: after an idle period, one client's downlink was pinned at MCS0 and stayed slow even under continuous download, while other clients looked fine.

Isolation: router-local downloads and LAN downloads ruled out the ISP and wired path; AP-sent versus client-received bytes ruled out a retransmission storm. The same client and channel were then compared across the mt76 vow_atf switch:

Conclusion: this is a firmware rate-recovery problem, not weak signal or a broken client. The fix needs a boot script plus a watchdog, because debugfs is reset when the driver reloads.

Trap 2: a 40 MHz client inside an 80 MHz BSS

Symptom: one client that only negotiated 40 MHz periodically collapsed inside an 80 MHz BSS; other 80 MHz clients were unaffected.

Isolation: switching the radio to HE40 produced six consecutive downloads of 384 / 375 / 328 / 416 / 411 / 419 Mbps, and the collapses disappeared. Returning to HE80 reproduced 7–10 Mbps again.

Conclusion: the observed trigger is a 40 MHz legacy client inside an 80 MHz BSS, not a single damaged SSID. Run the radio at the client's native width or isolate legacy clients on a separate radio. Because the internal firmware rate state was not instrumented, the result is not assigned to a specific register.

Hypotheses ruled out

How the capture became a dataset

1. Anonymise the transmitter MAC in the payload only; timestamps, RSSI and I/Q values stay unchanged;
2. Split the stream into 8 MiB parts and compute SHA-256 for every part and for the whole file;
3. Ship REASSEMBLE.md so a downloader can merge and verify the parts;
4. Publish the figures and metadata on Zenodo under CC BY 4.0.

Whole-file SHA-256: 527466ceb8b5f835e55ff348f02808736b947db39e7baac1f34e375de146a440. The parsing walkthrough is in the dataset tutorial.

What this dataset can and cannot support

Supported:

• GL-MT6000 + MT7986 + mt76 CSI can capture 256-subcarrier I/Q on real hardware;
• within this ten-minute window, band, channel and link, the system maintained measurable record rate and timing continuity;
• four-chain groups, known anomaly groups and long gaps must be represented in parsing and quality gates;
• vow_atf and the 40/80 MHz client combination had reproducible performance effects in this environment.

Not supported by this dataset alone:

• accuracy for fall, respiration, heart-rate, pose or identity recognition;
• portability across rooms, subjects, firmware versions or hardware revisions;
• treating 95.5 chain records/s as a 95.5 Hz time series;
• treating any throughput number here as a guaranteed rate for every MT6000 or client.

The public capture is MAC-de-identified but still retains outer absolute timestamps, activity rhythms and within-session linkage. It is pseudonymised data, not information that has become impossible to relate to its collection context.

Minimum reproduction order

# 1. Confirm that the analysis host can see UDP before starting a long run
tcpdump -ni any udp port 8888

# 2. Capture ten seconds and inspect the non-empty file plus summary
router-csi-toolkit/scripts/csi_capture_session.sh 10

# 3. Only then run for ten minutes
router-csi-toolkit/scripts/csi_capture_session.sh 600

Save the command, firmware, interface, channel, width, chain-record rate, independent group rate, chain composition and maximum gap together. A good-looking heatmap is not reproducible evidence by itself.

Lessons

• Fix the environment before comparing algorithms: band, width, channel and firmware all change the CSI distribution;
• Check timestamps and frame rate before tuning models: jitter creates fake spectral peaks, and many "algorithm problems" are actually capture problems;
• Fault-inject the long run: define daemon recovery, zero-frame behaviour with no clients and counter resets in advance;
• Separate performance layers: WAN, LAN, PHY, client power state and CSI capture cannot be diagnosed from one speed test;
• Keep the failure record: the ATF and 40 MHz traps say more about whether an experiment is real than any successful screenshot;
• Make data verifiable: without SHA-256 and reassembly instructions, nobody can confirm they received a complete copy.

Next

• Add more scenarios: different distances, postures and rooms;
• Turn the lab log into a regular column, updated with each capture batch;
• Keep expanding the reproduction guides and tooling docs so no page contains conclusions without the process.