All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH] Fix gprs provisioning for some SIM (non-USIM) cards
Date: Wed, 16 Oct 2013 17:35:53 -0500	[thread overview]
Message-ID: <525F14C9.3020709@gmail.com> (raw)
In-Reply-To: <CACM4vuAAmckEbnFWe_S47fsbmJ0iDsvhkvovkVyZZT066KS41A@mail.gmail.com>

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

Hi Alfonso,

 >> The MNC can only be one value and that value can even change 
depending on whether you're
>> operating the same SIM in a 2G device or 3G device. So trying length 3 when in reality it is 2
>> can and most likely will get you into trouble.
>
> I do not think this can happen. For a given MCC, the length of the MNC
> is always the same, or at least that is the recommendation of the ITU.
>

The MNC in the IMSI remains the same, but the network operator MNC can 
change.  For example, T-Mobile used to report its 2G network MCC/MNC as 
310 26 even though its MNC is 260.  Then there are countries that run 
mixed 2 and 3 length MNCs...

Regardless, my main point here is that without properly coded EFad data 
we cannot reliably tell what MNC length to use.

>> I might be convinced to default to MNC length 2 in that case
>>
>
>   I do not think this is a good idea. Taking a look the ITU database,
> countries like USA, Canada, or Colombia have MNC length == 3.
>

I said I might be convinced.  If the phase is set and the EFad length is 
3.  The SIMs from NA operators tend to omit EFad completely or populate 
it properly.  Still, the safest approach is that we should not report 
the MNC if the SIM doesn't tell us explicitly.

> As the relationship between MCC and MNC is deterministic, when we know
> the MCC we can directly find out the MNC length. I agree in that
> trying first length 2, then 3 is not very elegant. But if we do not do
> that I see two possible solutions:

It really isn't that clear cut.  For example, check out MCC 405.

>
> 1.- Store a table statically or in a file with the correspondence
> between MCC and MNC length. I foresee maintenance problems with this
> approach.
>
> 2.- Add a function in the provision driver so we can ask for the MNC
> length for a given MCC, which would be invoked when MNC length is not
> found in EFad. The implementation would search in the provisioning DB:
> it could return the length of the first MNC found for that MCC (it
> must be the same for all networks for that MCC).
>
> Opinions on this?

I think you're trying to solve a problem that doesn't need to be solved. 
  Its 2013, I've not seen 2G sims available for ages now.  3G sims 
mandate EFad data to be properly populated.  I really fail to see the 
point, especially breaking the core to do so.

Fallback to manual user provisioning and give the user a list to choose 
from.

Regards,
-Denis


  reply	other threads:[~2013-10-16 22:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16 10:55 [PATCH] Fix gprs provisioning for some SIM (non-USIM) cards Alfonso Sanchez-Beato
2013-10-16 11:19 ` Jonas Bonn
2013-10-16 15:57   ` Denis Kenzior
2013-10-16 17:50     ` Alfonso Sanchez-Beato
2013-10-16 22:35       ` Denis Kenzior [this message]
2013-10-17 16:20         ` Alfonso Sanchez-Beato
2013-10-17 19:52           ` Denis Kenzior
2013-10-23 10:20             ` Alfonso Sanchez-Beato
2013-10-24  0:48               ` Denis Kenzior
2013-10-16 15:37 ` Denis Kenzior

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=525F14C9.3020709@gmail.com \
    --to=denkenz@gmail.com \
    --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.