[Ovmsdev] ppp problem on disconnect

Mon Dec 11 15:12:08 HKT 2017

Last set of changes just got committed. It seems better now, but may not be perfect. I added a new state NetLoss to be able to specifically track loss of network.

From what I can see, there are two main edge cases we need to consider for PPP connection loss:

GSM connection is stable, but PPP connection goes down (at the lwip pppos level).

I’ve left the normal lwip pppos example code logic in place. In the event of any soft or error, in the GsmPPPOS_StatusCallback(), it posts a pppapi_connect(pcb, 30). This should cause a re-connection attempt to happen in 30 seconds. No idea what happens if that subsequent reconnect fails (I guess/hope it will appear as another status callback). Really hard to simulate this edge case. Maybe driving around, and moving between cell towers? Diagnostic for this would be an info-level gsm-ppp log of "Attempting PPP reconnecting in 30 seconds…”.

The alternative here is to do the same as the user shutdown case; set m_connected=false, get out, and let the simcom layer handle it (see #2 below).

GSM connection goes from online (home/roaming) to offline (searching, etc).

Here we implement it in the simcom layer. We transition to NetLoss state, which uses AT+CGATT=0 to shutdown the simcom PPP data port, and m_ppp.Shutdown(true) to hard shutdown (carrier loss) the lwip pppos connection.

Note that in all cases, I try to retain the m_ppp lwip pppos connection object and re-use it. I’m worried about destroying that as there are things like network interfaces and other sorts of structures associated. Safer to leave that and keep it relatively permanent. The previous fault we had (tasks locking up) seemed to be a double-initialisation of this structure causing issues (now solved by explicitly checking for that).

I’m hoping LWIP PPP (via simcom) will be more stable now, but will keep testing it here. Feedback appreciated.

Regards, Mark.

> On 11 Dec 2017, at 2:34 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> I’ve committed all my changes, to improve the testing environment for this:
> 
> Documented the existing SIMCOM states
> Split NetStart state into NetWait (waiting for cellular connection) and NetStart (start the PPP data session at the SIMCOM level)
> Added a ‘simcom setstate’ command to be able to manually force a state (in particular force a cellular connection loss, rather than having to wait for it)
> Sped up some of the detection checks (in particular, NetStart and NetWait).
> 
> It all look good, but then led to another issue:
> 
> D (40125) SIMCOM line: 55 4e 44 45 52 2d 56 4f 4c 54 41 47 45 20 57 41 UNDER-VOLTAGE WA
> D (40125) SIMCOM line: 52 4e 4e 49 4e 47 20 50 4f 57 45 52 20 44 4f 57 RNNING POWER DOW
> D (40125) SIMCOM line: 4e                                              N
> 
> D (40145) SIMCOM line: 73 74 61 72 74 69 6e 67 20 70 6f 77 65 72 20 6f starting power o
> D (40145) SIMCOM line: 66 66 20 74 68 65 20 6d 6f 64 75 6c 65 21       ff the module!
> 
> Good grief. I guess my USB port doesn’t have enough power. Perhaps related to the SIMCOM GPS being enabled by default? A complete power down resolved this.
> 
> Anyway, I can now at least simulate a loss of cellular connectivity (simcom setstate NetWait). I can now try to find out a way to properly tear down the PPP connection (both at the lwip pppos and simcom levels). Very frustrating there are no good examples for lwip ppos (many show how to establish, but none show best practices for modem scripting and handling loss of connectivity).
> 
> Regards, Mark.
> 
>> On 11 Dec 2017, at 9:55 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>> 
>> I’m aware of this, and working on it.
>> 
>> Something strange going on in the lwip pppos api. Seems to not be returning from the shutdown call, so our simcom thread gets locked up. Also messes up the main freertos threads (I think those drive the event timers for lwip).
>> 
>> I am working on a re-factor of the simcom state diagram to simplify the way we drive this, and also an ability to force a state change by command. At the moment, too much is being done in state NetMode. My test-debug cycle is also way too long (plug in antenna, power up simcom, wait for cellular connectivity, wait for GSM lock, wait for mux, wait for CSQ, wait for PPP, then disconnect antenna, and wait again…), can only be done in areas of poor cellular connectivity, and is driving me crazy. That should speed up debugging this issue. I’m working on it…
>> 
>> Regards, Mark.
>> 
>>> On 11 Dec 2017, at 2:55 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>> 
>>> Just had this after letting the module idle for a while:
>>> 
>>> …
>>> I (11249582) simcom: CREG Network Registration: RegisteredRoaming
>>> I (11253822) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11251,0,0,1,0,0.373626,0,0,0,0,0
>>> I (11273832) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11271,0,0,1,0,0.401099,0,0,0,0,0
>>> I (11279582) simcom: CREG Network Registration: RegisteredRoaming
>>> I (11282842) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11280,0,0,1,0,0.362637,0,0,0,0,0
>>> I (11286902) simcom: PPP Connection disconnected
>>> I (11286902) simcom: PPP Connection disconnected
>>> I (11287562) simcom: Lost network connection (+PPP disconnect in NetMode)
>>> I (11287562) gsm-ppp: Shutting down (hard)...
>>> I (11287562) simcom: State: Enter NetStart state
>>> I (11287562) gsm-nmea: Startup
>>> I (11292662) gsm-ppp: StatusCallBack: User Interrupt
>>> E (11292662) gsm-ppp: status_cb: User interrupt|
>>> I (11292662) gsm-ppp: Shutdown (via status callback)
>>> I (11292662) events: Signal(system.modem.down)
>>> I (11292662) events: Signal(network.modem.down)
>>> I (11292852) ovms-server-v2: Send MP-0 D0,0,5,0,0,-40,0,0,0,11290,0,0,1,0,0.417582,0,0,0,0,0
>>> I (11292902) simcom: PPP Connection disconnected
>>> I (11292902) simcom: PPP Connection disconnected
>>> I (11292902) simcom: PPP Connection disconnected
>>> I (11299592) simcom: PPP Connection is ready to start
>>> I (11300562) simcom: State: Enter NetMode state
>>> I (11300562) gsm-ppp: Initialising...
>>> OVMS > Task watchdog got triggered. The following tasks did not feed the watchdog in time:
>>> - IDLE (CPU 0)
>>> Tasks currently running:
>>> CPU 0: tiT
>>> CPU 1: ipc1
>>> Task watchdog got triggered. The following tasks did not feed the watchdog in time:
>>> - IDLE (CPU 0)
>>> Tasks currently running:
>>> CPU 0: tiT
>>> CPU 1: ipc1
>>> Task watchdog got triggered. The following tasks did not feed the watchdog in time:
>>> - IDLE (CPU 0)
>>> Tasks currently running:
>>> CPU 0: tiT
>>> CPU 1: ipc1
>>> …
>>> 
>>> … and so on, no more input reaction from the shell here, had to do a reset.
>>> 
>>> Regards,
>>> Michael
>>> 
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171211/9fa27873/attachment.htm>