Hi Alex,

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

It has been years since I wrote the provisioning plugin, but the intent 
was to fail if looking up MCC/MNC combo resulted in multiple matches. 
So this may be a bug, or you might be using some custom behavior.  But 
in the end, ordering of the entries should not affect the provisioning 
logic.

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

Then that's the problem.  The intent was never to allow duplicates. 
That boolean was added for tools/lookup-apn only.

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

The real fix is to fix mobile-broadband-provider-info.

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

Regards,
-Denis