6:02 a.m.
From: Forest Bond <forest.bond(a)rapidrollout.com>
If the device has retained parameters for a previously defined IP
context, is is probed via AT+CGDCONT?.
---
drivers/atmodem/gprs.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 3005867..280ca49 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -35,6 +35,7 @@
#include <ofono/log.h>
#include <ofono/modem.h>
#include <ofono/gprs.h>
+#include <ofono/gprs-provision.h>
#include "gatchat.h"
#include "gatresult.h"
@@ -408,6 +409,56 @@ error:
ofono_gprs_remove(gprs);
}
+static void at_cgdcont_read_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_gprs *gprs = user_data;
+ struct gprs_data *gd = ofono_gprs_get_data(gprs);
+ GAtResultIter iter;
+ gint cid;
+ const char *pdp_type;
+ const char *apn;
+ struct ofono_gprs_provision_data *ap;
+ gboolean found = FALSE;
+
+ if (!ok)
+ goto done;
+
+ g_at_result_iter_init(&iter, result);
+
+ while (!found && g_at_result_iter_next(&iter, "+CGDCONT:")) {
+ if (!g_at_result_iter_next_number(&iter, &cid))
+ continue;
+
+ if (!g_at_result_iter_next_string(&iter, &pdp_type))
+ continue;
+
+ if (!g_at_result_iter_next_string(&iter, &apn))
+ continue;
+
+ /* We look for IP PDPs */
+ if (g_str_equal(pdp_type, "IP"))
+ found = TRUE;
+ }
+
+ if (found == FALSE)
+ goto done;
+
+ ap = g_try_new0(struct ofono_gprs_provision_data, 1);
+ if (ap == NULL)
+ goto done;
+
+ ap->type = OFONO_GPRS_CONTEXT_TYPE_INTERNET;
+ ap->proto = OFONO_GPRS_PROTO_IP;
+ ap->apn = g_strdup(apn);
+ ofono_info("Probed AP %s from device", apn);
+ ofono_gprs_set_probed_ap(gprs, ap);
+
+done:
+ g_at_chat_send(gd->chat, "AT+CGREG=?", cgreg_prefix,
+ at_cgreg_test_cb, gprs, NULL);
+}
+
static void at_cgdcont_test_cb(gboolean ok, GAtResult *result,
gpointer user_data)
{
@@ -454,8 +505,8 @@ static void at_cgdcont_test_cb(gboolean ok, GAtResult *result,
ofono_gprs_set_cid_range(gprs, min, max);
- g_at_chat_send(gd->chat, "AT+CGREG=?", cgreg_prefix,
- at_cgreg_test_cb, gprs, NULL);
+ g_at_chat_send(gd->chat, "AT+CGDCONT?", cgdcont_prefix,
+ at_cgdcont_read_cb, gprs, NULL);
return;
--
1.7.0.4
10:12 a.m.
Hi Forest,
If the device has retained parameters for a previously defined IP
context, is is probed via AT+CGDCONT?.
this is really not a good idea. The AT+CGDCONT? settings are on a per
device basis. That is not how oFono actually works. It operates on a per
SIM card basis. And since you do not know to what SIM card these
previous settings apply to, the only sensible thing to do is to ignore
them.
You do know that oFono does keep its settings per SIM card persistent.
So no matter what device you enter that SIM card into, the settings will
be available the next time you try to connect. So it is a one time
configuration option.
Regards
Marcel
1:54 p.m.
Hi Marcel,
Thanks for your message.
On Thu, Dec 06, 2012 at 12:12:26AM +0100, Marcel Holtmann wrote:
Hi Forest,
> If the device has retained parameters for a previously defined IP
> context, is is probed via AT+CGDCONT?.
this is really not a good idea. The AT+CGDCONT? settings are on a per
device basis. That is not how oFono actually works. It operates on a per
SIM card basis. And since you do not know to what SIM card these
previous settings apply to, the only sensible thing to do is to ignore
them.
Okay, I was not aware of this. But surely the common case (i.e. the only one
I've personally seen) is to have a single SIM card per device, and under those
limited circumstances it is safe to assume that the settings are valid for that
SIM. Would it be reasonable to implement such a fallback for this more limited
case?
You do know that oFono does keep its settings per SIM card
persistent.
So no matter what device you enter that SIM card into, the settings will
be available the next time you try to connect. So it is a one time
configuration option.
Yes, I do know this. But it's just not a great fit for our use case.
We're using ConnMan and oFono to manage networking for computing appliances
(e.g. interactive kiosks and digital signs). These are typically deployed in
fleets of anywhere from 10 to 10,000 units. Clearly we do not want to manually
configure an APN for each machine. ;)
Ideally, we try to use a single configuration for the entire fleet to keep the
fleet easy to manage. But for a variety of business and technical reasons,
multiple service providers may be used within a given fleet. So we can't simply
provision a single APN for the entire fleet. What we really want is to be able
to plug a modem into the machine and it will Just Work.
So we'd like to choose the right APN based solely on information from the modem.
I've observed that modems tend to arrive with an IP context pre-configured
(including the correct APN). I assume the service provider sets this as part of
some internal provisioning process. Perhaps it is not safe to assume that this
will be the case with the majority of devices and/or providers. On the other
hand, if it is, it seems sensible to make use of that data.
The alternative to pulling the data from the device is to provide a mechanism
for specifying the APN policy for a particular fleet. (At least in theory the
APN selection policy can vary from one fleet to the next.) I assume this would
be implemented as a custom provisioning plugin that either hard-codes the policy
for the fleet, or provides a configuration mechanism that is flexible enough to
accommodate the needs of most fleets (probably using a provider -> APN mapping,
assuming we can guess the provider e.g. using the mobile-broadband-provider-info
database).
So this is probably a little heavier on the configuration side, but at least the
policy configuration would be the same over the entire fleet. I think we could
live with that. But of course it would be much easier if we didn't have to
bother. ;)
Thoughts?
Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com
3:41 p.m.
Hi Forest,
On 12/05/2012 08:54 PM, Forest Bond wrote:
Hi Marcel,
Thanks for your message.
On Thu, Dec 06, 2012 at 12:12:26AM +0100, Marcel Holtmann wrote:
> Hi Forest,
>
>> If the device has retained parameters for a previously defined IP
>> context, is is probed via AT+CGDCONT?.
>
> this is really not a good idea. The AT+CGDCONT? settings are on a per
> device basis. That is not how oFono actually works. It operates on a per
> SIM card basis. And since you do not know to what SIM card these
> previous settings apply to, the only sensible thing to do is to ignore
> them.
Okay, I was not aware of this. But surely the common case (i.e. the only one
I've personally seen) is to have a single SIM card per device, and under those
limited circumstances it is safe to assume that the settings are valid for that
SIM. Would it be reasonable to implement such a fallback for this more limited
case?
I admit your approach did make me chuckle for being so unorthodox :)
However, I think your perception is slightly wrong, there are people who
switch sim cards like crazy (e.g. frequent travelers) so this form of
provisioning is not really a good idea in those cases.
> You do know that oFono does keep its settings per SIM card
persistent.
> So no matter what device you enter that SIM card into, the settings will
> be available the next time you try to connect. So it is a one time
> configuration option.
Yes, I do know this. But it's just not a great fit for our use case.
We're using ConnMan and oFono to manage networking for computing appliances
(e.g. interactive kiosks and digital signs). These are typically deployed in
fleets of anywhere from 10 to 10,000 units. Clearly we do not want to manually
configure an APN for each machine. ;)
Ideally, we try to use a single configuration for the entire fleet to keep the
fleet easy to manage. But for a variety of business and technical reasons,
multiple service providers may be used within a given fleet. So we can't simply
provision a single APN for the entire fleet. What we really want is to be able
to plug a modem into the machine and it will Just Work.
So we'd like to choose the right APN based solely on information from the modem.
I've observed that modems tend to arrive with an IP context pre-configured
(including the correct APN). I assume the service provider sets this as part of
some internal provisioning process. Perhaps it is not safe to assume that this
will be the case with the majority of devices and/or providers. On the other
hand, if it is, it seems sensible to make use of that data.
The alternative to pulling the data from the device is to provide a mechanism
for specifying the APN policy for a particular fleet. (At least in theory the
APN selection policy can vary from one fleet to the next.) I assume this would
be implemented as a custom provisioning plugin that either hard-codes the policy
for the fleet, or provides a configuration mechanism that is flexible enough to
accommodate the needs of most fleets (probably using a provider -> APN mapping,
assuming we can guess the provider e.g. using the mobile-broadband-provider-info
database).
I'm getting lost, why is the default mobile-broadband-provider-info
plugin not good enough? And why don't you simply create your own
database based on the providers you are targeting? To me it seems like
you need X entries for all X providers you have. Unless the settings
vary within a given provider somehow?
Regards,
-Denis
10:45 p.m.
Hi Denis,
>>> If the device has retained parameters for a previously
defined IP
>>> context, is is probed via AT+CGDCONT?.
>>
>> this is really not a good idea. The AT+CGDCONT? settings are on a per
>> device basis. That is not how oFono actually works. It operates on a per
>> SIM card basis. And since you do not know to what SIM card these
>> previous settings apply to, the only sensible thing to do is to ignore
>> them.
>
> Okay, I was not aware of this. But surely the common case (i.e. the only one
> I've personally seen) is to have a single SIM card per device, and under those
> limited circumstances it is safe to assume that the settings are valid for that
> SIM. Would it be reasonable to implement such a fallback for this more limited
> case?
>
I admit your approach did make me chuckle for being so unorthodox :)
However, I think your perception is slightly wrong, there are people who
switch sim cards like crazy (e.g. frequent travelers) so this form of
provisioning is not really a good idea in those cases.
even if you switch your SIM card only once, it is a bad idea to start
out with a wrong context. Some operators do not include actually domain
names and a flatrate in one could mean pay as you go in another and
drain your bank account. Most operators should have their backends for
different billings fixed, but you never know. It is really the only
sensible way to bind the APN settings to your SIM card.
Why the SIM card does not come with the APN settings stored is another
story. You need to blame the operators for that.
>> You do know that oFono does keep its settings per SIM card
persistent.
>> So no matter what device you enter that SIM card into, the settings will
>> be available the next time you try to connect. So it is a one time
>> configuration option.
>
> Yes, I do know this. But it's just not a great fit for our use case.
>
> We're using ConnMan and oFono to manage networking for computing appliances
> (e.g. interactive kiosks and digital signs). These are typically deployed in
> fleets of anywhere from 10 to 10,000 units. Clearly we do not want to manually
> configure an APN for each machine. ;)
>
> Ideally, we try to use a single configuration for the entire fleet to keep the
> fleet easy to manage. But for a variety of business and technical reasons,
> multiple service providers may be used within a given fleet. So we can't
simply
> provision a single APN for the entire fleet. What we really want is to be able
> to plug a modem into the machine and it will Just Work.
>
> So we'd like to choose the right APN based solely on information from the
modem.
> I've observed that modems tend to arrive with an IP context pre-configured
> (including the correct APN). I assume the service provider sets this as part of
> some internal provisioning process. Perhaps it is not safe to assume that this
> will be the case with the majority of devices and/or providers. On the other
> hand, if it is, it seems sensible to make use of that data.
>
> The alternative to pulling the data from the device is to provide a mechanism
> for specifying the APN policy for a particular fleet. (At least in theory the
> APN selection policy can vary from one fleet to the next.) I assume this would
> be implemented as a custom provisioning plugin that either hard-codes the policy
> for the fleet, or provides a configuration mechanism that is flexible enough to
> accommodate the needs of most fleets (probably using a provider -> APN mapping,
> assuming we can guess the provider e.g. using the mobile-broadband-provider-info
> database).
I'm getting lost, why is the default mobile-broadband-provider-info
plugin not good enough? And why don't you simply create your own
database based on the providers you are targeting? To me it seems like
you need X entries for all X providers you have. Unless the settings
vary within a given provider somehow?
The default mobile-broadband-provider-info database has too many
duplicate choices and in that case oFono can not auto-provision your SIM
card, but a specific smaller version of that database just target to
your fleet would make oFono auto-provision the settings and you get
exactly what you wanted in the first place. No extra code to be written.
It is really a database problem that oFono backs out with the
auto-provision in most cases. That database is just overloaded. And in
case of oFono provision you also get the SPN information of your
provider if they provided it. I would trust the combination of MCC, MNC
and SPN more than anything stored via AT+CGDCONT.
In addition you can write your own provisioning plugin in case you do
not like the XML format from mobile-broadband-provider-info.
Regards
Marcel
2:37 a.m.
Hi,
On Thu, Dec 06, 2012 at 12:45:29PM +0100, Marcel Holtmann wrote:
> >>> If the device has retained parameters for a
previously defined IP
> >>> context, is is probed via AT+CGDCONT?.
> >>
> >> this is really not a good idea. The AT+CGDCONT? settings are on a per
> >> device basis. That is not how oFono actually works. It operates on a per
> >> SIM card basis. And since you do not know to what SIM card these
> >> previous settings apply to, the only sensible thing to do is to ignore
> >> them.
> >
> > Okay, I was not aware of this. But surely the common case (i.e. the only one
> > I've personally seen) is to have a single SIM card per device, and under
those
> > limited circumstances it is safe to assume that the settings are valid for
that
> > SIM. Would it be reasonable to implement such a fallback for this more
limited
> > case?
> >
>
> I admit your approach did make me chuckle for being so unorthodox :)
> However, I think your perception is slightly wrong, there are people who
> switch sim cards like crazy (e.g. frequent travelers) so this form of
> provisioning is not really a good idea in those cases.
even if you switch your SIM card only once, it is a bad idea to start
out with a wrong context. Some operators do not include actually domain
names and a flatrate in one could mean pay as you go in another and
drain your bank account. Most operators should have their backends for
different billings fixed, but you never know. It is really the only
sensible way to bind the APN settings to your SIM card.
Why the SIM card does not come with the APN settings stored is another
story. You need to blame the operators for that.
Fair enough. I suppose all this SIM card switching is more common outside of
the US.
> > The alternative to pulling the data from the device is to
provide a mechanism
> > for specifying the APN policy for a particular fleet. (At least in theory the
> > APN selection policy can vary from one fleet to the next.) I assume this
would
> > be implemented as a custom provisioning plugin that either hard-codes the
policy
> > for the fleet, or provides a configuration mechanism that is flexible enough
to
> > accommodate the needs of most fleets (probably using a provider -> APN
mapping,
> > assuming we can guess the provider e.g. using the
mobile-broadband-provider-info
> > database).
>
> I'm getting lost, why is the default mobile-broadband-provider-info
> plugin not good enough? And why don't you simply create your own
> database based on the providers you are targeting? To me it seems like
> you need X entries for all X providers you have. Unless the settings
> vary within a given provider somehow?
The default mobile-broadband-provider-info database has too many
duplicate choices and in that case oFono can not auto-provision your SIM
card, but a specific smaller version of that database just target to
your fleet would make oFono auto-provision the settings and you get
exactly what you wanted in the first place. No extra code to be written.
I think this approach makes sense (provided we never need to use different APNs
for the same provider within a given fleet).
It is really a database problem that oFono backs out with the
auto-provision in most cases. That database is just overloaded. And in
case of oFono provision you also get the SPN information of your
provider if they provided it. I would trust the combination of MCC, MNC
and SPN more than anything stored via AT+CGDCONT.
In addition you can write your own provisioning plugin in case you do
not like the XML format from mobile-broadband-provider-info.
If we do end up needing this, it will be so we can make the APN selection policy
dynamically configurable at runtime via an API (i.e. instead of via a
configuration file). But hopefully we won't need that. ;)
Thanks for your help.
Regards,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com
3573
days inactive
3574
days old
5 comments
3 participants
participants (3)
-
Denis Kenzior -
Forest Bond -
Marcel Holtmann