v1.0.7 — NanoPi Zero2 Wi-Fi 7 capture sensor

An Armbian image that turns a FriendlyElec NanoPi Zero2 and an M.2 Wi-Fi card into a
headless Wi-Fi scanning and packet-capture sensor.

Radio

• Mainline Linux 7.3, so the Intel BE200 runs on the kernel's own iwlmld driver rather
  than an out-of-tree backport, and every other card works without one being built per card.
• Wi-Fi 7: Intel BE200 (160 MHz), MediaTek MT7925/7927, Qualcomm WCN7850 and QCNCM865,
  Realtek RTL8922A and RTL8922D.
• Wi-Fi 6E: Qualcomm WCN6855 and QCA6390, MediaTek MT7921/7961 and MT7922, Realtek
  RTL8852 over PCIe and USB, Intel AX210.
• 2.4, 5 and 6 GHz, with all 110 frequencies available and no disabled channels on a clean
  boot, to 7115 MHz.
• A monitor interface, mon0, is created at boot and left alone; WLAN Commander drives the
  channel and the regulatory scan.
• Regulatory domain set to US in /etc/modprobe.d/cfg80211-regdom.conf. Change it for a unit
  deployed elsewhere — in the world domain there is no 6 GHz allocation at all, and every card
  except a self-managed Intel one silently loses the band.

Getting at it

• Gigabit ethernet through the board's RTL8211F.
• USB-C ethernet gadget on WLANPi's addressing, 198.18.42.1, handing the attached
  computer .9 to .19. Both gadget MAC addresses derive from the board serial, so they are
  stable across boots and distinct between units — two sensors on one laptop cannot collide.
• mDNS as _wlanpi._tcp and _ssh._tcp. Hostname is WC-nanopi-<last 3 of the SoC serial>, so a reflashed card keeps the name it had.
• Capture without sudo — dumpcap carries cap_net_admin,cap_net_raw, and the wlanpi
  account is in the wireshark group.
• Console is the UART header, 3.3 V at 1,500,000 baud.

Looking after itself

• SD card write speed measured once per boot, classified, and published as JSON at
  /run/wlan-commander/storage.json for WLAN Commander to read. Idle I/O priority, and it
  will not run while tcpdump is alive.
• fsck.repair=yes — a sensor is switched off by pulling its power, so the filesystem
  comes up dirty routinely rather than exceptionally, and a dirty ext4 must not strand a unit
  with no console.
• Root filesystem resizes itself on first boot.
• Orb Sensor 1.5.5 installed and unclaimed; open the Orb app on the same LAN to link it.
  Stop it before a client-mode throughput test on the same radio.

Verified on hardware

Card	Result
Intel BE200 (M.2)	iwlmld with firmware core 106; 6 GHz capture on channel 165
MediaTek MT7921U	2.4, 5 and 6 GHz capture, all three bands
MediaTek MT7925U (Netgear A9000)	Capture to 160 MHz; 136 beacons on 6 GHz
Realtek RTL8211F ethernet	Gigabit link
USB-C NCM gadget	Host reaches the sensor at 198.18.42.1
Sudoless capture	dumpcap with cap_net_admin,cap_net_raw

Qualcomm ath12k WCN7850 and Realtek rtw89 RTL8922AU ship in the image but have not been run on
hardware here, and 320 MHz is likewise unverified.

Flashing

xz -dc wlan-commander-nanopi-zero2-v1.0.7-bleedingedge.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

Replace /dev/sdX with the SD card. Writing to the wrong device destroys its data. First boot
resizes the root filesystem and reboots once, so allow about two minutes before looking for the
sensor on mDNS.

Log in as wlanpi, over the network or straight down the USB-C cable at
ssh wlanpi@198.18.42.1. Change the password before putting a unit on a network you do not
control — the image ships a default one, and a reflash resets it.

Source

Built from b42c222 against Armbian 6d07521a, kernel 7.3.0-rc1-bleedingedge-rockchip64,
clean tree. All build-time gates passed.

sha256 6e3c08ac97cc4e71ec6bacdedeeb43fef7dd0d196a85e383e3a5d1ca1931a494

v1.0.1 - WLANPi USB gadget addressing

The USB-C gadget now uses WLANPi's addressing

The sensor answers on 198.18.42.1 over USB-C and hands the attached computer
198.18.42.9 to .19. This is copied from WLANPi's own wlanpi-usb-ethernet package, so
an instruction written for a WLANPi now works verbatim on this board.

Up to v1.0.0 it was 192.168.7.0/24. That range has nothing to recommend it: it is a common
gadget default and it can collide with a network the attached host is already on.
198.18.0.0/15 is RFC 5735 benchmarking space, reserved so that cannot happen, which is why
WLANPi picked it and why upstream's own tooling refuses to move the gadget outside it.

Reflash to pick this up. A sensor running v1.0.0 stays on 192.168.7.1.

Three options came with it, matching upstream: link-local addressing and IPv6 router
advertisements off, and RequiredForOnline=no, so an unplugged usb0 can no longer make
systemd-networkd-wait-online stall the boot. The build now fails if the address ever drifts,
because on a unit with no ethernet attached usb0 is the only way in.

Everything else is unchanged from v1.0.0.

---

