RM520N-GL R01A07反复掉线,申请迁移至R03并咨询跨基线升级

各位移远工程师好:

我的RM520N-GL在特定位置使用一段时间后反复断网,希望协助分析。

据移远论坛公开回复,我理解R01已进入冻结或停止常规维护状态,R03是当前主要维护基线。因此,我希望优先确认本模组能否通过官方流程由R01迁移至R03,并申请匹配的正式固件、升级工具、操作手册及回退方案。若本模组不能升级R03,也希望获得包含相关断网修复的最新R01正式固件。

设备及购买信息

  • 模组:Quectel RM520N-GL AA
  • 当前固件:RM520NGLAAR01A07M4G_01.201.01.201
  • 主控平台:Banana Pi BPI-R3 Mini,MediaTek Filogic
  • 系统:ImmortalWrt/OpenWrt 24.10,Linux 6.6.133
  • 使用性质:个人测试、自组5G CPE/路由器
  • 目标产品类别:5G移动宽带路由器/CPE
  • 购买渠道:淘宝
  • IMEI:868371054416223

故障现象

设备在其他位置使用正常,在当前位置可能正常运行数小时后断网。执行AT+CFUN=1,1可以暂时恢复,但曾在恢复约5分钟后再次复现。

当前环境:

  • 驱动:qmi_wwan_q V1.5.0
  • 拨号:单实例quectel-CM-M,QMI/QMAP
  • 运营商:中国广电46015
  • 网络:5G SA,主要为n41,也连接过n28
  • APN:autocbnet均测试过

故障时内核出现:

qmi_wwan_q ... wwan0: NETDEV WATCHDOG: transmit queue 0 timed out

quectel-CM持续出现:

requestQueryDataCall message timeout
requestQueryDataCall err = 110
requestSetupDataCall message timeout

一次复现中,wwan0 TX errors从0增长至1200。

掉线现场状态:

  AT端口正常响应
  C5GREG: 0,1
  CGATT: 1
  CGACT: 1,0
  CGPADDR: 0.0.0.0
  USB仍为5 Gbps,cdc-wdm0仍存在
  温度约42至44摄氏度

即无线仍注册、AT和USB正常,但PDP/PDU会话失活,随后QMI/QMAP发送及控制路径持续超时。

已经确认:

  • auto和cbnet两个APN均复现。
  • n28和n41都曾正常工作。
  • 升级内核、QModem和QMI驱动后仍复现。
  • 故障时只有一个quectel-CM-M进程。

固件及资料申请

我的首要诉求是将当前R01模组安全迁移至仍在维护的R03基线。希望获得:

  1. 根据本机IMEI、硬件批次和出厂配置,确认是否支持由R01升级至R03。
  2. 如果支持,请提供适用的最新R03正式完整固件、对应升级工具、升级步骤及回退方案,并说明应选择R03A03还是R03A04。
  3. 如果不支持升级R03,请提供最新R01正式固件,并确认其中是否包含不稳定5G网络下断网问题的修复。
  4. 最新RM520N系列AT命令手册。
  5. Linux QMI/QMAP驱动及使用手册。
  6. Linux QFirehose升级工具和完整固件升级手册。
  7. QCN/NV备份、跨基线升级失败恢复及回退说明

在官方确认前,我不会直接将R03固件刷入当前R01模组。请根据IMEI、硬件批次和出厂配置,说明哪些固件可以安全使用。

希望确认的问题

  1. R01目前是否已经停止常规维护?当前最终或最新维护版本是什么?
  2. 本机R01A07是否存在不稳定5G网络下QMI/WDS或数据会话卡死的已知问题?
  3. R01A08 Release Note中“不稳定5G网络情况下网络断开”的修复是否与本问题有关,最新R01是否已包含该修复?
  4. 本模组能否由R01正式迁移至R03?
  5. 跨基线升级需要完整Firehose刷写还是支持DFOTA?升级前是否必须备份QCN/NV?
  6. R01和R03为什么默认不能互刷?是否涉及硬件版本、分区、QCN/NV、射频校准、MBN、认证或防回滚?
  7. 升级R03后能否回退R01,是否会影响射频参数、PC1.5能力、运营商认证或保修?
  8. 还需要提供哪些日志,才能进一步区分模组固件与Linux QMI/QMAP驱动问题?

