* [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi @ 2020-03-02 16:31 Nicola Lunghi 2020-03-04 16:10 ` Denis Kenzior 0 siblings, 1 reply; 14+ messages in thread From: Nicola Lunghi @ 2020-03-02 16:31 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-02 16:31 [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi Nicola Lunghi @ 2020-03-04 16:10 ` Denis Kenzior 2020-03-04 16:45 ` nick83ola 0 siblings, 1 reply; 14+ messages in thread From: Denis Kenzior @ 2020-03-04 16:10 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 16:10 ` Denis Kenzior @ 2020-03-04 16:45 ` nick83ola 2020-03-04 16:54 ` Giacinto Cifelli 0 siblings, 1 reply; 14+ messages in thread From: nick83ola @ 2020-03-04 16:45 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 16:45 ` nick83ola @ 2020-03-04 16:54 ` Giacinto Cifelli 2020-03-04 17:00 ` nick83ola 0 siblings, 1 reply; 14+ messages in thread From: Giacinto Cifelli @ 2020-03-04 16:54 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 16:54 ` Giacinto Cifelli @ 2020-03-04 17:00 ` nick83ola 2020-03-04 16:56 ` Denis Kenzior 0 siblings, 1 reply; 14+ messages in thread From: nick83ola @ 2020-03-04 17:00 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 17:00 ` nick83ola @ 2020-03-04 16:56 ` Denis Kenzior 2020-03-04 17:51 ` nick83ola 0 siblings, 1 reply; 14+ messages in thread From: Denis Kenzior @ 2020-03-04 16:56 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 16:56 ` Denis Kenzior @ 2020-03-04 17:51 ` nick83ola 2020-03-04 18:49 ` Denis Kenzior 0 siblings, 1 reply; 14+ messages in thread From: nick83ola @ 2020-03-04 17:51 UTC (permalink / raw) To: ofono [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 17:51 ` nick83ola @ 2020-03-04 18:49 ` Denis Kenzior 2020-03-12 13:22 ` Tarmo Kuuse 0 siblings, 1 reply; 14+ messages in thread From: Denis Kenzior @ 2020-03-04 18:49 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-04 18:49 ` Denis Kenzior @ 2020-03-12 13:22 ` Tarmo Kuuse 2020-03-12 14:49 ` Denis Kenzior 2020-03-12 15:51 ` Christophe Ronco 0 siblings, 2 replies; 14+ messages in thread From: Tarmo Kuuse @ 2020-03-12 13:22 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-12 13:22 ` Tarmo Kuuse @ 2020-03-12 14:49 ` Denis Kenzior 2020-03-12 19:36 ` Tarmo Kuuse 2020-03-12 15:51 ` Christophe Ronco 1 sibling, 1 reply; 14+ messages in thread From: Denis Kenzior @ 2020-03-12 14:49 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-12 14:49 ` Denis Kenzior @ 2020-03-12 19:36 ` Tarmo Kuuse 2020-03-12 20:06 ` Denis Kenzior 0 siblings, 1 reply; 14+ messages in thread From: Tarmo Kuuse @ 2020-03-12 19:36 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-12 19:36 ` Tarmo Kuuse @ 2020-03-12 20:06 ` Denis Kenzior 0 siblings, 0 replies; 14+ messages in thread From: Denis Kenzior @ 2020-03-12 20:06 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-12 13:22 ` Tarmo Kuuse 2020-03-12 14:49 ` Denis Kenzior @ 2020-03-12 15:51 ` Christophe Ronco 2020-03-12 19:17 ` Tarmo Kuuse 1 sibling, 1 reply; 14+ messages in thread From: Christophe Ronco @ 2020-03-12 15:51 UTC (permalink / raw) To: ofono [-- 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. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi 2020-03-12 15:51 ` Christophe Ronco @ 2020-03-12 19:17 ` Tarmo Kuuse 0 siblings, 0 replies; 14+ messages in thread From: Tarmo Kuuse @ 2020-03-12 19:17 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-03-12 20:06 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-02 16:31 [PATCH] plugin: provision: create multiple contexts for multiple entries in mbpi Nicola Lunghi 2020-03-04 16:10 ` Denis Kenzior 2020-03-04 16:45 ` nick83ola 2020-03-04 16:54 ` Giacinto Cifelli 2020-03-04 17:00 ` nick83ola 2020-03-04 16:56 ` Denis Kenzior 2020-03-04 17:51 ` nick83ola 2020-03-04 18:49 ` Denis Kenzior 2020-03-12 13:22 ` Tarmo Kuuse 2020-03-12 14:49 ` Denis Kenzior 2020-03-12 19:36 ` Tarmo Kuuse 2020-03-12 20:06 ` Denis Kenzior 2020-03-12 15:51 ` Christophe Ronco 2020-03-12 19:17 ` Tarmo Kuuse
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.