Even with detach_shutdown method implemented in qmimodem (patch done by Jonas Bonn two or three weeks ago), I still sometimes have problems when I have a lot of GPRS deconnections.

I use a MC7304 modem and to simulate short GPRS network losses, I simply unplug and replug modem antenna.

I figured out that my problems come from QMI_WDS_PKT_STATUS_IND that is received after GPRS network is back and context activation started once again (by connman).

I have posted a trace with connman and ofono traces here (available for the next 7 days): https://we.tl/FliZAdaVN5

I have added some additional traces in ofono to narrow down the problem.

Here is the trace explanation:

What happens before Apr 27 16:05:59:
1) Apr 27 16:05:44: GPRS attach lost, we asked to deactivate GPRS context.
2) Apr 27 16:05:53: GPRS attach is back

What happens at Apr 27 16:05:59:
1) Answer OK to qmi_deactivate_primary (stop_net_cb without error)
2) ofono_gprs_context_deactivated called with correct cid, property Active set to False
3) Connman immediately reacts and ask for context reactivation. qmi_activate_primary is called
4) pkt_status_notify received to say that packet status is disconnected => ofono_gprs_context_deactivated called again but context not activated yet. Nothing happens outside of gprs-context driver but active_context is set to 0.

What happens at Apr 27 16:10:28:
1) GPRS attach lost, we asked to deactivate GPRS context.
2) stop_net_cb called without error BUT active_context is 0.
3) ofono_gprs_context_deactivated called with wrong context id, nothing happens

And property Active of gprs context is not modified. Connman will never try to reconnect the service when GPRS attach is back (Apr 27 16:10:39).

I've done a patch that seems to correct the problem for me. I simply do not handle anymore QMI_WDS_PKT_STATUS_IND notifications. I assume it is not needed anymore (after Jonas Bonn patch implementing detach_shutdown method in qmimodem driver). But I might be wrong...

I'll send the patch after this message.

Best Regards,