atmodem/gprs: added autoattach handling
PATCH 1/1 atmodem/gprs: added autoattach handling
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(-)
drivers/atmodem/gprs.c +8 -1
@@ -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,
Signature · 1 line
2.17.1
Hii Giacinto,
Quoted 5 lines · Giacinto Cifelli
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?
Quoted 24 lines
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(-)drivers/atmodem/gprs.c +1
-0@@ -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) {
drivers/atmodem/gprs.c static void at_gprs_set_attached(struct ofono_gprs *gprs, int attached, · line 99
Quoted 10 lines
drivers/atmodem/gprs.c +6
-1struct 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.
drivers/atmodem/gprs.c static void at_gprs_set_attached(struct ofono_gprs *gprs, int attached, · line 103
Quoted 5 lines
drivers/atmodem/gprs.c +1
-0+ 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
Quoted 42 lines · Denis Kenzior
Hii Giacinto,
Quoted 5 lines · Giacinto Cifelli
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.clogic is not taking
technology into account. Should this be fixed there?Quoted 29 lines
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(-)drivers/atmodem/gprs.c +2
-1@@ -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 ];
Quoted 9 lines
drivers/atmodem/gprs.c static void at_gprs_set_attached(struct ofono_gprs *gprs, int attached, · line 99
Quoted 5 lines
drivers/atmodem/gprs.c +5
-0+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.
Quoted 9 lines
drivers/atmodem/gprs.c static void at_gprs_set_attached(struct ofono_gprs *gprs, int attached, · line 103
Quoted 6 lines
drivers/atmodem/gprs.c +1
-0+ 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
Hi Giacinto,
Quoted 6 lines
Quoted 3 lines
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
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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