All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
To: ofono@ofono.org
Subject: Re: Problems provisioning APN from SIMs
Date: Fri, 05 Jun 2015 00:05:33 +0200	[thread overview]
Message-ID: <5570CBAD.4050406@dynamicdevices.co.uk> (raw)
In-Reply-To: <5570CA31.6070002@dynamicdevices.co.uk>

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



On 04/06/2015 23:59, Alex J Lennon wrote:
>
> On 04/06/2015 23:03, Denis Kenzior wrote:
>> 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.
> Yes I would agree with that.
>
> As I come to investigate this, I find I am concerned about using the
> Service Provider Name as I can't see any registry for those names, it's
> free text for display purposes, so I assume it is at least possible it
> might change without warning,
> whereas there does seem to be a registry for MCC/MNC (e.g.
> http://www.mcc-mnc.com/)
>
> I am thinking it may be preferable to use the registered IIN number from
> the ICCID - http://www.controlf.net/iccid/
>
> This seems a more controlled way of providing the uniqueness needed to
> me and presumably it's easy enough to read the ICCID out, if it's not
> already being read out.

No that's not going to work. I see ICCID prefix is the same for e.g. O2
and Tesco Mobile, being MCC and MNC

UK

	

O2

	

894411

	

23410

	

UK

	

Tesco Mobile
<http://autopuk.grg.com/>(MVNO <http://en.wikipedia.org/wiki/MVNO> of O2)

	

894411

	

23410


Regards,

Alex


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

  reply	other threads:[~2015-06-04 22:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-03 12:07 Problems provisioning APN from SIMs Alex J Lennon
2015-06-04 19:52 ` Denis Kenzior
2015-06-04 20:23   ` Alex J Lennon
2015-06-04 21:03     ` Denis Kenzior
2015-06-04 21:59       ` Alex J Lennon
2015-06-04 22:05         ` Alex J Lennon [this message]
2015-06-04 22:16         ` Denis Kenzior
2015-06-04 22:30         ` Marcel Holtmann
2015-06-04 22:50         ` Marcel Holtmann
2015-06-04 23:48           ` Denis Kenzior
2015-06-05  8:29             ` Alex J Lennon
2015-06-12 13:09               ` Alex J Lennon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5570CBAD.4050406@dynamicdevices.co.uk \
    --to=ajlennon@dynamicdevices.co.uk \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.