Hi Denis,

On 04/06/2015 21:52, Denis Kenzior wrote:

Hi Alex,

On 06/03/2015 07:07 AM, Alex J Lennon wrote:

Hi,

A request for some advice.

We're having trouble provisioning APNs for SIMs from certain Telcos, and
it seems to be because of the ordering of providers in serviceproviders.xml

Ordering should have nothing to do with it.

Yes, the ordering is relevant. We (like other ofono users I suspect) have to allow multiple APNs or the automatic provisioning process fails.

Then, the first context found in serviceproviders.xml is what is used by default for the connection.

An example of the problem is that if you use a major telco's SIM card in the UK - Vodafone, ofono will then default to using an ASDA mobile context because of the ordering, and this will fail.

My feeling is that a larger provider like Vodafone or O2 should be the default, not ASDA mobile or GiffGaff, and this should thus come first (understanding that the Ofono project does not control this document)

Vodafone and O2 are cases in point. SIMs from either of those two
telcos, used in the UK, will fail to default to the standard APNs upon
provisioning.

In the case of Vodafone it is because an ASDA Mobile provider is present
before the Vodafone provider and both have the same MNC.

It's similar with O2, excepting that in this case there's a Giffgaff
provider before the O2 provider which thus is used for the APN.

oFono's provisioning logic is very conservative. We do not allow duplicate contexts. Thus if the database contains multiple matches for a MCC/MNC pair, the provisioning will fail. The way to to deal with this is to extend the database with additional identifying information. E.g. SPN. I believe we added the SPN field to Mobile-Broadband-Provider-Info XML DTD. But I haven't been paying much attention whether the database has been properly populated with this field since then.

Allowing Duplicates - Not by default no, but you have a boolean parameter in there and logic to allow for duplicate contexts, which we have to enable (as do others I think from my Googling on this) or the provisioning support is unusable with the upstream serviceproviders.xml as far as I can see.

I'm not entirely sure how the RilModem fork relates to Ofono but you can see they had the same problem

/*
	* TODO: review with upstream. Default behavior was to
	* disallow duplicate APN entries, which unfortunately exist
	* in the mobile-broadband-provider-info db.
	*/

ref: https://github.com/rilmodem/ofono/blob/master/plugins/provision.c#L55

SPN - Thanks. This seems promising. I will investigate the SPN values further.

I suspect our use case is similar to many others. We have a headless
embedded Linux board and we want an installation technician to be able
to put a SIM in, power the unit, and have everything else automated.

It looks like we may have to implement a custom serviceproviders.xml,
which would be a shame.

I am wondering if there are any other algorithmic or configuration
alternatives we can look at, such as Ofono trying different contexts
until one works? Or some additional Ofono provisioning configuration?

oFono can use any information present on the SIM to try and figure out the SIM provider. We already provide MCC, MNC and SPN to the provisioning plugin.

However, this really depends on the underlying provisioning database to contain this information and do so in such a way that duplicates are not possible.

I'll have a think about what might be achievable by adding SPN information into serviceproviders.xml.

Thanks again,

Alex