12:09 p.m.
Hello List,
I started working on Ofono GPRS support.
The patch set contains:
1) Documentation describing how an Ofono GPRS D-Bus API would look like.
2) Common Ofono GPRS support.
3) Ofono GPRS ISI driver.
4) Test script for trying out the GPRS functionality.
Note that the GPRS support is in no way completed -- many things are
still TODO or have rough edges. However, I thought that it would be a
good idea to send the patches to the mailing list to gather comments
and improvement suggestions before finalizing the work.
PS. A disclaimer: I'm a Nokia engineer, even though I'm sending this
email from my personal email account (due to incompatibilities with
Nokia email servers). If you need to contact me off-the-list, please
use the email address ismo.h.puustinen(a)nokia.com .
--
Ismo Puustinen <ismo(a)iki.fi>
8:02 p.m.
Ismo Puustinen a écrit :
I started working on Ofono GPRS support.
Hello,
With GPRS support, Ofono become very interesting!
I failed to understand how the "isi_gprs" code in your patch communicate
with a PPP stack. For example, I currently use a project where the APN
is configured and a connection open with it. Then a pppd process is
started to establish the IP link. It seem that you make this in a other
(and certainly better) way, but I missed the big picture.
Best Regards,
Jean-Christian de Rivaz
8:25 p.m.
Le mardi 1 septembre 2009 22:02:43 Jean-Christian de Rivaz, vous avez écrit :
With GPRS support, Ofono become very interesting!
I failed to understand how the "isi_gprs" code in your patch communicate
with a PPP stack.
That would be because it does NOT use a PPP stack.
ISI modems have their own IP path using a dedicated kernel driver
(net/phonet/pep-gprs.c in Linux 2.6.28 amd later). There is no point in using
the PPP line discipline.
--
Rémi Denis-Courmont
http://www.remlab.net/
9:17 p.m.
Rémi Denis-Courmont a écrit :
Le mardi 1 septembre 2009 22:02:43 Jean-Christian de Rivaz, vous avez
écrit :
> With GPRS support, Ofono become very interesting!
>
> I failed to understand how the "isi_gprs" code in your patch communicate
> with a PPP stack.
That would be because it does NOT use a PPP stack.
ISI modems have their own IP path using a dedicated kernel driver
(net/phonet/pep-gprs.c in Linux 2.6.28 amd later). There is no point in using
the PPP line discipline.
Thanks for the explanation. I will start learning how phonet works. But
I expect there exists a PPP stack somewhere in phonet because the modem
I use don't have one. And I don't think it's possible to have a IP link
over GPRS without the PPP protocol between them.
Jean-Christian de Rivaz
9:26 p.m.
Le mardi 1 septembre 2009 23:17:36 Jean-Christian de Rivaz, vous avez écrit :
Thanks for the explanation. I will start learning how phonet works.
But
I expect there exists a PPP stack somewhere in phonet because the modem
I use don't have one.
ISI modems have a PPP "server-side" implementation to handle USB CDC ACM and
BlueTooth DUN. But there is only one instance per modem, so we reserve it for
the dumb Windows PC that we may be connected to ;)
And I don't think it's possible to have a IP link
over GPRS without the PPP protocol between them.
It might be possible in the standard, but I have not found any network
offering such a PP over GPRS data service.
--
Rémi Denis-Courmont
http://www.remlab.net/
9:30 p.m.
On Tue, Sep 01, 2009 at 15:17:36, Jean-Christian de Rivaz wrote:
Thanks for the explanation. I will start learning how phonet works.
But I expect there exists a PPP stack somewhere in phonet because the
modem I use don't have one. And I don't think it's possible to have a
IP link over GPRS without the PPP protocol between them.
On most modern modems there is no need to have a PPP link between the Application
Processor (AP) and the modem. They will often be able to transmit IP traffic directly to
the AP.
Hence there is no PPP stack in phonet. If your modem does not support raw IP messaging (or
any other datagram service) to the AP you will probably be stuck with good old PPP.
8:27 p.m.
On Tue, Sep 01, 2009 at 14:02:43, Jean-Christian de Rivaz wrote:
I failed to understand how the "isi_gprs" code in your
patch
communicate with a PPP stack. For example, I currently use a project
where the APN is configured and a connection open with it. Then a pppd
process is started to establish the IP link. It seem that you make
this in a other (and certainly
better) way, but I missed the big picture.
The best way to do this is without PPP and this is probably what Ismo is doing. You would
just create a new net_device like "eth0" and hide all the ISI and cellular
messaging behind that interface providing a clean IP network device.
Best regards,
Mikkel Christensen
10:36 p.m.
Everyone,
So as it happens I had also been brainstorming a GPRS API for the last several
days. And somewhat spontaneously a GPRS api discussion happened on IRC
between myself, Marcel and Ismo. The following GPRS API proposal is a result
of this discussion. I'd like all interested to comment. What needs
improvement? What is missing? What should be removed?
Please note that Secondary PDP contexts, Traffic Filters and Network Activated
(Incoming) PDP contexts are not covered in this proposal. These features are
not commonly used and none of us have real experience with them yet. However,
we considered these features and have left room in the APIs for further
expansion.
Data Connection Manager hierarchy
=================
Service org.ofono
Interface org.ofono.DataConnectionManager
Object path [variable]
Methods dict GetProperties()
Returns all global system properties. See the
properties section for available properties.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
void DeactivateAll()
Deactivates all active contexts.
object CreateContext()
Creates a new Primary context. Returns the object
path of the created context.
object RemoveContext()
Removes a primary context. All secondary contexts, if
any, associated with the primary context are also
removed.
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Properties array{object} PrimaryContexts [readonly]
List of all primary contexts objects.
boolean Attached [readonly]
Contains whether the Packet Radio Service is attached.
The attach state might change dynamically based on
availability of network resources. If this value
changes to false, the user can assume that all
contexts have been deactivated.
If the modem is detached, certain features will not
be available, e.g. receiving SMS over packet radio
or network initiated PDP activation.
boolean RoamingAllowed [readwrite]
Contains whether data roaming is allowed. In the off
setting, if the packet radio registration state
indicates that the modem is roaming, oFono will
automatically detach and no further connection
establishment will be possible.
boolean Powered [readwrite]
Controls whether packet radio use is allowed. Setting
this value to off detaches the modem from the
Packet Domain network.
string Status [readonly]
The current packet radio registration status of a modem.
The possible values are:
"unregistered" Not registered to any network
"registered" Registered to home network
"searching" Not registered, but searching
"denied" Registration has been denied
"unknown" Status is unknown
"roaming" Registered, but roaming
uint16 LocationAreaCode [readonly, optional]
Contains the current location area code.
uint32 CellId [readonly, optional]
Contains the current network cell id.
string Technology [readonly, optional]
Contains the technology of the current network.
The possible values are: "GSM", "GSMCompact", "UTRAN",
"GSM+EGPS", "UTRAN+HSDPA",
"UTRAN+HSUPA",
"UTRAN+HSDPA+HSUPA",
"E-UTRAN"
Primary Data Context hierarchy
=================
Service org.ofono
Interface org.ofono.PrimaryDataContext
Object path [variable]
Methods dict GetProperties()
Returns all properties for the context object.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Properties boolean Activated [readwrite]
Holds whether the context is activated. This value
can be set to activate / deactivate the context.
string AccessPointName [readwrite]
Holds the name of the access point. This is
abbreviated as APN. This value cannot be changed when
the context is active.
string Username [readwrite]
Holds the username to be used for authentication
purposes. This value cannot be changed when the
context is active.
string Password [readwrite]
Holds the password to be used for authentication
purposes. This value cannot be changed when the
context is active.
string Interface [readonly, optional]
Holds the interface of the network interface created
by this context (e.g. "ppp0")
array{string} DomainNameServers [readonly, optional]
Holds the list of domain name servers for this
context.
Regards,
-Denis
11:42 p.m.
Hi Denis,
So as it happens I had also been brainstorming a GPRS API for the
last several
days. And somewhat spontaneously a GPRS api discussion happened on IRC
between myself, Marcel and Ismo. The following GPRS API proposal is a result
of this discussion. I'd like all interested to comment. What needs
improvement? What is missing? What should be removed?
Please note that Secondary PDP contexts, Traffic Filters and Network Activated
(Incoming) PDP contexts are not covered in this proposal. These features are
not commonly used and none of us have real experience with them yet. However,
we considered these features and have left room in the APIs for further
expansion.
Data Connection Manager hierarchy
=================
Service org.ofono
Interface org.ofono.DataConnectionManager
I think this should be GPRSManager or something to clearly separate
between GRPS connections and actual data connection,
Object path [variable]
Methods dict GetProperties()
Returns all global system properties. See the
properties section for available properties.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
void DeactivateAll()
Deactivates all active contexts.
object CreateContext()
Creates a new Primary context. Returns the object
path of the created context.
object RemoveContext()
Removes a primary context. All secondary contexts, if
any, associated with the primary context are also
removed.
I assume this is void RemoveContext(object context)
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Properties array{object} PrimaryContexts [readonly]
List of all primary contexts objects.
Calling this just Contexts seems to more reasonable. See comment about
interface name below.
boolean Attached [readonly]
Contains whether the Packet Radio Service is attached.
The attach state might change dynamically based on
availability of network resources. If this value
changes to false, the user can assume that all
contexts have been deactivated.
If the modem is detached, certain features will not
be available, e.g. receiving SMS over packet radio
or network initiated PDP activation.
boolean RoamingAllowed [readwrite]
Contains whether data roaming is allowed. In the off
setting, if the packet radio registration state
indicates that the modem is roaming, oFono will
automatically detach and no further connection
establishment will be possible.
boolean Powered [readwrite]
Controls whether packet radio use is allowed. Setting
this value to off detaches the modem from the
Packet Domain network.
string Status [readonly]
The current packet radio registration status of a modem.
The possible values are:
"unregistered" Not registered to any network
"registered" Registered to home network
"searching" Not registered, but searching
"denied" Registration has been denied
"unknown" Status is unknown
"roaming" Registered, but roaming
uint16 LocationAreaCode [readonly, optional]
Contains the current location area code.
uint32 CellId [readonly, optional]
Contains the current network cell id.
string Technology [readonly, optional]
Contains the technology of the current network.
The possible values are: "GSM", "GSMCompact", "UTRAN",
"GSM+EGPS", "UTRAN+HSDPA",
"UTRAN+HSUPA",
"UTRAN+HSDPA+HSUPA",
"E-UTRAN"
Primary Data Context hierarchy
=================
Service org.ofono
Interface org.ofono.PrimaryDataContext
I would prefer if we just call this GRPSContext and explain that this is
for the primary context. The confusion between primary context and
secondary context is some GSM specific non-sense.
Object path [variable]
Methods dict GetProperties()
Returns all properties for the context object.
Possible Errors: [service].Error.InvalidArguments
void SetProperty(string property, variant value)
Sets the property to a desired value
Possible Errors: [service].Error.InvalidArguments
[service].Error.InvalidFormat
[service].Error.Failed
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Properties boolean Activated [readwrite]
Holds whether the context is activated. This value
can be set to activate / deactivate the context.
string AccessPointName [readwrite]
Holds the name of the access point. This is
abbreviated as APN. This value cannot be changed when
the context is active.
string Username [readwrite]
Holds the username to be used for authentication
purposes. This value cannot be changed when the
context is active.
string Password [readwrite]
Holds the password to be used for authentication
purposes. This value cannot be changed when the
context is active.
string Interface [readonly, optional]
Holds the interface of the network interface created
by this context (e.g. "ppp0")
Our current assumption is that the basic setup of IP address, netmask
and broadcast are done by oFono. Only routing and DNS are up to other
programs like ConnMan for example.
array{string} DomainNameServers [readonly, optional]
Holds the list of domain name servers for this
context.
What about the gateway value. In theory we can just route it to the
interface, but if the device fakes a real Ethernet interface and the
gateway is in a different subnet we need a proper host route first.
Regards
Marcel
11:50 p.m.
Hi Marcel,
> Service org.ofono
> Interface org.ofono.DataConnectionManager
I think this should be GPRSManager or something to clearly separate
between GRPS connections and actual data connection,
Two reasons for this:
- Purpose of DataConnectionManager is easier to understand for people new to
GSM. Whereas GPRSManager really doesn't tell them anything. Everywhere else
we tend to use more easily understood terminology than what is used in the
specifications.
- GPRS is not easily Carmel-cased. E.g. we'd have to name it GprsManager.
> object RemoveContext()
>
> Removes a primary context. All secondary contexts, if
> any, associated with the primary context are also
> removed.
I assume this is void RemoveContext(object context)
You're absolutely correct.
> Properties array{object} PrimaryContexts [readonly]
>
> List of all primary contexts objects.
Calling this just Contexts seems to more reasonable. See comment about
interface name below.
That sounds fine to me.
> Primary Data Context hierarchy
> =================
>
> Service org.ofono
> Interface org.ofono.PrimaryDataContext
I would prefer if we just call this GRPSContext and explain that this is
for the primary context. The confusion between primary context and
secondary context is some GSM specific non-sense.
Should we just simply name this 'Context' and name the secondary pdp context
'SubContext'?
> array{string} DomainNameServers [readonly, optional]
>
> Holds the list of domain name servers for this
> context.
What about the gateway value. In theory we can just route it to the
interface, but if the device fakes a real Ethernet interface and the
gateway is in a different subnet we need a proper host route first.
Yes, this one needs to be added. Good catch.
Regards,
-Denis
7:39 a.m.
On Tue, 01 Sep 2009 15:42:40 -0700, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
Our current assumption is that the basic setup of IP address,
netmask
and broadcast are done by oFono. Only routing and DNS are up to other
programs like ConnMan for example.
WHAAAAAAAAAAT? No way. There is just no way.
We need to support letting the calling program configure the routing
parameters manually. For instance, if we want to connect to multiple
primary access points, it simply won't work if Ofono configures everything.
Instead, we need to either setup source routing or separate network
name-spaces. Ofono does not know what the caller intends to do with the APN
(and should not need to), so it cannot configure IP parameters. Besides, it
makes very little if any sense to configure IP parameters but not DNS.
--
Rémi Denis-Courmont
10:16 a.m.
Hi Remi,
> Our current assumption is that the basic setup of IP address,
netmask
> and broadcast are done by oFono. Only routing and DNS are up to other
> programs like ConnMan for example.
WHAAAAAAAAAAT? No way. There is just no way.
We need to support letting the calling program configure the routing
parameters manually. For instance, if we want to connect to multiple
primary access points, it simply won't work if Ofono configures everything.
Instead, we need to either setup source routing or separate network
name-spaces. Ofono does not know what the caller intends to do with the APN
(and should not need to), so it cannot configure IP parameters. Besides, it
makes very little if any sense to configure IP parameters but not DNS.
personally I don't care who finally sets the IP for the interface. It
really just makes no difference. What problem do you see if oFono would
set the IP address on that newly created interface that is up and
running now?
My point is that gateway and DNS is out of the question for oFono.
Regards
Marcel
10:22 a.m.
On Wed, 02 Sep 2009 02:16:40 -0700, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
Hi Remi,
> > Our current assumption is that the basic setup of IP address, netmask
> > and broadcast are done by oFono. Only routing and DNS are up to other
> > programs like ConnMan for example.
>
> WHAAAAAAAAAAT? No way. There is just no way.
>
> We need to support letting the calling program configure the routing
> parameters manually. For instance, if we want to connect to multiple
> primary access points, it simply won't work if Ofono configures
everything.
> Instead, we need to either setup source routing or separate network
> name-spaces. Ofono does not know what the caller intends to do with the
APN
> (and should not need to), so it cannot configure IP parameters. Besides,
it
> makes very little if any sense to configure IP parameters but not DNS.
personally I don't care who finally sets the IP for the interface. It
really just makes no difference. What problem do you see if oFono would
set the IP address on that newly created interface that is up and
running now?
Then the application cannot influence the way it's done. That's the whole
point. Maybe I want to migrate the interface in a new namespace. For that,
it must (1) create the interface, (2) migrate it, (3) configure it, in that
order. So Ofono cannot do (3) if it cannot do (2), and it certainly should
not do (2) by itself. So it has to stick to (1).
--
Rémi Denis-Courmont
11:43 a.m.
2009/9/2 Rémi Denis-Courmont <remi(a)remlab.net>:
> personally I don't care who finally sets the IP for the
interface. It
> really just makes no difference. What problem do you see if oFono would
> set the IP address on that newly created interface that is up and
> running now?
Then the application cannot influence the way it's done. That's the whole
point. Maybe I want to migrate the interface in a new namespace. For that,
it must (1) create the interface, (2) migrate it, (3) configure it, in that
order. So Ofono cannot do (3) if it cannot do (2), and it certainly should
not do (2) by itself. So it has to stick to (1).
And this generally applies to services that operators have decided to
run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC)
and others. For example, Elisa in Finland seems to be running their
MMSC behind an "mms" APN, with public IP address space, but firewalled
from the rest of the Internet. oFono should isolate such an access
from the rest of the system, since only the MMS client would know how
to work with it properly.
Cheers,
Aki
12:03 p.m.
Hi Aki,
>> personally I don't care who finally sets the IP for the
interface. It
>> really just makes no difference. What problem do you see if oFono would
>> set the IP address on that newly created interface that is up and
>> running now?
>
> Then the application cannot influence the way it's done. That's the whole
> point. Maybe I want to migrate the interface in a new namespace. For that,
> it must (1) create the interface, (2) migrate it, (3) configure it, in that
> order. So Ofono cannot do (3) if it cannot do (2), and it certainly should
> not do (2) by itself. So it has to stick to (1).
And this generally applies to services that operators have decided to
run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC)
and others. For example, Elisa in Finland seems to be running their
MMSC behind an "mms" APN, with public IP address space, but firewalled
from the rest of the Internet. oFono should isolate such an access
from the rest of the system, since only the MMS client would know how
to work with it properly.
if they are doing something nasty like that, then the only real solution
is network namespaces. This means we can just bring the interface up and
then have to give all networking details via D-Bus properties. Actually
we might should not even bring the network interface up, but it might be
tricky with PPP or the HSO point-to-point stuff.
Regards
Marcel
12:19 p.m.
On Wed, 02 Sep 2009 04:03:05 -0700, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
> And this generally applies to services that operators have
decided to
> run behind a dedicated APN, such as WAP, MMS, Push over Cellular (PoC)
> and others. For example, Elisa in Finland seems to be running their
> MMSC behind an "mms" APN, with public IP address space, but firewalled
> from the rest of the Internet. oFono should isolate such an access
> from the rest of the system, since only the MMS client would know how
> to work with it properly.
if they are doing something nasty like that, then the only real solution
is network namespaces. This means we can just bring the interface up and
then have to give all networking details via D-Bus properties.
Yes. That's what I was saying, or at least trying to say.
--
Rémi Denis-Courmont
12:30 p.m.
On Wed, Sep 2, 2009 at 12:36 AM, Denis Kenzior<denkenz(a)gmail.com> wrote:
of this discussion. I'd like all interested to comment. What
needs
improvement? What is missing? What should be removed?
Here are some comments. Some of the comments were already present in
the IRC discussion, but I'll repeat them here anyway. First of all,
the both Denis's proposal and mine look quite much the same -- the
basic objects are the GPRS manager and the PDP contexts, and they
offer quite the same functionality. Please correct me if I understood
some parts of Denis's proposal incorrectly. The big differences
between the API proposals are the creation and connecting of the
contexts and the handling of the attached/detached state. I'll try to
address the both issues below.
In this proposal the contexts PDP contexts are persistent on the
device, meaning that they stay there also when Ofono is shut down. The
idea is that the contexts are made to Ofono by the GPRS provisioning
programs or by the UI, and then ConnMan or another upper layer needs
just to activate the context to actually do the connection. In my
proposal I thought that the higher layer components would keep track
of the access points and call the Connect() method with the suitable
connection parameters.
This is a philosophical difference from the provisioning point of
view. An operator will likely support multiple configured access
points, and the provisioning program should know their purpose from
the configuration file (internet/MMS/WAP/...). This metadata is not
there in the Ofono context, meaning that the provisioning program
needs to store somewhere else the mapping between Ofono context object
paths and the neccessary metadata. This begs the question: why not
store all connection data (APN, authentication data, other metadata)
to this external store in the first place?
The attachment to the GPRS network in this proposal is bit vague. To
my understanding, to attach the GPRS you need to set "Powered"
property on and "RoamingAllowed" on. To detach you need to set the
"Powered" property off. Since attaching can take a long time (or
fail), does this mean that the attach errors are handled in the
"Powered" property setter callback? Or what happens when (during
roaming) the "Powered" is already on and the user puts the
"RoamingAllowed" on -- where are the attach errors handled? I kind of
think that it might be a better idea to just expose the GPRS
registration status and the attach status, and let a higher level
component explicitly set the attach/detach with either a readwrite
property or Attach() and Detach() methods.
In my proposal the "Status" variable was a three-state variable,
having the states "attached", "detached" and "suspended".
"Suspended"
was specified to mean that the GPRS was attached, but temporarily not
available (for instance because of a 2G phone call or temporary loss
of cellular connectivity). In the IRC discussion someone said that
this property would not be part of Denis's API because the tri-state
variables were bad and the "suspended" status was not supported by
spec 27.007. However, the problem is that Maemo 5 already has UI
support for indicating that the connection is suspended, and that
makes it harder to drop the feature. Could the "suspended" status enum
still be left there, and just have the modems that don't support the
feature to never go to "suspended" mode?
Still one difference to my proposal was the dropping of the TX and RX
byte counts, and the explanation that those statistics would be
handled by the upper layers by reading the values from the network
interface. I mentioned the problem where the connection was terminated
by the network and the network interface was brought down before the
upper layer had a chance to read the values. After giving the matter
some thought, I still feel that for this reason the modem driver would
need to get the TX/RX data and send it to the upper levels, if at all
possible. Since many operators charge by the amount of data
transferred, not losing the TX/RX data is quite crucial. At least
Nokia phones have a GPRS data counter feature, that is supposed to
show the transferred data. This said, I know that not all modem
drivers can get the data from a connection that has been terminated by
the network, but that does not mean that the modem drivers that can
get the data should just discard it.
Btw, is the context API missing the PDP type (IPv4 or IPv6)?
As I said, I think that the differences between this proposal and mine
are mostly philosophical -- should the context data be stored in Ofono
or in the upper layers of the stack? And should Ofono set the policies
(for instance the roaming case) or just act as a low-level interface
to the GPRS functionality?
By looking at Denis's proposal it is easy to see that my proposal
wasn't perfect either. ;-) At least the GPRS registration state and
possibly other properties need to be added to the D-Bus interface, and
the API also needs to be made more future-proof by thinking how the
network-initiated connections and the secondary contexts would be
made.
--
Ismo Puustinen <ismo(a)iki.fi>
1:02 p.m.
Hi Ismo,
> of this discussion. I'd like all interested to comment.
What needs
> improvement? What is missing? What should be removed?
Here are some comments. Some of the comments were already present in
the IRC discussion, but I'll repeat them here anyway. First of all,
the both Denis's proposal and mine look quite much the same -- the
basic objects are the GPRS manager and the PDP contexts, and they
offer quite the same functionality. Please correct me if I understood
some parts of Denis's proposal incorrectly. The big differences
between the API proposals are the creation and connecting of the
contexts and the handling of the attached/detached state. I'll try to
address the both issues below.
In this proposal the contexts PDP contexts are persistent on the
device, meaning that they stay there also when Ofono is shut down. The
idea is that the contexts are made to Ofono by the GPRS provisioning
programs or by the UI, and then ConnMan or another upper layer needs
just to activate the context to actually do the connection. In my
proposal I thought that the higher layer components would keep track
of the access points and call the Connect() method with the suitable
connection parameters.
This is a philosophical difference from the provisioning point of
view. An operator will likely support multiple configured access
points, and the provisioning program should know their purpose from
the configuration file (internet/MMS/WAP/...). This metadata is not
there in the Ofono context, meaning that the provisioning program
needs to store somewhere else the mapping between Ofono context object
paths and the neccessary metadata. This begs the question: why not
store all connection data (APN, authentication data, other metadata)
to this external store in the first place?
I mentioned that already. We do wanna store something like Type that
says internet, mms, wap etc. The only comment here was that for network
initiated context we have no idea of its intent.
The attachment to the GPRS network in this proposal is bit vague. To
my understanding, to attach the GPRS you need to set "Powered"
property on and "RoamingAllowed" on. To detach you need to set the
"Powered" property off. Since attaching can take a long time (or
fail), does this mean that the attach errors are handled in the
"Powered" property setter callback? Or what happens when (during
roaming) the "Powered" is already on and the user puts the
"RoamingAllowed" on -- where are the attach errors handled? I kind of
think that it might be a better idea to just expose the GPRS
registration status and the attach status, and let a higher level
component explicitly set the attach/detach with either a readwrite
property or Attach() and Detach() methods.
Powered = on and RoamingAllowed = yes and Roaming = true will lead to
auto-attach.
Powered = on and RoamingAllowed = no and Roaming = true will lead to
detach.
Powered = on and Roaming = false will lead to auto-attach.
Powered = off will lead to detach.
We are not going to expose Attach() or Detach() method. As explained
there are global anyway and so pointless to expose. This can be handled
in the background without bothering the higher level application with
these details.
In my proposal the "Status" variable was a three-state
variable,
having the states "attached", "detached" and "suspended".
"Suspended"
was specified to mean that the GPRS was attached, but temporarily not
available (for instance because of a 2G phone call or temporary loss
of cellular connectivity). In the IRC discussion someone said that
this property would not be part of Denis's API because the tri-state
variables were bad and the "suspended" status was not supported by
spec 27.007. However, the problem is that Maemo 5 already has UI
support for indicating that the connection is suspended, and that
makes it harder to drop the feature. Could the "suspended" status enum
still be left there, and just have the modems that don't support the
feature to never go to "suspended" mode?
I am still not seeing the point in what suspended will do for us and the
UI. And that Maemo 5 exposed such a state in the UI is not an argument
to keep doing it. I asked this before, what are we suppose to be doing
when we get signaled suspended?
Still one difference to my proposal was the dropping of the TX and
RX
byte counts, and the explanation that those statistics would be
handled by the upper layers by reading the values from the network
interface. I mentioned the problem where the connection was terminated
by the network and the network interface was brought down before the
upper layer had a chance to read the values. After giving the matter
some thought, I still feel that for this reason the modem driver would
need to get the TX/RX data and send it to the upper levels, if at all
possible. Since many operators charge by the amount of data
transferred, not losing the TX/RX data is quite crucial. At least
Nokia phones have a GPRS data counter feature, that is supposed to
show the transferred data. This said, I know that not all modem
drivers can get the data from a connection that has been terminated by
the network, but that does not mean that the modem drivers that can
get the data should just discard it.
This is for ConnMan or similar to figure out. And we can always count
via netfilter or some other facility. Counting inside oFono makes no
sense. However we could send out a statistics signal before taking the
interface down if it would be really needed. Making it part of the
properties and having to poll for it is wrong.
Btw, is the context API missing the PDP type (IPv4 or IPv6)?
I keep forgetting these since so far I haven't seen any provider giving
me IPv6, but you are correct, we need to be able to handle this.
As I said, I think that the differences between this proposal and
mine
are mostly philosophical -- should the context data be stored in Ofono
or in the upper layers of the stack? And should Ofono set the policies
(for instance the roaming case) or just act as a low-level interface
to the GPRS functionality?
While oFono is sort of low-level, it is not that low-level. If it would
we could expose the native AT commands. So in summary the PDP context
are stored persistently in oFono. Like BlueZ remember paired devices.
And for data roaming, we make it as simple as allowed = yes/no. This is
all the upper layer need to configure.
Not exposing method for attach/detach is a logical consequence as
explained above. It is a global per modem detail and thus there is not
point in exposing it. Also there is not point in having ConnMan and some
other potential application fighting for it. We do auto-attach if
available and tell the applications the status. If Attached = yes, then
the application can connect/disconnect contexts. As simple as that.
By looking at Denis's proposal it is easy to see that my
proposal
wasn't perfect either. ;-) At least the GPRS registration state and
possibly other properties need to be added to the D-Bus interface, and
the API also needs to be made more future-proof by thinking how the
network-initiated connections and the secondary contexts would be
made.
I prefer start simple and add more details later. Removing details is
more complicated than adding them.
Regards
Marcel
1:34 p.m.
2009/9/2 Marcel Holtmann <marcel(a)holtmann.org>:
Powered = on and RoamingAllowed = yes and Roaming = true will lead
to
auto-attach.
Powered = on and RoamingAllowed = no and Roaming = true will lead to
detach.
Powered = on and Roaming = false will lead to auto-attach.
Powered = off will lead to detach.
Why is auto-attach dependent on roaming?
We are not going to expose Attach() or Detach() method. As explained
there are global anyway and so pointless to expose. This can be handled
in the background without bothering the higher level application with
these details.
AFAIK, attach status of GPRS has both regulatory aspects to consider
(some operators require always attached vs. some prohibit it) as well
as power consumption issues (auto-attach might draw more power than
on-demand, although there's an inverse effect on latency). These are
issues you need to take into account, and higher layers in the stack
definitely *need* to be aware of as well. Also, I don' t think oFono
is the correct place for these decisions -> better expose a necessary
API and let upper layers deal with it.
In general, I appreciate the attempt to hide ugly details from
applications, but unfortunately some things can't well be hidden.
Another unrelated, but similar issue is network scanning. It just
isn't going to work without us exposing it in the D-Bus API
explicitly.
The reason is simple, Nokia modems suspend GPRS when scanning (or
registering), simply because the operation will take roughly three
times as long with GPRS attached. You will find this feature in
current phones, too.
Now, there is no way we can have GPRS suspend without warning just
because the stack deems it necessary to scan for networks. Again the
intention is good, but the end result not so good. I don't want to
start patching oFono to support this type of basic stuff.
> In my proposal the "Status" variable was a three-state
variable,
> having the states "attached", "detached" and
"suspended". "Suspended"
> was specified to mean that the GPRS was attached, but temporarily not
> available (for instance because of a 2G phone call or temporary loss
> of cellular connectivity). In the IRC discussion someone said that
> this property would not be part of Denis's API because the tri-state
> variables were bad and the "suspended" status was not supported by
> spec 27.007. However, the problem is that Maemo 5 already has UI
> support for indicating that the connection is suspended, and that
> makes it harder to drop the feature. Could the "suspended" status enum
> still be left there, and just have the modems that don't support the
> feature to never go to "suspended" mode?
I am still not seeing the point in what suspended will do for us and the
UI. And that Maemo 5 exposed such a state in the UI is not an argument
to keep doing it. I asked this before, what are we suppose to be doing
when we get signaled suspended?
You will find that practically every Nokia phone behaves this way,
i.e., you make a call in 2G, and the UI will inform you that GPRS is
suspended while on call.
> Still one difference to my proposal was the dropping of the TX
and RX
> byte counts, and the explanation that those statistics would be
> handled by the upper layers by reading the values from the network
> interface. I mentioned the problem where the connection was terminated
> by the network and the network interface was brought down before the
> upper layer had a chance to read the values. After giving the matter
> some thought, I still feel that for this reason the modem driver would
> need to get the TX/RX data and send it to the upper levels, if at all
> possible. Since many operators charge by the amount of data
> transferred, not losing the TX/RX data is quite crucial. At least
> Nokia phones have a GPRS data counter feature, that is supposed to
> show the transferred data. This said, I know that not all modem
> drivers can get the data from a connection that has been terminated by
> the network, but that does not mean that the modem drivers that can
> get the data should just discard it.
This is for ConnMan or similar to figure out. And we can always count
via netfilter or some other facility. Counting inside oFono makes no
sense. However we could send out a statistics signal before taking the
interface down if it would be really needed. Making it part of the
properties and having to poll for it is wrong.
I believe emitting a signal was Ismo's original proposal.
While oFono is sort of low-level, it is not that low-level. If it
would
we could expose the native AT commands. So in summary the PDP context
are stored persistently in oFono. Like BlueZ remember paired devices.
And for data roaming, we make it as simple as allowed = yes/no. This is
all the upper layer need to configure.
Not exposing method for attach/detach is a logical consequence as
explained above. It is a global per modem detail and thus there is not
point in exposing it. Also there is not point in having ConnMan and some
other potential application fighting for it. We do auto-attach if
available and tell the applications the status. If Attached = yes, then
the application can connect/disconnect contexts. As simple as that.
Then expose an AutoAttach = true/false property. That would work.
> By looking at Denis's proposal it is easy to see that my
proposal
> wasn't perfect either. ;-) At least the GPRS registration state and
> possibly other properties need to be added to the D-Bus interface, and
> the API also needs to be made more future-proof by thinking how the
> network-initiated connections and the secondary contexts would be
> made.
I prefer start simple and add more details later. Removing details is
more complicated than adding them.
For some of these features, there is no question whether or not we
need them. I think you should be listening closely for the
requirements we post, because this isn't something we *think* might be
needed some day -- this is stuff that we've implemented and will ship,
and expect to ship in the future.
Cheers,
Aki
1:46 p.m.
Hi Aki,
> Powered = on and RoamingAllowed = yes and Roaming = true will
lead to
> auto-attach.
>
> Powered = on and RoamingAllowed = no and Roaming = true will lead to
> detach.
>
> Powered = on and Roaming = false will lead to auto-attach.
>
> Powered = off will lead to detach.
Why is auto-attach dependent on roaming?
power consumption. No need to attach if you don't wanna allow data
roaming.
> We are not going to expose Attach() or Detach() method. As
explained
> there are global anyway and so pointless to expose. This can be handled
> in the background without bothering the higher level application with
> these details.
AFAIK, attach status of GPRS has both regulatory aspects to consider
(some operators require always attached vs. some prohibit it) as well
as power consumption issues (auto-attach might draw more power than
on-demand, although there's an inverse effect on latency). These are
issues you need to take into account, and higher layers in the stack
definitely *need* to be aware of as well. Also, I don' t think oFono
is the correct place for these decisions -> better expose a necessary
API and let upper layers deal with it.
I disagree. We can have a config option that always attaches or attached
on demand, but this should not be exposed to any higher level
applications.
In general, I appreciate the attempt to hide ugly details from
applications, but unfortunately some things can't well be hidden.
Another unrelated, but similar issue is network scanning. It just
isn't going to work without us exposing it in the D-Bus API
explicitly.
The reason is simple, Nokia modems suspend GPRS when scanning (or
registering), simply because the operation will take roughly three
times as long with GPRS attached. You will find this feature in
current phones, too.
Now, there is no way we can have GPRS suspend without warning just
because the stack deems it necessary to scan for networks. Again the
intention is good, but the end result not so good. I don't want to
start patching oFono to support this type of basic stuff.
I mentioned this before. We might need to add a config option to allow
integrators choose different behavior.
>> In my proposal the "Status" variable was a
three-state variable,
>> having the states "attached", "detached" and
"suspended". "Suspended"
>> was specified to mean that the GPRS was attached, but temporarily not
>> available (for instance because of a 2G phone call or temporary loss
>> of cellular connectivity). In the IRC discussion someone said that
>> this property would not be part of Denis's API because the tri-state
>> variables were bad and the "suspended" status was not supported by
>> spec 27.007. However, the problem is that Maemo 5 already has UI
>> support for indicating that the connection is suspended, and that
>> makes it harder to drop the feature. Could the "suspended" status
enum
>> still be left there, and just have the modems that don't support the
>> feature to never go to "suspended" mode?
>
> I am still not seeing the point in what suspended will do for us and the
> UI. And that Maemo 5 exposed such a state in the UI is not an argument
> to keep doing it. I asked this before, what are we suppose to be doing
> when we get signaled suspended?
You will find that practically every Nokia phone behaves this way,
i.e., you make a call in 2G, and the UI will inform you that GPRS is
suspended while on call.
So what is the difference signaling a disconnect and re-connect to the
application?
>> Still one difference to my proposal was the dropping of the
TX and RX
>> byte counts, and the explanation that those statistics would be
>> handled by the upper layers by reading the values from the network
>> interface. I mentioned the problem where the connection was terminated
>> by the network and the network interface was brought down before the
>> upper layer had a chance to read the values. After giving the matter
>> some thought, I still feel that for this reason the modem driver would
>> need to get the TX/RX data and send it to the upper levels, if at all
>> possible. Since many operators charge by the amount of data
>> transferred, not losing the TX/RX data is quite crucial. At least
>> Nokia phones have a GPRS data counter feature, that is supposed to
>> show the transferred data. This said, I know that not all modem
>> drivers can get the data from a connection that has been terminated by
>> the network, but that does not mean that the modem drivers that can
>> get the data should just discard it.
>
> This is for ConnMan or similar to figure out. And we can always count
> via netfilter or some other facility. Counting inside oFono makes no
> sense. However we could send out a statistics signal before taking the
> interface down if it would be really needed. Making it part of the
> properties and having to poll for it is wrong.
I believe emitting a signal was Ismo's original proposal.
I will talk with Stephen and David about this and what it a proper way
to collect statistics even if the interface goes away. They might have
some ideas. Changing the kernel and adding proper support for statistics
collection is not out the question here.
> While oFono is sort of low-level, it is not that low-level. If
it would
> we could expose the native AT commands. So in summary the PDP context
> are stored persistently in oFono. Like BlueZ remember paired devices.
>
> And for data roaming, we make it as simple as allowed = yes/no. This is
> all the upper layer need to configure.
>
> Not exposing method for attach/detach is a logical consequence as
> explained above. It is a global per modem detail and thus there is not
> point in exposing it. Also there is not point in having ConnMan and some
> other potential application fighting for it. We do auto-attach if
> available and tell the applications the status. If Attached = yes, then
> the application can connect/disconnect contexts. As simple as that.
Then expose an AutoAttach = true/false property. That would work.
I prefer these details as configuration option that integrators set when
building the actual device. No need to have higher application change
it.
>> By looking at Denis's proposal it is easy to see that my
proposal
>> wasn't perfect either. ;-) At least the GPRS registration state and
>> possibly other properties need to be added to the D-Bus interface, and
>> the API also needs to be made more future-proof by thinking how the
>> network-initiated connections and the secondary contexts would be
>> made.
>
> I prefer start simple and add more details later. Removing details is
> more complicated than adding them.
For some of these features, there is no question whether or not we
need them. I think you should be listening closely for the
requirements we post, because this isn't something we *think* might be
needed some day -- this is stuff that we've implemented and will ship,
and expect to ship in the future.
Then please give examples. I asked this on IRC. I have never used
Secondary PDP Context before. Same goes for network initiated contexts.
I would really like to know which networks use what. And I think we need
to start collecting these information somewhere. It is important to know
what is used in production.
Regards
Marcel
1:51 p.m.
On Wed, 02 Sep 2009 05:46:31 -0700, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
> You will find that practically every Nokia phone behaves this
way,
> i.e., you make a call in 2G, and the UI will inform you that GPRS is
> suspended while on call.
So what is the difference signaling a disconnect and re-connect to the
application?
It's like pausing or stopping your media player.
> For some of these features, there is no question whether or not
we
> need them. I think you should be listening closely for the
> requirements we post, because this isn't something we *think* might be
> needed some day -- this is stuff that we've implemented and will ship,
> and expect to ship in the future.
Then please give examples. I asked this on IRC. I have never used
Secondary PDP Context before. Same goes for network initiated contexts.
Neither did I.
OTOH, I did see annoying data counter requirements, and I did see suspended
mode.
--
Rémi Denis-Courmont
4:28 p.m.
Hi Aki,
> We are not going to expose Attach() or Detach() method. As
explained
> there are global anyway and so pointless to expose. This can be handled
> in the background without bothering the higher level application with
> these details.
AFAIK, attach status of GPRS has both regulatory aspects to consider
(some operators require always attached vs. some prohibit it) as well
as power consumption issues (auto-attach might draw more power than
on-demand, although there's an inverse effect on latency). These are
issues you need to take into account, and higher layers in the stack
definitely *need* to be aware of as well. Also, I don' t think oFono
is the correct place for these decisions -> better expose a necessary
API and let upper layers deal with it.
I know you guys are coming from mobile phone perspective, but that one isn't
the only scenario. We have netbooks/laptops with gprs data cards to consider
as well. Hardcoding operator requirements is also not an option, since SIM
cards can be changed.
I fundamentally disagree that the logic should be in the higher layers. oFono
has all the information to handle this, and can be hinted on what is
appropriate behavior easily enough. oFono should simply store the auto-attach
preferences in its IMSI-indexed preference store. The operator can bootstrap
these preferences if required.
In general, I appreciate the attempt to hide ugly details from
applications, but unfortunately some things can't well be hidden.
Another unrelated, but similar issue is network scanning. It just
isn't going to work without us exposing it in the D-Bus API
explicitly.
Modem drivers will have some control over whether the scan is performed
automatically, but denying the capability for everyone is not the right thing
to do either.
The reason is simple, Nokia modems suspend GPRS when scanning (or
registering), simply because the operation will take roughly three
times as long with GPRS attached. You will find this feature in
current phones, too.
Then ideally you should have two scan modes, periodic and user initiated. For
periodic mode we don't care how long it takes.
Regards,
-Denis
4:42 p.m.
2009/9/2 Denis Kenzior <denkenz(a)gmail.com>:
> AFAIK, attach status of GPRS has both regulatory aspects to
consider
> (some operators require always attached vs. some prohibit it) as well
> as power consumption issues (auto-attach might draw more power than
> on-demand, although there's an inverse effect on latency). These are
> issues you need to take into account, and higher layers in the stack
> definitely *need* to be aware of as well. Also, I don' t think oFono
> is the correct place for these decisions -> better expose a necessary
> API and let upper layers deal with it.
I know you guys are coming from mobile phone perspective, but that one isn't
the only scenario. We have netbooks/laptops with gprs data cards to consider
as well. Hardcoding operator requirements is also not an option, since SIM
cards can be changed.
I fundamentally disagree that the logic should be in the higher layers. oFono
has all the information to handle this, and can be hinted on what is
appropriate behavior easily enough. oFono should simply store the auto-attach
preferences in its IMSI-indexed preference store. The operator can bootstrap
these preferences if required.
Operator requirements were only half of the story. You need to be able
to disable auto-attach in low power conditions, and this logic
definitely doesn't belong in oFono. This applies equally well to
mobile phones as it does to laptops/netbooks.
> In general, I appreciate the attempt to hide ugly details from
> applications, but unfortunately some things can't well be hidden.
> Another unrelated, but similar issue is network scanning. It just
> isn't going to work without us exposing it in the D-Bus API
> explicitly.
>
Modem drivers will have some control over whether the scan is performed
automatically, but denying the capability for everyone is not the right thing
to do either.
Agree, and I don't think that was what I was suggesting either.
> The reason is simple, Nokia modems suspend GPRS when scanning
(or
> registering), simply because the operation will take roughly three
> times as long with GPRS attached. You will find this feature in
> current phones, too.
Then ideally you should have two scan modes, periodic and user initiated. For
periodic mode we don't care how long it takes.
+1
Cheers,
Aki
9:37 p.m.
Hi Aki,
>> AFAIK, attach status of GPRS has both regulatory aspects to
consider
>> (some operators require always attached vs. some prohibit it) as well
>> as power consumption issues (auto-attach might draw more power than
>> on-demand, although there's an inverse effect on latency). These are
>> issues you need to take into account, and higher layers in the stack
>> definitely *need* to be aware of as well. Also, I don' t think oFono
>> is the correct place for these decisions -> better expose a necessary
>> API and let upper layers deal with it.
>
> I know you guys are coming from mobile phone perspective, but that one isn't
> the only scenario. We have netbooks/laptops with gprs data cards to consider
> as well. Hardcoding operator requirements is also not an option, since SIM
> cards can be changed.
>
> I fundamentally disagree that the logic should be in the higher layers. oFono
> has all the information to handle this, and can be hinted on what is
> appropriate behavior easily enough. oFono should simply store the auto-attach
> preferences in its IMSI-indexed preference store. The operator can bootstrap
> these preferences if required.
Operator requirements were only half of the story. You need to be able
to disable auto-attach in low power conditions, and this logic
definitely doesn't belong in oFono. This applies equally well to
mobile phones as it does to laptops/netbooks.
this a different requirement. Where do you get your low power
information from? I would prefer that we add a plugin that gets informed
of this low power situation and then is able to adjust such things.
I am against exposing this in user application/UI API. I am with you
that such requirements have to be met, but not via the D-Bus API. So
these kind of policy details are device/manufacturer specific and having
a custom plugins that can be enabled by the integrator sounds best to me
if a config file is not flexible enough.
>> In general, I appreciate the attempt to hide ugly details
from
>> applications, but unfortunately some things can't well be hidden.
>> Another unrelated, but similar issue is network scanning. It just
>> isn't going to work without us exposing it in the D-Bus API
>> explicitly.
>>
>
> Modem drivers will have some control over whether the scan is performed
> automatically, but denying the capability for everyone is not the right thing
> to do either.
Agree, and I don't think that was what I was suggesting either.
>> The reason is simple, Nokia modems suspend GPRS when scanning (or
>> registering), simply because the operation will take roughly three
>> times as long with GPRS attached. You will find this feature in
>> current phones, too.
>
> Then ideally you should have two scan modes, periodic and user initiated. For
> periodic mode we don't care how long it takes.
+1
Sounds like a plan. So we do need an /etc/ofono/main.conf :)
Regards
Marcel
9:36 p.m.
Hi Marcel,
> >> The reason is simple, Nokia modems suspend GPRS when
scanning (or
> >> registering), simply because the operation will take roughly three
> >> times as long with GPRS attached. You will find this feature in
> >> current phones, too.
> >
> > Then ideally you should have two scan modes, periodic and user
> > initiated. For periodic mode we don't care how long it takes.
>
> +1
Sounds like a plan. So we do need an /etc/ofono/main.conf :)
So my current thinking is to introduce a method to NetworkRegistration
property called 'ProposeOperatorScan' and a new property called
'OperatorScanInterval'. The driver api can then support a (non-standard
*gasp*) option to say whether this scan was initiated actively or not.
Maybe the Nokia modems can use this information not to drop the GPRS link if
it isn't an active scan being performed.
Regards,
-Denis
10:09 p.m.
Hi Denis,
> > >> The reason is simple, Nokia modems suspend GPRS
when scanning (or
> > >> registering), simply because the operation will take roughly three
> > >> times as long with GPRS attached. You will find this feature in
> > >> current phones, too.
> > >
> > > Then ideally you should have two scan modes, periodic and user
> > > initiated. For periodic mode we don't care how long it takes.
> >
> > +1
>
> Sounds like a plan. So we do need an /etc/ofono/main.conf :)
So my current thinking is to introduce a method to NetworkRegistration
property called 'ProposeOperatorScan' and a new property called
'OperatorScanInterval'. The driver api can then support a (non-standard
*gasp*) option to say whether this scan was initiated actively or not.
Maybe the Nokia modems can use this information not to drop the GPRS link if
it isn't an active scan being performed.
I really prefer if we put this into /etc/ofono/main.conf since the UI
should not configure this at all. It is more a one time setting based on
what the integrator expects as a behavior.
Regards
Marcel
1:46 p.m.
On Wed, 02 Sep 2009 05:02:46 -0700, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
I mentioned that already. We do wanna store something like Type that
says internet, mms, wap etc. The only comment here was that for network
initiated context we have no idea of its intent.
And we do not want to.
> The attachment to the GPRS network in this proposal is bit vague.
To
> my understanding, to attach the GPRS you need to set "Powered"
> property on and "RoamingAllowed" on. To detach you need to set the
> "Powered" property off. Since attaching can take a long time (or
> fail), does this mean that the attach errors are handled in the
> "Powered" property setter callback? Or what happens when (during
> roaming) the "Powered" is already on and the user puts the
> "RoamingAllowed" on -- where are the attach errors handled? I kind of
> think that it might be a better idea to just expose the GPRS
> registration status and the attach status, and let a higher level
> component explicitly set the attach/detach with either a readwrite
> property or Attach() and Detach() methods.
Powered = on and RoamingAllowed = yes and Roaming = true will lead to
auto-attach.
That's just _idiotic_ from the naming perspective.
A modem can have radio on or off. Whether this is done by completely
powering the modem off, or by going into some kind of flight mode, is
driver-specific. Hence the "powered" name is semantically wrong. When
possible, it's actually best to keep the modem in flight mode, so that e.g.
the SIM is still usable.
The story is basically the same with roaming. Roaming means you are outside
your home network. It does not mean that you want to auto-attach or not.
Some people _never_ want to auto-attach, and some people _always_ want to
auto-attach. In fact, different operators have different requirements with
that regard. Sure, some people want to auto-attach if and only if not
roaming. Given that roaming is not just about GPRS, the name is wrong and
confusing. But more importantly, we need t support turning the radio on
while in the home network yet _not_ attach automatically. This has operator
requirements as well as power saving implications.
We are not going to expose Attach() or Detach() method.
And we are going to expose it.
I am still not seeing the point in what suspended will do for us and
the
UI. And that Maemo 5 exposed such a state in the UI is not an argument
to keep doing it. I asked this before, what are we suppose to be doing
when we get signaled suspended?
User, as well as intelligent (connectivity-aware) applications, need to
know about this so that they understand why "Internet" is momentarily
broken. It's as simple as that.
Oh we could also use the network device carrier flag, and then use Netlink
(and we probably should do that too), but we all know how horrible Netlink
is from userland.
(...)
This is for ConnMan or similar to figure out. And we can always
count
via netfilter or some other facility. Counting inside oFono makes no
sense. However we could send out a statistics signal before taking the
interface down if it would be really needed. Making it part of the
properties and having to poll for it is wrong.
This has legal(ish) implications related to charging. Skipping this is not
exactly an option (for a device vendor). I actually agree that this is ugly
in some ways. In theory, I don't really care if Ofono or the over-lying
connection manager takes care of it. *But* we even need to collect
statistics for contexts not handled in Ofono (e.g. Windows PC tethering).
And I doubt that Connman would be able to do that properly.
It's ugly and annoying, but we have to suck it up.
> As I said, I think that the differences between this proposal and
mine
> are mostly philosophical -- should the context data be stored in Ofono
> or in the upper layers of the stack? And should Ofono set the policies
> (for instance the roaming case) or just act as a low-level interface
> to the GPRS functionality?
While oFono is sort of low-level, it is not that low-level. If it would
we could expose the native AT commands. So in summary the PDP context
are stored persistently in oFono. Like BlueZ remember paired devices.
I fail to see how providing a direct low-level interface would prevent us
from providing _also_ a higher-level interface. The later can handle
provisioning and data persistence.
--
Rémi Denis-Courmont
2:01 p.m.
Hi Remi,
> I mentioned that already. We do wanna store something like Type
that
> says internet, mms, wap etc. The only comment here was that for network
> initiated context we have no idea of its intent.
And we do not want to.
>> The attachment to the GPRS network in this proposal is bit vague. To
>> my understanding, to attach the GPRS you need to set "Powered"
>> property on and "RoamingAllowed" on. To detach you need to set the
>> "Powered" property off. Since attaching can take a long time (or
>> fail), does this mean that the attach errors are handled in the
>> "Powered" property setter callback? Or what happens when (during
>> roaming) the "Powered" is already on and the user puts the
>> "RoamingAllowed" on -- where are the attach errors handled? I kind of
>> think that it might be a better idea to just expose the GPRS
>> registration status and the attach status, and let a higher level
>> component explicitly set the attach/detach with either a readwrite
>> property or Attach() and Detach() methods.
>
> Powered = on and RoamingAllowed = yes and Roaming = true will lead to
> auto-attach.
That's just _idiotic_ from the naming perspective.
A modem can have radio on or off. Whether this is done by completely
powering the modem off, or by going into some kind of flight mode, is
driver-specific. Hence the "powered" name is semantically wrong. When
possible, it's actually best to keep the modem in flight mode, so that e.g.
the SIM is still usable.
The story is basically the same with roaming. Roaming means you are outside
your home network. It does not mean that you want to auto-attach or not.
Some people _never_ want to auto-attach, and some people _always_ want to
auto-attach. In fact, different operators have different requirements with
that regard. Sure, some people want to auto-attach if and only if not
roaming. Given that roaming is not just about GPRS, the name is wrong and
confusing. But more importantly, we need t support turning the radio on
while in the home network yet _not_ attach automatically. This has operator
requirements as well as power saving implications.
you did read the API docs Denis send around? These are not global
Powered and RoamingAllowed properties. They are specific to the GPRS
Manager and thus have specific meaning in that context. It has nothing
to do with flight mode or radio off.
And for the different operator policy/behavior, that should be
configured via config option and not via D-Bus. The integrator should
make a choice. It it is a list of mappings of operator = attach policy,
then that is also fine.
> We are not going to expose Attach() or Detach() method.
And we are going to expose it.
And for what good is this. So we have two applications fighting about
Attach and Detach and some weird policy somewhere upper in the stack
with no real sense on what is happening. Sorry but I am not buying this
at all.
If the only argument is that different providers require different
auto-attach policies then we have that as described via a config option
and be done with it.
Otherwise I like to see real examples where something like ConnMan, an
MMS application or any other application need control over the attach
status.
> I am still not seeing the point in what suspended will do for us
and the
> UI. And that Maemo 5 exposed such a state in the UI is not an argument
> to keep doing it. I asked this before, what are we suppose to be doing
> when we get signaled suspended?
User, as well as intelligent (connectivity-aware) applications, need to
know about this so that they understand why "Internet" is momentarily
broken. It's as simple as that.
Oh we could also use the network device carrier flag, and then use Netlink
(and we probably should do that too), but we all know how horrible Netlink
is from userland.
Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some
suspended state.
(...)
> This is for ConnMan or similar to figure out. And we can always count
> via netfilter or some other facility. Counting inside oFono makes no
> sense. However we could send out a statistics signal before taking the
> interface down if it would be really needed. Making it part of the
> properties and having to poll for it is wrong.
This has legal(ish) implications related to charging. Skipping this is not
exactly an option (for a device vendor). I actually agree that this is ugly
in some ways. In theory, I don't really care if Ofono or the over-lying
connection manager takes care of it. *But* we even need to collect
statistics for contexts not handled in Ofono (e.g. Windows PC tethering).
And I doubt that Connman would be able to do that properly.
It's ugly and annoying, but we have to suck it up.
As I mentioned it before. We figure something out. We do have the same
problem for all hotplug network devices. Especially with hotplug 3G
dongles, we need to do something better than counting by ourself. The
kernel should do it for us. If you yank the dongle, then oFono is even
lost and the accounting is not accurate.
>> As I said, I think that the differences between this
proposal and mine
>> are mostly philosophical -- should the context data be stored in Ofono
>> or in the upper layers of the stack? And should Ofono set the policies
>> (for instance the roaming case) or just act as a low-level interface
>> to the GPRS functionality?
>
> While oFono is sort of low-level, it is not that low-level. If it would
> we could expose the native AT commands. So in summary the PDP context
> are stored persistently in oFono. Like BlueZ remember paired devices.
I fail to see how providing a direct low-level interface would prevent us
from providing _also_ a higher-level interface. The later can handle
provisioning and data persistence.
I don't see the need for the low-level interface in this context. What
do you expect it to do? I might be missing something here, but where do
we actually use dynamic one-time PDP contexts. These all look like
configured or provisioned settings to me.
Regards
Marcel
6:51 p.m.
> > I am still not seeing the point in what suspended will do
for us and
> > the UI. And that Maemo 5 exposed such a state in the UI is not an
> > argument to keep doing it. I asked this before, what are we suppose to
> > be doing when we get signaled suspended?
>
> User, as well as intelligent (connectivity-aware) applications, need to
> know about this so that they understand why "Internet" is momentarily
> broken. It's as simple as that.
+1
> Oh we could also use the network device carrier flag, and then
use
> Netlink (and we probably should do that too), but we all know how
> horrible Netlink is from userland.
Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some
suspended state.
IF_OPER_DORMANT seems a more accurate reflection of the state.
Cheers,
Waldo
9:40 p.m.
Hi Waldo,
> > > I am still not seeing the point in what suspended will
do for us and
> > > the UI. And that Maemo 5 exposed such a state in the UI is not an
> > > argument to keep doing it. I asked this before, what are we suppose to
> > > be doing when we get signaled suspended?
> >
> > User, as well as intelligent (connectivity-aware) applications, need to
> > know about this so that they understand why "Internet" is
momentarily
> > broken. It's as simple as that.
+1
they need to know if they can do something useful with this information.
If not, then this state is just pointless. However the D-Bus API is the
wrong location for this detail.
> > Oh we could also use the network device carrier flag, and
then use
> > Netlink (and we probably should do that too), but we all know how
> > horrible Netlink is from userland.
>
> Using IFF_RUNNING and IFF_LOWER_UP sounds more reasonable then some
> suspended state.
IF_OPER_DORMANT seems a more accurate reflection of the state.
Yep. That sounds good. We don't use that in ConnMan right now, but that
can be fixed of course. I still need to figure out what we are suppose
to do when this gets signaled to us.
Regards
Marcel
4 p.m.
Hi Ismo,
This is a philosophical difference from the provisioning point of
view. An operator will likely support multiple configured access
points, and the provisioning program should know their purpose from
the configuration file (internet/MMS/WAP/...). This metadata is not
there in the Ofono context, meaning that the provisioning program
needs to store somewhere else the mapping between Ofono context object
paths and the neccessary metadata. This begs the question: why not
store all connection data (APN, authentication data, other metadata)
to this external store in the first place?
Actually this one is missing from the API proposal. Marcel already wanted the
context type (internet, mms, wap, etc) information. I've updated the proposed
API in git.
As discussed previously, we want oFono to manage this data, since it can do
this by using the IMSI. So if you insert a different operator SIM your APN
settings are magically updated for that operator.
In my proposal the "Status" variable was a three-state
variable,
having the states "attached", "detached" and "suspended".
"Suspended"
was specified to mean that the GPRS was attached, but temporarily not
available (for instance because of a 2G phone call or temporary loss
of cellular connectivity). In the IRC discussion someone said that
this property would not be part of Denis's API because the tri-state
variables were bad and the "suspended" status was not supported by
So the general rule is that if a feature isn't explicitly allowed in 27.007,
we do not support it. There are exceptions to this of course. 27.007 only
supports two states for context: activated and deactivated.
spec 27.007. However, the problem is that Maemo 5 already has UI
support for indicating that the connection is suspended, and that
makes it harder to drop the feature. Could the "suspended" status enum
still be left there, and just have the modems that don't support the
feature to never go to "suspended" mode?
I'd rather not.
If this feature is really required, then some sort of heuristic can be
applied. (e.g. Powered on, Attached on, but context is deactivated most
likely means temporary unavailability of resources)
Still one difference to my proposal was the dropping of the TX and RX
byte counts, and the explanation that those statistics would be
handled by the upper layers by reading the values from the network
interface. I mentioned the problem where the connection was terminated
by the network and the network interface was brought down before the
upper layer had a chance to read the values. After giving the matter
some thought, I still feel that for this reason the modem driver would
need to get the TX/RX data and send it to the upper levels, if at all
possible. Since many operators charge by the amount of data
transferred, not losing the TX/RX data is quite crucial. At least
Nokia phones have a GPRS data counter feature, that is supposed to
show the transferred data. This said, I know that not all modem
drivers can get the data from a connection that has been terminated by
the network, but that does not mean that the modem drivers that can
get the data should just discard it.
This really belong in the kernel. Only the kernel can reliably know when a
network interface has been brought down and notify the interested applications
with the statistics. Nokia hardware supports this explicitly, but many others
don't. I don't want nasty kludges inside oFono to enable this.
Btw, is the context API missing the PDP type (IPv4 or IPv6)?
I left this out explicitly since I've never seen anything besides "IP" being
used. But we can add this easily enough if there's need.
Regards,
-Denis
4:32 p.m.
Hi Denis,
2009/9/2 Denis Kenzior <denkenz(a)gmail.com>:
So the general rule is that if a feature isn't explicitly allowed
in 27.007,
we do not support it. There are exceptions to this of course. 27.007 only
supports two states for context: activated and deactivated.
Ahem. Just like access selection mode is not in 27.007, yet Nokia has
it, and most AT modems have proprietary commands to query and set it
[1]. Maybe you call that the necessary exception to the rule, but I
think we might as well change the rule to:
"If a feature is explicitly requested by users of oFono, and can be
reasonably provided by modems that have it without braking those that
don't have it, it will be supported. And 27.007 can go fsck itself."
;-)
> spec 27.007. However, the problem is that Maemo 5 already has UI
> support for indicating that the connection is suspended, and that
> makes it harder to drop the feature. Could the "suspended" status enum
> still be left there, and just have the modems that don't support the
> feature to never go to "suspended" mode?
I'd rather not.
If this feature is really required, then some sort of heuristic can be
applied. (e.g. Powered on, Attached on, but context is deactivated most
likely means temporary unavailability of resources)
You want the UI to implement this heuristic, when the modem plugin has
explicit knowledge of that state, but isn't telling? Please explain
how that makes the UI simpler?
Cheers,
Aki
[1] http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/
4:36 p.m.
Hi Aki,
Hi Denis,
2009/9/2 Denis Kenzior <denkenz(a)gmail.com>:
> So the general rule is that if a feature isn't explicitly allowed in
> 27.007, we do not support it. There are exceptions to this of course.
> 27.007 only supports two states for context: activated and deactivated.
Ahem. Just like access selection mode is not in 27.007, yet Nokia has
it, and most AT modems have proprietary commands to query and set it
[1]. Maybe you call that the necessary exception to the rule, but I
think we might as well change the rule to:
So my stance on BandSelection is that we want a standard interface _if and
only if_ we can support it reliably across the majority of modems. You might
still find me telling every modem manufacturer to simply implement their own
BandSelection interface if this cannot be done.
The same goes for Neighbor Cell Info or any other stuff that isn't mandated by
27.007.
>> spec 27.007. However, the problem is that Maemo 5 already has UI
>> support for indicating that the connection is suspended, and that
>> makes it harder to drop the feature. Could the "suspended" status
enum
>> still be left there, and just have the modems that don't support the
>> feature to never go to "suspended" mode?
>
> I'd rather not.
>
> If this feature is really required, then some sort of heuristic can be
> applied. (e.g. Powered on, Attached on, but context is deactivated most
> likely means temporary unavailability of resources)
You want the UI to implement this heuristic, when the modem plugin has
explicit knowledge of that state, but isn't telling? Please explain
how that makes the UI simpler?
Then expose this signal on Nokia-only interface and be done with it. Why does
everything have to be part of the oFono official APIs?
Regards,
-Denis
4:38 p.m.
Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit :
Actually this one is missing from the API proposal. Marcel already
wanted
the context type (internet, mms, wap, etc) information. I've updated the
proposed API in git.
This is not going to work.
Depending on the operator, you may have more than one "type" for a single
context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g.
Internet with only Web and Internet with full IP).
As discussed previously, we want oFono to manage this data, since it
can do
this by using the IMSI. So if you insert a different operator SIM your APN
settings are magically updated for that operator.
I have a feeling this does not work either. If I upgrade my subscription, the
APN may change while not the IMSI, no?
> In my proposal the "Status" variable was a three-state
variable,
> having the states "attached", "detached" and
"suspended". "Suspended"
> was specified to mean that the GPRS was attached, but temporarily not
> available (for instance because of a 2G phone call or temporary loss
> of cellular connectivity). In the IRC discussion someone said that
> this property would not be part of Denis's API because the tri-state
> variables were bad and the "suspended" status was not supported by
So the general rule is that if a feature isn't explicitly allowed in
27.007, we do not support it. There are exceptions to this of course.
27.007 only supports two states for context: activated and deactivated.
Our general rule is that if we have a UI requirement, or better an actual use
case for it, we support it. Suspended GPRS fits both.
> spec 27.007. However, the problem is that Maemo 5 already has
UI
> support for indicating that the connection is suspended, and that
> makes it harder to drop the feature. Could the "suspended" status enum
> still be left there, and just have the modems that don't support the
> feature to never go to "suspended" mode?
I'd rather not.
If this feature is really required, then some sort of heuristic can be
applied. (e.g. Powered on, Attached on, but context is deactivated most
likely means temporary unavailability of resources)
Is this some kind of joke? Don't you know the difference between pause and
stop on your MP3 player and between suspend to memory and power off on your
computer?
Second guessing does not fit in my definition of "easy to use self-
documenting" for an API.
This really belong in the kernel. Only the kernel can reliably know
when a
network interface has been brought down and notify the interested
applications with the statistics.
You're missing the point.
Yes, any body can extract the statistics for a running context. But data
counters are cumulating. To compute the sum properly, there are but two
options:
# Either the GPRS middleware requests kernel per-interface statistics right
before destroying the interface, and sums with the earlier total.
# Or the modem does it internally.
There is no way some random userland interface application can do it just by
requesting the kernel, since it cannot know when to request those statistics.
Nokia hardware supports this explicitly, but many others don't.
That's irrelevant. Hardware support helps in the sense that it can include
statistics for contexts external to Ofono. If the hardware does not support
it, then it needs to be done manually in the GPRS middleware.
That won't make the requirement go away.
--
Rémi Denis-Courmont
http://www.remlab.net/
5:26 p.m.
Hi Remi,
Le mercredi 2 septembre 2009 18:00:22 Denis Kenzior, vous avez écrit
:
> Actually this one is missing from the API proposal. Marcel already
> wanted the context type (internet, mms, wap, etc) information. I've
> updated the proposed API in git.
This is not going to work.
Depending on the operator, you may have more than one "type" for a single
context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g.
Internet with only Web and Internet with full IP).
Worst case we make the field completely freeform. Right now we really only
care about "internet" type for connman.
> As discussed previously, we want oFono to manage this data, since it can
> do this by using the IMSI. So if you insert a different operator SIM
> your APN settings are magically updated for that operator.
I have a feeling this does not work either. If I upgrade my subscription,
the APN may change while not the IMSI, no?
Yes, but then you will probably receive an SMS/OTA message with new connection
details. Which either oFono or some external application will apply to your
GPRS settings.
> This really belong in the kernel. Only the kernel can reliably
know when
> a network interface has been brought down and notify the interested
> applications with the statistics.
You're missing the point.
Yes, any body can extract the statistics for a running context. But data
counters are cumulating. To compute the sum properly, there are but two
options:
# Either the GPRS middleware requests kernel per-interface statistics right
before destroying the interface, and sums with the earlier total.
# Or the modem does it internally.
I know why you want this, but I'm still against the counter being an oFono
driver API. There needs to be a proper kernel interface that signals the
application when an interface has gone away with the rx/tx details. This way
we handle this generically for all modems without relying on some intrinsic
hardware capabilities.
The rx/tx counter not being reported via PropertyChanged is also a bad idea
since it breaks our API conventions. I can deal with a one-time signal being
emitted when the interface has gone away though.
Regards,
-Denis
6:39 p.m.
> > This really belong in the kernel. Only the kernel can
reliably know
> > when a network interface has been brought down and notify the
> > interested applications with the statistics.
>
> You're missing the point.
>
> Yes, any body can extract the statistics for a running context. But data
> counters are cumulating. To compute the sum properly, there are but two
> options:
> # Either the GPRS middleware requests kernel per-interface statistics
> right before destroying the interface, and sums with the earlier total.
> # Or the modem does it internally.
I know why you want this, but I'm still against the counter being an oFono
driver API. There needs to be a proper kernel interface that signals the
application when an interface has gone away with the rx/tx details. This
way we handle this generically for all modems without relying on some
intrinsic hardware capabilities.
This still doesn't solve the case where the modem is accessed from a PC client and
forwards PPP data as that data will not go through any network interface, e.g. BT DUN or
USB tethering.
The modem is really in the best position to provide the most reliable information on data
usage. You can still use statistics from the network interfaces as a fall-back in case the
modem can not provide this information.
Cheers,
Waldo
6:46 p.m.
Hi Waldo,
> I know why you want this, but I'm still against the counter
being an
> oFono driver API. There needs to be a proper kernel interface that
> signals the application when an interface has gone away with the rx/tx
> details. This way we handle this generically for all modems without
> relying on some intrinsic hardware capabilities.
This still doesn't solve the case where the modem is accessed from a PC
client and forwards PPP data as that data will not go through any network
interface, e.g. BT DUN or USB tethering.
The cases you describe imply that oFono is not even in control of the gprs
context. How would we track/report the tx/rx statistics in that case?
The modem is really in the best position to provide the most reliable
information on data usage. You can still use statistics from the network
interfaces as a fall-back in case the modem can not provide this
information.
I don't disagree, but not every modem can track these statistics and this
isn't described by 27.007. I suggest the initial support should be enabled by
the modem driver implementing a custom D-Bus interface and expose these
details however it wishes.
Regards,
-Denis
7:41 p.m.
> > I know why you want this, but I'm still against the
counter being an
> > oFono driver API. There needs to be a proper kernel interface that
> > signals the application when an interface has gone away with the rx/tx
> > details. This way we handle this generically for all modems without
> > relying on some intrinsic hardware capabilities.
>
> This still doesn't solve the case where the modem is accessed from a PC
> client and forwards PPP data as that data will not go through any
> network interface, e.g. BT DUN or USB tethering.
The cases you describe imply that oFono is not even in control of the gprs
context. How would we track/report the tx/rx statistics in that case?
It's probably difficult if the PC client is allowed to redefine GPRS contexts, but
otherwise oFono should at least be able to report the total tx/rx for the context's it
has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the
stats to update them, e.g. when a BT DUN connection is disconnected.
> The modem is really in the best position to provide the most
reliable
> information on data usage. You can still use statistics from the network
> interfaces as a fall-back in case the modem can not provide this
> information.
I don't disagree, but not every modem can track these statistics and this
isn't described by 27.007. I suggest the initial support should be
enabled by the modem driver implementing a custom D-Bus interface and
expose these details however it wishes.
The modem driver has no desires of its own :-) It really comes down to what the UI needs
and I doubt that the UI wants to deal with this on a modem by modem basis, but sure
it's a possibility.
Cheers,
Waldo
10:01 p.m.
Hi Waldo,
> > > I know why you want this, but I'm still against
the counter being an
> > > oFono driver API. There needs to be a proper kernel interface that
> > > signals the application when an interface has gone away with the rx/tx
> > > details. This way we handle this generically for all modems without
> > > relying on some intrinsic hardware capabilities.
> >
> > This still doesn't solve the case where the modem is accessed from a PC
> > client and forwards PPP data as that data will not go through any
> > network interface, e.g. BT DUN or USB tethering.
>
> The cases you describe imply that oFono is not even in control of the gprs
> context. How would we track/report the tx/rx statistics in that case?
It's probably difficult if the PC client is allowed to redefine GPRS contexts, but
otherwise oFono should at least be able to report the total tx/rx for the context's it
has defined. The BT DUN / USB bridge could call into oFono and trigger a poll of all the
stats to update them, e.g. when a BT DUN connection is disconnected.
how should it do this if oFono is not in the mix. If you are using
Bluetooth DUN and point it to a virtual TTY, then you are out of look.
If using USB CDC ACM then same applies.
The real solution here is Bluetooth PAN and USB CDC Ether which do
properly interact with the networking stack.
> > The modem is really in the best position to provide the
most reliable
> > information on data usage. You can still use statistics from the network
> > interfaces as a fall-back in case the modem can not provide this
> > information.
>
> I don't disagree, but not every modem can track these statistics and this
> isn't described by 27.007. I suggest the initial support should be
> enabled by the modem driver implementing a custom D-Bus interface and
> expose these details however it wishes.
The modem driver has no desires of its own :-) It really comes down to what the UI needs
and I doubt that the UI wants to deal with this on a modem by modem basis, but sure
it's a possibility.
The current consent is that we might send a one time signal with all
statistics details once the interface goes away. Or we can make the
kernel help us here.
However I prefer that we sit this out a little and play with what is
possible before knocking down an API. I am not even sure what different
hardware would give us and how things need to work. I don't see us
having enough information to understand what is needed from a hardware,
driver or oFono core point of view.
Regards
Marcel
10:10 p.m.
Le jeudi 3 septembre 2009 00:01:03 Marcel Holtmann, vous avez écrit :
> It's probably difficult if the PC client is allowed to
redefine GPRS
> contexts, but otherwise oFono should at least be able to report the total
> tx/rx for the context's it has defined. The BT DUN / USB bridge could
> call into oFono and trigger a poll of all the stats to update them, e.g.
> when a BT DUN connection is disconnected.
how should it do this if oFono is not in the mix. If you are using
Bluetooth DUN and point it to a virtual TTY, then you are out of look.
If using USB CDC ACM then same applies.
The real solution here is Bluetooth PAN and USB CDC Ether which do
properly interact with the networking stack.
When we have patched all the Windows PC of the world, we can consider it.
In the mean time, AT+PPP emulation is required. Some modems do provide data
counters including that. I've seen it as a requirement that I would rather
have avoided but could not. It's ugly and arguably stupid, but required
anyway. In fact, if Ofono won't do it, ConnMan will have to, which is probably
by all means worse.
You can argue that it should be a driver-specific feature, but it has to be
there. Hence, I would guess that more than one driver will support eventually,
at which point it should probably be in the common API.
--
Rémi Denis-Courmont
http://www.remlab.net/
10:18 p.m.
Hi Remi,
> > It's probably difficult if the PC client is allowed to
redefine GPRS
> > contexts, but otherwise oFono should at least be able to report the total
> > tx/rx for the context's it has defined. The BT DUN / USB bridge could
> > call into oFono and trigger a poll of all the stats to update them, e.g.
> > when a BT DUN connection is disconnected.
>
> how should it do this if oFono is not in the mix. If you are using
> Bluetooth DUN and point it to a virtual TTY, then you are out of look.
> If using USB CDC ACM then same applies.
>
> The real solution here is Bluetooth PAN and USB CDC Ether which do
> properly interact with the networking stack.
When we have patched all the Windows PC of the world, we can consider it.
my approach would be to try and see how far we get this pushing towards
PAN and CDC Ether :)
In the mean time, AT+PPP emulation is required. Some modems do
provide data
counters including that. I've seen it as a requirement that I would rather
have avoided but could not. It's ugly and arguably stupid, but required
anyway. In fact, if Ofono won't do it, ConnMan will have to, which is probably
by all means worse.
Actually it is worth for high-speed modems with a network interface and
no internal PPP emulation, we would have to do that emulation somewhere
in the host stack. And now my brain hurts :(
You can argue that it should be a driver-specific feature, but it has
to be
there. Hence, I would guess that more than one driver will support eventually,
at which point it should probably be in the common API.
We have to figure something out, but right I would prefer if we GPRS up
and running and after that tackle the statistics part. Since without
GPRS, we don't need the statistics ;)
Regards
Marcel
9:53 p.m.
Hi Remi,
> Actually this one is missing from the API proposal. Marcel
already wanted
> the context type (internet, mms, wap, etc) information. I've updated the
> proposed API in git.
This is not going to work.
Depending on the operator, you may have more than one "type" for a single
context (e.g. WAP+MMS), or worse, multiple contexts of the same type (e.g.
Internet with only Web and Internet with full IP).
we might need some extra work here and define what we want. I am
confident that we can break this down to something useful. Worst case we
something free form.
> As discussed previously, we want oFono to manage this data,
since it can do
> this by using the IMSI. So if you insert a different operator SIM your APN
> settings are magically updated for that operator.
I have a feeling this does not work either. If I upgrade my subscription, the
APN may change while not the IMSI, no?
We can update these details at any time. Storing them on a per ISMI
basis is a good idea and something new that oFono does (as far as what I
have seen). So if you switch SIM cards, then you don't have to worry
about anything when traveling. It does the right thing you configured.
Especially with the devices like the Nokia netbook and the iPhone where
you can easily switch SIM cards without power on/off this will come in
handy.
If an upgrade of the subscription needs manual interaction from the user
or an operator message to update the settings, then that is fine. Since
the user did something to begin with. So they are aware of that
something changed (hope the operator told them). While just switching a
SIM card and by accident using a wrong APN and causing expensive roaming
would be a worse thing. Especially since there is an expectation from
the user when switching SIM cards.
> > In my proposal the "Status" variable was a
three-state variable,
> > having the states "attached", "detached" and
"suspended". "Suspended"
> > was specified to mean that the GPRS was attached, but temporarily not
> > available (for instance because of a 2G phone call or temporary loss
> > of cellular connectivity). In the IRC discussion someone said that
> > this property would not be part of Denis's API because the tri-state
> > variables were bad and the "suspended" status was not supported by
>
> So the general rule is that if a feature isn't explicitly allowed in
> 27.007, we do not support it. There are exceptions to this of course.
> 27.007 only supports two states for context: activated and deactivated.
Our general rule is that if we have a UI requirement, or better an actual use
case for it, we support it. Suspended GPRS fits both.
Can you share these UI requirements with us.
> > spec 27.007. However, the problem is that Maemo 5 already
has UI
> > support for indicating that the connection is suspended, and that
> > makes it harder to drop the feature. Could the "suspended" status
enum
> > still be left there, and just have the modems that don't support the
> > feature to never go to "suspended" mode?
>
> I'd rather not.
>
> If this feature is really required, then some sort of heuristic can be
> applied. (e.g. Powered on, Attached on, but context is deactivated most
> likely means temporary unavailability of resources)
Is this some kind of joke? Don't you know the difference between pause and
stop on your MP3 player and between suspend to memory and power off on your
computer?
Second guessing does not fit in my definition of "easy to use self-
documenting" for an API.
> This really belong in the kernel. Only the kernel can reliably know when a
> network interface has been brought down and notify the interested
> applications with the statistics.
You're missing the point.
Yes, any body can extract the statistics for a running context. But data
counters are cumulating. To compute the sum properly, there are but two
options:
# Either the GPRS middleware requests kernel per-interface statistics right
before destroying the interface, and sums with the earlier total.
# Or the modem does it internally.
There is no way some random userland interface application can do it just by
requesting the kernel, since it cannot know when to request those statistics.
So my 2 cents here are that whatever so modem does for statistics it
should match the details its exports via the networking interface.
And on the kernel part and destroyed interface, as I mentioned, we need
to discuss this with the kernel guys. I wanna get an answer what can be
done to help us. We have most kernel guys at netconf in Portland in
three weeks and I gonna check with them.
> Nokia hardware supports this explicitly, but many others
don't.
That's irrelevant. Hardware support helps in the sense that it can include
statistics for contexts external to Ofono. If the hardware does not support
it, then it needs to be done manually in the GPRS middleware.
That won't make the requirement go away.
What do you expect middleware to do exactly. Our problem is that we
loose the latest state of statistics when interface destroyed. If that
can be fixed inside the kernel, why work around in user space. In case
it can not be fixed and solved to what we need then we revisit this
proposal. Until then we should put this on hold.
Regards
Marcel
4:37 p.m.
Hi Ismo,
I started working on Ofono GPRS support.
The patch set contains:
1) Documentation describing how an Ofono GPRS D-Bus API would look like.
2) Common Ofono GPRS support.
3) Ofono GPRS ISI driver.
4) Test script for trying out the GPRS functionality.
Note that the GPRS support is in no way completed -- many things are
still TODO or have rough edges. However, I thought that it would be a
good idea to send the patches to the mailing list to gather comments
and improvement suggestions before finalizing the work.
since we have the upstream GPRS support for MBM and HSO devices, it
would be great to have this for Phonet, too. I tried to work on the
patch, but without proper documentation it is impossible. So please
adapt it to the current upstream and resend it.
Regards
Marcel
11 a.m.
Hi Marcel,
since we have the upstream GPRS support for MBM and HSO devices, it
would be great to have this for Phonet, too. I tried to work on the
patch, but without proper documentation it is impossible. So please
adapt it to the current upstream and resend it.
Yes, the GPRS ISI support has been delayed. Because the internal API
between the Ofono GPRS atom and the modem driver was changed, the ISI
driver won't work out of the box. I have been recently quite busy with
other tasks, but I'll try to find the time to do the porting or
preferably get Rémi to do it. :-) Since the ISI GPRS support was
already demonstrated to be working, the actual work amount shouldn't
be too big.
--
Ismo Puustinen <ismo(a)iki.fi>
3:40 p.m.
Hi Ismo,
> since we have the upstream GPRS support for MBM and HSO devices,
it
> would be great to have this for Phonet, too. I tried to work on the
> patch, but without proper documentation it is impossible. So please
> adapt it to the current upstream and resend it.
Yes, the GPRS ISI support has been delayed. Because the internal API
between the Ofono GPRS atom and the modem driver was changed, the ISI
driver won't work out of the box. I have been recently quite busy with
other tasks, but I'll try to find the time to do the porting or
preferably get Rémi to do it. :-) Since the ISI GPRS support was
already demonstrated to be working, the actual work amount shouldn't
be too big.
I tried it by myself, but without the ISI specification, it is a pretty
big effort. So we rely on you guys to do it. Do you have any estimate
when this could be achieved. I am asking because this feature is also
useful for desktop users wanting to attach their Nokia phone just for
Internet access. Better than Dialup and PPP since they would get proper
signal strength etc. with it.
Regards
Marcel
12:38 p.m.
On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
since we have the upstream GPRS support for MBM and HSO devices, it
would be great to have this for Phonet, too. I tried to work on the
patch, but without proper documentation it is impossible. So please
adapt it to the current upstream and resend it.
I can't quite implement the current API for ISI modem. For a start, ofono
is currently crashing in setpowered as soon as it sees an ISI modem.
But there are some more fundamental issues. First, the ISI General Packet
Data Service does not provide any location informations (roaming/not
roaming, area code, cell ID). And I must say I don't understand why this is
part of the GPRS atom. This has nothing to do with packet data.
Second, I couldn't figure how to handle auto-attach. The ISI protocol
supports it, but I could not find the driver callback. Thus, I would have
to force the device into manual mode. This is going to be an issue as some
operators require auto-attach
Also, it prevents optimizing context activation when detached, i.e. "follow
on" GPRS attach, which the ISI modem provides.
I haven't had time to look at the context stuff yet.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
3:39 p.m.
Hi Remi,
On Sat, 05 Dec 2009 17:37:36 +0100, Marcel Holtmann
<marcel(a)holtmann.org>
wrote:
> since we have the upstream GPRS support for MBM and HSO devices, it
> would be great to have this for Phonet, too. I tried to work on the
> patch, but without proper documentation it is impossible. So please
> adapt it to the current upstream and resend it.
I can't quite implement the current API for ISI modem. For a start, ofono
is currently crashing in setpowered as soon as it sees an ISI modem.
Wasn't this fixed by commit ee1e9d14bde006da64d3e9d0c1f61523f113869a?
If not, get me a backtrace or a patch.
But there are some more fundamental issues. First, the ISI General Packet
Data Service does not provide any location informations (roaming/not
roaming, area code, cell ID). And I must say I don't understand why this is
part of the GPRS atom. This has nothing to do with packet data.
That is because 3GPP in their infinite wisdom structured the spec this way.
There are 2 registration states, one reported by CREG and one reported by
CGREG. Both report essentially the same information, namely registration
status, lac, cellid and radio access technology.
The way we know an AT-command based modem is attached is when we start
receiving these CGREG indications (registered/roaming + lac/ci/rat)
I'm open to suggestions on how to fix this (for instance we can get rid of
Status, LocationAreaCode, CellId attributes, since they're essentially the
same as in NetworkRegistration interface), but for now this can be easily
faked by just re-using the information you're providing to netreg atom.
Second, I couldn't figure how to handle auto-attach. The ISI protocol
supports it, but I could not find the driver callback. Thus, I would have
to force the device into manual mode. This is going to be an issue as some
operators require auto-attach
Is this where the network requests an attach or are you talking about
something else?
Regards,
-Denis
4:31 p.m.
----- Message d'origine -----
> But there are some more fundamental issues. First, the ISI
General Packet
> Data Service does not provide any location informations (roaming/not
> roaming, area code, cell ID). And I must say I don't understand why this is
> part of the GPRS atom. This has nothing to do with packet data.
That is because 3GPP in their infinite wisdom structured the spec this way.
Just because AT commands group both pieces of unrelated data does not mean it is a good
idea. I fail to see why the DBus and driver API should do the same mistake as 3GPP
27.007.
There are 2 registration states, one reported by CREG and one
reported by
CGREG. Both report essentially the same information, namely registration
status, lac, cellid and radio access technology.
The way we know an AT-command based modem is attached is when we start
receiving these CGREG indications (registered/roaming + lac/ci/rat)
A device cannot attach to GPRS an a different network than the one it is registered with.
I do not see the value of tying those in oFono. The caller can use the network
registration interface, and in fact, I think it should.
I am not an expert on GPRS internals but I guess the protocol does not provide those
values, and this is just a misdesign of AT commands.
I'm open to suggestions on how to fix this (for instance we can
get rid of
Status, LocationAreaCode, CellId attributes, since they're essentially the
same as in NetworkRegistration interface), but for now this can be easily
faked by just re-using the information you're providing to netreg atom.
I could steal that data, but it would be vomitively ugly. Worse, it would be hide a race
condition through the DBus interface. There is no way for me to request both atomically.
> Second, I couldn't figure how to handle auto-attach. The ISI
protocol
> supports it, but I could not find the driver callback. Thus, I would have
> to force the device into manual mode. This is going to be an issue as some
> operators require auto-attach
Is this where the network requests an attach or are you talking about
something else?
No no, I am not talking about network-initiated context *activation*. I am talking about
the requirement from some operator that the device be always *attached* even if it has no
active contexts. Note that the battery impact is negligible. Also, this is NOT quite the
same as attaching when oFono starts: the device could be outside of the GPRS network;
auto-attach will get it attached as soon as possible.
Rémi
4:53 p.m.
Hi Rem,
> That is because 3GPP in their infinite wisdom structured the
spec this
> way.
Just because AT commands group both pieces of unrelated data does not mean
it is a good idea. I fail to see why the DBus and driver API should do the
same mistake as 3GPP 27.007.
I already told you I'm open to fixing it. However 27.007 is the only standard
we have right now.
> There are 2 registration states, one reported by CREG and one reported by
> CGREG. Both report essentially the same information, namely registration
> status, lac, cellid and radio access technology.
>
> The way we know an AT-command based modem is attached is when we start
> receiving these CGREG indications (registered/roaming + lac/ci/rat)
A device cannot attach to GPRS an a different network than the one it is
registered with. I do not see the value of tying those in oFono. The caller
can use the network registration interface, and in fact, I think it should.
Different network probably not, but different base station? Again I'm not the
expert here either. The API was posted for review back in early September,
and Nokia participated in the design.
If someone can give a definitive answer we can look into making our API more
sane.
> I'm open to suggestions on how to fix this (for instance we
can get rid
> of Status, LocationAreaCode, CellId attributes, since they're essentially
> the same as in NetworkRegistration interface), but for now this can be
> easily faked by just re-using the information you're providing to netreg
> atom.
I could steal that data, but it would be vomitively ugly. Worse, it would
be hide a race condition through the DBus interface. There is no way for me
to request both atomically.
What race condition? The attach callback does not mean we're attached at that
point, it just means we're trying to. Attached status only comes in once
we're 'registered' to GPRS, so you can safely query whatever you need and then
call ofono_gprs_status_notify
> Is this where the network requests an attach or are you talking
about
> something else?
No no, I am not talking about network-initiated context *activation*. I am
talking about the requirement from some operator that the device be always
*attached* even if it has no active contexts. Note that the battery impact
is negligible. Also, this is NOT quite the same as attaching when oFono
starts: the device could be outside of the GPRS network; auto-attach will
get it attached as soon as possible.
I believe the current API already covers this. Context active state and
attached state are tracked separately. Thus you can be attached with no
active context, I do it all the time. Can't you just turn on your 'auto-
attach' mode when oFono calls 'set_attached' with TRUE and turn off attachment
when oFono calls 'set_attached' with FALSE?
Regards,
-Denis
5:11 p.m.
----- Message d'origine -----
I already told you I'm open to fixing it. However 27.007 is the
only standard
we have right now.
That's easy to fix. Remove those from the GPRS status.
Different network probably not, but different base station? Again
I'm not the
expert here either. The API was posted for review back in early September,
and Nokia participated in the design.
That is not possible either to our understanding. If it were possible, the ISI modems
would expose that data separately, which they don't.
> No no, I am not talking about network-initiated context
*activation*. I am
> talking about the requirement from some operator that the device be always
> *attached* even if it has no active contexts. Note that the battery impact
> is negligible. Also, this is NOT quite the same as attaching when oFono
> starts: the device could be outside of the GPRS network; auto-attach will
> get it attached as soon as possible.
I believe the current API already covers this. Context active state and
attached state are tracked separately. Thus you can be attached with no
active context, I do it all the time. Can't you just turn on your 'auto-
attach' mode when oFono calls 'set_attached' with TRUE and turn off
attachment
when oFono calls 'set_attached' with FALSE?
That is different. If you are outside of coverage, or in a non-GPRS area, you can turn
auto-attach on. That will make some operators happy but it wont't attach just yet.
Whether it makes practical sense, I dunno. Operators ask for this. Maybe there is a reason
(maybe not).
Rémi
5:25 p.m.
Hi Remi,
----- Message d'origine -----
> I already told you I'm open to fixing it. However 27.007 is the only
> standard we have right now.
That's easy to fix. Remove those from the GPRS status.
The core only reports these attributes, it doesn't actually use them for
anything. When attached you can simply send a status=registered, LAC, CellId
and Tech set to -1. We can see about removing these a bit later.
> Different network probably not, but different base station? Again I'm
> not the expert here either. The API was posted for review back in early
> September, and Nokia participated in the design.
That is not possible either to our understanding. If it were possible, the
ISI modems would expose that data separately, which they don't.
I suspect you're right.
> I believe the current API already covers this. Context active
state and
> attached state are tracked separately. Thus you can be attached with no
> active context, I do it all the time. Can't you just turn on your 'auto-
> attach' mode when oFono calls 'set_attached' with TRUE and turn off
> attachment when oFono calls 'set_attached' with FALSE?
That is different. If you are outside of coverage, or in a non-GPRS area,
you can turn auto-attach on. That will make some operators happy but it
wont't attach just yet.
Sorry I don't see a practical difference. You set 'Powered' to TRUE, gprs
atom
issues a 'set_attached' with TRUE. Once you have attached the driver sends
out a ofono_gprs_status_notify. Whether this happens in 1 second or 2 hours
doesn't really matter.
Regards,
-Denis
6:09 p.m.
The core only reports these attributes, it doesn't actually use
them for
anything. When attached you can simply send a status=registered, LAC, CellId
and Tech set to -1. We can see about removing these a bit later.
I would do that, but there is no apparent way to return the attached state without making
a statement on roaming as well. IOW, this is unimplementable with ISI.
> That is different. If you are outside of coverage, or in a
non-GPRS area,
> you can turn auto-attach on. That will make some operators happy but it
> wont't attach just yet.
Sorry I don't see a practical difference. You set 'Powered' to TRUE, gprs
atom
issues a 'set_attached' with TRUE. Once you have attached the driver sends
out a ofono_gprs_status_notify. Whether this happens in 1 second or 2 hours
doesn't really matter.
Again and again, auto-attach and attach are different things. Setting attach to false will
forcefully deactivate all existing contexts and detach the terminal from GPRS. Setting
auto-attach to false will cause the terminal to detach after all pending contexts are
deactivated, but won't cause them to be detached immediately (AT+CGATT does that).
Conversely, enabling auto-attach will cause the terminal to attach once it has GPRS
coverage, whereas false will have it wait for an explicit attach request, or implicitly
for a context activation. This is dkifferent from attaching which is an immediate action
and will fail if GPRS is unavailable (like AT+CGATT).
Furthermore, when attaching, the terminal is supposed to state its intent to activate a
context immediately or not. If it does, then some optimizations are possible in 3G case.
Rémi
6:25 p.m.
Hi Remi,
> The core only reports these attributes, it doesn't actually
use them for
> anything. When attached you can simply send a status=registered, LAC,
> CellId and Tech set to -1. We can see about removing these a bit later.
I would do that, but there is no apparent way to return the attached state
without making a statement on roaming as well. IOW, this is unimplementable
with ISI.
Don't worry about this for now. The roaming of CGREG is never checked, only
CREG roaming state is checked. You can safely return status=registered here.
> > That is different. If you are outside of coverage, or in a non-GPRS
> > area, you can turn auto-attach on. That will make some operators happy
> > but it wont't attach just yet.
>
> Sorry I don't see a practical difference. You set 'Powered' to TRUE,
> gprs atom issues a 'set_attached' with TRUE. Once you have attached the
> driver sends out a ofono_gprs_status_notify. Whether this happens in 1
> second or 2 hours doesn't really matter.
Again and again, auto-attach and attach are different things. Setting
attach to false will forcefully deactivate all existing contexts and detach
the terminal from GPRS. Setting auto-attach to false will cause the
terminal to detach after all pending contexts are deactivated, but won't
cause them to be detached immediately (AT+CGATT does that).
Conversely, enabling auto-attach will cause the terminal to attach once it
has GPRS coverage, whereas false will have it wait for an explicit attach
request, or implicitly for a context activation. This is dkifferent from
attaching which is an immediate action and will fail if GPRS is unavailable
(like AT+CGATT).
Again, I don't see a point of exposing this to the user. Worst case we can
always add intelligence / heuristics to oFono to attempt re-attaching
periodically. We have to solve this for all modems, since there are no such
'auto-attach' semantics in 27.007.
One strategy you can use today is to just activate auto-attach when the driver
is asked to attach and force a detach when the driver is asked to detach.
This is essentially the behavior of most AT command modems.
Furthermore, when attaching, the terminal is supposed to state its
intent
to activate a context immediately or not. If it does, then some
optimizations are possible in 3G case.
I have two suggestions here:
1. Lets make it work first, we can then make it work better.
2. Can you describe these optimizations and suggest how the API/behavior can
be changed to take advantage of them?
Regards,
-Denis
7:13 p.m.
----- Message d'origine -----
Again, I don't see a point of exposing this to the user. Worst
case we can
always add intelligence / heuristics to oFono to attempt re-attaching
periodically. We have to solve this for all modems, since there are no such
'auto-attach' semantics in 27.007.
If it comes to the question of usefulness, I find the current attach/detach to be even
more useless than always-attach/demand-attach.
AT modems will attach automatically when a context is activated, so do ISI modems (when
adequately configured), and foobar modems could always emulate it (from inside their
context API).
I agree that auto-attach is not of much use to end-users, for the exact same reason that
attach is not very useful. But it is apparently of use to network operators at least.
One strategy you can use today is to just activate auto-attach when
the driver
is asked to attach and force a detach when the driver is asked to detach.
This is essentially the behavior of most AT command modems.
Sure. ISI modems can do that too. And I argue it makes manual attach/detach even more
useless than auto-attach.
I'd note that flight mode requires deregistering from the network as a whole, not just
detaching from GPRS anyway.
So I can implement the current attach/detach logic, but it seems not very pertinent to me
as an API.
I have two suggestions here:
1. Lets make it work first, we can then make it work better.
2. Can you describe these optimizations and suggest how the API/behavior can
be changed to take advantage of them?
We just need to know if the core or the upper-layer application intends to activate a
context. It is a boolean flag hint to Attach basically.
7:34 p.m.
Hi Remi,
----- Message d'origine -----
> Again, I don't see a point of exposing this to the user. Worst case we
> can always add intelligence / heuristics to oFono to attempt re-attaching
> periodically. We have to solve this for all modems, since there are no
> such 'auto-attach' semantics in 27.007.
If it comes to the question of usefulness, I find the current attach/detach
to be even more useless than always-attach/demand-attach.
There are actually usecases for being attached and not having an active
context. Most of this comes from weird devices that cannot be attached to GSM
& GPRS at the same time or have other limitations.
We also have MO SMS bearer selection (+CGSMS) to consider here.
Not to mention that the network can actually activate a context on the modem
without user action which is used in IMS I believe.
And of course context activation latency is also something to consider.
Please don't just say 'It sucks' or 'I don't like this', offer up
what *you*
think the API should look like. The most appropriate time was in September
when we were having these design discussions, but it is never too late to
change it.
Regards,
-Denis
7:35 p.m.
Hi Remi
> I have two suggestions here:
> 1. Lets make it work first, we can then make it work better.
> 2. Can you describe these optimizations and suggest how the API/behavior can
> be changed to take advantage of them?
We just need to know if the core or the upper-layer application intends to activate a
context. It is a boolean flag hint to Attach basically.
I really prefer that we get this working first and then talk again about
usefulness, API issues etc. We are clearly stating that the API is not
set in stone yet. And that is on purpose since we still have some areas
where we have to see what makes most sense in practice and how it plays
together with other systems.
In some cases we better add a configuration option to a global config
file instead of exposing this via a D-Bus. In other cases D-Bus is the
better choice. For me the attach policy sounds like a configuration
option that the system integrators should be choosing at package time
depending on operator preference/requirement.
Regards
Marcel
1:46 p.m.
On Wed, 09 Dec 2009 13:38:18 +0100, Rémi Denis-Courmont <remi(a)remlab.net>
wrote:
I haven't had time to look at the context stuff yet.
It's just worse. oFono is enforcing an integer ID on any primary context.
This is again an idiosyncrasy of AT commands. With ISI modems, the context
ID space is managed by the modem, so oFono does not get to choose.
In theory, I could remap those, but that really would not make sense.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
2:27 p.m.
Hi Remi,
> I haven't had time to look at the context stuff yet.
It's just worse. oFono is enforcing an integer ID on any primary context.
This is again an idiosyncrasy of AT commands. With ISI modems, the context
ID space is managed by the modem, so oFono does not get to choose.
In theory, I could remap those, but that really would not make sense.
there has to be a mapping on some level. At least one driver has to do
some sort of mapping. If you have a better idea to handle it in the core
daemon, please propose something.
Please remember that non of us have the ISI specification and until you
guys communicate these details with us, we go based on what public
specifications are using.
Regards
Marcel
2:35 p.m.
On Thu, 10 Dec 2009 15:27:26 +0100, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
there has to be a mapping on some level. At least one driver has to
do
some sort of mapping. If you have a better idea to handle it in the core
daemon, please propose something.
Of course we have context ID. But we cannot manage them ourselves - the
modem does it.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
2:45 p.m.
Hi Remi,
> there has to be a mapping on some level. At least one driver has
to do
> some sort of mapping. If you have a better idea to handle it in the core
> daemon, please propose something.
Of course we have context ID. But we cannot manage them ourselves - the
modem does it.
I did understand that part. What is your proposal to handle this better?
Problem is I don't know how the PDP context setup flow works in ISI and
so I would be wild guessing until you propose something.
Regards
Marcel
3:43 p.m.
Hello,
On Thu, 10 Dec 2009 15:45:21 +0100, Marcel Holtmann <marcel(a)holtmann.org>
wrote:
> > there has to be a mapping on some level. At least one driver
has to do
> > some sort of mapping. If you have a better idea to handle it in the
> > core daemon, please propose something.
>
> Of course we have context ID. But we cannot manage them ourselves - the
> modem does it.
I did understand that part. What is your proposal to handle this better?
Problem is I don't know how the PDP context setup flow works in ISI and
so I would be wild guessing until you propose something.
It goes like this:
1. Allocate context ID from the modem.
2. Configure context.
3. Authenticate.
4. Setup local link.
5. Activate context.
6. Profit.
7. Deactivate context.
8. Tear down local link.
9. Delete context ID.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
4:01 p.m.
Hi Remi,
>> > there has to be a mapping on some level. At least one
driver has to do
>> > some sort of mapping. If you have a better idea to handle it in the
>> > core daemon, please propose something.
>>
>> Of course we have context ID. But we cannot manage them ourselves - the
>> modem does it.
>
> I did understand that part. What is your proposal to handle this better?
>
> Problem is I don't know how the PDP context setup flow works in ISI and
> so I would be wild guessing until you propose something.
It goes like this:
1. Allocate context ID from the modem.
2. Configure context.
3. Authenticate.
4. Setup local link.
5. Activate context.
6. Profit.
7. Deactivate context.
8. Tear down local link.
9. Delete context ID.
doesn't sound like a big problem to me at all. I think there are
multiple ways to solve this and make it simple for all drivers to
provide their own method of allocating context IDs.
One approach might be to add a callback to ofono_grps_context_driver to
allocate the context ID. If present then the modem driver is responsible
to allocate them. If not then the core will do it for you.
Essentially a way of overwriting gprs_cid_alloc() from within a driver.
Regards
Marcel
2:52 p.m.
Hi Remi,
On Thu, 10 Dec 2009 15:27:26 +0100, Marcel Holtmann
<marcel(a)holtmann.org>
wrote:
> there has to be a mapping on some level. At least one driver has to do
> some sort of mapping. If you have a better idea to handle it in the core
> daemon, please propose something.
Of course we have context ID. But we cannot manage them ourselves - the
modem does it.
A context atom in ofono represents the active/activating context. The id is
managed by the core since the majority of the hardware in this world does it
like this. There can be several gprs-context atoms present in a modem at
once. So context management inside the gprs context would be extremely
tricky.
I suggest you store the id in a private struct and let the modem pick you one.
As long as you notify oFono of context deactivation using the id it gave you,
everyone is happy.
Regards,
-Denis
4548
days inactive
4648
days old
62 comments
8 participants
participants (8)
-
Aki Niemi -
Bastian, Waldo -
Christensen, Mikkel -
Denis Kenzior -
Ismo Puustinen -
Jean-Christian de Rivaz -
Marcel Holtmann -
Rémi Denis-Courmont