3:16 a.m.
Hi All,
Currently, if GPRS service is detached for whatever reason, the only way
to get PS services back is to set the Powered property to FALSE and back
to TRUE.
With these patches, GPRS context activation will cause oFono to
automatically attempt GPRS attach if the modem is presently detached.
Br,
MikaL
[PATCH 1/3] gprs: attach on demand
[PATCH 2/3] gprs: update documentation
[PATCH 3/3] isimodem: context activation might follow attach
3:16 a.m.
New subject: [PATCH 1/3] gprs: attach on demand
Attach automatically when a GPRS context is activated
---
src/gprs.c | 153 ++++++++++++++++++++++++++++++++---------------------------
1 files changed, 83 insertions(+), 70 deletions(-)
diff --git a/src/gprs.c b/src/gprs.c
index 610f3b2..d4b4e24 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -106,6 +106,7 @@ struct context_settings {
struct pri_context {
ofono_bool_t active;
+ ofono_bool_t activation_pending;
enum ofono_gprs_context_type type;
char name[MAX_CONTEXT_NAME_LENGTH + 1];
char message_proxy[MAX_MESSAGE_PROXY_LENGTH + 1];
@@ -647,6 +648,49 @@ static DBusMessage *pri_get_properties(DBusConnection *conn,
return reply;
}
+static gboolean assign_context(struct pri_context *ctx)
+{
+ struct idmap *cidmap = ctx->gprs->cid_map;
+ unsigned int cid_min;
+ GSList *l;
+
+ if (cidmap == NULL)
+ return FALSE;
+
+ cid_min = idmap_get_min(cidmap);
+
+ ctx->context.cid = gprs_cid_alloc(ctx->gprs);
+ if (ctx->context.cid == 0)
+ return FALSE;
+
+ for (l = ctx->gprs->context_drivers; l; l = l->next) {
+ struct ofono_gprs_context *gc = l->data;
+
+ if (gc->inuse == TRUE)
+ continue;
+
+ if (gc->type == OFONO_GPRS_CONTEXT_TYPE_ANY ||
+ gc->type == ctx->type) {
+ ctx->context_driver = gc;
+ ctx->context_driver->inuse = TRUE;
+ return TRUE;
+ }
+ }
+
+ return FALSE;
+}
+
+static void free_context(struct pri_context *ctx)
+{
+ gprs_cid_release(ctx->gprs, ctx->context.cid);
+ ctx->context.cid = 0;
+ ctx->active = FALSE;
+ ctx->activation_pending = FALSE;
+ if (ctx->context_driver)
+ ctx->context_driver->inuse = FALSE;
+ ctx->context_driver = NULL;
+}
+
static void pri_activate_callback(const struct ofono_error *error,
const char *interface,
ofono_bool_t static_ip,
@@ -666,11 +710,7 @@ static void pri_activate_callback(const struct ofono_error *error,
__ofono_dbus_pending_reply(&ctx->pending,
__ofono_error_failed(ctx->pending));
- gprs_cid_release(ctx->gprs, ctx->context.cid);
- ctx->context.cid = 0;
- ctx->context_driver->inuse = FALSE;
- ctx->context_driver = NULL;
-
+ free_context(ctx);
return;
}
@@ -706,15 +746,9 @@ static void pri_deactivate_callback(const struct ofono_error *error,
void *data)
return;
}
- gprs_cid_release(ctx->gprs, ctx->context.cid);
- ctx->context.cid = 0;
- ctx->active = FALSE;
- ctx->context_driver->inuse = FALSE;
- ctx->context_driver = NULL;
-
+ free_context(ctx);
__ofono_dbus_pending_reply(&ctx->pending,
dbus_message_new_method_return(ctx->pending));
-
pri_reset_context_settings(ctx);
value = ctx->active;
@@ -957,38 +991,6 @@ static DBusMessage *pri_set_message_center(struct pri_context *ctx,
return NULL;
}
-static gboolean assign_context(struct pri_context *ctx)
-{
- struct idmap *cidmap = ctx->gprs->cid_map;
- unsigned int cid_min;
- GSList *l;
-
- if (cidmap == NULL)
- return FALSE;
-
- cid_min = idmap_get_min(cidmap);
-
- ctx->context.cid = gprs_cid_alloc(ctx->gprs);
- if (ctx->context.cid == 0)
- return FALSE;
-
- for (l = ctx->gprs->context_drivers; l; l = l->next) {
- struct ofono_gprs_context *gc = l->data;
-
- if (gc->inuse == TRUE)
- continue;
-
- if (gc->type == OFONO_GPRS_CONTEXT_TYPE_ANY ||
- gc->type == ctx->type) {
- ctx->context_driver = gc;
- ctx->context_driver->inuse = TRUE;
- return TRUE;
- }
- }
-
- return FALSE;
-}
-
static DBusMessage *pri_set_property(DBusConnection *conn,
DBusMessage *msg, void *data)
{
@@ -1030,8 +1032,19 @@ static DBusMessage *pri_set_property(DBusConnection *conn,
if (ctx->active == (ofono_bool_t) value)
return dbus_message_new_method_return(msg);
- if (value && !ctx->gprs->attached)
- return __ofono_error_not_attached(msg);
+ if (value && !ctx->gprs->attached) {
+ gprs_netreg_update(ctx->gprs);
+
+ if (!(ctx->gprs->flags & GPRS_FLAG_ATTACHING))
+ return __ofono_error_not_attached(msg);
+
+ if (!assign_context(ctx))
+ return __ofono_error_not_implemented(msg);
+
+ ctx->activation_pending = TRUE;
+ ctx->pending = dbus_message_ref(msg);
+ return NULL;
+ }
if (ctx->gprs->flags & GPRS_FLAG_ATTACHING)
return __ofono_error_attach_in_progress(msg);
@@ -1284,6 +1297,8 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
const char *path;
ofono_bool_t attached;
dbus_bool_t value;
+ GSList *l;
+ struct pri_context *ctx;
attached = gprs->driver_attached &&
(gprs->status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
@@ -1294,24 +1309,32 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
gprs->attached = attached;
- if (gprs->attached == FALSE) {
- GSList *l;
- struct pri_context *ctx;
-
- for (l = gprs->contexts; l; l = l->next) {
- ctx = l->data;
+ for (l = gprs->contexts; l; l = l->next) {
+ struct pri_context *ctx = l->data;
+ struct ofono_gprs_context *gc = ctx->context_driver;
- if (ctx->active == FALSE)
+ if (attached) {
+ if (!ctx->activation_pending)
continue;
- gprs_cid_release(gprs, ctx->context.cid);
- ctx->context.cid = 0;
- ctx->active = FALSE;
- ctx->context_driver->inuse = FALSE;
- ctx->context_driver = NULL;
+ ctx->activation_pending = FALSE;
+ gc->driver->activate_primary(gc, &ctx->context,
+ pri_activate_callback,
+ ctx);
+ } else {
+ ofono_bool_t active = ctx->active;
+
+ if (ctx->activation_pending)
+ __ofono_dbus_pending_reply(&ctx->pending,
+ __ofono_error_failed(ctx->pending));
+
+ free_context(ctx);
pri_reset_context_settings(ctx);
+ if (!active)
+ continue;
+
value = FALSE;
ofono_dbus_signal_property_changed(conn, ctx->path,
OFONO_CONNECTION_CONTEXT_INTERFACE,
@@ -1758,12 +1781,7 @@ static void gprs_deactivate_for_all(const struct ofono_error
*error,
return;
}
- gprs_cid_release(gprs, ctx->context.cid);
- ctx->active = FALSE;
- ctx->context.cid = 0;
- ctx->context_driver->inuse = FALSE;
- ctx->context_driver = NULL;
-
+ free_context(ctx);
pri_reset_context_settings(ctx);
value = ctx->active;
@@ -1997,12 +2015,7 @@ void ofono_gprs_context_deactivated(struct ofono_gprs_context *gc,
if (ctx->context.cid != cid)
continue;
- gprs_cid_release(ctx->gprs, ctx->context.cid);
- ctx->context.cid = 0;
- ctx->active = FALSE;
- ctx->context_driver->inuse = FALSE;
- ctx->context_driver = NULL;
-
+ free_context(ctx);
pri_reset_context_settings(ctx);
value = FALSE;
--
1.7.1
3:16 a.m.
New subject: [PATCH 2/3] gprs: update documentation
---
doc/connman-api.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/doc/connman-api.txt b/doc/connman-api.txt
index 22e02e5..e53032c 100644
--- a/doc/connman-api.txt
+++ b/doc/connman-api.txt
@@ -142,6 +142,9 @@ Properties boolean Active [readwrite]
Holds whether the context is activated. This value
can be set to activate / deactivate the context.
+ Activating a context will automatically trigger the
+ GPRS attach procedure if necessary.
+
string AccessPointName [readwrite]
Holds the name of the access point. This is
--
1.7.1
3:16 a.m.
New subject: [PATCH 3/3] isimodem: context activation might follow attach
---
drivers/isimodem/gprs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isimodem/gprs.c b/drivers/isimodem/gprs.c
index 3c9facd..deffb1a 100644
--- a/drivers/isimodem/gprs.c
+++ b/drivers/isimodem/gprs.c
@@ -259,7 +259,7 @@ static GIsiRequest *attach_request_send(GIsiClient *client, void
*data)
{
const unsigned char msg[] = {
GPDS_ATTACH_REQ,
- GPDS_FOLLOW_OFF
+ GPDS_FOLLOW_ON
};
return g_isi_send(client, msg, sizeof(msg), GPDS_TIMEOUT,
--
1.7.1
7:02 p.m.
Hi Mika,
On 12/02/2010 10:16 AM, Mika Liljeberg wrote:
Hi All,
Currently, if GPRS service is detached for whatever reason, the only way
to get PS services back is to set the Powered property to FALSE and back
to TRUE.
With these patches, GPRS context activation will cause oFono to
automatically attempt GPRS attach if the modem is presently detached.
Before I look at these patches: Have you considered fixing the attach
behavior instead? It seems like the approach you're proposing is
essentially hitting oFono over the head because it isn't doing what you
want...
Regards,
-Denis
7:12 p.m.
Hi Denis,
> With these patches, GPRS context activation will cause oFono to
> automatically attempt GPRS attach if the modem is presently
detached.
>
Before I look at these patches: Have you considered fixing the attach
behavior instead?
I'm not quite sure what you mean here. There are many different cases, where the
network can detach a UE from GPRS service. See possible detach causes in 24.008.
Currently, oFono does not recover at all. Trying to figure out when GPRS is again
available can get pretty complicated and the different detach causes require different
handling. IMO, the simplest approach by far is to retry GPRS attach when someone actually
needs a PDP context.
It seems like the approach you're proposing is
essentially hitting oFono over the head because it isn't
doing what you
want...
Sorry, still confused. What do you mean?
MikaL
8:22 p.m.
Hi Mika,
On 12/09/2010 02:12 AM, Mika.Liljeberg(a)nokia.com wrote:
Hi Denis,
>> With these patches, GPRS context activation will cause oFono to
>> automatically attempt GPRS attach if the modem is presently
> detached.
>>
>
> Before I look at these patches: Have you considered fixing the attach
> behavior instead?
I'm not quite sure what you mean here. There are many different cases, where the
network can detach a UE from GPRS service. See possible detach causes in 24.008.
Currently, oFono does not recover at all. Trying to figure out when GPRS is again
available can get pretty complicated and the different detach causes require different
handling. IMO, the simplest approach by far is to retry GPRS attach when someone actually
needs a PDP context.
So here's the problem, ConnMan is in charge of activating the context on
Meego. ConnMan activates the context once we're attached. So how do
you expect your 'on-demand' re-attach to work exactly?
Besides, 24.008 cause codes give us plenty of hints of whether / when to
re-attach, and only a few of them require 'special' handling.
I still think that we should come up with some strategy to re-attach
automatically when detached by the network.
Regards,
-Denis
8:57 p.m.
Hi Denis,
> I'm not quite sure what you mean here. There are many
different cases, where the network can detach a UE from GPRS
service. See possible detach causes in 24.008. Currently,
oFono does not recover at all. Trying to figure out when GPRS
is again available can get pretty complicated and the
different detach causes require different handling. IMO, the
simplest approach by far is to retry GPRS attach when someone
actually needs a PDP context.
So here's the problem, ConnMan is in charge of activating the
context on
Meego. ConnMan activates the context once we're attached. So how do
you expect your 'on-demand' re-attach to work exactly?
ConnMan really should not care whether we are attached or not. Why do you need a trigger
in ConnMan, anyway? As far as I can see, a GPRS connection should only be activated if
some client of ConnMan requests it.
Besides, 24.008 cause codes give us plenty of hints of
whether / when to
re-attach, and only a few of them require 'special' handling.
I still think that we should come up with some strategy to re-attach
automatically when detached by the network.
Even if you can come up with an algorithm, testing it is very very challenging. There are
plenty of differences in operator networks and it is very difficult to cover all cases.
Making sure that the algorithm works requires extensive IOT and Field testing. We really
don't want a case, where oFono fails to re-attach for whatever reason. We also
don't want the case where oFono has not yet attempted to re-attach (e.g. on a timer)
and a PDP context activation fails, even though GPRS would actually be available.
For the above reasons, retrying attach on PDP context activation makes sense as a
safe-guard, regardless of whether we have a re-attach algorithm or not. We use on-demand
attach in pretty much all our products (except for certain operator specific variants)
precisely because it is certain to work. No funny business. If there is GPRS service, you
get a connection. It is also an approach that should work with any AT modem as well.
Br,
MikaL
9:12 p.m.
Hi Mika,
On 12/09/2010 03:57 AM, Mika.Liljeberg(a)nokia.com wrote:
Hi Denis,
>> I'm not quite sure what you mean here. There are many
> different cases, where the network can detach a UE from GPRS
> service. See possible detach causes in 24.008. Currently,
> oFono does not recover at all. Trying to figure out when GPRS
> is again available can get pretty complicated and the
> different detach causes require different handling. IMO, the
> simplest approach by far is to retry GPRS attach when someone
> actually needs a PDP context.
>
> So here's the problem, ConnMan is in charge of activating the
> context on
> Meego. ConnMan activates the context once we're attached. So how do
> you expect your 'on-demand' re-attach to work exactly?
ConnMan really should not care whether we are attached or not. Why do you need a trigger
in ConnMan, anyway? As far as I can see, a GPRS connection should only be activated if
some client of ConnMan requests it.
Actually it should care. We do safe-guard against attaching while
roaming...
Besides, ConnMan doesn't really work this way. Maybe in the future with
the session API it would be able to, but not at the moment. I'll let
Marcel explain this more if he wants too..
> Besides, 24.008 cause codes give us plenty of hints of
> whether / when to
> re-attach, and only a few of them require 'special' handling.
>
> I still think that we should come up with some strategy to re-attach
> automatically when detached by the network.
Even if you can come up with an algorithm, testing it is very very challenging. There are
plenty of differences in operator networks and it is very difficult to cover all cases.
Making sure that the algorithm works requires extensive IOT and Field testing. We really
don't want a case, where oFono fails to re-attach for whatever reason. We also
don't want the case where oFono has not yet attempted to re-attach (e.g. on a timer)
and a PDP context activation fails, even though GPRS would actually be available.
For the above reasons, retrying attach on PDP context activation makes sense as a
safe-guard, regardless of whether we have a re-attach algorithm or not. We use on-demand
attach in pretty much all our products (except for certain operator specific variants)
precisely because it is certain to work. No funny business. If there is GPRS service, you
get a connection. It is also an approach that should work with any AT modem as well.
You might be right, but I'd really like to see whether the re-attach
algorithm would be good enough first...
Regards,
-Denis
9:27 p.m.
Hi Mika,
> > I'm not quite sure what you mean here. There are many
> different cases, where the network can detach a UE from GPRS
> service. See possible detach causes in 24.008. Currently,
> oFono does not recover at all. Trying to figure out when GPRS
> is again available can get pretty complicated and the
> different detach causes require different handling. IMO, the
> simplest approach by far is to retry GPRS attach when someone
> actually needs a PDP context.
>
> So here's the problem, ConnMan is in charge of activating the
> context on
> Meego. ConnMan activates the context once we're attached. So how do
> you expect your 'on-demand' re-attach to work exactly?
ConnMan really should not care whether we are attached or not. Why do you need a trigger
in ConnMan, anyway? As far as I can see, a GPRS connection should only be activated if
some client of ConnMan requests it.
so what about the cases when roaming is allowed or not? These needs to
be taken into account and that is oFono's job. That is the reason why
ConnMan follows the attach state. Since we don't wanna activate a
context when roaming and data roaming is not allowed.
> Besides, 24.008 cause codes give us plenty of hints of
> whether / when to
> re-attach, and only a few of them require 'special' handling.
>
> I still think that we should come up with some strategy to re-attach
> automatically when detached by the network.
Even if you can come up with an algorithm, testing it is very very challenging. There are
plenty of differences in operator networks and it is very difficult to cover all cases.
Making sure that the algorithm works requires extensive IOT and Field testing. We really
don't want a case, where oFono fails to re-attach for whatever reason. We also
don't want the case where oFono has not yet attempted to re-attach (e.g. on a timer)
and a PDP context activation fails, even though GPRS would actually be available.
I don't think such an algorithm is hard. Either we are forbidden, then
we wait until we switch to a new cell. Otherwise we will just retry to
attach.
For the above reasons, retrying attach on PDP context activation
makes sense as a safe-guard, regardless of whether we have a re-attach algorithm or not.
We use on-demand attach in pretty much all our products (except for certain operator
specific variants) precisely because it is certain to work. No funny business. If there is
GPRS service, you get a connection. It is also an approach that should work with any AT
modem as well.
This is really not ConnMan's problem and I don't wanna make it ConnMan's
problem.
I am really against just pushing this problem off to someone else. And
in ConnMan we have even less information to decide what happens when
context activation fails. The algorithm to handle such rare error
conditions smoothly becomes more complicated than making this easier.
So I agree with Denis that we need to fix this inside oFono and just try
to intelligently re-attach.
Regards
Marcel
10:41 p.m.
Hi Denis,
> ConnMan really should not care whether we are attached or
not. Why do you need a trigger in ConnMan, anyway? As far as
I can see, a GPRS connection should only be activated if some
client of ConnMan requests it.
Actually it should care. We do safe-guard against attaching while
roaming...
I don't think so. Preventing GPRS attach and GPRS context activation during roaming
can be done based on network registation status. Besides, oFono probably should be the
component to enforce it, so that the feature cannot be easily bypassed.
Besides, ConnMan doesn't really work this way. Maybe in the
future with
the session API it would be able to, but not at the moment. I'll let
Marcel explain this more if he wants too..
Admittedly, I haven't really looked at ConnMan. My assumption, though, is that a PDP
context is not activated by default when ConnMan starts up. I.e., someone has to request
the internet connectivity. Is that correct? Activating a context by default would be very
bad for power consumption and standby times, unless both the handset and the network
support CPC. The decision should be up to the user.
>> Besides, 24.008 cause codes give us plenty of hints of
>> whether / when to
>> re-attach, and only a few of them require 'special' handling.
>>
>> I still think that we should come up with some strategy to
re-attach
>> automatically when detached by the network.
>
> Even if you can come up with an algorithm, testing it is
very very challenging. There are plenty of differences in
operator networks and it is very difficult to cover all
cases. Making sure that the algorithm works requires
extensive IOT and Field testing. We really don't want a case,
where oFono fails to re-attach for whatever reason. We also
don't want the case where oFono has not yet attempted to
re-attach (e.g. on a timer) and a PDP context activation
fails, even though GPRS would actually be available.
>
> For the above reasons, retrying attach on PDP context
activation makes sense as a safe-guard, regardless of whether
we have a re-attach algorithm or not. We use on-demand attach
in pretty much all our products (except for certain operator
specific variants) precisely because it is certain to work.
No funny business. If there is GPRS service, you get a
connection. It is also an approach that should work with any
AT modem as well.
>
You might be right, but I'd really like to see whether the re-attach
algorithm would be good enough first...
But what re-attach algorithm? I sure don't have one up my sleeve...
As I said, extensive IOT and field testing (with mobility) is necessary in order to see
how the prospective algorithm works in practise. Even then, you can't possibly cover
all the angles. In practise, you end up discovering the rest of the glitches when the
first products are already out there. That is a very expensive road indeed for a feature
that is a bit dubious to begin with.
Why are we attaching to GPRS by default, anyway?
That said, various operators tend to have different requirements on this. Some want
autoattach, some want on-demand attach, and some want a UI for changing the mode. In
practise we will probably need at least a variation point on this and possibly a setting
to change the behaviour. I'd propose starting by adding the on-demand attach code, to
make sure that GPRS at least works in all cases.
MikaL
10:49 p.m.
Hi Marcel,
so what about the cases when roaming is allowed or not? These needs
to
be taken into account and that is oFono's job. That is the reason why
ConnMan follows the attach state. Since we don't wanna activate a
context when roaming and data roaming is not allowed.
Ok, I see the concern. I'd propose making GPRS availability a separate property from
GPRS attach status. Availability can be decided on registration status alone (i.e., does
the network advertise GPRS and does the roaming check allow GPRS). Both GPRS attach and
PDP context activation can in any case fail for transient reasons, so ConnMan needs to
have some logic to retry context activation.
Br,
MikaL
11:40 p.m.
<Mika.Liljeberg(a)nokia.com> writes:
> Besides, ConnMan doesn't really work this way. Maybe in the
future
> with the session API it would be able to, but not at the moment. I'll
> let Marcel explain this more if he wants too..
Admittedly, I haven't really looked at ConnMan. My assumption, though,
is that a PDP context is not activated by default when ConnMan starts
up. I.e., someone has to request the internet connectivity. Is that
correct?
Connman services have autoconnect property which control if the
connection is automatically created or not.
Activating a context by default would be very bad for power
consumption and standby times, unless both the handset and the network
support CPC.
If I plugin a usb modem on my laptop, I really want to connect it
automatically.
The decision should be up to the user.
And with the autoconnect property the user can control this.
--
Kalle Valo
8:27 p.m.
Hi Marcel,
I somehow missed your other comments on this mail. More responses below.
> Even if you can come up with an algorithm, testing it is
very very challenging. There are plenty of differences in
operator networks and it is very difficult to cover all
cases. Making sure that the algorithm works requires
extensive IOT and Field testing. We really don't want a case,
where oFono fails to re-attach for whatever reason. We also
don't want the case where oFono has not yet attempted to
re-attach (e.g. on a timer) and a PDP context activation
fails, even though GPRS would actually be available.
I don't think such an algorithm is hard. Either we are forbidden, then
we wait until we switch to a new cell.
Mostly that would be just a waste of power. Some of the errors are PLMN or LA specific, so
retrying at cell change would be redundant. A proper retry strategy would have to be based
on the detach reason and any subsequent attach failure causes. In general, activating the
RF all the time, when no-one has even requested a PDP context is simply bad idea. There
are better uses for the battery power.
And yes, coming up with an algorithm (whatever it is) is probably easy enough. Making sure
it works with all the networks and modems out there is the hard part.
Otherwise we will just retry to attach.
That's also tricky. What do you do if the attach attempt fails? Retry again? How
often? Use some kind of backoff?
> For the above reasons, retrying attach on PDP context
activation makes sense as a safe-guard, regardless of whether
we have a re-attach algorithm or not. We use on-demand attach
in pretty much all our products (except for certain operator
specific variants) precisely because it is certain to work.
No funny business. If there is GPRS service, you get a
connection. It is also an approach that should work with any
AT modem as well.
This is really not ConnMan's problem and I don't wanna make
it ConnMan's
problem.
I am really against just pushing this problem off to someone else.
No-one is proposing to. You're actually making this ConnMan's problem by
monitoring the GPRS attach status. If ConnMan needs a trigger, it should be based on
network registration status alone.
And
in ConnMan we have even less information to decide what happens when
context activation fails.
Unfortunately, oFono cannot hide context activation failures from ConnMan. ConnMan will
just have to cope, regardless of what we do with attach.
The algorithm to handle such rare error
conditions smoothly becomes more complicated than making this easier.
As far as I can see, the approach I'm proposing is simpler than the one you and Denis
are proposing.
So I agree with Denis that we need to fix this inside oFono
and just try
to intelligently re-attach.
As I already explained to Denis, it's not really a choise between one or the other.
Some opearators require autoattach, some require on-demand attach and some require a UI to
change the mode. All of these should be supported. So, by all means develop a re-attach
algorith. It won't be easy to maturize, though. Using context activation requests as a
triggers to retry attach simply makes a lot of sense as a safe-guard, even if we're in
autoattach mode. If anything, it removes one potential failure case.
Br,
MikaL
4300
days inactive
4308
days old
13 comments
5 participants
participants (5)
-
Denis Kenzior -
Kalle Valo -
Marcel Holtmann -
Mika Liljeberg -
Mika.Liljeberg＠nokia.com