[PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Nicola Lunghi]

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

if the mobile provider information database has multiple apn settings for the
same operator, ofono was throwing an error and creating a default internet
context with an empty apn.

This patch will instead allow the automatic creation of multiple context
allowing the user to pick one of the default via connman.

Connman supports multiple cellular context so no issue there.

Previously proposed by Martin Hundebøll here:
https://lists.ofono.org/hyperkitty/list/ofono(a)ofono.org/thread/2SC46PH5CWT3A3HTHGUKUUVI3QDYIL73/#7B6CPARJQMZUBQUPXBJMAOXZY4RW2L3D

And tested by Nicola Lunghi with connman 1.37

Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>
---
 plugins/provision.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/provision.c b/plugins/provision.c
index 99c299eb..aa0b05e4 100644
--- a/plugins/provision.c
+++ b/plugins/provision.c
@@ -50,7 +50,7 @@ static int provision_get_settings(const char *mcc, const char *mnc,
 
 	DBG("Provisioning for MCC %s, MNC %s, SPN '%s'", mcc, mnc, spn);
 
-	apns = mbpi_lookup_apn(mcc, mnc, FALSE, &error);
+	apns = mbpi_lookup_apn(mcc, mnc, TRUE, &error);
 	if (apns == NULL) {
 		if (error != NULL) {
 			ofono_error("%s", error->message);
-- 
2.20.1

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Denis Kenzior]

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

Hi Nicola,

On 3/2/20 10:31 AM, Nicola Lunghi wrote:
> if the mobile provider information database has multiple apn settings for the
> same operator, ofono was throwing an error and creating a default internet
> context with an empty apn.
> 
> This patch will instead allow the automatic creation of multiple context
> allowing the user to pick one of the default via connman.

I still maintain this is a horrible idea.  Yes it is a nice workaround 
if you don't have a proper provisioning database, but not something I'd 
use in production.

What I can do is allow this to be configurable via some config file or 
environment variable (and off by default).

> 
> Connman supports multiple cellular context so no issue there.
> 
> Previously proposed by Martin Hundebøll here:
> https://lists.ofono.org/hyperkitty/list/ofono(a)ofono.org/thread/2SC46PH5CWT3A3HTHGUKUUVI3QDYIL73/#7B6CPARJQMZUBQUPXBJMAOXZY4RW2L3D
> 
> And tested by Nicola Lunghi with connman 1.37
> 
> Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>

No SoB please.

> ---
>   plugins/provision.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Regards,
-Denis

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[nick83ola]

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

Hi Denis,
thanks for your response

Can you say why it is a terrible idea?
In this way I can select in connman (or via dbus) the right context
that I want to use
I can also create other context manually.
Maintaining a custom database is an hassle you don't know what
operator your user are using.
For example I have user that depending on the contract with the same
company they have different APNs.
Without this change ofono provision an empty context.
With this at least the user has a predefined list of APNs and can choose.
I think is better to have 3 profiles to choose from than having a broken one.

Also if you want your behaviour you can still provide a database with
one APN per operator and this will still work....

But if you're against it I can use for example a compile flag set to
disabled by default

Cheers
Nick

On Wed, 4 Mar 2020 at 16:26, Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Nicola,
>
> On 3/2/20 10:31 AM, Nicola Lunghi wrote:
> > if the mobile provider information database has multiple apn settings for the
> > same operator, ofono was throwing an error and creating a default internet
> > context with an empty apn.
> >
> > This patch will instead allow the automatic creation of multiple context
> > allowing the user to pick one of the default via connman.
>
> I still maintain this is a horrible idea.  Yes it is a nice workaround
> if you don't have a proper provisioning database, but not something I'd
> use in production.
>
> What I can do is allow this to be configurable via some config file or
> environment variable (and off by default).
>
> >
> > Connman supports multiple cellular context so no issue there.
> >
> > Previously proposed by Martin Hundebøll here:
> > https://lists.ofono.org/hyperkitty/list/ofono(a)ofono.org/thread/2SC46PH5CWT3A3HTHGUKUUVI3QDYIL73/#7B6CPARJQMZUBQUPXBJMAOXZY4RW2L3D
> >
> > And tested by Nicola Lunghi with connman 1.37
> >
> > Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>
>
> No SoB please.
>
> > ---
> >   plugins/provision.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Regards,
> -Denis

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Giacinto Cifelli]

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

Hi Nick,

On Wed, Mar 4, 2020 at 5:45 PM nick83ola <nick83ola@gmail.com> wrote:
>
> Hi Denis,
> thanks for your response
>
> Can you say why it is a terrible idea?
> In this way I can select in connman (or via dbus) the right context
> that I want to use
> I can also create other context manually.
> Maintaining a custom database is an hassle you don't know what
> operator your user are using.
> For example I have user that depending on the contract with the same
> company they have different APNs.
> Without this change ofono provision an empty context.
> With this at least the user has a predefined list of APNs and can choose.
> I think is better to have 3 profiles to choose from than having a broken one.

one question about the reasoning above: how do you pick the "right"
context if your application is not maintaining the database?
You cycle through all of them until one works?

thank you,
Giacinto

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Denis Kenzior]

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