附件:

2026-08-15_0147_quectel-CM-dial.txt (639.0 KB)
2026-08-15_0147_router-dmesg.txt (123.2 KB)

感谢协助。

从现象看,模组 AT、USB 枚举仍正常,但数据会话失活,且 QMI 控制/数据路径超时;需要结合模组侧日志和主机侧 QMI/QMAP 日志进一步判断是网络侧、固件侧还是主机驱动/拨号侧问题。

关于固件与资料申请:

  1. R01 跨基线迁移到 R03 不能仅凭当前版本号判断,需由移远工程师结合 IMEI、硬件版本、出厂配置、QCN/NV、认证配置等确认。未确认前不建议自行刷入 R03 固件。
  2. R01/R03 是否可互刷、是否支持回退、是否需要完整包 Firehose 升级或 DFOTA、是否需备份 QCN/NV,均应以移远针对该模组批次给出的正式升级方案为准。
  3. 涉及正式固件、升级工具、回退包、QCN/NV 备份说明等资源,需要通过官方确认后发放。请提供邮箱地址,以便为您发送对应资料。
  4. R01 当前维护状态、最新维护版本、R01A08 修复项是否覆盖您描述的断网问题,以及本机是否可迁移 R03,需等待官方技术人员根据内部版本记录和日志确认,AI 无法直接判定。

建议补充/保留以下信息供工程师分析:

  • 完整 quectel-CM 日志,建议覆盖正常拨号、掉线前、掉线后、重拨失败全过程。
  • 掉线前后 dmesg,重点保留 USB reset、cdc-wdm、qmi_wwan_q、NETDEV WATCHDOG、TX timeout 相关内容。
  • 掉线时 AT 侧注册、附着、PDP/PDU 会话、IP 地址、信号质量、服务小区信息等状态快照。
  • 若条件允许,提供同一位置不同时间段、不同小区或锁频/不锁频条件下的复现对比。
  • 模组侧诊断日志需按官方工程师提供的工具和步骤抓取。

您当前“不直接刷 R03”的处理是正确的。跨基线升级存在配置、分区、射频校准、运营商配置等风险,应等待官方确认后再操作。

本回答仅供参考。若问题已解决,可标记为 :white_check_mark:解决方案 ;若仍有疑问,请等待官方技术人员回复,最终请以专业解答为准。

我已按建议保存本次完整掉线现场,补充情况如下。

1. quectel-CM日志

附件2026-08-15_0308_quectel-CM-dial.txt包含:

  • 02:06:51模组重新枚举及QMI初始化过程。
  • 02:07:09 IPv4/IPv6成功拨号。
  • 03:01:49开始出现requestQueryDataCall超时。
  • 03:04、03:06、03:08连续出现requestSetupDataCall超时。
  • 03:09再次停在未完成的requestQueryDataCall。
  • 直到03:20仍未自动恢复。

故障期间只有一个quectel-CM-M进程。

2. 内核及USB状态

03:01:48、03:02:11、03:03:49和03:18:51分别出现:

NETDEV WATCHDOG: transmit queue 0 timed out

wwan0 TX errors从0增长至1200。

02:06曾发生一次USB断开和重新枚举,随后成功拨号并正常运行约54分钟。
03:01本次掉线发生时没有USB reset或USB disconnect,cdc-wdm0、ttyUSB端口和
5 Gbps USB连接一直存在。

3. 掉线时AT状态

