AT error handling

AT error handling

[Mattias =?unknown-8bit?q?M=C3=A5nsson?=]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

I have a problem with a modem and USB suspend where the OK from some AT commands are sometimes lost. This will be corrected by the vendor, but it got me wondering how Ofono handles problems like this. As I can see, there is no timeouts for AT commands that doesn't respond? Or have I missed something? It seemed to me that Ofono got stuck in the initial setup forever if this happens. In my experience you can't trust that a modem will always respond and in that case it might be good to have a timeout and reset the modem or something like that.


/Mattias

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1058 bytes --]

Re: AT error handling

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hi Mattias,

On 05/09/2018 03:28 AM, Mattias Månsson wrote:
> I have a problem with a modem and USB suspend where the OK from some AT 
> commands are sometimes lost. This will be corrected by the vendor, but 
> it got me wondering how Ofono handles problems like this. As I can see, 
> there is no timeouts for AT commands that doesn't respond? Or have I 
> missed something? It seemed to me that Ofono got stuck in the initial 

This question comes up periodically.  The answer is that GAtChat does 
not have a built-in mechanism for AT command timeouts.  There are 
several reasons for this:

1. It is hard to pick a default timeout that will work in most cases. 
Some commands can take a large amount of time (e.g. COPS operator discovery)
2. If a timeout does trigger, there's really no way to recover reliably. 
  While ITU v.250 does mention the possibility of command cancelation, 
most firmware simply does not support this or only supports a subset of 
commands where this can work.  And even then the behavior can vary 
wildly between implementations.

> setup forever if this happens. In my experience you can't trust that a 

Yep

> modem will always respond and in that case it might be good to have a 
> timeout and reset the modem or something like that.

There's nothing stopping you from implementing a heart-beat check or 
similar logic inside the modem driver itself.  However, the logic of 
'what to do' in case the heart beat stops is quite modem model/firmware 
specific.  This has to be handled by each driver individually.

There's also the possibility that modem firmware itself has a built-in 
heart-beat / crash detector.  This is why ofono_modem_reset was 
introduced and is/was used for modems that have been productized...

Regards,
-Denis