GL-MT6000 CSI firmware pre-flight: six checks before the first flash

By Wu Jun · Updated 2026-10-29 · GL-MT6000, MT7986, OpenWrt, firmware verification, sysupgrade, Wi-Fi CSI, rollback · 7 min read

A router image can boot and still be wrong for the experiment. It may target the wrong board, contain the wrong Wi-Fi firmware, lack a CSI symbol, omit the daemon, or leave no known-good rollback file. This article records the six checks made before the first GL-MT6000 CSI flash on 2026-10-10.

Evidence grade E for measurements of this build. The exact image is not distributed by this site; use the commands below to inspect the image you built yourself. A pre-flight check proves artifact provenance and component presence. It does not prove that firmware emits CSI at runtime. Runtime evidence is the separate 10-minute capture published with the dataset ^{[1] [2]}.

The verified artifact set

The stock rollback came from GL.iNet's official GL-MT6000 download entry ^[4]. The hash above belongs only to the exact downloaded file used in this experiment. Downloading the same version later is not enough: recompute the hash on the new file before trusting it.

Check 1: verify the outer image and board target

The .bin name is not evidence. Open the container and inspect its members:

IMG=openwrt-mediatek-filogic-glinet_gl-mt6000-squashfs-sysupgrade.bin

shasum -a 256 "$IMG"
# expected for this build:
# 3226cde7201c43f2c015d1be035888bc269cc98070f678a03b1a185ca6c4defe

tar -tf "$IMG"
# sysupgrade-glinet_gl-mt6000/
# sysupgrade-glinet_gl-mt6000/CONTROL
# sysupgrade-glinet_gl-mt6000/kernel
# sysupgrade-glinet_gl-mt6000/root

tar -xOf "$IMG" sysupgrade-glinet_gl-mt6000/CONTROL
# BOARD=glinet_gl-mt6000

This check catches three different failures:

1. a file changed after the build test;
2. a factory or unrelated image was placed under a sysupgrade filename;
3. the image targets another GL.iNet or OpenWrt board.

The hash identifies the artifact. It does not create trust by itself. Record where the build came from and compare this file with the output of that trusted build.

Check 2: keep a rollback image with its own hash

The rollback file is not a filename kept “somewhere on the desktop”. It is a tested artifact with an identity:

shasum -a 256 mt6000-4.11.0_release3.bin
# expected:
# 4004632eaf516fd2844be0e5595b6e4171d243181ff49b81569b986c79007dae

This stock image was 83,146,618 bytes. Store it outside the router, include the hash in the experiment record, and verify it again while the recovery computer is connected by Ethernet. The GL-MT6000 U-Boot recovery page is reached at 192.168.1.1; the recovery rehearsal itself must be completed in the flashing window because it requires a physical reset.

The pre-flight did not publish or redistribute the vendor binary. The official download page remains the source, and the local hash ties the recovery plan to the exact vendor file tested here.

Check 3: identify the Wi-Fi firmware twice

The MT7986 Wi-Fi firmware is separate from the OpenWrt kernel and root filesystem. The known working shape for this experiment was the 2026-05-15 build:

md5sum mt7986_wm.bin
# 3ce21edabe201608e7bec0dd16898019

sha256sum mt7986_wm.bin
# 86baa5bcb05436c23ac443dd937cbb6d8cc9920eab6fd86bc4421038f526a03a

strings mt7986_wm.bin | grep -o '_[_0-9]*20260515120459' | head
# ____00000020260515120459

Why keep an MD5 value that is not a modern security hash? Because the MediaTek firmware ecosystem and the CSI project use 3ce21eda… as a compact build identifier. MD5 is useful here for exact-build identification, not for deciding whether a download is safe. SHA-256 is the stronger integrity value.

The important sequence is:

1. calculate the hash of the firmware in the build output;
2. extract the sysupgrade root filesystem;
3. calculate the hash of /lib/firmware/mediatek/mt7986_wm.bin inside that root filesystem;
4. require the two values to match before flashing.

Checking only the file in the build directory can miss a failed package copy or a different firmware being installed into the image.

Check 4: prove the CSI code reached the kernel module

The image contained mt7915e.ko, but the filename alone does not tell us whether the CSI path was compiled in. The verification searched for implementation-specific strings:

