Unexpected +CGDCONT? error: 'Sending command failed: 'Resource temporarily unavailable''

[Aleksander Morgado]

On Thu, Jul 20, 2017 at 11:15 AM, Ben Chan <benchan at chromium.org> wrote:
> On Thu, Jul 20, 2017 at 1:42 AM, Ben Chan <benchan at chromium.org> wrote:
>> Looking into it a bit more, the periodic signal update doesn't seem to
>> cause the issue. But it seems like the primary port is closed and then
>> reopened, and the init sequence runs while a connect operation is
>> starting.
>>
>
> Looks like the problem is that, the data port is closed and reopened
> during the disconnect operation. When the port is reopened, the init
> AT sequence is sent via mm_port_serial_at_run_init_sequence, which
> returns immediately without waiting for AT responses. The disconnect
> operation completes but the init AT sequence may still be sending out.
> A connect operation could happen right after the disconnect operation
> completed but in the middle of an init sequence.

But for that sequence, the AT port still should wait for the responses
of each of the AT commands sent, even if they're discarded and not
passed as result of any async operation. This issue you're seeing may
happen if for any reason one of the commands sent (regardless of
whether we wait for the response or not) takes longer than the timeout
we have configured for it. E.g. if we say ATI will take 3s and it
takes 15, if we end up sending more commands after the 3s we waited
for, you'll end up seeing the sequence you're getting. This is also
very normal if we try to send commands to a TTY that was connected and
in data mode and it didn't get back into command mode again: all
commands sent to it e.g. after the port close/reopen done during
disconnection, will end up timing out. Does this make some sense now?

We would need to identify whether this is a one-time issue, or if
there is any command that takes longer than expected, and if so,
update the timeout we use for that one.

-- 
Aleksander
https://aleksander.es