Hi Nicola,

No top posting please.

On 3/4/20 11:00 AM, nick83ola wrote:
> Hi Giacinto,
> We have a web application that is talking to connman and ofono over dbus.
> We present the user with the list and once is connected to a profile
> connman remembers
> it so if I connect again the same modem connman will remember it as a
> favourite and automatically connect.
> or at least is what I'm thinking of doing.

If you're making the user choose, why not follow the advice I have 
already given Martin and others?  Just provision the context once 
if/when automatic provisioning fails.  This is how connman/ofono were 
designed to be used.  Any workarounds you introduce will just make your 
life harder.

> 
> To automatically connect without the user I was thinking of
> implementing what you said:
> - retrieve "cellular" services from connman
> - check if there are favourite services
> - if there are not try one context one after the another
> 

So method of elimination.  Doesn't sound elegant ;)

> The main issue is that connman is not exposing the APN and data over
> dbus and is not easy to identify also the context
> which a service is referring to... the other indication is the name
> So if I create something in ofono I don't know how connman will call it.... :-(
> 

ConnMan was explicitly designed not to expose such details.

Regards,
-Denis

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[nick83ola]

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

Hi Giacinto,
We have a web application that is talking to connman and ofono over dbus.
We present the user with the list and once is connected to a profile
connman remembers
it so if I connect again the same modem connman will remember it as a
favourite and automatically connect.
or at least is what I'm thinking of doing.

To automatically connect without the user I was thinking of
implementing what you said:
- retrieve "cellular" services from connman
- check if there are favourite services
- if there are not try one context one after the another

The main issue is that connman is not exposing the APN and data over
dbus and is not easy to identify also the context
which a service is referring to... the other indication is the name
So if I create something in ofono I don't know how connman will call it.... :-(

Thanks
Nick

On Wed, 4 Mar 2020 at 16:55, Giacinto Cifelli <gciofono@gmail.com> wrote:
>
> Hi Nick,
>
> On Wed, Mar 4, 2020 at 5:45 PM nick83ola <nick83ola@gmail.com> wrote:
> >
> > Hi Denis,
> > thanks for your response
> >
> > Can you say why it is a terrible idea?
> > In this way I can select in connman (or via dbus) the right context
> > that I want to use
> > I can also create other context manually.
> > Maintaining a custom database is an hassle you don't know what
> > operator your user are using.
> > For example I have user that depending on the contract with the same
> > company they have different APNs.
> > Without this change ofono provision an empty context.
> > With this at least the user has a predefined list of APNs and can choose.
> > I think is better to have 3 profiles to choose from than having a broken one.
>
> one question about the reasoning above: how do you pick the "right"
> context if your application is not maintaining the database?
> You cycle through all of them until one works?
>
> thank you,
> Giacinto

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[nick83ola]

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

Hi Dennis,