Mainline Linux 7.3-rc1 in place of Rockchip's vendor 6.1, so the Intel BE200 runs on the
kernel's own iwlmld driver instead of an out-of-tree backport, and the other Wi-Fi 6E and
Wi-Fi 7 cards work without one being built per card.

The image behaves like a WLANPi: account wlanpi / wlanpi, blanket passwordless sudo, mDNS
advertisement as _wlanpi._tcp and _ssh._tcp, USB-C ethernet gadget and serial console, and
dumpcap capture without sudo.

Verified on hardware

Card	Result
Intel BE200 (M.2)	iwlmld with firmware core 106; 6 GHz capture on channel 165
MediaTek MT7921U	2.4, 5 and 6 GHz capture, all three bands
MediaTek MT7925U (Netgear A9000)	Capture to 160 MHz; 136 beacons on 6 GHz
Realtek RTL8211F ethernet	Gigabit link
USB-C NCM gadget	Host reaches the sensor at 198.18.42.1
Sudoless capture	dumpcap with cap_net_admin,cap_net_raw

On a v1.0.0 unit booted 2026-09-04 the radio came up with all three bands and no disabled
channels, topping out at 7115 MHz, with zero firmware errors. On the old 6.1 image 6 GHz
stayed locked until a regulatory scan ran with a monitor interface up.

Drivers and firmware for Qualcomm ath12k WCN7850 and Realtek rtw89 RTL8922AU ship in the
image but have not been run on hardware here. 320 MHz capture is likewise unverified.

The regulatory domain matters

The image sets ieee80211_regdom=US. In the world domain there is no 6 GHz allocation at all,
and every card except a self-managed Intel one silently loses the band. Measured here: an MT7925U
refused to tune 6775 MHz and scanned zero 6 GHz APs, while the BE200 beside it found 21. Change
the country in /etc/modprobe.d/cfg80211-regdom.conf if a unit is deployed outside the US.

Orb Sensor

Orb 1.5.5 is installed and starts on first boot, unclaimed. Open the Orb app on the same LAN to
link it. It does active measurement on the uplink, so stop it before a client-mode throughput
test on the same radio. It never touches a monitor interface.

Flashing

xz -dc wlan-commander-nanopi-zero2-v1.0.1-bleedingedge.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

Replace /dev/sdX with the SD card. Writing to the wrong device destroys its data. First boot
resizes the root filesystem and reboots once, so allow about two minutes before looking for the
sensor on mDNS. The hostname derives from the SoC serial, not the card.

Source

Built from c96ae9a against Armbian 6d07521a, kernel 7.3.0-rc1-bleedingedge-rockchip64.
Both build-time gates passed.

sha256 93af0312dbdd0f480ae3a591a390bf5d8a82fb878c25b58626226eec0a1b9af3

v1.0.0 - mainline 7.3 sensor image

Mainline Linux 7.3-rc1 in place of Rockchip's vendor 6.1, so the Intel BE200 runs on the
kernel's own iwlmld driver instead of an out-of-tree backport, and the other Wi-Fi 6E and
Wi-Fi 7 cards work without one being built per card.

The image still behaves like a WLANPi: account wlanpi / wlanpi, blanket passwordless sudo,
mDNS advertisement as _wlanpi._tcp and _ssh._tcp, USB-C ethernet gadget and serial console,
and dumpcap capture without sudo.

Verified on hardware

Card	Result
Intel BE200 (M.2)	iwlmld with firmware core 106; 6 GHz capture on channel 165
MediaTek MT7921U	2.4, 5 and 6 GHz capture, all three bands
MediaTek MT7925U (Netgear A9000)	Capture to 160 MHz; 136 beacons on 6 GHz
Realtek RTL8211F ethernet	Gigabit link
USB-C NCM gadget	Host reaches the sensor at 192.168.7.1
Sudoless capture	dumpcap with cap_net_admin,cap_net_raw

Drivers and firmware for Qualcomm ath12k WCN7850 and Realtek rtw89 RTL8922AU ship in the
image but have not been run on hardware here. 320 MHz capture is likewise unverified.

The regulatory domain matters

The image sets ieee80211_regdom=US. In the world domain there is no 6 GHz allocation at all,
and every card except a self-managed Intel one silently loses the band. Measured here: an MT7925U
refused to tune 6775 MHz and scanned zero 6 GHz APs, while the BE200 beside it found 21. Change
the country in /etc/modprobe.d/cfg80211-regdom.conf if a unit is deployed outside the US.

Orb Sensor

Orb 1.5.5 is installed and starts on first boot, unclaimed. Open the Orb app on the same LAN to
link it. It does active measurement on the uplink, so stop it before a client-mode throughput
test on the same radio. It never touches a monitor interface.

Flashing

xz -dc wlan-commander-nanopi-zero2-v1.0.0-bleedingedge.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

Replace /dev/sdX with the SD card. Writing to the wrong device destroys its data. First boot
resizes the root filesystem and reboots once, so allow about two minutes before looking for the
sensor on mDNS. The hostname derives from the SoC serial, not the card.

Source

Built from b5689d4 against Armbian 6d07521a, kernel 7.3.0-rc1-bleedingedge-rockchip64.
Both build-time gates passed: the driver, firmware, device-tree and boot-glue check, and the
final-image check covering the regulatory domain, the BE200 tweak and Orb.

sha256 caf24df945bc92dc5955fae5c68cd0f775d905ef5874a2c2406c8947baae0629