> The best course of action would be to have modem.disable() issue
> CFUN=0 equivalent that resets everything properly. If that's not
> possible, then a solution along the lines of what you propose is
> needed. E.g. sending a '+++' in at_gprs_context_remove if the state
> isn't IDLE.
I don't have a document describing AT command supported by MS2372. I use
a document describing AT command supported by another Huawei modem. I
didn't find any better command than AT+CFUN=0 to try to put back PPP
channel in command mode.
Sometimes these modules take an extra reset parameter after the CFUN.
E.g. AT+CFUN=0,1 to reset the module completely. Not sure if this has
other implications. Possibly we can issue a AT+CFUN=1,1 or AT+CFUN=4,1
on .enable() that might fix this as well.
I had a look at g_at_ppp_suspend and you are right, there is a guard
timeout before sending '+++'. That's why it won't solve my problem.
Ofono will die before this command is really sent.
So I don't have any better idea than patch I already sent? Should I send
a proper patch series with similar content?
That's the issue, the guard timeout is supposed to be used after all
activity has been stopped and only then should '+++' be sent. So it
might be a good idea to put this behind a VENDOR guarded if-statement
and issue the '+++' directly to the GAtIO without involving GAtPPP at all.