A Client has a number of Fastrack (M1306B and Supreme) units in the field which are not responding to SMS.
The message delivery notifications show that the network is delivering the message to the unit, but the unit is not reacting.
I have not been able to reliably reproduce this situation in the lab, but I’m sure I have seen it happen (when I’ve been in the middle of something else, and haven’t been able to stop to investigate).
It seems that messages are, indeed, being delivered to the unit - but not passed to the subscribed SMS Handler. When this has happened, the messages have been stored on the SIM - again, this shows that they were delivered to unit, but were not passed to the SMS Handler!
Has anyone else seen this?
Is it a known bug?
And does anyone know what causes it - and, more importantly, how to recover afterwards?!
(at the moment, a restart seems to be the only recovery)
As I said, I haven’t been able to reliably reproduce this situation in the lab, but I’m sure I have seen it happen (when I’ve been in the middle of something else, and haven’t been able to stop to investigate).
In those situations, the handlers have been happily receiving SMS, but then it just stops.
I have not done anything to specifically disable (or enable) the +CMTI notifications - so what could make them “just stop”?
I think I’ve had the same problem on a couple of units. It looks like OpenAT randomly unsubscribes from SMS adl. SMSs are still received by the unit, but the the SMS handler is never called. One solution is to regularly un-subscribe and resubscribe to the SMS adl (I know, this is a work around and not a solution!), or just reset the processor completely and resubscribe to the SMS adl. Would be nice to find out what is causing the problem in the first place!
I’ve worked around this by periodically calling AT+CMGL=“ALL” and analyzing the response. It’s hack-y, but it works. When the application discovers an unprocessed message, it reads in the contents, deletes it from the SIM, and feeds the message into my application processing framework. It also works great for getting messages that get sent to the SIM when the application isn’t running (which happens all the time during development).
Primarily what I have observed is that if a message is sent to the SIM (usually when I am not running the application but an SMS arrives while the device is on), then subsequent messages are also written to the SIM. I expected the former behavior (if no application is registered to receive the SMS, it should go to the SIM, default behavior). What I did not expect, and in fact found confusing, is that when I start my application and it registers to receive SMS messages, it will not be notified of new messages if I do not first clear off the SIM - they are instead blindly written to the SIM. Whether this is a bug or intended behavior on the part of OpenAT is unknown, but it is definitely repeatable behavior.
My solution has been to read the SIM on application boot up and clear it off. After that, I do not normally miss messages, but since it is not outside the realm of possibilities, I periodically rescan the SIM just in case.
I would like to know from Sierra exactly why this behavior happens, and if it is intended or a bug, so I can plan appropriately for future implementations.
My application does clear the SIM on startup as a matter of course - so, if this ever happens on one of my units, I would never notice!
If it’s intended behaviour, then it should certainly be documented as such!
Yes, I do that.
Neither do I - normally!
Unfortunately, on the couple of occasions when I think I’ve seen it in the lab, I haven’t been in a position to investigate.
There are some issues in the field where the symptoms seem to suggest that this is happening - but, again, it has not been possible to investigate these properly.
My suspicion is that, somehow, ADL manages to “miss” one notification - and, once that has happened, it will miss all further notifications.
If I (or anyone else) could confirm this, we might have a better chance to investigate what causes it to “miss” that first one and/or why that then causes all subsequent messages to be missed…
Again, if the possibility is known, it should be documented - but I can’t see how that could possibly be intended behaviour!
I don’t think SiWi do themselves any favours by ignoring issues like this!
Yes, problem exist, and before i think it is caused by flooded sim (sms storage already overflowed before sim inserted into module). Clearing the sim and resetting (but not just resetting) resolves the problem.
To the point. Yesterday I accidentally witnessed a situation where after successfully receiving and processing SMS-message handler as usual returns FALSE (SMS should not be forwarded), but module decided to save SMS on flash.
Really, i dont know if this result in further handler error, because after detecting unauthorized SMS on SIM storage my application at the same moment perform storage erase and module reboot…
That might be one cause, but it is not the only cause - and certainly not the one that I think I have (I ensure that the SIM is cleared on application startup, and do not store received messages to the SIM).
Well, ADL should not miss incoming SMS messages - but it is now well-attested that it does!
Therefore, something is certainly wrong, and it may well be that the fault lies in adl_atUnSoSubscribe…
The fact that gsav has reported that other unsolicited notifications (RING, +CLIP, NO CARRIER) also stop working when the problem manifests would tend to point the finger rather strongly at adl_atUnSoSubscribe
See: forum.sierrawireless.com/viewtop … ibe#p23269
Hi
To add to all your observations this can be reproduced consistently in an open at application.
just subscribe to a 1sec timer in the adl and then start to send an SMS from it say every 15 to 20 sec to let the sms service complete the task, it is observed that only the first sms is sent and the remaining sms sending calls fail. From this point onwards it can be observed that the sms reception by the adl also stops.
On checking the sms handle value it will be returned as -8 which means that the SMS handle is in bad state and this continues until the reset.
after a reset if the same situation is faced again by the application it will again enter the same state.
better avoid calling smssend api from very low value timer handlers in the application( as it some how tends to put the sms handle in bad state) instead would prefer to have a seperate function being called to send sms.
ofcorse this one of the case there can be similar other cases which needs to figured out by closely observing the application.
