alfred_zheng

Photonicat 2 固件更新日志 2026-08-11 r7897 显示
蜂窝网络修复可能导致蜂窝网络完全不通的启动时序问题,且不再覆盖您的路由优先级。

但我升级后的实际测试结果是：问题没有解决。在整机重启、MCU 升级重启及 WWAN 模块重启后，故障均可复现。部分情况下，蜂窝数据超过3分钟仍无法自动恢复。

测试报告无法上传附件，贴在下面。

Photonicat 2 r7897 / RM500Q-CN 蜂窝网络启动时序故障报告

报告日期：2026-08-12（Asia/Shanghai）

设备：Photonicat 2 / Quectel RM500Q-CN

报告性质：现场复现与对照测试记录

隐私说明：本文已省略设备序列号、IMEI、公网 IP、SSH 凭据、代理订阅及节点信息。

1. 摘要

Photonicat 2 官方固件更新日志称，2026-08-11 发布的 r7897 修复了蜂窝网络启动时序问题，使 5G 连接中断后能够自行恢复，并且不再覆盖路由优先级。

但本机升级后的测试结果显示：在 RM500Q-CN 使用厂商 QMI 拨号链路的场景下，问题没有消失。整机重启、MCU 升级重启或厂商页面执行 WWAN 模块重启后，未使用的 wwan_5g MBIM 接口可能被再次触发，进入：

pending=true
PIN_FAILED
mbim capability timeout / retry

与此同时，厂商 pcat-manager → quectel-cm → QMI 链路也使用同一个 /dev/cdc-wdm0。部分测试中，wwan0 长时间无法获得 IPv4 地址及默认路由，蜂窝数据超过 3 分钟仍未自动恢复。

对照实验表明：先将 network.wwan_5g.disabled 设置为 1、停止 MBIM 重试，再通过独立 WWAN rfkill 控制对象重启模块，QMI 数据链路可以在约 30 秒内恢复。因此，现有证据更支持 QMI/MBIM 双控制路径及配置覆盖问题，而不是 SIM、APN、基站注册或 RM500Q 硬件本身故障。

严谨结论是：r7897 未在本机 RM500Q-CN/QMI 场景下消除该问题，并可在特定重启路径下复现。由于升级前也发生过类似问题，目前尚不足以证明 r7897 一定提高了故障发生率。

2. 官方更新说明与报告目标

官方 r7897 更新日志涉及以下蜂窝网络修复：

5G 连接中断后可以自行恢复；
修复可能导致蜂窝网络完全不通的启动时序问题；
不再覆盖用户设置的路由优先级。

官方页面：

Photonicat 2 固件更新日志：2026-08-11 r7897

本报告用于确认：

r7897 是否能在 RM500Q-CN/QMI 场景下自动恢复蜂窝数据；
wwan_5g MBIM 接口为何会在 auto=0 或曾设为 disabled=1 后再次启动；
厂商页面的 WWAN 模块重启是否会覆盖用户 UCI 配置；
PIN_FAILED 是否代表真实 SIM PIN 错误；
哪种恢复方式能够稳定保留厂商 QMI 拨号所有权。

3. 测试环境

项目	现场信息
设备	Photonicat 2，4GB + 64GB
蜂窝模块	Quectel RM500Q-CN
SIM	中国广电，MCC/MNC `46015`
APN	`cbnet`
当前系统固件	`R26.04.1 / r7897-c65d7593d9`
升级前系统固件	`R26.04.1 / r7854`
内核	`6.12.91`
当前 MCU	`RA2E1260809000`
升级前 MCU	`RA2E1260730001`
Modem 驱动	`qmi_wwan`
Modem 控制节点	`/dev/cdc-wdm0`
数据接口	`wwan0`
管理路径	独立 LAN 管理，P2 地址 `172.16.0.1`

厂商拨号链路为：

pcat-manager
  → quectel-cm -4 -6 -s cbnet
  → QMI /dev/cdc-wdm0
  → wwan0

