* [PATCH] gprs: Attach status confusion
@ 2014-04-09 13:57 Brian Ruptash
2014-04-09 15:51 ` Denis Kenzior
0 siblings, 1 reply; 2+ messages in thread
From: Brian Ruptash @ 2014-04-09 13:57 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 5154 bytes --]
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
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:
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:
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.
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);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH] gprs: Attach status confusion
2014-04-09 13:57 [PATCH] gprs: Attach status confusion Brian Ruptash
@ 2014-04-09 15:51 ` Denis Kenzior
0 siblings, 0 replies; 2+ messages in thread
From: Denis Kenzior @ 2014-04-09 15:51 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 6275 bytes --]
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-04-09 15:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-09 13:57 [PATCH] gprs: Attach status confusion Brian Ruptash
2014-04-09 15:51 ` Denis Kenzior
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.