On Wed, 4 Mar 2020 at 17:11, Denis Kenzior <denkenz@gmail.com> wrote:

> Hi Nicola,
>
> No top posting please.
>
Ok sorry


> On 3/4/20 11:00 AM, nick83ola wrote:
> > Hi Giacinto,
> > We have a web application that is talking to connman and ofono over dbus.
> > We present the user with the list and once is connected to a profile
> > connman remembers
> > it so if I connect again the same modem connman will remember it as a
> > favourite and automatically connect.
> > or at least is what I'm thinking of doing.
>
> If you're making the user choose, why not follow the advice I have
> already given Martin and others?  Just provision the context once
> if/when automatic provisioning fails.  This is how connman/ofono were
> designed to be used.  Any workarounds you introduce will just make your
> life harder.
>
In my case automatic provisioning always fails:
- the database has multiple entries for basically every operator/country
- also Ofono doesn;t expose a Dbus API to query the database
- so the current plugin is useless: it always provision the wrong settings

If I want to do it externally I have to reimplement the whole "quering
thedatabase logic", delete
all the automatic provisioned profile and setup custom ones.
So the provision plugin is basically useless.

> To automatically connect without the user I was thinking of

> > implementing what you said:
> > - retrieve "cellular" services from connman
> > - check if there are favourite services
> > - if there are not try one context one after the another
> >
> So method of elimination.  Doesn't sound elegant ;)
>

What is the more "elegant" solution in your opinion?


> > The main issue is that connman is not exposing the APN and data over
> > dbus and is not easy to identify also the context
> > which a service is referring to... the other indication is the name
> > So if I create something in ofono I don't know how connman will call
> it.... :-(
> >
>
> ConnMan was explicitly designed not to expose such details
>

mmm Those are details that are exposed in every connection manager that I
know of... see Android network settings for example
(maybe there's a reason??)


> Regards,
> -Denis
>

Regards
- Nicola

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

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Denis Kenzior]

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

Hi,

> In my case automatic provisioning always fails:
> - the database has multiple entries for basically every operator/country

mbpi is just not a very good database.  It provides lots of duplicates 
and doesn't distinguish by spn last I checked.  Ubuntu Touch folks used 
the android apndb and others used custom ones.  As far as I'm aware, 
ofono + mbpi was never used in production.  If I'm wrong, I'd love to 
hear about it.

I have discouraged the use of mbpi for these reasons.  Not stopping you 
from using it, just pointing out what has been done historically.

> - also Ofono doesn;t expose a Dbus API to query the database

There was never a reason to...

> - so the current plugin is useless: it always provision the wrong settings

Pretty much, yes.

> 
> If I want to do it externally I have to reimplement the whole "quering 
> thedatabase logic", delete
> all the automatic provisioned profile and setup custom ones.

The null profile created when automatic provisioning fails is by design. 
  It serves as a hint to ConnMan & settings service that manual 
provisioning is required.  So the current behavior is how oFono + 
ConnMan were designed to interoperate.  You can certainly try and change 
the design, I'm just pointing out that this might not be the path of 
least resistance.

> What is the more "elegant" solution in your opinion?

Not sure, ideally there should be a way to avoid something like this. 
Also some providers allow a context to be activated, but no traffic can 
pass, so this might not be a foolproof solution anyway.

> mmm Those are details that are exposed in every connection manager that 
> I know of... see Android network settings for example
> (maybe there's a reason??)

That is something you can take up with ConnMan guys.

Regards,
-Denis

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Tarmo Kuuse]

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

Hi Denis,

On 04.03.20 20:49, Denis Kenzior wrote:
>> In my case automatic provisioning always fails:
>> - the database has multiple entries for basically every operator/country
> 
> mbpi is just not a very good database.  It provides lots of duplicates 
> and doesn't distinguish by spn last I checked.  Ubuntu Touch folks used 
> the android apndb and others used custom ones.  As far as I'm aware, 
> ofono + mbpi was never used in production.  If I'm wrong, I'd love to 
> hear about it.
> 
> I have discouraged the use of mbpi for these reasons.  Not stopping you 
> from using it, just pointing out what has been done historically.

As I understand it, ofono is designed to automatically pick the correct 
service provider parameters (primarily APN) for the installed SIM - 
unlike a simple solution like pppd. When arriving to the connman/ofono 
community I found it very difficult getting my widget online when ofono 
refuses to use the ready-to-use mbpi database and authoritative response 
is "mbpi is bad, don't used it".

I don't see how am I going to solve this. The end user cannot configure 
the device (there's no user interaction whatsoever). I could not find 
the mythical Android database at the time (I do now - it's at 
https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml). 
It contains many duplicates, because the virtual MNO-s share MCC and 
MNC-s with the physical ones. That's how the mobile networks are built 
in the real world. So I was very confused about how to proceed.

Sure, after much, much frustration I arrived to the workaround of 
manually provisioning APNs (which I stole from mbpi!) for each factory 
installed SIM through Christophe Ronco's file-provision plugin. This 
plugin is a life-saver, but it certainly falls short of automatic 
provisioning. That's the same level of sophistication as pppd. And as 
extra punishment I have to write a network supervisor which orders 
connman to actually use the service of a new SIM whenever it is replaced 
- even if it's from the same MNO. But that's a different rant altogether.

So, for perspective - saying "mbpi is just not a very good database" 
helps me none at all when I need to get my widget to go online :) Please 
handle the duplication, as this is how the mobile networks are built.

-- 
Kind regards,
Tarmo

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Denis Kenzior]

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

