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@ofono.org/thread/2SC46PH5CW... And tested by Nicola Lunghi with connman 1.37 Signed-off-by: Nicola Lunghi <nick83ola(a)gmail.com&gt;

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

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.

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.... :-(

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.

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

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??)

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-con...). 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.

> 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.

>>> 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-con...). > 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.