Making disconnection more robust

[Aleksander Morgado]

On Fri, Aug 11, 2017 at 1:05 PM, Tim Small <tim at seoss.co.uk> wrote:
> A couple more questions...
>
> What should the code do if a return to AT command mode fails?  Currently
> the code just continues to try and use a port which is still in data
> mode - issuing AT commands on it...
>

Yeah, not ideal :)


> In my case I'd like to be able to (as a last resort) power-cycle the
> modem if it remains unresponsive.  Being able to do this is quite common
> for embedded systems (and with most phones entering "aeroplane mode"
> does that too).  One possible way to integrate that would be to allow an
> external binary to be specified via a udev rule, does that sound reasonable?
>

No, we shouldn't call any external binary. I'd suggest we try to move
that modem to "Failed" state instead, as we really lost the control
port; and let the applications using MM do whatever they need to do
with a failed modem, including external power cycle or whatever.

Actually, IIRC, there should already be some mechanism to detect an
unresponsive TTY and if it's the control port of a modem, do a full
modem removal and re-probe (e.g. for RS232 modems which get suddenly
powered off).

-- 
Aleksander
https://aleksander.es