Hi Tarmo,

> I don't see how am I going to solve this. The end user cannot configure 
> the device (there's no user interaction whatsoever). I could not find 
> the mythical Android database at the time (I do now - it's at 
> https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml). 
> It contains many duplicates, because the virtual MNO-s share MCC and 
> MNC-s with the physical ones. That's how the mobile networks are built 
> in the real world. So I was very confused about how to proceed.

MVNOs are handled by utilizing the EFspn file as a differentiator.  So 
even if MNC/MCC is the same, once you include the SPN, the number of 
duplicates goes down drastically.  This is why oFono uses the following 
signature for get_settings:

         int (*get_settings)(const char *mcc, const char *mnc, const 
char *spn,

Once a proper database is used, this mostly goes away as an issue.  We 
did add the SPN field to MBPI schema in the olden days.  The problem is 
that nobody actually updated the MBPI database to take advantage of this.

> 
> Sure, after much, much frustration I arrived to the workaround of 
> manually provisioning APNs (which I stole from mbpi!) for each factory 
> installed SIM through Christophe Ronco's file-provision plugin. This 
> plugin is a life-saver, but it certainly falls short of automatic 
> provisioning. That's the same level of sophistication as pppd. And as 
> extra punishment I have to write a network supervisor which orders 
> connman to actually use the service of a new SIM whenever it is replaced 
> - even if it's from the same MNO. But that's a different rant altogether.
> 
> So, for perspective - saying "mbpi is just not a very good database" 
> helps me none at all when I need to get my widget to go online :) Please 
> handle the duplication, as this is how the mobile networks are built.
> 

I can take a patch that enables duplicates as a config / environmental 
setting.  As long as the default is the old behavior.  But as I 
mentioned previously, ConnMan / oFono were not designed to work this 
way, and so far nobody has been willing to do the work in both projects 
to change that.

Regards,
-Denis

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Christophe Ronco]

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

Hi Tarmo,