CFUN: 1
CPIN: READY
COPS: 46015,5G SA
C5GREG: 0,1
CGATT: 1
CGACT: 1,0 / 2,0 / 3,0
CGPADDR: 全部为0.0.0.0
CGCONTRDP: 无活动上下文
CEER: No cause information available

4. 服务小区和载波聚合

掉线前02:52:
如需测试,请提供官方建议的锁频命令、恢复默认方法和测试步骤。

5. 请求模组诊断方法

当前附件包含主机dmesg、logread、完整拨号日志和AT快照,但没有模组QLog/RRC日志。
请提供适用于RM520N-GL和R01A07的QLog/QXDM抓取工具、USB端口配置、抓取步骤及
推荐过滤项。希望重点确认:

  • RRC Reconfiguration及SCell增加/释放
  • SCG/CA failure
  • NAS注册和PDU Session建立/释放
  • WDS、DS、RmNet及QMAP状态
  • QMI服务无响应或模组内部子系统重启

完整附件包:
RM520N-drop-2026-08-15_0308-original-raw.zip (171.4 KB)

补充升级 R01A08 后的复现情况。

我已通过 QFirehose 将固件从:

RM520NGLAAR01A07M4G_01.201.01.201

升级至:

RM520NGLAAR01A08M4G_01.206.01.206

升级及重启后模组、USB和AT均正常,但原故障仍可复现,而且本次复现更快。

A08首次复现

  • 03:58:35:注册中国广电46015,5G SA附着正常。
  • 03:58:36:IPv4/IPv6拨号成功。
  • 04:00:53:出现requestQueryDataCall message timeout
  • 04:01:23:第二次查询超时。
  • 04:03:23起:requestSetupDataCall持续超时,无法恢复。

掉线时仍是:

C5GREG: 0,1
CGATT: 1
CGACT: 所有CID均为0
CGPADDR: 所有CID均为0.0.0.0
CGCONTRDP: 无活动上下文
CEER: No cause information available

USB保持5 Gbps,cdc-wdm0和ttyUSB端口存在,AT正常响应。

CFUN恢复及n28/n41现象

之后进行了两次AT+CFUN=1,1测试。

第二次测试捕获到以下过程:

  • 04:38:05:IPv4/IPv6 PDU会话建立,获得IPv4 10.1.147.21。
  • 04:38:17:驻留n28,PCI 358,公网ping 2/2成功。
  • 04:38:32:公网开始无响应,服务小区查询短暂无结果。
  • 04:38:50:驻留变为n41,PCI 154。
  • 04:39:05:首次requestQueryDataCall超时。
  • 04:39:35:第二次超时,IPv4地址和默认路由被撤销。
  • 监测至04:44仍未自动恢复。

主动扫描命令:

 tom_modem -d /dev/ttyUSB2 -c 'AT+QSCAN=3,1' -t 180 -g

扫描到的广电/移动共享小区中:

  n28  ARFCN 155770  PCI 358  RSRP -83  RSRQ -12  SINR 37
  n41  ARFCN 533070  PCI 118  RSRP -109 RSRQ -12  SINR 11

故障时服务小区主要为n41 ARFCN 504990,PCI在154和317之间变化,RSRP约-103至-105 dBm,SINR约0至5 dB。

本次观察显示:n28可正常传输,随后重选到n41时数据立即停止,约30秒后QMI/WDS开始超时。二者时间相关性较强,但仅凭当前记录还不能确认
是基站侧切换问题、模组固件问题,还是QMI/QMAP交互问题。

第二次CFUN后没有新增USB异常或NETDEV WATCHDOG,TX errors仍为0,温度约42至43摄氏度。此前的WATCHDOG均出现在数据会话长期卡死之后,
更像后续表现。

另外,A08当前自动选择并激活:

  Volte_OpenMkt-Commercial-CMCC

请确认该MBN用于中国广电46015是否符合预期。

