Hi everyone,
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, with residual congestion through June 29.
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:
- EC25EUGAR06A05M4G_BETA1108_01.005.00.000 (Beta A05)
- EC25EUGAR06A08M4G_01.200.00.000 (A08)
No correlation between firmware version and whether a device is affected — both versions appear in offline and working devices alike.
Workaround
A SIM swap (swapping SIMs between two devices and swapping back) forces a modem re-initialization and restores connectivity. This worked at most sites.
Questions
- Is there a known bug in the Quectel EC25-EU firmware (A05/A08) related to “limited service” / loss of network registration after network events?
- What is the latest stable modem firmware for the EC25-EU module used in TRB140?
- How do you update the modem firmware on TRB140 — is this possible via the WebUI, CLI, or does it require a factory procedure?
Any insights appreciated — especially if others have seen similar behavior after carrier-side outages.
Thanks
Mike
Is there any internal firmware or modem function, block or restriction that prevents the device from reconnecting after such outage? It seems like it “blocks” the SIM or the connection, although all network related blocks and issues have been resolved, even after power-cycles.
Only a SIM swap resolves the issue. It can directly connect with the new SIM and when we put back the old SIM it directly connects as well and works properly.
Hello Teltonika,
it would be nice to get an answer to the following points:
- What is the latest stable modem firmware for the EC25-EU module used in TRB140? Can you provide the latest version?
- How do you update the modem firmware on TRB140?
Thanks,
Mike
Hello Teltonika Support,
In addition to the described problems, we detected that some of the affected TRB140 went offline after a scheduled reboot. This affects our devices with
modem firmware version: EC25EUGAR06A05M4G_BETA1108_01.005.00.000
and IMEI starting with 865546…
We have 4 devices that cannot reconnect. Is there any persistent information in the modem’s memory, like a corrupt mobile session, that can cause this behavior?
Hence, I would like to update the firmware of the Quectel modem of TRB140. Please provide the latest firmware file and instructions.
Thanks
Mike
Update — root cause narrowed to persistent modem NV, and it is firmware-independent
We took one affected TRB140 (Quectel EC25-EU, IMEI TAC 865546) to the bench and
reproduced the fault reliably: after every reboot the modem stays in “limited service”
(CEREG: 2,2 / CGATT: 0) on a strong Telekom cell, then finally attaches after ~23 minutes.
AT+CEER returns 0 (no network reject) — a very slow LTE attach after reboot, not a
radio/coverage issue. With our connection watchdog rebooting before those 23 minutes,
the device loops and stays offline.
Key finding: we flashed the same unit through A05 (beta) → A09 (01.200) → A11 (01.302).
The behaviour is identical every time. A firmware update does NOT fix it.
This points to something stuck in the modem’s persistent NV/EFS (the LTE/EPS registration
context): it survives reboots, full power-cycles and even a complete modem firmware flash
(the update rawprogram preserves the EFS2 partition). Only physically removing/reinserting
the SIM clears it — but it returns on the next reboot.
Our question: how can we clear/reset this modem NV/EFS context on a TRB140 — ideally
remotely or via an AT/QMI command (a specific NV item, or a supported modem NV reset) —
WITHOUT wiping calibration/IMEI? AT+QNVFR/QNVW are rejected on this build. Is there a
known command or procedure?
Also: is there a known behavioural difference between IMEI TAC 865546 and 864303 units?
Our 864303 devices are unaffected.