we’re running a fleet of Teltonika TRB140 LTE gateways on the Deutsche Telekom M2M network across multiple industrial sites in Europe. On June 28, 2026, Telekom had a nationwide M2M network outage. Telekom confirmed the outage was resolved the same evening.
Since then, 10 out of 106 devices have been stuck offline and won’t recover on their own.
Symptom
Affected devices show:
Operator state: “limited service”
Modem in permanent network search — never connects
No self-recovery, even days after the outage or power cycles
Hardware & firmware
Device: Teltonika TRB140
Modem: Quectel EC25-EU
Affected devices run two different modem firmware versions:
A new SIM card forces a modem re-initialization and restores connectivity. This worked at all sites. However, after another power-cycle the device remains in the same offline status.
Is there a known bug in the Quectel EC25-EU firmware (A05/A08) related to “limited service” / loss of network registration after network events?
Please provide the latest firmware and instructions how to upgrade.
Any insights appreciated — especially if others have seen similar behavior after carrier-side outages.
I remembered that I sent you latest firmware of EC25EUGAR06 through your email. Can you help to check and flash to the latest firmware and feedback the update.
We’ve successfully installed the new firmware version. This should prevent the modem from storing invalid session context in the persistent memory according to the change notes.
One piece of context first: the modem runs inside a Teltonika TRB140, so we cannot flash your package directly — the EC25 firmware has to be repackaged into Teltonika’s RUTOS modem_update format and applied through the router. We rebuilt that package ourselves from the files you sent; the modem afterwards reports EC25EUGAR06A11M4G_01.302 correctly.
On the abnormality: flashing the latest modem firmware on an already-affected unit did not clear the fault. After each reboot the modem still went to “limited service” and took ~23 min to attach — identical to before the update.
What reliably does clear it: physically removing and reinserting the SIM (a SIM cross-swap works too). In the lab, a full RUTOS reflash cleared it as well. Both have one thing in common — a complete modem re-initialization — which is what finally drops the stale session context from NV. A modem-FW update alone, on top of the already-corrupted context, was not sufficient.
So the new firmware looks useful as prevention (a modem that never stored the bad context stays clean), but it did not repair a modem already in the bad state.
I think this could be related to hot swap detection in the configuration. You can try by running AT+QSIMDET=1,0 for low level detection and AT+QSIMDET=1,1 for high level detection