希望工程师进一步确认:

  1. R01A08是否仍存在n28/n41重选后PDU会话或QMI/WDS卡死的已知问题?
  2. A08版本说明中的“不稳定5G网络情况下网络断开”修复是否覆盖本类问题?
  3. 请提供RM520N-GL适用的QLog/QXDM抓取工具、端口配置和过滤建议。
  4. 请继续确认本机能否由R01迁移至R03,以及可使用的最新R01/R03正式固件。

补充附件:
20-QSCAN-tom_modem-g.txt (2.1 KB)
21-second-CFUN-monitor.txt (16.7 KB)
22-quectel-CM-after-second-CFUN-original.txt (1.4 MB)
23-second-CFUN-final-state-and-AT.txt (12.2 KB)

故障发生后,RM520N 仍保持 5G SA 注册及 PS attach;通过 AT CGACT 仍能成功建立 PDU Session 并获得 IPv4/IPv6 地址,但现有 QMI/WDS 控制路径持续出现 Query/Setup Data Call timeout,Linux QMAP 接口无法建立对应的数据连接。故障范围因此已收敛至 quectel-CM-M WDS client、主机 USB QMI/cdc-wdm/qmi_wwan_q transport 与 RM520N 内部 QMI/WDS service 之间。目前尚未确定具体位于边界哪一侧。QMAP TX/watchdog 属于伴随故障,但现有时间线不能证明其为首发原因。
无线质量、CA/SCell 重配置或其它 PDU/RRC 事件仍可能是触发条件,但目前没有证据证明 n28→n41 小区重选是必要触发条件。

各位移远工程师好,继续补充本帖中 RM520N-GL AA 升级 A08 后的复现和分层恢复测试。

模组已由:

RM520NGLAAR01A07M4G_01.201.01.201

升级到:

RM520NGLAAR01A08M4G_01.206.01.206

升级方式为 OpenWrt/Linux 下使用 QFirehose 进行 R01 同基线升级,未刷写 R03。升级后已完整重启路由器并确认版本,但相同类型的掉线仍然复现。

当前环境

模组:Quectel RM520N-GL AA
IMEI:868371054416223
主控:Banana Pi BPI-R3 Mini
系统:ImmortalWrt 24.10-SNAPSHOT r33648-ec9ef10efc
Kernel:Linux 6.6.133, aarch64
QModem:3.2.0-r2
quectel-CM-5G-M:3.2.0-r1
QMI 驱动包:kmod-qmi_wwan_q 6.6.133.1.5-r1
驱动 runtime:qmi_wwan_q V1.5.0
拨号:单实例 quectel-CM-M,QMI + QMAP
QMAP:mode=1, version=9, muxid=0x81, wwan0_1
运营商:中国广电 46015
APN:cbnet,IPv4v6
网络:5G SA

历史上 autocbnet 都曾复现,本次使用 cbnet

分层恢复测试

故障开始时仍为:

C5GREG=1
CGATT=1
CGACT=0
CGPADDR=0.0.0.0
2_1: up=false, pending=true
QMI QueryDataCall / SetupDataCall timeout

本次不使用 QModem LuCI“重新拨号”,不执行 network restart,从轻到重进行了以下测试:

恢复方式 初始结果 再次失效 USB 变化 模组软件重启
仅重启 quectel-CM-M 05:15:31 已获得 IP,ping 2/2 05:16:00 ping 0/3,不超过 29 秒
qmi_wwan_q unbind/bind 新 QMI client、IP、路由和 ping 均恢复 建链后约 40 秒再次不可达 仅重建 QMI network function,devnum 仍为 4
USB authorized 0 -> 1 10/20 秒时 ping 成功 30 秒开始 ping 失败 ttyUSB/cdc-wdm/wwan 重建,devnum 仍为 4
AT+CFUN=1,1 USB 重新枚举,QMI/IP/路由/ping 恢复 后续仍自然复现 devnum 发生变化

这些结果表明:四种方式都曾重新建立数据连接,但都没有实现持久恢复。CFUN=1,1 在这次测试中维持时间较长,但也不能防止故障再次发生。

