Handle broken AT command process

Handle broken AT command process

[Martin =?unknown-8bit?q?Hundeb=C3=B8ll?=]

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

Hi,

Does ofono have a way to handle lacking OK/error messages? I seems like 
my modem (Quectel M95) is buggy when it comes to unsolicited indications 
and (as far as I have seen) SIM commands:

  > AT+CRSM=178,28614,3,4,8
  < +CRSM: 144,0,"FFFFFFFFFFFFFFFF"
  < OK
  > AT+CRSM=178,28614,4,4,8
  < Call Ready
  < +CREG: 5,"0119","04EA"

The "Call Ready" indication causes a lacking "OK" from the preceding 
"AT+CRSM" command. This has happened with other CRSM commands, and can 
also be caused by an unsolicited +CREG indication.

I guess one way handle it, is to to glue op the URC listeners to peek 
into the AT command queue and check if a command is pending for 
OK/errors, and retry it if so.

But that could cause unexpected side effects depending on the retried 
command...

// Martin

Re: Handle broken AT command process

[Denis Kenzior]

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

Hi Martin,

On 8/19/19 2:29 PM, Martin Hundebøll wrote:
> Hi,
> 
> Does ofono have a way to handle lacking OK/error messages? I seems like 
> my modem (Quectel M95) is buggy when it comes to unsolicited indications 
> and (as far as I have seen) SIM commands:
> 
>   > AT+CRSM=178,28614,3,4,8
>   < +CRSM: 144,0,"FFFFFFFFFFFFFFFF"
>   < OK
>   > AT+CRSM=178,28614,4,4,8
>   < Call Ready
>   < +CREG: 5,"0119","04EA"
> 
> The "Call Ready" indication causes a lacking "OK" from the preceding 
> "AT+CRSM" command. This has happened with other CRSM commands, and can 
> also be caused by an unsolicited +CREG indication.

Eww.  Get your vendor on the phone ;)

> 
> I guess one way handle it, is to to glue op the URC listeners to peek 
> into the AT command queue and check if a command is pending for 
> OK/errors, and retry it if so.

Anyway, generally we can't peek ahead.  GAtChat just doesn't work this 
way.  Also, handling unsolicited notifications interleaved with AT 
command responses is why it is a good idea to provide a list of prefixes 
of the expected responses to g_at_chat_send.  That tells GAtChat which 
lines to consume as a 'response' and which to allow through for 
unsolicited notification processing.  If you provide a NULL prefix, then 
everything is consumed as a 'response'.

> 
> But that could cause unexpected side effects depending on the retried 
> command...

I'm not really even sure what to suggest as a workaround to try here... 
If you have multiple TTYs to play with, maybe fork off one dedicated to 
+CRSM and disable all unsolicited notifications on it?

Regards,
-Denis

Re: Handle broken AT command process

[Martin =?unknown-8bit?q?Hundeb=C3=B8ll?=]

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

Hi Denis,

On 19/08/2019 21.55, Denis Kenzior wrote:
> Hi Martin,
> 
> On 8/19/19 2:29 PM, Martin Hundebøll wrote:
>> Does ofono have a way to handle lacking OK/error messages? I seems 
>> like my modem (Quectel M95) is buggy when it comes to unsolicited 
>> indications and (as far as I have seen) SIM commands:
>>
>>   > AT+CRSM=178,28614,3,4,8
>>   < +CRSM: 144,0,"FFFFFFFFFFFFFFFF"
>>   < OK
>>   > AT+CRSM=178,28614,4,4,8
>>   < Call Ready
>>   < +CREG: 5,"0119","04EA"
>>
>> The "Call Ready" indication causes a lacking "OK" from the preceding 
>> "AT+CRSM" command. This has happened with other CRSM commands, and can 
>> also be caused by an unsolicited +CREG indication.
> 
> Eww.  Get your vendor on the phone ;)

They are involved. Hopefully they'll come back with something useful :)

>>
>> I guess one way handle it, is to to glue op the URC listeners to peek 
>> into the AT command queue and check if a command is pending for 
>> OK/errors, and retry it if so.
> 
> Anyway, generally we can't peek ahead.  GAtChat just doesn't work this 
> way.  Also, handling unsolicited notifications interleaved with AT 
> command responses is why it is a good idea to provide a list of prefixes 
> of the expected responses to g_at_chat_send.  That tells GAtChat which 
> lines to consume as a 'response' and which to allow through for 
> unsolicited notification processing.  If you provide a NULL prefix, then 
> everything is consumed as a 'response'.

OK

>>
>> But that could cause unexpected side effects depending on the retried 
>> command...
> 
> I'm not really even sure what to suggest as a workaround to try here... 
> If you have multiple TTYs to play with, maybe fork off one dedicated to 
> +CRSM and disable all unsolicited notifications on it?

There's four tty's of which only two are currently used. I think I'll 
try with a dedicated tty for the SIM handling.

Thanks for the pointers.

// Martin