strings mt7915e.ko | grep -E \
  'mt7915_vendor_csi_ctrl|mt7915_vendor_csi_ctrl_dump|mt7915_get_csi_stats|csi_stats|data_i|data_q'

Observed symbols included:

MTK_VENDOR_ATTR_CSI_DATA_I
MTK_VENDOR_ATTR_CSI_DATA_INFO
MTK_VENDOR_ATTR_CSI_DATA_Q
csi_stats
mt7915_get_csi_stats
mt7915_vendor_csi_ctrl
mt7915_vendor_csi_ctrl_dump

That is stronger than checking package names. It shows that CSI control, dump and data fields exist inside the kernel module that will load on the router. It still does not prove the firmware returns a CSI event. The driver and firmware are separate layers; this is the central distinction between pre-flight evidence and runtime evidence.

The driver source is the upstream mt76 tree with the CSI changes layered on top ^[5]. The exact community branch and commit are pinned above so the check can be repeated ^[3].

Check 5: verify userspace and autostart

CSI capture also needs a control utility and a daemon. The image root contained:

/usr/sbin/mt76-vendor
/usr/sbin/mt76-csi-daemon
/etc/init.d/mt76-csi
/etc/mt76-csi.conf
/etc/rc.d/S95mt76-csi
/etc/rc.d/K10mt76-csi

The two rc.d links matter because a binary that exists but never starts is not a working image. After flashing, verify the package state and service separately:

apk info -e mt76-vendor mt76-csi-daemon luci-app-csi
/etc/init.d/mt76-csi enabled && echo enabled
lsmod | grep -E 'mt7915e|mt76'
find /sys/kernel/debug -name csi_stats

Do not infer frame production from a successful service start. The next gate is a received UDP record with the expected 256-subcarrier shape and chain_info grouping.

Check 6: pin package versions in the manifest

The relevant installed package lines were:

kmod-mt7915e - 6.18.36.2026.07.01~59676919-r100
kmod-mt7986-firmware - 6.18.36.2026.07.01~59676919-r100
mt7986-wo-firmware - 20260622-r1
mt76-vendor - 1
mt76-csi-daemon - 1.0.0-r3
luci-app-csi - 0.260905.03384

These names and versions let another researcher compare a different build without reducing the whole stack to “I used OpenWrt”. The kernel package version also exposes the mt76 pin embedded in the package release.

What passed, and what did not

Passed before flashing:

• exact outer image hash and board identifier;
• exact stock rollback image hash;
• matching Wi-Fi firmware in build output and image root;
• CSI implementation strings in both the built module and image root module;
• daemon, vendor utility, init script, configuration and autostart links;
• relevant package versions in the install manifest.

Not proven before flashing:

• that MT7986 firmware emits CSI for this AP/client combination;
• the frame or measurement rate;
• whether normal Wi-Fi throughput recovers after idle;
• whether the rollback procedure succeeds on the physical device;
• whether the claimed CSI fields remain stable for ten minutes.

Those questions require the physical device. They are why the project later published raw records, the 10-minute checksum, the timing audit and the Wi-Fi slowdown experiments rather than stopping at “the image contains CSI code”.

Flash-day order

The safe order used here was:

1. rehearse entry into U-Boot recovery without uploading a file;
2. verify the stock rollback hash again;
3. disconnect WAN and use only a wired LAN link to the computer;
4. flash the sysupgrade image without keeping the previous configuration;
5. reach the temporary LAN address and move it off the upstream subnet before reconnecting WAN;
6. verify the Wi-Fi firmware, module, service, debugfs node and UDP output;
7. keep the rollback image available until CSI capture and normal Wi-Fi operation both pass.

Disconnecting WAN is not optional when the router and upstream gateway both use the same 192.168.1.1/24 network. The first boot address can collide with the home gateway and create a misleading “flashing failed” diagnosis.

Download the sanitized pre-flight record

• Pre-flight JSON
• Pre-flight README
• SHA-256 checksums
• Full reproduction guide
• 10-minute capture-quality audit

The record intentionally omits internal IP addresses, usernames, local filesystem paths and the firmware binary itself. It keeps the values needed to compare a build without exposing the lab network.