需要说明:这是同一次故障中按顺序执行的单次连续测试,每一层并非从完全相同的初始状态独立复现,因此不能仅凭此严格归因。

恢复全部 NR 频段后的再次复现

分层测试后,我已取消 n28 限制、恢复全部 5G NR 频段,然后再次执行 CFUN=1,1

恢复后的当前实例为:

USB device number 6
quectel-CM-M PID 25917

关键时间线(UTC+8):

05:33:45.091-05:33:45.251  WDS/DMS/NAS/UIM/WDA client 建立成功
05:33:46.338                 IPv4 SetupDataCall 成功
05:33:46.643                 配置 IPv4 10.0.2.99/29
05:33:46.646                 建立默认路由
05:38:33.316                 首次 QueryDataCall timeout, err=110
05:39:03.316                 第二次 QueryDataCall timeout
05:41:03.559                 首次 SetupDataCall timeout
05:43:08-06:08              Query/SetupDataCall 持续超时,退避重试不能恢复

从成功建链到首次 QMI timeout 约为 4 分 47 秒。

故障快照:

C5GREG: 0,1
CGATT: 1
CGACT: 1,0
CGPADDR: 0.0.0.0
CGCONTRDP: 无活动上下文
2_1: up=false, pending=true
wwan0 TX errors: 0
wwan0_1 TX errors: 0

无线侧为:

5G SA n41
NCI: 150841002
PCI: 154
NRARFCN: 504990
QCAINFO: 仅 PCC,无 SCC
RSRP: 约 -103/-107 dBm
RSRQ: 约 -11 dB
SINR: 约 4 dB

恢复全部 NR 频段后曾观察到 n28/n41 切换,但切换过程中并非每次都掉线,而且故障快照时只有 n41 PCC、没有 SCC。因此无线/小区变化可能是触发环境,但目前不能证明是 n28/n41 切换或双载波本身直接导致。

本次没有 TX error / NETDEV WATCHDOG

当前 USB device number 6 枚举后,没有新的:

NETDEV WATCHDOG
transmit queue timeout
TX errors
USB disconnect/reset
cdc-wdm removal
qmi_wwan_q unregister

因此本次可以确认:QMI/WDS timeout 与完整数据断联可以在没有 TX error、WATCHDOG 和 USB reset 的样本中出现。TX/WATCHDOG 是部分旧样本的伴随现象,不是所有复现的必要条件。

对 quectel-CM-M 状态的更正

在 05:50 的早期快照中,dial_log 曾暂时停在 05:46 的一个未完整行,当时 /proc 显示主线程等待在 futex_wait_queue,另一线程在 do_sys_poll

后续保存的完整 dial_log 表明,05:48 至 06:08 仍持续有 Query/SetupDataCall timeout 和退避重试记录。因此,不应将早期的“半行+暂时未刷新”解读为已经证明 quectel-CM-M 死锁。

更准确的描述是:

quectel-CM-M 进程仍存活,/dev/cdc-wdm0 仍被打开,客户端持续按退避策略重试 QMI/WDS 事务,但所有 Query/SetupDataCall 仍持续超时,无法自动恢复。

err=110 是 Linux 客户端观察到的 ETIMEDOUT,能够证明事务没有在期限内完成,但不能单独区分是模组未回复、USB/QMI 响应未交付,还是用户态事务状态异常。

目前能够客观确认的内容

  1. A08 下相同类型故障仍然可复现。
  2. 本次最早可观察异常是 requestQueryDataCall timeout
  3. 由于没有从建链时开始连续采样 CGACT?,目前仍不能确定 PDU 先失活还是 QMI/WDS 先超时。
  4. 重启用户态 client、重绑驱动、USB reauthorize 和完整 CFUN 都曾短暂重建数据连接,但都没有阻止再次复现。
  5. 无线环境可能是触发条件,但持续 QMI/WDS timeout 且无法自恢复仍是核心故障表现。