OpenWrt 中同时存在另一段网络接口配置：

network.wwan_5g.proto='mbim'
network.wwan_5g.device='/dev/cdc-wdm0'
network.wwan_5g.apn='cbnet'
network.wwan_5g.auto='0'

这意味着系统中可能存在两条访问同一控制节点的路径：

厂商路径：pcat-manager → quectel-cm → QMI  → /dev/cdc-wdm0 → wwan0
系统路径：netifd       → mbim.sh/umbim → MBIM → /dev/cdc-wdm0 → wwan_5g

3.1 代理和 DNS 排除条件

r7897 升级后的首次故障发生时，OpenClash 尚未恢复安装；
PassWall2 没有运行；
故障发生在 wwan0 获取 IPv4 地址和默认路由之前；
因此本报告中的蜂窝启动故障不是由透明代理、防火墙接管或代理 DNS 导致的。

后续页面出现“无法上网”的健康提示属于另一层问题：设备可能已经具有 QMI 默认路由，但厂商健康探测因 DNS、代理或目标站访问失败而误报。该提示不能单独用于判断蜂窝数据会话是否建立。

3.2 MCU 因果边界

r7897 升级后、MCU 仍为旧版 RA2E1260730001 时，已经复现过 wwan_5g pending=true/PIN_FAILED 及 QMI 数据未恢复。升级 MCU 至 RA2E1260809000 并重启后，问题再次复现。

因此：

新 MCU 不是首次复现的必要条件；
MCU 升级导致的整机重启和 Modem 重枚举可能成为触发条件；
当前不能把 QMI/MBIM 竞争直接归因于 MCU 固件。

4. 预期行为

开机或重启 WWAN 模块后，由 pcat-manager 启动并维护 quectel-cm；
quectel-cm 通过 QMI 建立数据会话；
wwan0 获得 IPv4 地址及默认路由；
配置为 auto=0 或 disabled=1 的 wwan_5g MBIM 接口不应被启动；
WWAN 电源重启不应改写用户已经保存的 network.wwan_5g.disabled；
蜂窝会话发生异常时，系统应在合理时间内自动恢复，不需要用户反复重启整机或 Modem。

5. 实际现象

典型故障状态为：

wwan_lte:
  up=false
  pending=false
  wwan0 无 IPv4
  无蜂窝默认路由

wwan_5g:
  up=false
  pending=true
  proto=mbim
  error=PIN_FAILED

系统日志持续出现：

mbim message timeout
Failed to read modem caps
mbim bringup failed, retry in 15s
Interface 'wwan_5g' is now down
Interface 'wwan_5g' is setting up now

现场还能观察到：

pcat-manager 和 quectel-cm -4 -6 -s cbnet 仍在运行；
/dev/cdc-wdm0 和 /dev/ttyUSB0-3 均存在；
内核驱动实际为 qmi_wwan；
mbim.sh/umbim 会在后台周期性重试；
QMI 和 MBIM 两条路径均指向 /dev/cdc-wdm0。

因此，这不是单纯的前端显示错误，而是后台确实启动了 MBIM setup/retry 流程。

SIM 本身没有启用 PIN 锁。停止 MBIM 路径后，相同 SIM、相同 APN 和相同 RM500Q 模块可以通过 QMI 正常获得地址及默认路由。因此，该现场中的 PIN_FAILED 更像是 MBIM 初始化或能力查询失败后的错误映射，不能单凭这一字段认定 SIM 被锁定。

6. 复现过程

6.1 复现一：升级 r7897 后首次启动

从 r7854 升级至 r7897；
等待系统启动约 3 分钟；
确认 pcat-manager、quectel-cm、/dev/cdc-wdm0 和 /dev/ttyUSB0-3 均存在；
观察到 wwan_5g 进入 pending=true/PIN_FAILED；
日志持续出现 MBIM capability timeout 及约 15 秒一次的 retry；
wwan0 没有 IPv4 地址及默认路由；
继续等待仍不能确认蜂窝数据能够自动恢复。

