LTE Is Connected, but SMS Fails: Troubleshooting Industrial Router Alerts and Commands
The router can reach a server, but an SMS status query from your phone gets no reply. Or the device receives messages, yet its alerts never arrive. In either case, an LTE connection is not proof that SMS is working.
Test reception, transmission, command processing and the action result separately to find where the failure occurs. A working data connection answers only the data-connectivity question. SMS also depends on the SIM plan, the current carrier network, the cellular module and the router's software configuration. Cradlepoint's SMS documentation requires an SMS-capable module with SMS enabled, and notes that carriers do not guarantee delivery of messages or replies.
The sequence below covers SMS sent and received through the router's SIM. If a cloud platform sends alerts through an SMS provider instead, inspect the platform event, the send request and the provider's receipt. That is a different path from the device's own SMS service.
First, identify the step with missing evidence
After a phone sends a command, the message must reach the device and pass authorization and parsing before the device can act and reply according to its configuration. Follow that sequence to narrow down what “no reply” actually means.
What you observe | What you can confirm so far | Where to look next |
|---|---|---|
LTE is online, but you cannot find the test SMS on the device | The data connection works; SMS reception is not yet confirmed | SIM-plan and roaming support, reception service, module and incoming-message records |
An incoming-message record exists, but the command does not run | The message reached a visible stage of inbound handling | Allowed senders, authentication, command format and processing logs |
The device receives SMS, but a direct outbound test fails | Reception works; the outbound path still has a problem | Sending permissions, destination number, module response and carrier restrictions |
An ordinary SMS can be sent, but an alert is not sent | The basic outbound path works | Whether the event occurred, the rule is enabled and the recipient is correct |
The action occurred, but the phone received no reply | The action and reply have different outcomes | Reply configuration, reply-send records and reception on the phone |
Not finding a message may simply mean the current interface does not show its record. Check which logs the device provides, whether it retains the original text and whether command messages are removed after processing before concluding that reception failed.
Step 1: Check the SIM, network and device combination
Record the router model, cellular-module model, router and module firmware versions, active SIM, home carrier, serving carrier and roaming status. On a dual-SIM device, confirm which SIM the test uses.
Ask the carrier specific questions: Does this SIM support both incoming and outgoing SMS? Is that service supported on the current roaming network? Are there number, plan or device-compatibility restrictions? Give the device vendor the same deployment details and ask about SMS support for that module and firmware on that network. Let this evidence determine whether to investigate IP Multimedia Subsystem (IMS) registration or carrier configuration; do not copy settings from another device without checking their relevance.
If the SIM receives SMS in a phone, that confirms operation in that phone under those network conditions. It does not rule out a router-side problem. A Quectel EG25-G roaming report describes a similar symptom. Its follow-up matters: the author reported that SMS recovered before the new firmware was flashed, while the original cause remained unclear. The report is not evidence that a firmware update fixed the fault.
If data connectivity also fails, first check the basic connection using the industrial router troubleshooting and repair guide, then return to the SMS tests.
Step 2: Test reception and transmission with ordinary SMS
Start with a short message that will not trigger a device action, such as TEST-001. Confirm that it does not match an existing automation rule and that the phone sends it as SMS. Record the time, time zone and sender number, then look for that message on the device.
Send the first test from the phone to the device and inspect its reception log or inbox. Then use a method supported by the device documentation to send an ordinary SMS from the device to the test phone. Record the two tests separately. “The device received it” is not evidence that the device can also send. For the outbound test, retain the device's returned status or error and check whether the phone actually receives the message. Acceptance of a send request is not proof of delivery to the recipient.
If reception fails, check whether SMS reception is enabled, which module or interface is selected and the state of message storage. For example, the MikroTik RouterOS SMS manual documents reception settings, port selection, storage-full conditions that prevent reception and supported SMS encoding. These are examples of items to investigate, not settings or defaults shared by every brand. Preserve the records needed for diagnosis before clearing storage.
Once a short message passes, test the Chinese text, long messages or special characters used in the actual alert. This separates basic send-and-receive faults from message-format problems. Check the current device documentation for its encoding and multipart-message support.
Step 3: Check command authorization, parsing and the actual action
After ordinary incoming and outgoing SMS pass, test a read-only status query explicitly supported by the device documentation. Check the permitted sender number, including the country code and the format the device actually recognizes. Check authentication details, letter case, spaces and command syntax. Do not remove sender restrictions or authentication to make a test work.
Then check three distinct outcomes: whether the device accepted the command, whether the action succeeded and whether the reply arrived. If processing logs are available, tie each outcome to the same test. If the device does not provide that evidence, record the outcome as “not confirmed from the device side,” rather than marking it successful.
Test reboot, network-switching or other state-changing commands in a maintenance window, with a way to restore the site connection ready. Record the actual state before and after the command. If there is no reply, check whether the action already occurred before deciding to retry. Repeated reboot commands may interrupt a device that has already recovered.
For SMS alerts, test the trigger rule separately. Use a supported test function or a controlled condition to trace “event occurs → rule matches → send requested → recipient receives.” A successful manual send verifies only part of that chain.
Step 4: Test which connectivity failures SMS can cover
If SMS is intended for remote recovery, test it against the failure it is supposed to address. Cradlepoint's documentation describes SMS access that may remain available without an active data connection. That does not mean SMS covers every reason a device goes offline.
With someone able to restore the site connection, record SMS behavior during normal data connectivity, a controlled interruption of the data connection and recovery after a reboot. SMS still depends on device power, the cellular module and available carrier service. It may share those failure points with the data service. A data-interruption test is not a substitute for a recovery plan for power loss or module failure.
For each test, record at least the device and firmware combination, SIM and network, test content, reception evidence, transmission evidence, action result and reply result. Repeat the affected tests after changing the SIM, roaming network or relevant firmware.
Finish with a finding that lets the next person continue: “Reception verified; sending failed with the following error,” or “Ordinary incoming and outgoing SMS work; the alert rule did not trigger.” Give support that failed path together with the device, SIM and network details. The next diagnostic step is then much clearer.
Frequently asked questions
If an industrial router can access the internet, should it also be able to send SMS?
You cannot infer that from data connectivity alone. Confirm SMS support for the plan and current network, check the module and router configuration, and test reception and transmission separately. A working data connection cannot replace those results.
Why can the router receive SMS but not send it?
Send a short test message independently and check the destination number, sending permissions and the device's returned result. If an ordinary message can be sent but an alert fails, investigate the trigger conditions and alert rule rather than continuing to check reception settings alone.
Does a missing reply mean the remote command did not execute?
Not necessarily. The command may have executed while the reply was disabled, not sent or not delivered. Confirm the action through device logs, operating state or an observation at the site. In particular, do not repeatedly resend disruptive commands while the state is unknown.
Can a firmware update fix an SMS fault?
Release notes, the vendor's assessment or validation of the current deployment combination must support that approach. Preserve the fault records and existing configuration first, then follow the vendor-supported process. A community report that SMS “later recovered” does not establish that an update caused the recovery.