希望移远协助确认

  1. RM520NGLAAR01A08M4G_01.206.01.206 是否存在已知的 WDS data service 无响应、WDS/PDU 状态不同步或 QMI transaction 持续超时问题?
  2. 是否可以提供适用于此版本的官方 Linux quectel-CM、QMI/QMAP 驱动及推荐参数,以便和 QModem 当前组合做 A/B 对照?
  3. 请提供 RM520N-GL Linux 下 QLog/QXDM 抓取方法和推荐 mask,希望同时覆盖 NAS/5GSM、PDU Session、WDS/DS、RmNet/QMAP、RRC/CA 和 USB/QMI。
  4. 当前 46015 自动选择并激活 Volte_OpenMkt-Commercial-CMCC,请确认这是否是 RM520N-GL AA + 中国广电的预期 MBN。
  5. 如果 R01 还有新于 01.206 的正式固件,希望获取最新 R01 固件及 Release Note 继续验证。

本次原始 quectel-CM-M dial_log、完整 dmesg、分层恢复每一步的记录以及 AT/PDU 对照记录已整理为附件。感谢协助分析。

RM520N-GL_A08_layered-recovery_forum-evidence_2026-08-15.zip (178.8 KB)

补充一个可能与小区及时间段有关的现象。

我在同一使用位置不同时间取得了两次QSCAN结果,一次是凌晨一次是6-7点。问题频发期和当前稳定期的无线环境存在明显差异:

  1. 两次均能扫描到同一个n28小区:

    • ARFCN 155770
    • PCI 358
    • NCI 15623D00C
    • 问题期:RSRP -85 dBm,SINR 35 dB
    • 稳定期:RSRP -88 dBm,SINR 33 dB

    因此n28覆盖层一直存在,且信号质量较好。

  2. 问题频发期可见的最强n41约为:

    • ARFCN 533070
    • PCI 118
    • RSRP -108 dBm
    • SINR 12 dB
  3. 稳定期新增了一个明显更强的n41小区:

    • ARFCN 504990
    • PCI 883
    • NCI 15726F004
    • RSRP -94 dBm
    • SINR 26 dB
  4. 问题期约扫描到5个物理NR小区,稳定期约扫描到8个,同时稳定期的n41、n78和n1信号整体更好。QSCAN中46000/46015、46001/46011的成对
    记录应为共享网络标识,并非两个独立物理小区。

另外,一次已经记录到的故障现场服务小区为:

n41 / ARFCN 504990 / PCI 154 / NCI 150841002

而当前稳定期使用或扫描到的是:

n41 / ARFCN 504990 / PCI 883 / NCI 15726F004

两者虽然频点相同,但PCI和NCI均不同,应该不是同一个NR小区/扇区。

故障多数发生在凌晨,因此我怀疑夜间可能存在容量小区节能、发射功率调整、维护、负载均衡或小区重选策略变化,导致终端从一个n41小区切
换到n28或另一个n41小区。也不排除特定小区或特定切换路径存在兼容性问题。

但目前还不能仅凭两次QSCAN证明基站夜间休眠或关闭。即使网络侧发生小区关闭或切换,正常终端理论上也应当重新选择仍然可用且信号良好的
n28小区并恢复数据业务。

因此目前倾向于两阶段过程:

网络侧小区变化、重选或PDU释放
→ 触发模组异常
→ 模组注册和附着仍正常,但PDU失活
→ QMI/WDS的QueryDataCall和SetupDataCall持续超时
→ 无法自行恢复,最终表现为长时间断网

希望工程师协助判断:

  1. RM520N-GL A08是否存在小区重选、n41/n28切换或网络释放PDU后,QMI/WDS无法自动恢复的已知问题?
  2. 是否需要抓取QXDM/Quectel诊断日志,才能确认故障前是否发生小区关闭、重选、RRC释放、PDU Session Release或网络侧拒绝?
  3. 是否可以从模组诊断日志中确认故障是否总是与某个NCI、PCI或特定切换路径相关?

