RG500Q-EA — IPv6-only and dual-stack always fail (QMI call_end_reason 241), IPv4 works (Orange Poland)

IoT Modules 5G Module
1

Setup

  • Module: Quectel RG500Q-EA, firmware RG500QEAAAR13A01M4G

  • Carrier: Orange Poland (MCC 260, MNC 03), LTE / 5G-NSA

  • Host: OpenWrt — driver qmi_wwan_q V1.2.9, QMAP enabled (qmap_mode=1, muxid 0x81), connection manager quectel-cm (QConnectManager Linux V1.6.5)

  • SIM is SIM_READY, PIN disabled

What works

  • IPv4-only on APN internet (IPv4 PDP) connects and works normally.

What fails

  1. IPv6-only — APN internetipv6, IPv6 PDP. quectel-cm always fails at requestSetupDataCall: QMUXResult = 0x1, QMUXError = 0xe call_end_reason = 1, call_end_reason_type = 2, call_end_reason_verbose = 241 (INTERFACE_IN_USE_CONFIG_MATCH) Consistent, regardless of profile/CID/auth/mux.

  2. Dual-stack (separate IPv4 + IPv6 PDN) — the IPv4 context connects and gets an address, but the IPv6 context fails with the same 241; a second quectel-cm then issues requestDeactivateDefaultPDP and tears down the working IPv4 context.

Observation: the network appears to auto-activate the IPv6 context (CID2 internetipv6, +CGACT: 2,1 with a valid IPv6 via AT+CGCONTRDP) on every attach, even when not configured locally — so setup seems to hit a context that is already in use (241). AT+QCFG="ResetFactory" helps only temporarily and is irreversible. The same physical SIM works fine for IPv6 in a ZTE MF286D (raw-ip, no QMAP).

Questions

  1. Why does IPv6-only (APN internetipv6) consistently fail with call_end_reason_verbose 241, while IPv4 on the same SIM and modem works?

  2. Why does dual-stack (separate IPv4 + IPv6 PDN contexts) fail in the same way?

  3. Where are the current official sources for quectel-cm (QConnectManager Linux) and the kernel modules (qmi_wwan_q / QMAP)? We want to confirm we are not running outdated versions.

We can provide full logs (quectel-cm verbose output, AT traces, dmesg) on request.

2

Hi @secam7
Do you confirm the APN and IPtype is correct during your test?
Use AT+CGDCONT or AT+QICSGP to confirm.

3

@silvia Yes — APN and IP type are confirmed correct by AT:

AT+CGDCONT?
+CGDCONT: 1,“IPV6”,“internetipv6”,…
+CGDCONT: 2,“IPV6”,“internetipv6”,… (← network-provisioned, +CGACT: 2,1 active even when not configured locally)
+CGDCONT: 3,“IPV4V6”,“sos”,…

AT+CGCONTRDP=2 returns a valid global IPv6 address, gateway and DNS — i.e., the bearer is already up on the network side before quectel-cm runs.

quectel-cm -6 -n 1 -s internetipv6 internet internet pap -i wwan0 -b then hits:
requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
call_end_reason 1 / type 2 / verbose 241 (INTERFACE_IN_USE_CONFIG_MATCH)

This is consistent with the modem refusing to start a new IPv6 PDN because one with the same config is already active (auto-provisioned by the network).

We tried AT+QCFG=“ResetFactory” — IPv6 worked briefly, then 241 returned after re-attach (network re-provisions the context). The same SIM works fine for IPv6 on a ZTE MF286D (raw-ip, no QMAP, uses uqmi).

Questions:

  1. Is there a way for quectel-cm to “attach to” an already-active IPv6 PDN (auto-provisioned by the network) instead of trying to create a new one and getting 241? The IPv4 path handles this gracefully — IPv4 setup attaches to the active default bearer.
  2. Are there newer official sources for quectel-cm and qmi_wwan_q than V1.6.5 / V1.2.9 with IPv6 fixes for this scenario?