From: Richard Röjfors
The callback calls cgact and cgdcont to get information
regarding any activate context.
---
drivers/atmodem/gprs.c | 167 +
1 file changed, 134 insertions(+), 33 deletions(-)
diff --git a/drivers/atmodem/gprs.c
From: Richard Röjfors
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
So ignore the activated contexts until gprs is ready,
then it calls
From: Richard Röjfors
This is useful for instance during startup where early
activated contexts can be listed at a suitable point in time.
---
include/gprs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/gprs.h b/include/gprs.h
index 988d6102..20bdb7a4 100644
---
Hi Richard,
On 8/12/19 3:37 PM, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
There are cases where the gprs status might updated to for instance
"unknown" while LTE is the bearer.
In that case we should not set the attach state to FALSE,
since then running LTE the conext activation
Hi Richard,
On 8/12/19 3:18 PM, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
The callback calls cgact and cgdcont to get information
regarding any activate context.
---
drivers/atmodem/gprs.c | 149 -
1 file changed, 116 insertions(+), 33
If the modem isn't powered on, the use of g_at_chat_set_wakeup_command()
makes ofono send out AT strings in an endless loop. Avoid this by using
g_at_chat_retry() in a timer instead.
---
plugins/quectel.c | 64 +++
1 file changed, 53 insertions(+), 11
The current API doesn't support canceling an in-progress command;
instead g_at_chat_cancel() simply removes the callback.
In cases where the modem doesn't respond at all to a command, a chat is
simply stalled without any way to write new commands to the modem.
Support that case by adding a
From: Richard Röjfors
There are cases where the gprs status might updated to for instance
"unknown" while LTE is the bearer.
In that case we should not set the attach state to FALSE,
since then running LTE the conext activation reflects the attached
state.
---
src/gprs.c | 23
Hi Richard,
On 8/12/19 3:18 PM, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
This is useful for instance during startup where early
activated contexts can be listed at a suitable point in time.
---
include/gprs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Richard Röjfors
This is useful for instance during startup where early
activated contexts can be listed at a suitable point in time.
---
include/gprs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/gprs.h b/include/gprs.h
index 988d6102..c276517f 100644
---
From: Richard Röjfors
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
So ignore the activated contexts until gprs is ready,
then it calls
From: Richard Röjfors
The callback calls cgact and cgdcont to get information
regarding any activate context.
---
drivers/atmodem/gprs.c | 149 -
1 file changed, 116 insertions(+), 33 deletions(-)
diff --git a/drivers/atmodem/gprs.c
Hi Richard,
I have more in the pipeline regarding this, I'm kind of working step by step
to get LTE to work properly and with hand over to come.
Nice! About time someone looked into this :)
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
Hi Denis,
Den mån 12 aug. 2019 kl 21:57 skrev Denis Kenzior :
> Hi Richard,
>
> > So I don't get this. We have CREG telling us: "we're on LTE" and
> CGREG
> > telling us "Oh we don't know what our status is". Why do you trust
> one
> > and not the other? Are you sure this doesn't
Hi Richard,
list_active_contexts? Also, since there can in theory be multiple ones
of these, I'd do something like:
typedef void (*ofono_gprs_active_context_cb_t)(int cid, const char *apn,
void *data);
void
Hi Richard,
So I don't get this. We have CREG telling us: "we're on LTE" and CGREG
telling us "Oh we don't know what our status is". Why do you trust one
and not the other? Are you sure this doesn't belong in a driver quirk
somewhere?
When CREG tells us we are on LTE, we
Hi Denis,
Den mån 12 aug. 2019 kl 19:28 skrev Denis Kenzior :
> Hi Richard,
>
> >> +void (*get_active_auto_context)(struct ofono_gprs *gprs,
> >> +ofono_gprs_active_context_cb_t cb,
> >> +void *data);
> >
> > list_active_contexts? Also, since there
Hi Denis,
Den mån 12 aug. 2019 kl 19:10 skrev Denis Kenzior :
> Hi Richard,
>
> On 8/11/19 11:46 AM, richard.rojf...@gmail.com wrote:
> > From: Richard Röjfors
> >
> > There is an issue if an context gets auto activated early,
> > then provisioning might not have run yet for instance,
> > so a
Hi Denis,
Den mån 12 aug. 2019 kl 18:58 skrev Denis Kenzior :
> Hi Richard,
>
> On 8/11/19 9:58 AM, richard.rojf...@gmail.com wrote:
> > From: Richard Röjfors
> >
> > There are cases where the gprs status might updated to for instance
> > "unknown" while LTE is the bearer.
> > In that case we
Hi Richard,
+ void (*get_active_auto_context)(struct ofono_gprs *gprs,
+ ofono_gprs_active_context_cb_t cb,
+ void *data);
list_active_contexts? Also, since there can in theory be multiple ones
of these, I'd do something like:
typedef void
Hi Richard,
On 8/11/19 11:46 AM, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
Hi Richard,
On 8/11/19 9:58 AM, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
There are cases where the gprs status might updated to for instance
"unknown" while LTE is the bearer.
In that case we should not set the attach state to FALSE,
since then running LTE the conext activation
Hi Pavel,
On 8/12/19 3:22 AM, Pavel Machek wrote:
Hi!
Droid 4 has ... something similar to AT commands, but not quite. For
voice calls, I modified atmodem... but I guess there are so many
changes that creating separate motorolamodem/voicecall.c might be
an option? (send_clcc() changes make
Hi Pavel,
On 8/10/19 6:14 PM, Pavel Machek wrote:
Hi!
Motorola Droid 4 runs packet protocol over serial... and its kernel
driver requires explicit "write()" boundaries at places where packet
boundaries should be.
So I can send SMS using low level g_at... functions (that are not
normally
Hi!
Droid 4 has ... something similar to AT commands, but not quite. For
voice calls, I modified atmodem... but I guess there are so many
changes that creating separate motorolamodem/voicecall.c might be
an option? (send_clcc() changes make sense as a cleanup, and were sent
in separate mail.)
Hi Giacinto,
On 8/11/19, Giacinto Cifelli wrote:
> can you check with the ofono script test/list-contexts if the method
> is static or dhcp?
# ofono/test/list-contexts
[ /ubloxqmi_0 ]
[ /ubloxqmi_0/context1 ]
Name = Internet
Type = internet
AuthenticationMethod =
26 matches
Mail list logo