补充一次正常位置下的受控PS detach/attach测试结果。

测试环境仍为:

模组:RM520N-GL AA
固件:RM520NGLAAR01A08M4G_01.206.01.206
拨号:quectel-CM-M,QMI/QMAP
驱动:qmi_wwan_q V1.5.0
APN:cbnet,IPv4v6
网络:中国广电46015,5G SA

测试前网络正常,CID 1处于active状态,IPv4/IPv6均可访问公网,wwan0和wwan0_1无TX errors或WATCHDOG。

首先尝试只释放CID 1:

AT+CGACT=0,1

模组返回:

ERROR

CID 1没有失活,网络保持正常。因此这一步没有成功模拟单独PDU释放。

随后执行标准PS detach/attach:

AT+CGATT=0
等待约17秒
AT+CGATT=1

CGATT=0返回OK后立即观察到:

CGATT=0
CID 1 inactive
IPv4/IPv6地址撤销
WDS IPv4ConnectionStatus: DISCONNECTED
WDS IPv6ConnectionStatus: DISCONNECTED
wwan0 link down
执行CGATT=1后:

约1秒后wwan0 link up

quectel-CM-M一直保持原PID 11571
没有重新建立用户态QMI client
没有重绑qmi_wwan_q
没有USB重新枚举
没有执行CFUN
没有新增QMI timeout
没有TX errors或NETDEV WATCHDOG

测试前后/etc/config/qmodem和/etc/config/network的SHA-256一致,uci changes为空,没有产生永久配置修改。

这次测试建立了一个正常恢复对照:当RM520N的WDS服务能够正常返回DISCONNECTED时,原quectel-CM-M、QMI/QMAP驱动及OpenWrt网络层可以自
动处理PDU失活并恢复连接。

这与自然故障不同。自然故障中出现的是:

requestQueryDataCall message timeout
requestSetupDataCall message timeout
err=110 / ETIMEDOUT

ETIMEDOUT是主机等待QMI事务完成超时,并不是模组返回的DISCONNECTED状态。

因此,本次测试说明普通、正常完成的PS/PDU释放本身不会必然造成持续卡死。自然故障的关键差异应是QMI/WDS事务没有正常完成。

希望移远工程师确认:

  1. QMI持有CID 1时,AT+CGACT=0,1返回ERROR是否属于预期行为?
  2. A08是否存在WDS事务长时间无响应,而AT、USB和5G注册仍正常的已知问题?
  3. 下一次自然复现需要抓取哪些QLog类别和mask,才能区分模组未回复与USB/QMI传输异常?

01-before-test-baseline.txt (9.5 KB)
02-controlled-CGACT0-PDU-release-monitor.txt (8.6 KB)
03-controlled-CGATT-detach-attach-monitor.txt (7.2 KB)
04-post-wifi-reconnect-final-state.txt (53.9 KB)

各位移远工程师好,更新一下迁移至 R03A04 后的刷写及测试情况。

模组已由:

RM520NGLAAR01A08M4G_01.206.01.206

升级至:

RM520NGLAAR03A04M4G_A0.303.A0.303

升级使用 Linux/OpenWrt 下的 QFirehose 完整包。第一次刷写过程中 SSH 连接中断,无法确认该次流程是否完整结束;随后重新执行了一次完整刷写,29 个文件 MD5 校验全部通过,Sahara 和 Firehose 阶段完成,所有分区写入均返回 ACK,进度达到 100%,最终
提示:

Upgrade module successfully.

模组重启后能够正常枚举,并确认固件版本已经更新为 R03A04。

启动初期曾短暂出现 QmiWwanInit message timeout,当时模组的 QMI 服务尚未完全就绪;随后初始化和拨号自动完成,没有持续超时,也没有人工重启模组或拨号进程。

