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)

故障发生后,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)