10:21 p.m.
In case of LTE modem, attaching manually is normally unneeded.
Forcing a detach (in case of gprs-context activation failure) is
actually a mistake, also because this will also trigger a technology
reselection and a possible invalid state, especially for LTE-only
modems.
This simple patch adds a flag to skip the AT+CGATT=x command.
The flag is to be set by vendor-specific options.
By default the behavior remains unchanged.
---
drivers/atmodem/gprs.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 6e01738a..fc0d8aa3 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -59,6 +59,7 @@ struct gprs_data {
gboolean has_cereg;
gboolean has_c5greg;
gboolean nb_inds;
+ gboolean auto_attach; /* for LTE modems & co */
int attached;
int cgreg_status;
int cereg_status;
@@ -88,9 +89,15 @@ static void at_gprs_set_attached(struct ofono_gprs *gprs, int
attached,
ofono_gprs_cb_t cb, void *data)
{
struct gprs_data *gd = ofono_gprs_get_data(gprs);
- struct cb_data *cbd = cb_data_new(cb, data);
+ struct cb_data *cbd;
char buf[64];
+ if (gd->auto_attach) {
+ CALLBACK_WITH_SUCCESS(cb, data);
+ return;
+ }
+
+ cbd = cb_data_new(cb, data);
snprintf(buf, sizeof(buf), "AT+CGATT=%i", attached ? 1 : 0);
if (g_at_chat_send(gd->chat, buf, none_prefix,
--
2.17.1
8:49 a.m.
Hii Giacinto,
On 09/23/2018 12:21 AM, Giacinto Cifelli wrote:
In case of LTE modem, attaching manually is normally unneeded.
Forcing a detach (in case of gprs-context activation failure) is
actually a mistake, also because this will also trigger a technology
reselection and a possible invalid state, especially for LTE-only
modems.
Okay, so it sounds like the core src/gprs.c logic is not taking
technology into account. Should this be fixed there?
This simple patch adds a flag to skip the AT+CGATT=x command.
The flag is to be set by vendor-specific options.
By default the behavior remains unchanged.
---
drivers/atmodem/gprs.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 6e01738a..fc0d8aa3 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -59,6 +59,7 @@ struct gprs_data {
gboolean has_cereg;
gboolean has_c5greg;
gboolean nb_inds;
+ gboolean auto_attach; /* for LTE modems & co */
int attached;
int cgreg_status;
int cereg_status;
@@ -88,9 +89,15 @@ static void at_gprs_set_attached(struct ofono_gprs *gprs, int
attached,
ofono_gprs_cb_t cb, void *data)
{
struct gprs_data *gd = ofono_gprs_get_data(gprs);
- struct cb_data *cbd = cb_data_new(cb, data);
+ struct cb_data *cbd;
char buf[64];
+ if (gd->auto_attach) {
+ CALLBACK_WITH_SUCCESS(cb, data);
+ return;
+ }
+
You can't really do that though. It is fully possible for a modem to
roam off LTE onto 3G and not be attached... So we still need tosend
+CGATT in this case.
+ cbd = cb_data_new(cb, data);
snprintf(buf, sizeof(buf), "AT+CGATT=%i", attached ? 1 : 0);
if (g_at_chat_send(gd->chat, buf, none_prefix,
Regards,
-Denis
10:41 p.m.
On Thu, Sep 27, 2018 at 5:49 PM Denis Kenzior <denkenz(a)gmail.com> wrote:
Hii Giacinto,
On 09/23/2018 12:21 AM, Giacinto Cifelli wrote:
> In case of LTE modem, attaching manually is normally unneeded.
> Forcing a detach (in case of gprs-context activation failure) is
> actually a mistake, also because this will also trigger a technology
> reselection and a possible invalid state, especially for LTE-only
> modems.
Okay, so it sounds like the core src/gprs.c logic is not taking
technology into account. Should this be fixed there?
>
> This simple patch adds a flag to skip the AT+CGATT=x command.
> The flag is to be set by vendor-specific options.
>
> By default the behavior remains unchanged.
> ---
> drivers/atmodem/gprs.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
> index 6e01738a..fc0d8aa3 100644
> --- a/drivers/atmodem/gprs.c
> +++ b/drivers/atmodem/gprs.c
> @@ -59,6 +59,7 @@ struct gprs_data {
> gboolean has_cereg;
> gboolean has_c5greg;
> gboolean nb_inds;
> + gboolean auto_attach; /* for LTE modems & co */
> int attached;
> int cgreg_status;
> int cereg_status;
> @@ -88,9 +89,15 @@ static void at_gprs_set_attached(struct ofono_gprs *gprs, int
attached,
> ofono_gprs_cb_t cb, void *data)
> {
> struct gprs_data *gd = ofono_gprs_get_data(gprs);
> - struct cb_data *cbd = cb_data_new(cb, data);
> + struct cb_data *cbd;
> char buf[64];
>
> + if (gd->auto_attach) {
> + CALLBACK_WITH_SUCCESS(cb, data);
> + return;
> + }
> +
You can't really do that though. It is fully possible for a modem to
roam off LTE onto 3G and not be attached... So we still need tosend
+CGATT in this case.
You can't really do that, either. It is possible that the module hops
off LTE for a CSFB call of for a simple SMS, and the current logic
will send immediately AT+CGATT=0 which will wreak havoc: the contexts
that should be handed-over or suspended are released, and the module
is never able to return to LTE because forced to detach.
I didn't see the call drop in my tests, but it is not impossible that
some modules would also do that as a consequence.
I didn't test on the move or with a simulator, but I suppose also in
case of HO LTE->3G we have the same scenario.
For Gemalto modules it is kind of mandatory to let the module handle
the attach by itself if it supports LTE, and I believe also for other
vendors, hence the autoattach flag.
Maybe the data-roaming logic should move from attach to context activation.
Also the operators expect it to work this way nowadays, even for
pre-LTE modules.
> + cbd = cb_data_new(cb, data);
> snprintf(buf, sizeof(buf), "AT+CGATT=%i", attached ? 1 : 0);
>
> if (g_at_chat_send(gd->chat, buf, none_prefix,
>
Regards,
-Denis
6:40 a.m.
Hi Giacinto,
> You can't really do that though. It is fully possible for a
modem to
> roam off LTE onto 3G and not be attached... So we still need tosend
> +CGATT in this case.
You can't really do that, either. It is possible that the module hops
off LTE for a CSFB call of for a simple SMS, and the current logic
It may be the logic is flawed here. Or the event sequence causes GPRS
to thrash about and cause a detach. I wonder if this can be fixed in
the gprs core atom itself?
E.g. for a CSFB / SMS, we should see something like:
+CREG: 1, foo, bar, 7 // Home network, EUTRAN
+CREG: 1, baz, bea, 2
+CGREG: 1, baz, bea, 2
will send immediately AT+CGATT=0 which will wreak havoc: the
contexts
that should be handed-over or suspended are released, and the module
So if we're sending a +CGATT=0 in that event sequence, then it is likely
a bug. Can you actually share an AT command trace / debug log of what
is happening? export OFONO_AT_DEBUG=1 prior to running oFono.
is never able to return to LTE because forced to detach.
I didn't see the call drop in my tests, but it is not impossible that
some modules would also do that as a consequence.
I didn't test on the move or with a simulator, but I suppose also in
case of HO LTE->3G we have the same scenario.
The problem is that every vendor handles CGATT slightly differently. It
is a bit of a mess, but yes it sounds like we are doing something wrong
here.
For Gemalto modules it is kind of mandatory to let the module handle
the attach by itself if it supports LTE, and I believe also for other
vendors, hence the autoattach flag.
Well, this is a bit of a strange situation actually. So the original
RoamingAllowed logic was introduced because some networks actually
charged roaming fees when the Modem was attached (not even context
activated) to the PS network. So the RoamingAllowed hammer was added to
make sure that if the user enabled that option, no attach would be
attempted while roaming.
This still in theory applies to LTE-capable devices: even if we drop
from LTE to 3G to make a phone call, we should still detach if the
setting applies. So the question is why does +CGATT affect anything in
the LTE state? In some sense I don't think it was meant to affect LTE
state.
However, I think the fundamental problem is that 27.007 never provided
us the right command to actually tell the modem what to do. We really
just needed a hint out to the modem not to auto-attach while roaming,
something that mapped to RoamingAllowed setting. Unfortunately the
+CGATT was the only thing available.
Maybe the data-roaming logic should move from attach to context activation.
Also the operators expect it to work this way nowadays, even for
pre-LTE modules.
So honestly I was never happy with the RoamingAllowed stuff, nor the
logic that drove it. But at this point we're kind of stuck with it for
1.x. The question is, can this be fixed somehow?
If not, then we can consider starting oFono 2.x branch and dropping
RoamingAllowed from the D-Bus API. This would also allow us to fix some
other long-standing issues with the D-Bus API as well. However, this is
quite a major step with its own consequences...
Regards,
-Denis
846
days inactive
851
days old
3 comments
2 participants
participants (2)
-
Denis Kenzior -
Giacinto Cifelli