测试环境基本保持不变:

主控:Banana Pi BPI-R3 Mini
系统:ImmortalWrt 24.10,Linux 6.6.133
QModem:3.2.0-r2
驱动:qmi_wwan_q V1.5.0
拨号:quectel-CM-M,QMI + QMAP
运营商:中国广电 46015
APN:cbnet,IPv4v6
网络:5G SA

升级后先进行了两次短时间 QLog 测试:

  • 第一次约 808 秒,观察到一次约 235 ms 的 service unavailable 和约 174 ms 的 bearer deregister/register,随后自动恢
    复,主机侧没有出现断网。

  • 第二次约 734 秒,没有出现 service/bearer 异常,也没有出现 QMI timeout。

之后使用 T5 filter 进行了连续一小时的正式采集,时间为:

2026-08-17 02:49:59 至 03:49:59(UTC+8)

主机侧结果如下:

IPv4/IPv6 连通性:695/695 正常
netifd/接口状态:全程保持 up
AT 采集记录:3228/3228,返回码全部为 0
CGACT=1,1:719 次
CGATT=1:119 次
wwan0_1 RX:增加 786,671,799 bytes
wwan0_1 TX:增加 85,352,292 bytes
RX/TX error 增量:0
RX/TX drop 增量:0
温度范围:49 至 59 摄氏度

测试期间观察到 n28 和 n41 多次变化,其中 n28 记录 148 次、n41 记录 90 次,数据业务始终正常。

QLog 共选取 190 个连续的 QMDL2 分片进行分析,原始数据约 1.59 GB,解码得到约 529 万帧。以下关键故障标志均为 0:

QmiWwanInit message timeout
requestQueryDataCall timeout
requestSetupDataCall timeout
err=110
service unavailable
WAN DS Bearer Deregister/Register
USB disconnect/reset
QMAP unregister
NETDEV WATCHDOG
接口 down
CID/PDU 失活

QLog 中仍可见以下模组内部信息:

CTCC_FAIL! get mode fail
DSQMI_FAIL! eType:10 NOT support
DSQMI_FAIL! eType:7 NOT support
NB_ABORT
RX IU Async Reset

但这些信息没有伴随 QMI timeout、PDU 失活、接口 down 或公网连通性失败。目前只能将其视为模组内部基线信息或无线重配置相关指标,尚不能单独判定为故障。

与此前 R01A07/R01A08 下自然复现的持续 QueryDataCall/SetupDataCall timeout 相比,R03A04 在目前的两个短样本及一小时连续测试中均未复现原故障,当前观察结果较好。

不过旧故障可能与夜间特定小区、重选路径或较长运行时间有关,过去也曾在运行数小时后才出现,因此目前还不能仅凭一小时测试确认问题已经彻底修复。我会继续进行通宵或更长时间的连续 QLog 和主机侧日志采集。

希望移远工程师协助确认:

  1. R03A04 是否包含与 QMI/WDS transaction timeout、PDU Session 异常恢复或不稳定 5G 网络断开有关的修复?
  2. 启动阶段短暂出现 QmiWwanInit message timeout,随后自动恢复,是否属于 QMI 服务尚未就绪时的正常现象?
  3. 上述 CTCC_FAIL、DSQMI_FAIL、NB_ABORT 和 RX IU Async Reset 在 R03A04 中分别表示什么,是否需要重点关注?
  4. 当前使用的 T5 filter 是否足以覆盖 NAS/5GSM、PDU Session、WDS/DS、RmNet/QMAP、RRC/CA 和 USB/QMI?
  5. 当前自动激活的 Volte_OpenMkt-Commercial-CMCC 是否是 RM520N-GL AA 使用中国广电 46015 时的预期 MBN?

如有需要,我可以继续提供一小时测试的主机日志、AT 采样、QLog 统计报告以及对应时间段的原始 QMDL2 文件。