Hi Denis,
On 07/19/2018 06:20 PM, Denis Kenzior wrote: > Hi Christophe, > >>> The best course of action would be to have modem.disable() issue a >>> 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. With huawei plugin, we have: start ofono: huawei_enable: AT+CFUN=1 AT+CFUN=5 huawei_set_online: AT+CFUN=1 stop ofono: huawei_disable: AT+CFUN=0 I tried to add reset parameter both in huawei_disable and in huawei_enable and reproduced the current problem with these changes. This test was done with a different huawei USB key (E3372). In traces attached, you will see usual problem and +CFUN like that: start ofono: huawei_enable: Jul 25 07:09:18 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: > AT+CFUN=1,1\r Jul 25 07:09:18 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: > AT+CFUN=5\r huawei_set_online: Jul 25 07:09:19 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: > AT+CFUN=1\r stop ofono: huawei_disable: Jul 25 07:09:53 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: > AT+CFUN=0,1\r restart ofono: huawei_enable: Jul 25 07:10:03 klk-lpbs-06029C daemon.info ofonod[2579]: PCUI: > AT+CFUN=1,1\r Jul 25 07:10:03 klk-lpbs-06029C daemon.info ofonod[2579]: PCUI: > AT+CFUN=5\r huawei_set_online: Jul 25 07:10:03 klk-lpbs-06029C daemon.info ofonod[2579]: PCUI: > AT+CFUN=1\r > >> 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. Ok for the VENDOR guarded if-statement and the direct call to GAtIO. Patches follow. Best regards, Christophe
reconnectError_04.tar.gz
Description: application/gzip
_______________________________________________ ofono mailing list [email protected] https://lists.ofono.org/mailman/listinfo/ofono