此时 MCU 仍为旧版 RA2E1260730001，所以该次复现与新 MCU 无关。

6.2 复现二：MCU 升级后的整机重启

将 MCU 从 RA2E1260730001 升级至 RA2E1260809000；
整机重启并等待 RM500Q 重新枚举；
设备的 USB/QMI 节点及厂商进程重新出现；
network.wwan_5g.disabled 恢复为 0；
wwan_5g 再次进入 pending=true/PIN_FAILED；
QMI 数据链路没有立即自动恢复。

设备重启后系统时间曾回到 2020-01-01，因此该阶段日志中的 08:xx 是设备重置后的相对启动时间，不是实际日期变化。

6.3 复现三：厂商页面重启 WWAN 模块

重启前已经设置：

network.wwan_5g.auto='0'
network.wwan_5g.disabled='1'

随后通过厂商页面执行“重启模块/WWAN”：

RM500Q USB/QMI 设备断开；
约 28 秒后 /dev/cdc-wdm0 和 ttyUSB 节点重新出现；
network.wwan_5g.disabled 被恢复为 0；
wwan_5g 再次进入 pending=true/PIN_FAILED；
mbim.sh/umbim 恢复周期性重试；
厂商 QMI 数据会话超过 3 分钟仍未正常恢复。

该结果表明：本次测试中，厂商页面的 WWAN 重启操作不只是切换 Modem 电源，还伴随了 wwan_5g 配置重建或覆盖。

7. 对照实验：隔离 MBIM 后重启 WWAN 电源

7.1 操作顺序

先禁用未使用的 MBIM 接口：

uci set network.wwan_5g.disabled='1'
uci commit network
ifdown wwan_5g

确认：

wwan_5g pending=false
没有 mbim.sh/umbim 进程
/dev/cdc-wdm0 只由 quectel-cm 使用

随后通过设备独立的 rfkill-usb-wwan 控制对象关闭并重新开启 WWAN 模块。该操作没有启动第二个拨号器，也没有停止或替换 pcat-manager。

7.2 第一次对照结果

USB 设备断开后约 20 秒重新枚举；
wwan0 随后 link up；
DHCP 获得 IPv4 地址和默认路由；
最终 wwan_lte up=true/pending=false；
wwan_5g 保持无活动状态；
pcat-manager 和 quectel-cm -4 -6 -s cbnet 持续存活；
没有 MBIM/umbim 进程；
ping -I wwan0 1.1.1.1 为 3/3 成功。

7.3 MCU 重启后的再次对照结果

USB/QMI 于设备时间约 08:15:00 断开；
约 08:15:11 重新枚举；
约 08:15:27 wwan0 link up；
约 08:15:30 DHCP 获得 IPv4 和默认路由；
从 USB 断开到数据路由恢复约 30 秒；
network.wwan_5g.disabled=1 在该受控 rfkill 循环中保持不变；
没有出现新的 MBIM PIN_FAILED 重试。

该对照实验说明：

RM500Q、SIM、APN、基站注册和 QMI 数据能力均可正常工作；
仅执行底层 WWAN 电源循环时，QMI 可以自动恢复；
厂商页面 WWAN 重启与底层 rfkill 重启的行为不同；
禁用 MBIM 后，QMI 恢复路径明显更可控。

8. 当前临时解决办法

当前通过以下配置隔离未使用的 MBIM 接口：

network.wwan_5g.auto='0'
network.wwan_5g.disabled='1'

保持厂商 QMI 链路作为唯一 Modem owner：

pcat-manager → quectel-cm → QMI → wwan0

当前验收状态：

wwan_5g:
  disabled=1
  无 pending
  无 MBIM/umbim 进程

wwan_lte:
  up=true
  pending=false

wwan0:
  已获得 IPv4
  已建立默认路由

