Repository navigation
Releases
r10 — 第一个正式版：IPv6、Wi-Fi↔LAN 桥接加速、中继修复（HW-A/B/C/D）
r10 — IPv6、SQM、Wi-Fi↔LAN 桥接加速、中继修复
本项目第一个正式版。问题见 #3 和 QQ 群反馈。
修复内容
- WAN 口 IPv6 拿不到地址
产品自带的防火墙配置替换了 OpenWrt 默认配置，但漏掉了Allow-ICMPv6-Input/Allow-ICMPv6-Forward两条规则，wan 区域也没有包含wan6。上级发来的 RA/NS/NA 被拒绝，所以没有 IPv6 默认路由。r10 补上这两条规则和wan6；保留配置升级时由迁移脚本自动补上，不需要恢复出厂。 - 无 5 GHz FEM 的 D 板（如部分 RC3000）5G 信号很弱（#3）
HW-D 镜像首次启动时读取本机 ART，判断 5 GHz 是否带 FEM：没有 FEM 时自动改用 HW-B 的无线板数据，并在系统日志和 LuCI 状态页提示「这台应使用 HW-B 镜像」。这类机器可以直接 sysupgrade 到 HW-B 镜像，不需要-F（不保留配置）；带 FEM 的 D 板会拒绝 HW-B 镜像。docs/HW-ABCD-CLASSIFICATION.md 里关于 RC3000 B0 的分类已更正。 - 中继/桥接时上级路由器每次看到的 MAC 都不一样
STA 接口没有设置 MAC 时，系统用无线芯片里的占位地址00:03:7f:…生成 MAC。r10 改为由本机出厂 MAC 派生一个本地管理地址（与 AP 地址不同），重启和无线重载后保持不变。 - 无线偶尔首次启动失败、需要重试
OpenWrt 21.02 随机生成 HE BSS color 的写法大约每 10 次会算出空值或08/09这类被当作八进制的数，射频初始化报arithmetic syntax error，netifd 重试后才起来。r10 改用一个随机字节。 - 2.4G 中继：上级路由器断开约 1 分钟后整机重启
2.4G 做中继（STA）时，如果上级 AP 消失，IPQ5018 的 2.4G 无线固件大约 1 分钟后就会崩溃，每次都会。驱动默认不做固件恢复，直接触发内核 panic，整机重启，这很可能就是「2.4G 中继十几分钟掉线」的原因。r10 开机后自动打开 ath11k 的固件恢复，固件崩溃时只重启 2.4G 无线（约 3 秒），上级恢复后自动重连；同时修了恢复失败时驱动清理 NSS 资源的空指针。5G 中继没有这个问题。如果中继需要长期稳定，建议用 5G。
中继的上级路由器请用 WPA2-AES（CCMP）加密：测试者把光猫从 WPA/WPA2 混合加密改成 WPA2-AES 后，掉线间隔从十几分钟变成 14 小时以上。如果仍然掉线，请先不要重启无线，执行logread | grep -iE 'wpa|wlan|sta0|ath11k|hostapd|netifd' | tail -200和dmesg | tail -100，把输出发到群里或 issue。 - 内核模块里带有构建机路径：7 个 backports 无线模块（ath11k、mac80211、cfg80211 等）里残留了构建机的目录路径，r10 已去掉。
新功能
- Wi-Fi ↔ LAN 桥接加速：无线客户端和有线 LAN 主机之间（同一网段、经过 br-lan 桥接）的流量以前全部由 CPU 转发，5 GHz 跑满时 CPU 约 55–60%；r10 恢复了 NSS ECM 的桥接钩子，这部分流量也走硬件加速，CPU 降到约 4–5%，吞吐不变（受无线链路限制）。防火墙规则对局域网内部流量的处理与以前相同。客户端在 5 GHz 和 2.4 GHz 之间切换时约 2 秒恢复。可以在「网络 → 硬件加速」关闭。
- SQM（cake）：LuCI「网络 → SQM QoS」，默认关闭，接口已指向本机 WAN 口。
- 硬件加速开关：LuCI「网络 → 硬件加速」。启用任何一条 SQM 队列时会自动暂停 NSS 加速（否则加速的流量不经过 SQM，限速无效），关闭 SQM 后自动恢复。不需要重启。
- UPnP、DDNS、网络唤醒（WoL）：LuCI 应用，默认关闭。
已知情况
- UPnP 在光猫后面不生效：WAN 口是私网地址（如 192.168.x.x、10.x.x.x）时，miniupnpd 会拒绝端口映射（日志：
Reserved / private IP address … Port forwarding is impossible）。这是 miniupnpd 的设计。请把光猫改成桥接、由本路由器拨号。UPnP 设置里的 STUN 只能探测公网地址，上级 NAT 不放行时仍然无效。 - 开启 SQM 后速度变慢是正常的：SQM 由 CPU 做整形，加速会暂停；千兆宽带不建议开。
- 关闭硬件加速时，Wi-Fi ↔ LAN 桥接流量的 CPU 占用比 r9 高（HW-D 5 GHz 约 66–86%，r9 约 55–60%），因为桥接流量现在要经过连接跟踪。默认开启加速时没有这个开销。
- 5G 160 MHz：在 36 信道使用 160 MHz 时覆盖 DFS 信道 52–64，每次无线启动要先做 60 秒雷达检测，期间看不到 5G；路由器自己做扫描（中继向导/LuCI 扫描）时也会是空的。需要中继或扫描时请用 80 MHz。149 信道不支持 160 MHz。
- 2.4G 40 MHz：在 6、11、13 等信道回落到 20 MHz 是 20/40 MHz 共存规则，不是故障（同 r9 说明）。
- 中继时上级断开，同频段 AP 会暂停：STA 连不上上级时，同一频段的 AP 会一起暂停，上级恢复后自动恢复。这是 OpenWrt 的行为。
验证范围
- 正式版镜像（rc6）：A/C 从 r10 测试版、D 从 r9 之前的版本保留配置升级，迁移脚本自动补上桥接加速设置；B 此前装的是 HW-D 镜像（模拟无 5G FEM 的 D 板），升级时按规则换成 HW-B 镜像、不保留配置。冷启动 A、C、D 各 5 次，换上 U-Boot v0.1.0 后 A/B/C/D 再各 3 次，无 panic/OOM，25–30 秒可以 SSH（B 全新安装后首次启动 48 秒），两个频段 AP 都起来，WAN 拿到地址。桥接加速：A 489/471、B 520/527、C 570/561、D 537/563 Mbit/s（客户端→LAN / LAN→客户端），CPU 4–5%，ECM 有连接；HW-D 关闭加速开关后 ECM 为 0、流量照常，打开后恢复；有线 NAT 双向 940 Mbit/s。
- 大分区：HW-A 在 U-Boot v0.1.0 下切换到单系统 80 MiB 分区，写入本版，内核收到
h3c.boot_slot=0x900000 h3c.boot_size=0x5000000、overlay 约 57 MB；保留配置升级、冷启动 5 次通过，桥接加速 500/404 Mbit/s、CPU 3–4%；之后恢复双系统，两个槽与备份逐字节一致。 - 2.4G 中继长测（约 1 小时，每 5 秒检测一次连通）：WPA2-AES 每 60 秒换组密钥 30 分钟 0 次掉线；上级 AP 关闭再打开 5 次，每次都自动重连（4 次约 11 秒，1 次 80 秒）；上级换信道 1→6→11→1 三次，都在约 6 秒内跟随；WPA/WPA2 混合（TKIP）每 60 秒换密钥 15 分钟 0 次掉线；全程无固件崩溃、无重启。测试者 14 小时后的那次掉线在台架上没有复现。
- 四块板实机（
0x900000槽，U-Boot 单次引导）：HW-A/C/D 用 RA 测试 WAN IPv6，都能拿到地址和默认路由，ping6通（r9 对照不通）；有线 NAT 双向 941 Mbit/s（A、C），开 SQM（100/50M）时为 96/48 并自动暂停加速，关闭后恢复；加速开关关闭 870 Mbit/s、软中断 47%，打开 941 Mbit/s、CPU 95% 空闲。 - 中继 MAC：A 的 2.4G STA 用本机派生地址，3 次无线重载、5 次冷启动不变。
- 保留配置升级：D 从 r9 正式版升级，SSID、主机名、静态 DHCP 保留，防火墙自动补上 ICMPv6/wan6；rc3→rc4→rc5 在 A/B/C/D 上保留配置升级正常。
- 无 FEM 判定：带 FEM 的 D 识别为 fem，拒绝 HW-B 镜像；在无 5G FEM 的板子上运行 HW-D 镜像，识别为 nofem，5G 使用 HW-B 数据（board id 0x90），同一位置的客户端信号从 -71 提高到 -20 dBm，下行从 144 提高到约 720 Mbit/s；允许升级到 HW-B 镜像，不保留配置。
- 2.4G 中继：上级 AP 开关 15 轮，固件崩溃 14 次，全部只重启 2.4G，整机无重启，每轮上级恢复后都能重连（r10 之前：第一次崩溃就整机重启）。
- 冷启动：A 5/5、C 10+5、D 10+5 次，无 panic/OOM，25–29 秒可以 SSH；HE BSS color 修复后连续 20 次无线初始化 0 失败。
- UPnP：SSDP/NAT-PMP 正常，WAN 为公网地址时能添加转发规则，私网 WAN 下按 miniupnpd 设计拒绝。
安装与升级
需要 H3C-NX30-Uboot v0.1.0-pre.5 或更新，推荐同时发布的 v0.1.0 正式版。按硬件系列选择 H3C-Magic-r10-HW-A/B/C/D-*。nand-factory.ubi 在 U-Boot 救援页写入，sysupgrade.bin 用于系统内升级。安装前核对 SHA256SUMS。
从 r9 可以保留配置升级：无线、DHCP、主机名等设置保留，防火墙自动补上 IPv6 规则。
无 FEM 的 D 板用户：可以直接升级 r10 的 HW-D 镜像（5G 会自动改用 HW-B 数据），也可以改装 HW-B 镜像（推荐，不保留配置）。r9 的 HW-D 系统还不认识这条规则，从 r9 直接换 HW-B 镜像时需要 sysupgrade -F -n 一次。
English summary
r10 is the first stable release. Bridged Wi-Fi <-> LAN traffic is now NSS-accelerated (CPU ~55-60 % -> ~4-5 % on 5 GHz at the same throughput; firewall behaviour for LAN-internal traffic unchanged; can be switched off under Network > Hardware acceleration). For 2.4 GHz repeaters use WPA2-AES on the upstream router. IPv6 on WAN now works: the product firewall lacked the ICMPv6 input/forward rules and wan6 (a keep-settings upgrade migrates old configs). HW-D images detect a board without 5 GHz FEMs from ART and use the HW-B board data, warn in the log and LuCI, and accept a sysupgrade to the HW-B image (#3). Repeater/STA interfaces get a stable MAC derived from the factory MAC instead of one built from the 00:03:7f placeholder. In 2.4 GHz repeater mode the IPQ5018 WLAN firmware crashes about a minute after the upstream AP disappears; ath11k's default (no firmware recovery) turned that into a kernel panic and reboot. r10 enables ath11k firmware recovery at boot (the radio restarts in ~3 s; bench: 14 crashes in 15 upstream drops, no reboot) and fixes a NULL dereference in the NSS teardown after a failed recovery. The random HE BSS color no longer fails shell arithmetic about one radio setup in ten. Build-host paths were removed from the backports modules. New: SQM (cake, off by default), a hardware-acceleration switch that pauses NSS acceleration while any SQM queue is enabled, and UPnP/DDNS/WoL (off by default). Note: miniupnpd refuses mappings when WAN has a private address (behind an ISP router).
r9 — 修复无线默认配置、AP 下扫描、客户端互通和升级保留设置（HW-A/B/C/D Developer Preview）
r9 — 修复无线默认配置、AP 下扫描、客户端互通和升级保留设置
本版修复 r8 引入的无线默认配置问题，以及两个一直存在的无线问题。问题见 #2 和 QQ 群反馈。
修复内容
- HW-A/B/C 无线默认配置丢失（r8 回归）
r8 的四个镜像都误用了为 HW-D 构建的 base-files，HW-A/B/C 因此缺少首次启动的无线初始化脚本：两个频段默认关闭、SSID 不加密、没有国家码，无线 MAC 是通用的00:03:7f:…（每台都一样）。r9 每块板单独重建 base-files，A/B/C 恢复与 r7 相同的默认配置。HW-D 不受影响。 - AP 运行时扫描结果为空
路由器开着 AP 时，LuCI「扫描」和中继/桥接向导看不到任何网络。QSDK 的驱动要求 AP 接口上的扫描带NL80211_SCAN_FLAG_AP标志，而 iwinfo 没带。r9 给 iwinfo 打了补丁，AP 接口上扫描会带这个标志。 - 同一 AP 下的无线客户端互相不通（#2，感谢 @Keridium 的详细分析）
netifd 在没有设置multicast_to_unicast时会强制打开ap_isolate，依赖网桥 hairpin 转发客户端之间的流量；但 NSS 无线加速绕过了 hairpin，所以客户端之间连 ARP 都不通，LuCI 里也关不掉。r9 不再强制隔离；在无线接口上勾选「隔离客户端」（isolate=1）仍然有效。 - 保留配置升级不再重置无线设置
以前每次保留配置 sysupgrade 后，HW-A/B/D 的首次启动脚本都会把 SSID、密码、国家码和频宽改回默认值。现在和 HW-C 一样，只改系统新生成、从没被设置过的默认无线配置，其余一律保留。 - HW-D 状态灯：加入红灯（GPIO23）和绿灯（GPIO24）的设备树节点。
- HW-D 全新安装后 LAN/WAN 反了、无线没开（r8 起）
r8 开始 U-Boot 把 ECC8 / spare 128 交给内核，HW-D 的 ENV 分区 OOB 大小从 64 变成 128，读出厂 MAC 的工具hwd-factory-mac因此拒绝读取，首次启动的网络和无线脚本提前退出：LAN 跑到了 WAN 口上，两个频段关闭、SSID 不加密、没有国家码。r9 接受两种 OOB 大小（工具只读数据区）。
说明：2.4G 40 MHz
2.4G 设为 40 MHz 后在 6、11、13 等信道上回落到 20 MHz，是 hostapd 按 802.11 的 20/40 MHz 共存规则检测到周围有重叠网络，不是故障。在 1 信道或自动信道下通常能用 40 MHz；确需强制使用，可在 LuCI 勾选「强制 40MHz 模式」（noscan=1），但这会干扰周围网络，也不符合规范。
验证范围
正式版镜像与测试版 r9rc3 逐字节相同，只改了文件名；下文的 rc2 / rc3 指测试版。
- 源码离线测试：WAN 链路、MAC 策略与配置路径、Wi-Fi 首启策略、5G BDF、静态源码检查、设备控制模拟共 7 组全部通过（两组旧 Wi-Fi 测试已按 r9 的新首启策略更新，断言未放宽）；新的首启策略测试 12/12 通过。
- 四块板镜像离线检查：首次启动脚本、uboot_env、pin 工具的文件集合与 r7 一致；netifd 不再强制隔离；iwinfo 含 AP 扫描标志；HW-D 设备树含红/绿状态灯。
- HW-A 实机（全新写入）：首次启动两个频段开启、WPA2 加密、国家码 CN，无线 MAC 来自本机；AP 运行时扫描 3/3 次有结果（2.4G 8 个、5G 6 个），无崩溃；同一 5G AP 下两个客户端互 ping 双向 4/4（r8 为 0/4）；2.4G 40 MHz 在 1 信道和自动信道生效，6 信道因共存回落 20 MHz；运行 5 分钟无 panic/OOM，可用内存约 70 MB。
- HW-A 升级（r9rc2）：r8 原样配置保留配置升级 → 自动改为默认值；r8 上手动设置过无线（US、自定义 SSID/密码、149 信道 HE40、主机名）→ 全部保留，只把通用 MAC 换成本机 MAC；r9 上修改 5G 设置后再次保留配置升级 → 修改保留；恢复出厂 → 回到默认值。
- HW-D 实机（r9rc3，GD5F1GQ5 + ECC8 交接，U-Boot 6d377e7d 单次引导）：全新写入 → LAN=eth1（交换机口）、WAN=eth0，SSH 直接从 LAN 口可达；两个频段开启、WPA2、国家码 CN，信标 BSSID 为本机 MAC +2/+3；绿灯亮。r9rc2 首启的错误状态保留配置升级到 rc3 → 无线自动修正为默认值（网络配置按规则保留，见下）。
- HW-B / HW-C 实机（全新写入，单次引导）：B（ECC8）LAN=eth1、WAN=eth0，两个频段开启、WPA2、国家码 CN，无线 MAC 来自本机，hostapd 正常，可用内存约 72 MB；C（RTL8367S，ECC4）同样的默认无线配置和本机 MAC，LAN 口 SSH 可达，可用内存约 52 MB。均无崩溃。
安装与升级
与 r8 相同：需要 H3C-NX30-Uboot v0.1.0-pre.5 或更新（推荐最新版）。按硬件系列选择 H3C-Magic-r9-HW-A/B/C/D-*。nand-factory.ubi 在 U-Boot 救援页写入，sysupgrade.bin 用于系统内升级。安装前核对 SHA256SUMS。
从 r8 保留配置升级：HW-A/B/C 上 r8 留下的无线配置（关闭、未加密、无国家码）会在升级后首次启动时自动改成上面的默认值，无需恢复出厂。如果你已经在 r8 上手动设置过无线，你的 SSID、密码、国家码、频宽和信道都会保留，只会补上本机的无线 MAC（替换 00:03:7f:…）。
HW-D 用户注意：如果你是在 r8 上全新安装的 HW-D，网络配置里 LAN/WAN 是反的。保留配置升级不会改动你的网络设置（无线会自动修正），请升级时不保留配置，或升级后恢复出厂设置。从 r7 或更早版本保留配置升级上来的 HW-D 不受影响。
已经在 r8 上手动去掉 isolate 的用户，升级后无需再改 netifd 脚本。
English summary
r8 shipped HW-D base-files in all four images, so HW-A/B/C booted with both radios disabled, open SSIDs, no country code and the same generic wlan MAC on every unit; r9 rebuilds base-files per board. iwinfo now sets NL80211_SCAN_FLAG_AP when scanning on an AP interface, so scans work while the AP is up. netifd no longer forces ap_isolate when multicast_to_unicast is unset (with NSS Wi-Fi offload the bridge hairpin was bypassed, so clients of the same AP could not reach each other, #2); an explicit isolate=1 still works. A keep-settings sysupgrade no longer resets the user's Wi-Fi on HW-A/B/D: only the untouched mac80211 template gets the product defaults (as HW-C already did), other APs only gain a missing factory MAC. HW-D gets its status LED nodes. On HW-D, since r8 the ENV partition reports a 128-byte OOB (ECC8 handoff), which hwd-factory-mac rejected, so a fresh install came up with LAN/WAN swapped and radios disabled; r9 accepts 64 and 128 (only the data area is read). HW-D units that were freshly installed with r8 should upgrade without keeping settings (network config is kept as-is by sysupgrade). 2.4 GHz 40 MHz falling back to 20 MHz on busy channels is hostapd 20/40 coexistence, not a bug. The release images are byte-identical to the tested r9rc3 build. Tested on all four boards with a fresh install, keep-settings upgrades on HW-A and HW-D, AP scanning and client-to-client traffic on HW-A. Requires H3C-NX30-Uboot v0.1.0-pre.5 or later.
Contributors
Assets 12
r8 — 更多 NAND 闪存可以运行 QSDK（HW-A/B/C/D Developer Preview）
r8 — 更多 NAND 闪存可以运行 QSDK
本版修复内核对 NAND 闪存的识别：以前只有少数闪存型号能启动本固件，其余机器内核挂不上 rootfs，开机后回到救援页。问题见 #1。
修复内容
H3C-NX30-Uboot 会按自己审核过的闪存表识别本机 NAND，并在内核命令行里传入这台机器的物理 spare 大小和写入时用的 ECC（nandspare=64|128 nandeccbits=4|8），原厂内核就是这样读取的。以前的 QSDK 内核不看这两个参数，只按 nand_ids.c 的固定表配置，而这张表分辨不了下面几种情况：
- 同一颗 GD5F1GQ5REYIG（c8:41）出厂时有按 ECC4 写入的，也有按 ECC8 写入的；
- DS35M1GA（e5:21）、GD5F4GQ6（c8:45）的 spare 是 128，表里写的是 64；
- TC58CYG0S3HRAIG（98:d2）、TC58CYG1S3HRAIJ（98:db）、FM25LS01（a1:a5）、GD5F1GM7REYIG（c8:81）、DS35Q2GA（e5:72）、DS35M4GM（e5:a4）表里没有。
另外 HW-D 的内核只认 Winbond W25N01GWZEIG（EF:BA:21）。
本版：
- 四类主板：U-Boot 传入有效的组合（64/4、128/4、128/8）时，内核按它配置 OOB 大小和 ECC 强度；补上上面 6 种闪存。
- HW-D：有 U-Boot 传参时，要求闪存参数与 U-Boot 核对的一致，不再限定固定的型号名单；没有传参时仍只接受 W25N01GWZEIG、F50D1G41LB（c8:11）、GD5F1GQ5REYIH（c8:21）、GD5F1GQ4RE9IH（c8:c9）、MX35UF1GE4AC（c2:92）、W25N01JW（ef:bc），并要求 OOB64/ECC4。
- HW-C、HW-D 的分区写保护检查接受同样的三种组合，以及容量大于 128 MiB 的闪存（只使用前 128 MiB）。
分区表、系统槽选择、网络、无线和升级写入范围都没有改变。
验证范围
- HW-D（GD5F1GQ5REYIG，spare128，ECC4，以前的内核无法使用）：在 U-Boot pre.6 的 RAM 救援版下加载只读的 RAM 验证内核，内核按传参配置为 OOB128/ECC4，读出 APPSBL、ART 和两个系统槽无 ECC 错误，UBI 可正常挂载。没有在这台机器上写入或长期运行。
- HW-A（W25N01GWZEIG，64/4）、HW-B（GD5F1GQ5REYIG，128/8）、HW-C（W25N01GWZEIG，64/4）：从 r7 保留配置 sysupgrade 到本版的同源构建，rootfs 正常挂载；写入 1 MiB 文件后断电冷启动，读回一致，无 ECC 错误。
- 新增的其他闪存型号没有实物，只有构建与主机测试结论。
- 离线检查（WAN、MAC、配置路径、Wi-Fi、BDF、candidate10、设备控制模拟）全部通过。
安装
需要 H3C-NX30-Uboot v0.1.0-pre.5 或更新（推荐 pre.6），由它传入闪存参数。
按硬件系列选择 H3C-Magic-r8-HW-A/B/C/D-*，不要只按机身商品型号选择。nand-factory.ubi 用于在 U-Boot 救援页写入；sysupgrade.bin 用于已经运行本固件的系统内升级。使用稳定电源，升级前备份。安装前核对随包 SHA256SUMS。
English summary
The H3C U-Boot passes the NAND spare size and the ECC each unit was written with (nandspare= / nandeccbits=); QSDK ignored them and used the fixed nand_ids.c table, so units with an ECC4-written GD5F1GQ5REYIG, spare128 parts listed as spare64, or parts missing from the table could not mount rootfs, and HW-D only accepted the Winbond W25N01GWZEIG. r8 uses the U-Boot handoff on all four boards, adds six missing parts, and makes the HW-D check follow the geometry U-Boot verified. Tested on HW-D (GD5F1GQ5REYIG spare128/ECC4, read-only RAM kernel) and with sysupgrade plus a cold-boot readback on HW-A, HW-B and HW-C. Requires H3C-NX30-Uboot v0.1.0-pre.5 or later.
r7 — WAN 百兆链路修复（HW-A/B/C/D Developer Preview）
Note
r7 的固件镜像已移除，请改用 r8。r8 包含 r7 的全部修复，并支持更多 NAND 闪存。
r7 — WAN PHY 链路与速率跟踪修复
本版修复 HW-A、HW-B、HW-D 的 WAN 设备树缺少 qcom,link-poll 的问题。HW-C 已启用该属性，本次不改变其 WAN 节点。
修复内容
WAN 节点已有 MDIO 总线和 PHY 地址，但缺少 PHY 轮询开关。QSDK NSS-DP 驱动因此不连接 PHY，而在接口启动时直接报告 carrier up；PHY 的链路和速率变化也无法沿该路径通知 SSDK。现场表现为百兆链路已建立但接收包为零、DHCP 无法取得地址，千兆连接则可以接收数据。
本版在 A/B/D 的 WAN 节点添加 qcom,link-poll = <1>;，不改变 PHY 接口模式、MDIO 地址、MAC 派生、无线、分区表、系统槽选择或升级写入范围。增加设备树回归检查并纳入离线 CI。另修正既有 BDF 候选测试：在临时目录生成历史 Candidate 5 后核验，避免把当前原始 H3C BDF 当作候选。实际固件使用的 BDF 文件保持不变。
验证范围
- HW-B 的单独修复构建已完成百兆/千兆故障对照，用户在升级后报告恢复有效。这是本次修复的现场依据。
- 此前的校园定制镜像不是本次公开 Release 附件；公开固件使用常规
configs/h3c-magic.config，不包含校园认证、防护或用户配置。 - r6 的四板验收与吞吐记录仅属于 r6，不能视为 r7 的硬件验收。新 Release 附件的离线构建、DTB 和镜像检查结果由随包构建清单记录；A/C/D 的本轮硬件回归、10 Mbps、长稳和各 NAND 批次仍待验证。
- 保留配置升级仍建议先导出备份。本轮现场的配置保留完整性未取得独立验收证据。
安装
按硬件系列选择 H3C-Magic-r7-HW-A/B/C/D-*，不要只按机身商品型号选择。nand-factory.ubi 用于匹配硬件的 U-Boot 救援安装；sysupgrade.bin 用于已有匹配系统的正常升级。使用稳定电源，升级前备份。安装前核对随包 SHA256SUMS。
English summary
Enable WAN PHY link polling on HW-A/B/D; HW-C already has it. This allows NSS-DP to attach the PHY and propagate negotiated link/speed changes instead of treating the WAN as permanently up. The observed HW-B failure was zero receive traffic on a 100 Mbps link while a 1 Gbps PC link received normally. A separate HW-B fix build received positive user feedback; this does not establish hardware acceptance for all new public release images. Partition layout, slot selection, PHY mode and radio settings are unchanged by this fix. No campus packages or private configuration are included.
r6 — QSDK 11.5 HW-A/B/C/D Developer Preview
Tip
三步上手： ① 用 BootBridge 网页版装上 U-Boot pre.5（免拆机、免 TTL）→ ② 在救援页「系统信息」查看「硬件系列」→ ③ 下载下表中对应的 nand-factory.ubi，写入非原厂系统所在的槽。
交流与反馈：QQ 群 1131957442。
r6 — QSDK 11.5 HW-A/B/C/D Developer Preview
⚠️ 实验性预发布。 每个 HW 组只在项目的一台样机上实测。动手前请完整阅读 README 的安装说明，并先在救援页「闪存备份」备份两个系统槽。
同一套源码（r6 标签）和同一份配置 configs/h3c-magic.config 为四个 HW 组各出一个镜像。
选择镜像
镜像必须与 U-Boot 识别出的 HW 组一致，不能凭商品型号或 machid 猜（B、D 可共用 0x08040000）。
| HW 组 | 样机 | 首次写入（U-Boot 救援页） | 系统内升级（LuCI） |
|---|---|---|---|
| HW-A | RW3000 | H3C-Magic-r6-HW-A-nand-factory.ubi |
H3C-Magic-r6-HW-A-sysupgrade.bin |
| HW-B | RT3000 | H3C-Magic-r6-HW-B-nand-factory.ubi |
H3C-Magic-r6-HW-B-sysupgrade.bin |
| HW-C | RT3000（RTL8367S） | H3C-Magic-r6-HW-C-nand-factory.ubi |
H3C-Magic-r6-HW-C-sysupgrade.bin |
| HW-D | NX30 | H3C-Magic-r6-HW-D-nand-factory.ubi |
H3C-Magic-r6-HW-D-sysupgrade.bin |
附件已按硬件分类重命名，文件内容和 SHA-256 都没有变；自己构建时，产物仍是 OpenWrt 默认的文件名。
前置条件
需要 H3C-NX30-Uboot 的 U-Boot v0.1.0-pre.5。还在原厂系统的设备用 BootBridge 网页版安装。r6 不使用 r5 的原厂 Telnet 安装流程。
默认值
- LAN
192.168.10.1，LuCIhttp://192.168.10.1/，SSH 仅 LAN；新装没有 root 密码。 - 2.4 GHz
OpenWrt、5 GHzOpenWrt-5G，WPA2，密码12345678，国家码 CN。公开默认值，请尽快更换。 - MAC 与原厂编号一致：WAN 为出厂地址，LAN / 2.4 GHz / 5 GHz 为 +1 / +2 / +3。从 r5 升级会改变这三个地址。
- 无线校准数据开机时从本机 ART 读取，镜像不含任何设备的校准数据。
相对 r5 的主要变化
- 新增 HW-A、HW-C、HW-D 支持；四组共用出厂默认和同一套 sysupgrade。
- QSDK 可从任一系统槽启动，也支持 U-Boot pre.4+ 的 80 MiB 大分区。
- RTL8367S（HW-C）DSA / 扩展驱动；IPQ5018 / QCN6102 的 ath11k 修复；各组 BDF 包。
- ath11k 监控状态环缩小到 128 项，空闲可用内存多约 2～3 MB。
- 修复：全新构建 HW-C 时会装入未清零天线轴字段的 QCN6122 BDF，导致 Q6 开机断言。
验证范围
每组一台样机，镜像即本页附件（哈希见 SHA256SUMS）：救援页写入非原厂槽 → 启动检查（型号、槽位、MTD 映射、UBI 无错误）→ 系统内升级并保留配置 → 连续 5 次断电冷启动，每次两个射频和两个 AP 均正常、无固件断言。四组全部通过（各 13 项，0 失败）。
iperf3 4 流，客户端为 MT7921（Wi-Fi 6，2×2，近距离，信号约 -9 ～ -19 dBm）；有线 NAT 为 LAN → 路由器 NAT → WAN。单位 Mbps，上行 / 下行：
| 样机 | 空闲可用内存 | 5 GHz HE80 | 2.4 GHz HE20 | 有线 NAT |
|---|---|---|---|---|
| HW-A | 约 73 MB | 646 / 729 | 216 / 102 | 942 / 942 |
| HW-B | 约 72 MB | 727 / 692 | 200 / 114 | 941 / 942 |
| HW-C | 约 52 MB | 672 / 774 | 213 / 187 | 941 / 942 |
| HW-D | 约 53 MB | 727 / 729 | 188 / 174 | 939 / 939 |
任一系统槽和 80 MiB 大分区的启动，由同一源码的前一轮构建在四组样机上实测；本页镜像只在非原厂槽实测。
已知限制
- 每组只有一台样机，其他 NAND 型号和批次未验证。
- 有线 WAN↔LAN 路由经 NSS/ECM 加速；LAN 内无线与有线的桥接流量由 CPU 转发，未加速。
- HW-C / HW-D 沿用原厂 Q6 内存预留，可用内存比 HW-A / HW-B 少约 20 MB。
- 10/100 Mbps、长时间运行、LED / 按键尚未完整验证。
- 大分区会抹掉原厂系统；回原厂需先在救援页写回原厂双系统分区表。
English summary. One source tree builds images for HW-A (RW3000), HW-B (RT3000), HW-C (RT3000 RTL8367S) and HW-D (NX30). Requires the H3C-NX30-Uboot U-Boot v0.1.0-pre.5 (install it with BootBridge from OEM firmware); write nand-factory.ubi to the non-OEM slot from the rescue page, then upgrade with sysupgrade.bin. Defaults: LAN 192.168.10.1, no root password, SSIDs OpenWrt / OpenWrt-5G, WPA2 key 12345678, country CN. Each image passed rescue-page install, in-place upgrade with config kept and five power-cycle cold boots with both APs up on one unit per group. Pick the image for the HW group U-Boot reports, not by model name. See the README for limitations.
Product R1 r5 — RT3000 Machine-B Developer Preview
Product R1 r5 — Developer Preview
⚠️ 实验性预发布。 请在动手前完整阅读 已更正的安装教程。r5标签保留发布当时的源码快照，旧版教程中把 B 机配置头 D009 误写成原厂软件版本；请以此处更正说明和最新教程为准。2026-09-23 已在 RT3000 Machine-B 上按当前教程复走安装、读回、主动双向切换、保留配置升级和恢复出厂。原厂 Telnet 配置导入本轮未重复执行；配套工具已在三份不同配置头的 RT3000 原厂备份上离线复核，输出分别与已有启用版逐字节一致。故障注入、断电和完整 U-Boot + TFTP 救援仍未实测。
版本勘误：B 机网页和 display version 的软件版本是 RT3000V100R005；同一台 B 机导出的配置文件第二行是 RT3000/RT3000V100D009。这两个字段用途不同，不能据 D009 将 B 机备份认作另一台设备。另两台样机的配置头字段为 RT3000V100D012、RT3000V100D023；这些字段也不能直接替代各自网页／CLI 的软件版本。下述固件镜像仍只在 B 机实测，配置工具的离线兼容结果不扩大镜像适用范围。
硬件勘误（2026-09-30）：经实体芯片顶标与照片复核，本项目 B 机的 SoC 为 Qualcomm IPQ5000，内存为集成 256 MiB DDR3L，早期 IPQ5018 记载有误。本次仅修正文档，r5 固件附件及校验值不变，支持范围仍限于本项目已实测的 B 机。
📦 直接下载原厂 Telnet 一键工具 ZIP（SHA-256：3a28ef6bd025caee0b58136fedcc530ecf95b63565e2d582592168679d170120）。解压后按第一部分教程操作；ZIP 不包含用户配置备份。
📦 直接下载 Machine-B r5 OEM/QSDK 传输工具 ZIP（8,569 字节；SHA-256：8a0117f63ca7e461a2684b2602a092b09b52eafbf01dc6771ec080758778cb95）。包含 rt3bcwrite、Windows 临时文件服务器批处理和中文说明；factory .ubi 镜像需从本页单独下载并核验。
这是什么
H3C Magic RT3000（Machine-B）的双槽位固件。
在不改动原厂系统的前提下，把 OpenWrt 21.02.7 + Qualcomm QSDK 11.5 装进第二个 NAND 槽位，
并支持在原厂系统与 QSDK 之间双向切换。
版本识别：r5 是本次对外发布标签；已实机验证的镜像内部清单仍写作 Product R1 Upgrade Preview。这是同一组镜像的内部构建名称，不代表另一款硬件或另一个可互换版本。识别附件请以本页文件大小、SHA-256 和内部 kernel/rootfs 校验值为准；本次没有为了改名称重新构建镜像。
| SoC | Qualcomm IPQ5000 |
| RAM | Integrated 256 MiB DDR3L |
| 平台 | QSDK 11.5（NHSS.QSDK.11.5.0.5） |
| 内核 | Linux 5.4.164 |
| 用户空间 | OpenWrt 21.02.7（r16847-f8282da11e） |
| NAND | 128 MiB（GigaDevice GD5F1GQ5REYIG） |
| 槽位 | A = 原厂（mtd15）／B = QSDK（mtd16） |
| 界面 | 中文 LuCI + 网页终端（TTYD） |
本版修复了什么
WiFi 关联缺陷（重要）
r4 版本存在 WiFi 无法连接的问题：设备能广播、客户端能认证、能关联，
但无法完成密钥握手 —— 表现为「连不上 WiFi」、反复重连，日志里是：
nl80211: NL80211_ATTR_STA_VLAN (... vlan_id=0) failed: -34
根因：ath11k 声明了 VLAN_OFFLOAD 能力，导致 hostapd 在关联时
多发一个内核不接受的属性值（vlan_id=0），整条设置命令被内核以 -ERANGE 拒绝。
修复：让 hostapd 在「不绑定 VLAN」时不发送该属性。
| 补丁 | package/network/services/hostapd/patches/803-nl80211-only-set-VLAN-ID-when-non-zero.patch |
⚠️ 说明：这个问题并非所有历史版本都存在。
更早的测试版本有真实客户端成功关联并跑出吞吐的记录。
为什么某些版本正常、r4 不正常，原因尚未完全确定。
r5 已通过上述补丁消除了该现象。
实机验证：2.4G / 5G 均可连接、能上网、能断开重连、能双频切换。
本版还包含
| 项 | 内容 |
|---|---|
| 默认 LAN | 192.168.10.1（与 OEM 一致，避免与常见家用网关冲突） |
| 默认 WiFi | 2.4G RT3000 / 5G RT3000-5G，均开启，WPA2，密码 RTRCRWNX |
| 5G 频宽 | HE80（比 HE160 更易落在非 DFS 信道；是否需要 DFS 取决于实际选用信道，不能仅凭频宽保证） |
| 中文界面 | 首次启动自动选择中文（保留用户显式选择） |
| 软件源 | 用户空间包指向国内镜像；内核包走本项目构建 |
| 升级脚本 | rt3000.sh：修复 /dev/ubi* 节点缺失、NAND→NAND 升级、配置保留 |
🔑 首次登录请立即设置 root 密码。
新装的 QSDK 没有 root 密码，且 SSH 只绑 LAN 口。
在设置密码前，任何能访问 LAN 的人都能以 root 登录。
附件
| 文件 | 大小 | 用途 |
|---|---|---|
openwrt-ipq50xx-arm-h3c_rt3000-squashfs-nand-factory.ubi |
13,107,200 | 首次安装（从原厂写入第二槽位） |
openwrt-ipq50xx-arm-h3c_rt3000-squashfs-nand-sysupgrade.bin |
12,299,027 | 升级（QSDK → 新 QSDK） |
openwrt-ipq50xx-arm-h3c_rt3000-initramfs-fit-uImage.itb |
10,988,236 | 救援（内存系统） |
openwrt-ipq50xx-arm-h3c_rt3000-squashfs-release.json |
398 | 发布身份清单 |
openwrt-ipq50xx-arm.manifest |
4,522 | 包清单 |
SHA256SUMS |
— | 校验值 |
RT3000-OEM-Telnet-OneClick-r5-corrected.zip |
5,263 | Windows 原厂配置一键开启 Telnet 工具；更正说明，不含用户配置 |
RT3000-Machine-B-r5-OEM-Transfer-Tools.zip |
8,569 | rt3bcwrite、Windows 临时文件服务器与中文说明；不含固件及备份 |
校验值
80e99811887ec3bedaf648a32954d93fc5e1482ab70605d6e41d791ce181c529 openwrt-ipq50xx-arm-h3c_rt3000-squashfs-nand-factory.ubi
7f8f9e5dca42bc0b1fdb0c5dc9d01f8863878631202d2d325df6cd659bf1d65a openwrt-ipq50xx-arm-h3c_rt3000-squashfs-nand-sysupgrade.bin
65a374d29ab533788e2b51e96878ace57c582034a1ce2f8329747cd78a043a31 openwrt-ipq50xx-arm-h3c_rt3000-initramfs-fit-uImage.itb
51d17fbd3a93a0e9d20b60003e9467f00cb7bcdc5d69198885a191a3435e1359 openwrt-ipq50xx-arm-h3c_rt3000-squashfs-release.json
258ae87574d4b0a9bf48b570aebc5d12600e385b025369c73f167727c43d3764 openwrt-ipq50xx-arm.manifest
3a28ef6bd025caee0b58136fedcc530ecf95b63565e2d582592168679d170120 RT3000-OEM-Telnet-OneClick-r5-corrected.zip
8a0117f63ca7e461a2684b2602a092b09b52eafbf01dc6771ec080758778cb95 RT3000-Machine-B-r5-OEM-Transfer-Tools.zip
下载后请核对：
sha256sum -c SHA256SUMS # LinuxmacOS 可用 shasum -a 256 文件名，逐项对照上面的校验值。
certutil -hashfile openwrt-ipq50xx-arm-h3c_rt3000-squashfs-nand-factory.ubi SHA256镜像内部载荷
| 载荷 | 长度 | SHA-256 |
|---|---|---|
kernel |
3,474,820 | 7a7c048e92bcd53bfdba554770195adbbaf4cf4deb0d383d4f3c85ba881c31c9 |
rootfs |
8,810,094 | 31115a4c01c29357f6ed1e27a1f5007ef6e25904342054be48542610c5605f74 |
槽位切换工具
rt3bcwrite 已包含在本页的 Machine-B r5 OEM/QSDK 传输工具 ZIP 中，也可从源码工具目录单独获取。文件 SHA-256：
e23d8634af3fb20a5c383aa22ad2dc65752133ffd91d3715a70df5121d0789f5
原厂固件中没有这个工具；首次安装时可从工具 ZIP 的文件服务器传到设备。实际安装与切换步骤仍按第二、三部分教程操作。
安装
完整步骤见 rt3000-machine-b/release/INSTALL.md。
概要：
第一部分 获取 telnet （改一个配置开关；不刷写系统镜像，但会修改并保存原厂配置）
刷写前 保存 OEM 备份 （原厂 .cfg 与本机 mtd15 读取备份；大小和 SHA-256 核对）
第二部分 安装 QSDK （写入 mtd16，含保命检查与读回校验）
第三部分 双向切换 （只更新两份 BOOTCONFIG 中的启动选择；不刷写系统镜像）
第四部分 固件升级
第五部分 救援
适用范围
仅在下列硬件上实机验证：
| 项 | 值 |
|---|---|
| 型号 | H3C Magic RT3000 |
| 硬件平台 | Machine-B |
| NAND | GigaDevice GD5F1GQ5REYIG（128 MiB） |
| 原厂固件 | Chaos Calmer 15.05.1 / Linux 4.4.60；网页／CLI 软件版本 RT3000V100R005 |
| 同机导出配置的第二行 | RT3000/RT3000V100D009（配置头字段，不是软件版本） |
| U-Boot | H3C RT3000 Boot, Version 100，启动配置 config@mp02.1 |
🔴 RT3000 存在不同硬件批次。
如果你的分区表或 NAND 型号与上表不同，请先停下 ——
尤其分区表不同时，教程里的mtd15/mtd16引用可能指向错误的分区。
⚠️ 安全边界（必读）
本方案有多重保护，但保护机制不等于「一定救得回来」。
已实测
| 能力 | 验证方式 |
|---|---|
从原厂安装 QSDK 到 mtd16 |
✅ 完整走通 |
| 从 NAND 启动 QSDK | ✅ |
| 主动双向切换（只更新启动选择，不刷写系统镜像） | ✅ 含配置逐字节保留证据 |
保留配置升级（sysupgrade） |
✅ |
恢复出厂（sysupgrade -n） |
✅ |
🔴 未实测 / 无法保证
| 事项 | 实际状态 |
|---|---|
| 切到 QSDK 后启动失败，是否自动回退原厂 | 未验证。机制上 U-Boot 会读 selector，但失败时的行为未实测。 |
| 写入 / 升级过程中断电 | 未实测。机制上启动目标仍指向原厂，但这只是推断。 |
| 原厂内容完好 ⇒ 无需串口就能切回 | 不成立。切回需要能运行命令的环境。 |
| 两个系统都无法启动 | 需要 TTL 串口 + U-Boot。该救援路径未端到端验证。 |
结论：
保护机制降低风险，但不能替代两件事 —— 备份，以及串口救援的准备（TTL 线）。
从不触碰
| 项 | 状态 |
|---|---|
mtd15（原厂系统） |
全程不写入 |
| bootloader | 不修改 |
| 分区表 | 不修改 |
| U-Boot 持久化环境 | 不执行任何 saveenv |
已知问题
见 rt3000-machine-b/release/KNOWN_ISSUES.md。
回退到原厂
在 QSDK 里执行一条命令：
rt3slot oem --reboot这只更新启动选择，不重写、不删除 QSDK。需要从原厂返回时，先确认原厂正常启动且能进入 shell，再按教程第三部分操作。
详见第三部分：双向切换。
反馈
欢迎反馈，尤其是照着教程走时卡住的地方。请附上：
- 卡在哪一步
- 实际输出 vs 文档预期
- 你的硬件版本（
cat /proc/mtd和uname -r的输出）
维护者联系方式见 PUBLICATION.md。
上游与许可证
本项目基于 OpenWrt 21.02.7 与 Qualcomm QSDK 11.5。
原有上游许可证与署名保留，见 LICENSES/ 与 COPYING。
⚠️ 本发布为实验性 Developer Preview，不提供任何担保。