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