限制：disabled=1 目前不能可靠跨越整机重启、MCU 升级重启或厂商页面的 WWAN 模块重启；这些操作可能再次将其恢复为 0。受控的底层 rfkill WWAN 电源循环则能保留该配置。

9. 因果分级

9.1 已证实

当前 QMI 和 MBIM 两条控制路径均指向 /dev/cdc-wdm0；
wwan_5g 会被实际启动，而不是仅在前端显示异常；
MBIM 路径会出现 timeout、PIN_FAILED 及周期性重试；
network.wwan_5g.auto=0 不能阻止某些显式触发流程启动该接口；
本次厂商页面 WWAN 重启会把已保存的 disabled=1 恢复为 0；
禁用 MBIM 后，厂商 QMI 链路可以通过受控 WWAN 电源循环恢复；
旧、新两个 MCU 版本下都观察到过故障。

9.2 高概率推断

启动、热插拔、Web 后端或附加脚本显式触发了 ifup wwan_5g；
QMI/MBIM 对同一控制节点的竞争是 MBIM timeout 和 PIN_FAILED 的主要解释；
MBIM 重试可能增加 QMI 建链延迟、DHCP 重建、路由抖动或公网丢包风险；
厂商页面 WWAN 重启路径可能执行网络配置重建，而不仅是 rfkill 电源循环。

9.3 尚未证实

具体触发者是标准 netifd、Web 后端、ubus 事件、hotplug 还是其他厂商脚本；
PIN_FAILED 在此处是否完全属于错误映射；尚缺原始 MBIM PIN 状态或同期只读 AT+CPIN? 证据；
每一次公网丢包或路由抖动是否都由 MBIM 重试直接造成；
r7897 的故障发生率是否高于 r7854；现有测试证明“未修复并可复现”，但样本量不足以证明统计意义上的“加重”；
问题是否只影响 RM500Q-CN，或也影响其他 QMI 模块。

10. 希望官方协助确认

RM500Q-CN 使用 qmi_wwan 和 quectel-cm 时，为什么还会自动启动 wwan_5g 的 MBIM 路径？
是哪个组件在 auto=0 的情况下显式执行了 ifup wwan_5g？
为什么厂商页面重启 WWAN 模块后，会把 network.wwan_5g.disabled=1 恢复为 0？
PIN_FAILED 是否是 MBIM 初始化或 capability query 失败后的通用错误映射？
能否在检测到 qmi_wwan + quectel-cm 时不创建、自动禁用或跳过 MBIM 接口？
厂商页面重启 WWAN 时，能否只执行 Modem 电源循环并保留用户已有 UCI 配置？
能否提供用于定位 wwan_5g 启动触发来源的调试版本或日志采集方法？
r7897 所称的“蜂窝网络启动时序修复”是否覆盖 RM500Q-CN/QMI 场景？

superlynx

Aug 12

我们默认不安装modemmanager，所以不应该存在MBIM相关的项目，默认的wwan_5g应工作在以太网连接模式。

admin Staff

Aug 12

感谢详细报告，定位非常准确，已确认是固件 bug 并已修复。

根因：Web 后端的 WAN 管理器在每次开机和保存设置时，会无条件把 wwan_5g 的 disabled 改回 0 并强制拉起（刻意绕过 auto=0），导致 MBIM 和 quectel-cm 抢占同一个 /dev/cdc-wdm0。PIN_FAILED 是争用超时的错误映射，不是 SIM 问题，您的判断正确。rfkill 接口不碰 UCI，所以您的对照实验能保住配置。

修复：新固件（2026-08-12 之后构建）中，proto 为 mbim/qmi 的蜂窝接口视为用户自管，固件不再改写 disabled、不再强制拉起。您的 disabled=1 会持久生效；如果不用 MBIM 拨号，也可直接把 wwan_5g 恢复出厂（proto='dhcp'，device='usb0'）。

过两天发布，请升级后在 RM500Q 上验证，欢迎回帖反馈。