Controlling GPRS connections through Ofono in the presence of Connman

Controlling GPRS connections through Ofono in the presence of Connman

[Frederik Lotter]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Hi,

I am working on uBlox support in Ofono. My aim is further than the
traditional desktop type use case, so I am extending Ofono with a custom
APN provisioning service.

I want to get some tips on how I should proceed because I do not wish to go
into an unintentional direction.

We have 3rd party software that needs to finely control the GPRS session,
constantly monitoring and switching APN's as the network changes.

I need a way for our software to know when the context has successfully
been activated, for example a post_context_activate() in the driver would
be great, so that I could add a DBUS message in our custom driver which
send states to our software in order to know when a socket could be opened
(not only the post_context_activate() but I also need the other states the
driver will enter).

Is there a better approach than adding a callback for successful context
activation in the driver, in Ofono? I feel like Connman is too distant and
unaware of detailed Ofono states to manage this on the Connman side.

Secondly, I have tested changing states on the Ofono side with the Python
scripts (enable -> online ) and visa versa and connman seems OK with me
doing this. I plan to do this from my 3rd party application to manage APNs
and sockets. Is this an acceptable use case with Connman, it seems like it
has been designed so that Connman always gets updates on Ofono state
changes.

Kind Regards,
Frederik Lotter

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1652 bytes --]

Re: Controlling GPRS connections through Ofono in the presence of Connman

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

Hi Frederik,

On 07/15/2014 02:03 AM, Frederik Lotter wrote:
> Hi,
> 
> I am working on uBlox support in Ofono. My aim is further than the
> traditional desktop type use case, so I am extending Ofono with a custom
> APN provisioning service.
> 
> I want to get some tips on how I should proceed because I do not wish to
> go into an unintentional direction.
> 
> We have 3rd party software that needs to finely control the GPRS
> session, constantly monitoring and switching APN's as the network changes. 
> 
> I need a way for our software to know when the context has successfully
> been activated, for example a post_context_activate() in the driver

The driver is already performing the "callback" into the core.  So what
you're looking for is probably something.  Perhaps something similar to
__ofono_netreg_add_status_watch.  Before you go there though...

> would be great, so that I could add a DBUS message in our custom driver
> which send states to our software in order to know when a socket could
> be opened (not only the post_context_activate() but I also need the
> other states the driver will enter). 

Since you are sending a D-Bus message anyway, is it not possible for the
3rd party software to monitor the oFono context state directly?  E.g.
the org.ofono.ConnectionContext.Active Property seems to do exactly what
you need.  What other states do you require?

> 
> Is there a better approach than adding a callback for successful context
> activation in the driver, in Ofono? I feel like Connman is too distant
> and unaware of detailed Ofono states to manage this on the Connman side. 
> 
> Secondly, I have tested changing states on the Ofono side with the
> Python scripts (enable -> online ) and visa versa and connman seems OK
> with me doing this. I plan to do this from my 3rd party application to
> manage APNs and sockets. Is this an acceptable use case with Connman, it
> seems like it has been designed so that Connman always gets updates on
> Ofono state changes.

All clients of oFono are notified of state changes regardless of which
client initiated a particular state change.  So ConnMan should be just
fine with you manipulating the context states from other clients.  You
might interfere with some auto-connect / reconnect behavior there, but
sounds like you don't want that behavior active anyway.

Regards,
-Denis

Re: Controlling GPRS connections through Ofono in the presence of Connman

[Frederik Lotter]

[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]

Hi Denis,

Thank you very much for the reply.

I have one question remaining, which comes back to detection when my ppp
connection is up in the Linux network stack.

Will the "ConnectionContext.Active" property not only indicate the Ofono
side is done? I was under the understanding that Connman still has to
assign the IP and modify the routing table before I can open a socket for
comms? Is this something I need to check against a Connman property?

Kind Regards,
Fred


On 15 July 2014 15:27, Denis Kenzior <denkenz@gmail.com> wrote:

> Hi Frederik,
>
> On 07/15/2014 02:03 AM, Frederik Lotter wrote:
> > Hi,
> >
> > I am working on uBlox support in Ofono. My aim is further than the
> > traditional desktop type use case, so I am extending Ofono with a custom
> > APN provisioning service.
> >
> > I want to get some tips on how I should proceed because I do not wish to
> > go into an unintentional direction.
> >
> > We have 3rd party software that needs to finely control the GPRS
> > session, constantly monitoring and switching APN's as the network
> changes.
> >
> > I need a way for our software to know when the context has successfully
> > been activated, for example a post_context_activate() in the driver
>
> The driver is already performing the "callback" into the core.  So what
> you're looking for is probably something.  Perhaps something similar to
> __ofono_netreg_add_status_watch.  Before you go there though...
>
> > would be great, so that I could add a DBUS message in our custom driver
> > which send states to our software in order to know when a socket could
> > be opened (not only the post_context_activate() but I also need the
> > other states the driver will enter).
>
> Since you are sending a D-Bus message anyway, is it not possible for the
> 3rd party software to monitor the oFono context state directly?  E.g.
> the org.ofono.ConnectionContext.Active Property seems to do exactly what
> you need.  What other states do you require?
>
> >
> > Is there a better approach than adding a callback for successful context
> > activation in the driver, in Ofono? I feel like Connman is too distant
> > and unaware of detailed Ofono states to manage this on the Connman side.
> >
> > Secondly, I have tested changing states on the Ofono side with the
> > Python scripts (enable -> online ) and visa versa and connman seems OK
> > with me doing this. I plan to do this from my 3rd party application to
> > manage APNs and sockets. Is this an acceptable use case with Connman, it
> > seems like it has been designed so that Connman always gets updates on
> > Ofono state changes.
>
> All clients of oFono are notified of state changes regardless of which
> client initiated a particular state change.  So ConnMan should be just
> fine with you manipulating the context states from other clients.  You
> might interfere with some auto-connect / reconnect behavior there, but
> sounds like you don't want that behavior active anyway.
>
> Regards,
> -Denis
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4010 bytes --]

Re: Controlling GPRS connections through Ofono in the presence of Connman

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Hi Frederik,

Just a gentle reminder not to top post on this mailing list.

>
> Will the "ConnectionContext.Active" property not only indicate the Ofono
> side is done? I was under the understanding that Connman still has to
> assign the IP and modify the routing table before I can open a socket
> for comms? Is this something I need to check against a Connman property? 
> 

If you are using ConnMan, then yes you would have to monitor the
relevant ConnMan properties.  oFono lets the network management daemon
deal with the IP assignment.  Of course you can always write your own
network management handling code specifically for your use case...

Regards,
-Denis