Hi,
Small note: I used ChatGPT to help structure this post, but all tests and outputs below are from my own troubleshooting. I have spent most of the day trying to find a solution or workaround for this SMS sending issue.
We are experiencing SMS sending issues on multiple Teltonika routers. The issue does not affect all routers, but it is reproducible on several units and different router/modem firmware combinations.
I am mainly looking for a practical solution or workaround, because SMS sending is needed in our setup.
Symptoms
Sending SMS from the WebUI hangs on:
Waiting for response from the modem...
CLI also fails:
gsmctl -D -S -s "00316XXXXXXXX test"
Result:
GSMCTL modem[0]: Debug mode enabled
GSMCTL Modem id: 0
GSMCTL modem[0]: Calling Send SMS
GSMCTL modem[0] SMS: Checking input format
GSMCTL modem[0] SMS: Calling LGSM SEND SMS
[gsmctl_send_sms:22] error: ERROR: Failed to parse response
UBUS also fails:
ubus -t 20 call gsm.modem0 send_sms '{"number":"00316XXXXXXXX","text":"test","validate":false,"async":false}'
Result:
Command failed: Request timed out
Using async:true does not solve the issue either. Sometimes it returns immediately without output, but the SMS is not sent and/or the SMS/AT channel becomes unresponsive afterwards.
Modem/network checks
On an affected RUT951, the modem itself appears to be registered correctly:
ubus call gsm.modem0 exec '{"command":"AT"}'
# OK
ubus call gsm.modem0 exec '{"command":"AT+CPIN?"}'
# +CPIN: READY
ubus call gsm.modem0 exec '{"command":"AT+CREG?"}'
# Registered
ubus call gsm.modem0 exec '{"command":"AT+COPS?"}'
# 20416
ubus call gsm.modem0 exec '{"command":"AT+CSQ"}'
# +CSQ: 18,99
ubus call gsm.modem0 exec '{"command":"AT+CSCA?"}'
# +31624000000
So SIM, registration, signal and SMSC appear to be OK.
Important observation
On an affected RUT951, SMS-related AT commands work before sending SMS:
ubus -t 15 call gsm.modem0 exec '{"command":"AT+CMGF=?","timeout":10}'
# +CMGF: (0-1)
ubus -t 15 call gsm.modem0 exec '{"command":"AT+CMGF=1","timeout":10}'
# OK
ubus -t 15 call gsm.modem0 exec '{"command":"AT+CSMS=1","timeout":10}'
# +CSMS: 1,1,1
But after calling send_sms, the SMS/AT channel becomes unresponsive:
ubus -t 10 call gsm.modem0 send_sms '{"number":"00316XXXXXXXX","text":"test","validate":false,"async":true}'
After that, commands such as these start timing out:
AT+CMEE=2
AT+CMGF=?
AT+CSMS?
AT+CMGF=1
A modem reset or power cycle is then needed to recover.
Affected combinations
| Type | RutOS firmware | Modem firmware live (gsmctl -y) |
|---|---|---|
| RUTX50 | RUTX_R_00.07.22.1 |
RG501QEUAAR12A11M4G_04.300.04.300 |
| RUTX50 | RUTX_R_00.07.23.1 |
RG501QEUAAR12A11M4G_04.300.04.300 |
| RUT950 | RUT9_R_00.07.06.21 |
EC25ECGAR06A04M1G_01.004.01.004 |
| RUT951 | RUT9M_R_00.07.23.1 |
SLM750-V_4.0.12_EQ101 |
| RUT951 | RUT9M_R_00.07.23.1 |
SLM750-V_4.57.19_EQ101 |
| RUT950 | RUT9_R_00.07.06.21 |
EC25ECGAR06A04M1G_01.004.01.004 |
| RUT950 | RUT9_R_00.07.06.21 |
EC25ECGAR06A04M1G_01.004.01.004 |
Working combinations
| Type | RutOS firmware | Modem firmware live (gsmctl -y) |
|---|---|---|
| RUTX50 | RUTX_R_00.07.22.1 |
RG501QEUAAR12A11M4G_04.202.04.202 |
| RUTX50 | RUTX_R_00.07.22.1 |
RG501QEUAAR12A11M4G_04.202.04.202 |
| RUTX50 | RUTX_R_00.07.22.1 |
RG501QEUAAR12A11M4G_04.300.04.300 |
| RUTX14 | RUTX_R_00.07.22.1 |
EG12EAPAR01A15M4G_01.202.01.202 |
| RUTX14 | RUTX_R_00.07.22.1 |
EG12EAPAR01A15M4G_01.202.01.202 |
| RUTX14 | RUTX_R_00.07.22.1 |
EG12EAPAR01A13M4G_01.001.01.001 |
| RUT950 | RUT9XX_R_00.06.09.5 |
EC25EFAR02A08M4G |
| RUT950 | RUT9_R_00.07.06.20 |
SLM750_4.0.6_EQ101 |
| RUTX50 | RUTX_R_00.07.21.2 |
RG501QEUAAR12A11M4G_04.300.04.300 |
| RUTX50 | RUTX_R_00.07.22.1 |
RG501QEUAAR12A11M4G_04.202.04.202 |
| RUTX50 | RUTX_R_00.07.22.1 |
RG501QEUAAR12A11M4G_04.202.04.202 |
Already tested
- WebUI SMS sending
gsmctl -S -subus call gsm.modem0 send_smsasync:falseandasync:true- Number format
0031... - Number format
+31... AT+CMGF=1AT+CSMS=1AT+CMEE=2- SMSC check with
AT+CSCA? - Factory reset on one affected RUT951
- Downgrade on one affected RUT951 to
RUT9M_R_00.07.16.3_WEBUI
The issue remains after factory reset and downgrade.
Question
Has anyone seen this before, and is there a known solution or workaround?
The main thing I need is a way to make SMS sending reliable again. At the moment, both WebUI SMS sending and CLI/UBUS SMS sending fail on the affected routers.
Which logs or debug commands should I collect before and after the send_sms timeout to help diagnose this?
Most importantly: what can I try to actually fix or work around this?
Thanks in advance.
Kind regards,
Jelle