On 3/12/20 2:22 PM, Tarmo Kuuse wrote:
> Hi Denis,
>
> On 04.03.20 20:49, Denis Kenzior wrote:
>>> In my case automatic provisioning always fails:
>>> - the database has multiple entries for basically every
>>> operator/country
>>
>> mbpi is just not a very good database.  It provides lots of
>> duplicates and doesn't distinguish by spn last I checked.  Ubuntu
>> Touch folks used the android apndb and others used custom ones.  As
>> far as I'm aware, ofono + mbpi was never used in production.  If I'm
>> wrong, I'd love to hear about it.
>>
>> I have discouraged the use of mbpi for these reasons.  Not stopping
>> you from using it, just pointing out what has been done historically.
>
> As I understand it, ofono is designed to automatically pick the
> correct service provider parameters (primarily APN) for the installed
> SIM - unlike a simple solution like pppd. When arriving to the
> connman/ofono community I found it very difficult getting my widget
> online when ofono refuses to use the ready-to-use mbpi database and
> authoritative response is "mbpi is bad, don't used it".
>
> I don't see how am I going to solve this. The end user cannot
> configure the device (there's no user interaction whatsoever). I could
> not find the mythical Android database at the time (I do now - it's at
> https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml).
> It contains many duplicates, because the virtual MNO-s share MCC and
> MNC-s with the physical ones. That's how the mobile networks are built
> in the real world. So I was very confused about how to proceed.
>
> Sure, after much, much frustration I arrived to the workaround of
> manually provisioning APNs (which I stole from mbpi!) for each factory
> installed SIM through Christophe Ronco's file-provision plugin. This
> plugin is a life-saver, but it certainly falls short of automatic
> provisioning. That's the same level of sophistication as pppd. And as
> extra punishment I have to write a network supervisor which orders
> connman to actually use the service of a new SIM whenever it is
> replaced - even if it's from the same MNO. But that's a different rant
> altogether.

Thanks! Happy to see this is used outside my company.

I assume we are in the same case, once our device is on field, there is
no end user to configure anything. So we need automatic choices or in
factory provisioning.

In my case, I wouldn't want multiple contexts to be created from mbpi
database. If I could choose today, I would totally remove mbpi database
from our product. Some of our clients have a private APN and I am always
afraid that they can connect with a public APN instead of using the
specific, secure, with QoS network they have negotiated with their
network operator.

I know it's a pain to configure APN (and it's a lot worth for support
team than for me) but saying "we will magically select an APN, don't
bother with that" seems dangerous to me.

About your problem with ConnMan and first connection with a new SIM, I
have a patch in ConnMan to handle that (and roaming SIM cards also if I
remember well). We can discuss that outside the list if it can help.


Christophe Ronco


>
> So, for perspective - saying "mbpi is just not a very good database"
> helps me none at all when I need to get my widget to go online :)
> Please handle the duplication, as this is how the mobile networks are
> built.
>

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Tarmo Kuuse]

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

Hi Cristophe,

On 12.03.20 17:51, Christophe Ronco wrote:
>>>> In my case automatic provisioning always fails:
>>>> - the database has multiple entries for basically every
>>>> operator/country
>>>
>>> mbpi is just not a very good database.  It provides lots of
>>> duplicates and doesn't distinguish by spn last I checked.  Ubuntu
>>> Touch folks used the android apndb and others used custom ones.  As
>>> far as I'm aware, ofono + mbpi was never used in production.  If I'm
>>> wrong, I'd love to hear about it.
>>>
>>> I have discouraged the use of mbpi for these reasons.  Not stopping
>>> you from using it, just pointing out what has been done historically.
>>
>> As I understand it, ofono is designed to automatically pick the
>> correct service provider parameters (primarily APN) for the installed
>> SIM - unlike a simple solution like pppd. When arriving to the
>> connman/ofono community I found it very difficult getting my widget
>> online when ofono refuses to use the ready-to-use mbpi database and
>> authoritative response is "mbpi is bad, don't used it".
>>
>> I don't see how am I going to solve this. The end user cannot
>> configure the device (there's no user interaction whatsoever). I could
>> not find the mythical Android database at the time (I do now - it's at
>> https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml).
>> It contains many duplicates, because the virtual MNO-s share MCC and
>> MNC-s with the physical ones. That's how the mobile networks are built
>> in the real world. So I was very confused about how to proceed.
>>
>> Sure, after much, much frustration I arrived to the workaround of
>> manually provisioning APNs (which I stole from mbpi!) for each factory
>> installed SIM through Christophe Ronco's file-provision plugin. This
>> plugin is a life-saver, but it certainly falls short of automatic
>> provisioning. That's the same level of sophistication as pppd. And as
>> extra punishment I have to write a network supervisor which orders
>> connman to actually use the service of a new SIM whenever it is
>> replaced - even if it's from the same MNO. But that's a different rant
>> altogether.
> 
> Thanks! Happy to see this is used outside my company.

It's very useful. Either I've misunderstood something, or it's the only 
usable method for manually provisioning SIMs in ofono.

> I assume we are in the same case, once our device is on field, there is
> no end user to configure anything. So we need automatic choices or in
> factory provisioning.
> 
> In my case, I wouldn't want multiple contexts to be created from mbpi
> database. If I could choose today, I would totally remove mbpi database
> from our product. Some of our clients have a private APN and I am always
> afraid that they can connect with a public APN instead of using the
> specific, secure, with QoS network they have negotiated with their
> network operator.
> 
> I know it's a pain to configure APN (and it's a lot worth for support
> team than for me) but saying "we will magically select an APN, don't
> bother with that" seems dangerous to me.

