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
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.