Hi Brian,
On 04/09/2014 08:57 AM, Brian Ruptash wrote:
I'm using a Cinterion PH8-P and an ofono driver I wrote for it,
and
having a problem with how src/gprs.c manages the GPRS attach status.
You'll observe in the below trace that the modem deregisters/registers
and GPRS detaches/attaches several times in a short span, however I'm
intentionally inducing this in order to reproduce a problem that happens
in the field; my use case is a handheld terminal where the user is
constantly on the move, usually in an urban environment, so frequent
signal/connection loss is observed as expected.
Following is a trace of ofono events. Prior to this point the modem was
happily network registered and attached, and now the modem loses both:
18:39:27.023 ph8.c:122 ph8_debug App: < \r\n+CGREG: 2\r\n\r\n+CREG: 2\r\n
18:39:27.030 gprs.c:2174 ofono_gprs_status_notify /ph8_1 status 2 powered
18:39:27.030 gprs.c:1503 gprs_attached_update /ph8_1 status 2 attached
driver_attached changed active
18:39:27.030 gprs.c:1471 release_active_contexts /ph8_1 active
18:39:27.030 gprs-context.c:447 at_gprs_detach_shutdown cid 1
18:39:28.344 network.c:1349 ofono_netreg_status_notify /ph8_1 status 2 tech -1
18:39:28.358 gprs.c:1629 netreg_status_changed 2
18:39:28.358 gprs.c:1600 gprs_netreg_update /ph8_1 2 powered driver_attached
18:39:28.361 ph8.c:122 ph8_debug App: > AT+CGATT=0\r
18:39:28.412 ph8.c:122 ph8_debug App: < \r\nOK\r\n
18:39:28.413 gprs.c:1558 gprs_attach_callback /ph8_1 error = 0
18:39:28.431 ph8.c:122 ph8_debug App: > AT+CGREG?\r
18:39:28.442 ph8.c:122 ph8_debug App: < \r\n+CGREG: 1,2\r\n\r\nOK\r\n
So CGATT=0 succeeded, but the modem tells us it is 'searching'. It may
be a good idea to reset driver_attached to TRUE in this case.
18:39:28.443 gprs.c:1539 registration_status_cb /ph8_1 error
0 status 2 attaching
18:39:28.443 gprs.c:2174 ofono_gprs_status_notify /ph8_1 status 2 powered
18:39:28.443 gprs.c:1503 gprs_attached_update /ph8_1 status 2 active
So now the modem is neither registered nor attached, and
driver_attached=0.
Now the modem network registers and attaches. Yes, it's odd that the
modem attaches even though the prior +CGATT=0 completed; according to
the modem vendor the reason for this is that +CGATT=0 doesn't take
effect until the device has registered:
So this is really the issue, that the modem returns OK to a +CGATT=0,
even though it really should be returning an error. Does your vendor
provide a way to control the auto-attach logic?
18:39:29.972 ph8.c:122 ph8_debug App: < \r\n+CGREG: 1\r\n\r\n+CREG:
1,"0B2D","5F82F11"\r\n
18:39:29.972 gprs.c:2174 ofono_gprs_status_notify /ph8_1 status 1 powered
18:39:29.972 gprs.c:1503 gprs_attached_update /ph8_1 status 1 driver_attached
changed active
18:39:29.983 network.c:1349 ofono_netreg_status_notify /ph8_1 status 1 tech 2
18:39:30.001 gprs.c:1629 netreg_status_changed 1
18:39:30.001 gprs.c:1600 gprs_netreg_update /ph8_1 1 powered driver_attached
And now that the modem is both registered and attached,
driver_attached=1.
However the modem is now registered, so it obeys the +CGATT=0 and
detaches. Note it returns +CGREG: 0 indicating it is detached and will
not attach until instructed to do so:
That is bizarre. Would a quirk in the modem driver solve this? So for
Cinterion devices, if we try to detach while the device is searching,
return an error.
18:39:33.422 ph8.c:122 ph8_debug App: < \r\n+CGREG: 0\r\n
18:39:33.422 gprs.c:2174 ofono_gprs_status_notify /ph8_1 status 0 powered
18:39:33.422 gprs.c:1503 gprs_attached_update /ph8_1 status 0 driver_attached
active
18:39:34.452 gprs-context.c:104 ppp_debug HDLC: < 0d 0a 4e 4f 20 43 41 52 52 49 45 52
0d 0a ..NO CARRIER..
18:39:37.809 gprs-context.c:183 ppp_disconnect state active, reason 6
18:39:37.809 gprs.c:2311 ofono_gprs_context_deactivated /ph8_1 update
18:39:37.813 gprs.c:1503 gprs_attached_update /ph8_1 status 0 driver_attached
So I'm now in a state where the modem is registered and detached, but
gprs->driver_attached=1. And since +CGATT=0 it will never attach.
driver_attached should not be 1. Perhaps the modem driver should be
quirked to call ofono_gprs_detached_notify in this case.
The underlying reason for this seems to be that gprs->driver_attached
follows the +CGATT state, but there's no logic to "synchronize" attach
status changes against the network registration status. One could
better argue the underlying reason is the modem's misbehaviour in
attaching even though +CGATT=0, but it's simpler for me to address this
in ofono than to (1) convince the modem vendor that it's their problem,
(2) get them to release a firmware update, and (3) download the update
in 20,000 devices :)
Following is a proposed patch that seems to address this issue.
-- Brian
---
src/gprs.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/gprs.c b/src/gprs.c
index e379f7b..73edfb4 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -2149,6 +2149,21 @@ void ofono_gprs_status_notify(struct ofono_gprs *gprs, int
status)
gprs->status = status;
+ if (status == NETWORK_REGISTRATION_STATUS_NOT_REGISTERED) {
+ if (gprs->flags & GPRS_FLAG_ATTACHING)
+ return;
+
+ gprs->driver_attached = FALSE;
+
+ if (gprs->powered == FALSE) {
+ gprs_attached_update(gprs);
+ return;
+ }
+
+ gprs_netreg_update(gprs);
+ return;
+ }
+
if (status != NETWORK_REGISTRATION_STATUS_REGISTERED &&
status != NETWORK_REGISTRATION_STATUS_ROAMING) {
gprs_attached_update(gprs);
I'm wondering whether this should be solved in the driver. Some devices
signal CGREG:0 immediately followed by CGREG:2 when losing signal, so
this might result in some weird interactions on other devices.
Regards,
-Denis