I agree, it's dangerous to automatically provision stuff in GSM networks.

However, if my options include:

a) support case for almost every customer in another country who needs 
to insert any unseen-by-me, commodity SIM (so I could ask them which SIM 
they inserted, determine the APN, update provisioning file; very 
politely ask customer to take the gadget to office, open waterproof 
enclosure, connect Ethernet; push the updated provisioning file, verify 
dialup; finally ask customer to close enclosure and take it to site).

b) support case only for customers with SIMs that require non-standard 
provisioning, private APNs and other corner cases.

... option b) would win. I _was_ the support team, among other things. 
Option a) was the only option for a few years because I used pppd for 
dialup. I had hoped to fix it with ofono and mbpi.

There are partial workarounds. Unrestricted roaming in EU means we could 
ship gadgets with our own SIMs instead of badgering customers. Apart 
from that it was often a struggle and a waste of time getting commodity 
SIMs in other countries to connect.

I guess the user should eventually be able to set the APN on their own, 
e.g. via Bluetooth. This takes non-trivial effort, though.

> About your problem with ConnMan and first connection with a new SIM, I
> have a patch in ConnMan to handle that (and roaming SIM cards also if I
> remember well). We can discuss that outside the list if it can help.

Thank you for the kind offer. I would otherwise accept it, but I've left 
the job. As a stopgap measure I had a script which poked ConnMan and 
ofono via dbus until they accepted a new SIM and connected.

--
Kind regards,
Tarmo

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Tarmo Kuuse]

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

Hi Denis,

On 12.03.20 16:49, Denis Kenzior wrote:
> Hi Tarmo,
> 
>> I don't see how am I going to solve this. The end user cannot 
>> configure the device (there's no user interaction whatsoever). I could 
>> not find the mythical Android database at the time (I do now - it's at 
>> https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml). 
>> It contains many duplicates, because the virtual MNO-s share MCC and 
>> MNC-s with the physical ones. That's how the mobile networks are built 
>> in the real world. So I was very confused about how to proceed.
> 
> MVNOs are handled by utilizing the EFspn file as a differentiator.  So 
> even if MNC/MCC is the same, once you include the SPN, the number of 
> duplicates goes down drastically.  This is why oFono uses the following 
> signature for get_settings:
> 
>          int (*get_settings)(const char *mcc, const char *mnc, const 
> char *spn,
> 
> Once a proper database is used, this mostly goes away as an issue.  We 
> did add the SPN field to MBPI schema in the olden days.  The problem is 
> that nobody actually updated the MBPI database to take advantage of this.

So if the SPN for every duplicate in mbpi was populated, ofono would 
start provisioning them? That's useful information. Where could one find 
the details of this schema documented?

>> Sure, after much, much frustration I arrived to the workaround of 
>> manually provisioning APNs (which I stole from mbpi!) for each factory 
>> installed SIM through Christophe Ronco's file-provision plugin. This 
>> plugin is a life-saver, but it certainly falls short of automatic 
>> provisioning. That's the same level of sophistication as pppd. And as 
>> extra punishment I have to write a network supervisor which orders 
>> connman to actually use the service of a new SIM whenever it is 
>> replaced - even if it's from the same MNO. But that's a different rant 
>> altogether.
>>
>> So, for perspective - saying "mbpi is just not a very good database" 
>> helps me none at all when I need to get my widget to go online :) 
>> Please handle the duplication, as this is how the mobile networks are 
>> built.
>>
> 
> I can take a patch that enables duplicates as a config / environmental 
> setting.  As long as the default is the old behavior.  But as I 
> mentioned previously, ConnMan / oFono were not designed to work this 
> way, and so far nobody has been willing to do the work in both projects 
> to change that.

I emphasize.

Stepping back, I suspect the task of maintaining a clean, accurate 
provisioning database of every SIM in the world is rather challenging. 
Perhaps more challenging, than re-designing ofono :)

I could pick up a few commodity SIMs from my country, determine the SPN 
and contribute updates somewhere. Heh, I don't even know which MVNOs 
here are dead and which are operational.

--
Kind regards,
Tarmo

Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi

[Denis Kenzior]

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

Hi Tarmo,

>> Once a proper database is used, this mostly goes away as an issue.  We 
>> did add the SPN field to MBPI schema in the olden days.  The problem 
>> is that nobody actually updated the MBPI database to take advantage of 
>> this.

Hmm, maybe my memory is faulty (it has been ~9 years now), but I do not 
see anything in the mbpi DTD file for the SPN.  The oFono change was 
done in 2011 in ef37b3fe4244d823a5dde1a311c0d466ad2e7172.  And we did 
have someone working on extending mbpi, but it seems SPN changes never 
made it.  I no longer recall what happened, exactly.

> 
> So if the SPN for every duplicate in mbpi was populated, ofono would 
> start provisioning them? That's useful information. Where could one find 
> the details of this schema documented?

It is much more likely to, yes.  The number of duplicates goes down 
tremendously, particularly if the db is reasonably up to date.  There 
may be a few extra bits we can also differentiate on as well, and extend 
the provisioning API for these.

See above about the schema.  Maybe someone wants to pick up this work 
again...

> 
>>> Sure, after much, much frustration I arrived to the workaround of 
>>> manually provisioning APNs (which I stole from mbpi!) for each 
>>> factory installed SIM through Christophe Ronco's file-provision 
>>> plugin. This plugin is a life-saver, but it certainly falls short of 
>>> automatic provisioning. That's the same level of sophistication as 
>>> pppd. And as extra punishment I have to write a network supervisor 
>>> which orders connman to actually use the service of a new SIM 
>>> whenever it is replaced - even if it's from the same MNO. But that's 
>>> a different rant altogether.
>>>
>>> So, for perspective - saying "mbpi is just not a very good database" 
>>> helps me none at all when I need to get my widget to go online :) 
>>> Please handle the duplication, as this is how the mobile networks are 
>>> built.
>>>
>>
>> I can take a patch that enables duplicates as a config / environmental 
>> setting.  As long as the default is the old behavior.  But as I 
>> mentioned previously, ConnMan / oFono were not designed to work this 
>> way, and so far nobody has been willing to do the work in both 
>> projects to change that.
> 
> I emphasize.
> 
> Stepping back, I suspect the task of maintaining a clean, accurate 
> provisioning database of every SIM in the world is rather challenging. 
> Perhaps more challenging, than re-designing ofono :)

Quite possible.  But I would still question whether trying APNs at 
semi-random is a good strategy.

> 
> I could pick up a few commodity SIMs from my country, determine the SPN 
> and contribute updates somewhere. Heh, I don't even know which MVNOs 
> here are dead and which are operational.

Exactly.  In the Meego days Nokia had their own APN database.  And it 
was considered crown jewels / company secret ;)  Understandable, 
considering how much work probably went into keeping it up to date.

Regards,
-Denis