Re: [MM 0.6] Plumb up the SPN display-rule bits
Hi Dan, > > >> A possible fix to handle the case where we don't know how much > > >> we can > > >> > > >> read would be to try to read the first bytes of the record (3 or > > >> 4 or 5 > > >> just in case) to get the full record length of the record, > > >> assuming 1-3 > > >> bytes max for the size field, so we read "A3" + size encoded in > > >> 1 or 2 > > >> or 3 bytes + "80"); and once we know the whole record size, read > > >> the > > >> exact list size. > > >> > > >> > > >> Yeah, I thought about this, but had hoped to avoid it (If the record > > >> is present at all, there will be a minimum of 7 bytes - > > >> A3058003FF - so I think that's the right amount for an initial > > >> read). > > >> > > >> > > >> Here's a version that does the 7-then-more retry. It works on my SIM > > >> (retrying from 7 to 34 bytes, even though the entries are all FF); > > >> see what you think. > > >> > > > > > > That worked very well for me. > > > > > > Now that we have the 3 values we needed from the SIM card (2 flags + > > > SPDI list), we could now also implement the "RequiredNameDisplay" > > > property which contains the whole logic for us, as Dan suggested > > > earlier. Given that this value depends on the current 3GPP operator ID, > > > I would really include that new property in the 3GPP interface. Will try > > > to implement this later on today. > > > > > > > I pushed now a '06-api-display-rules' branch in upstream git; with the > > changes discussed here and a new "RequiredDisplayName" property. > > > > Dan, Nathan, are you guys happy with the new branch? I'm not very > > convinced yet about the flag property names... > > Need to check it out; but this is what Marcel is always talking about > when he says that "you really need to implement the SIM filesystem" > since I believe you can actually read the lengths of various EF records > out of the SIM using using some of the various commands, and thus you > know what length to request and you don't have to retry with other > lengths. That's not foolproof though, since some firmware > implementations are simply dumb. I ran into the length problem a few > times when trying to read the IMSI and the MNC length; same thing there > where some modems want one length and others want another, even though > it's exactly the same damn SIM just swapped between devices. many modems that have never been used in a real phone have broken SIM filesystem access. They are getting better, but some of them are still pretty bad. Try an Ericsson MBM if you want some of the better ones. You do need to read SIM filesystem information structures first. That is how you suppose to do the access. And not wildly guess. Otherwise you do not even know what type you have and how to read it. But for some of them you have fixed information struct and types of binary, record or cyclic. Also the access bits and what PIN needs to be entered first to access this data is nasty. If you really wanna know this complex crazy from 3GPP, then have a look at oFono and what we needed to do to make this work properly. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Mon, 2012-03-12 at 14:28 +0100, Aleksander Morgado wrote: > Hey, > > >> A possible fix to handle the case where we don't know how much > >> we can > >> > >> read would be to try to read the first bytes of the record (3 or > >> 4 or 5 > >> just in case) to get the full record length of the record, > >> assuming 1-3 > >> bytes max for the size field, so we read "A3" + size encoded in > >> 1 or 2 > >> or 3 bytes + "80"); and once we know the whole record size, read > >> the > >> exact list size. > >> > >> > >> Yeah, I thought about this, but had hoped to avoid it (If the record > >> is present at all, there will be a minimum of 7 bytes - > >> A3058003FF - so I think that's the right amount for an initial > >> read). > >> > >> > >> Here's a version that does the 7-then-more retry. It works on my SIM > >> (retrying from 7 to 34 bytes, even though the entries are all FF); > >> see what you think. > >> > > > > That worked very well for me. > > > > Now that we have the 3 values we needed from the SIM card (2 flags + > > SPDI list), we could now also implement the "RequiredNameDisplay" > > property which contains the whole logic for us, as Dan suggested > > earlier. Given that this value depends on the current 3GPP operator ID, > > I would really include that new property in the 3GPP interface. Will try > > to implement this later on today. > > > > I pushed now a '06-api-display-rules' branch in upstream git; with the > changes discussed here and a new "RequiredDisplayName" property. > > Dan, Nathan, are you guys happy with the new branch? I'm not very > convinced yet about the flag property names... Need to check it out; but this is what Marcel is always talking about when he says that "you really need to implement the SIM filesystem" since I believe you can actually read the lengths of various EF records out of the SIM using using some of the various commands, and thus you know what length to request and you don't have to retry with other lengths. That's not foolproof though, since some firmware implementations are simply dumb. I ran into the length problem a few times when trying to read the IMSI and the MNC length; same thing there where some modems want one length and others want another, even though it's exactly the same damn SIM just swapped between devices. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey, >> A possible fix to handle the case where we don't know how much >> we can >> >> read would be to try to read the first bytes of the record (3 or >> 4 or 5 >> just in case) to get the full record length of the record, >> assuming 1-3 >> bytes max for the size field, so we read "A3" + size encoded in >> 1 or 2 >> or 3 bytes + "80"); and once we know the whole record size, read the >> exact list size. >> >> >> Yeah, I thought about this, but had hoped to avoid it (If the record >> is present at all, there will be a minimum of 7 bytes - >> A3058003FF - so I think that's the right amount for an initial >> read). >> >> >> Here's a version that does the 7-then-more retry. It works on my SIM >> (retrying from 7 to 34 bytes, even though the entries are all FF); >> see what you think. >> > > That worked very well for me. > > Now that we have the 3 values we needed from the SIM card (2 flags + > SPDI list), we could now also implement the "RequiredNameDisplay" > property which contains the whole logic for us, as Dan suggested > earlier. Given that this value depends on the current 3GPP operator ID, > I would really include that new property in the 3GPP interface. Will try > to implement this later on today. > I pushed now a '06-api-display-rules' branch in upstream git; with the changes discussed here and a new "RequiredDisplayName" property. Dan, Nathan, are you guys happy with the new branch? I'm not very convinced yet about the flag property names... -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey Nathan,
On 03/01/2012 02:28 PM, Aleksander Morgado wrote:
>> -/* First byte is metadata; remainder is GSM-7 unpacked into octets;
>> convert to UTF8 */
>> > +/* Bits in the first byte specify rules for name display */
>> > +if (bin[0] == '\xFF' && bin[1] == '\xFF') {
>> > +/* If we got all-FF, don't enable display */
>> > +*display_reg_home = FALSE;
>> > +*display_op_roaming = FALSE;
>> > +} else {
>> > +*display_reg_home = ((bin[0] & 1) == 1);
>> > +*display_op_roaming = ((bin[0] & 2) == 2);
> You sure this is not the inverse? The documentation says that "b2=0"
> means "required" and "b1=0" means "not required".
>
>
I still think that reading the b2 bit should be fixed here; b2=0 means
to "require" to show the SPN while roaming in a network !home and !spdi; so:
*display_op_roaming = !(bin[0] & 2);
--
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
> A possible fix to handle the case where we don't know how much > we can > > read would be to try to read the first bytes of the record (3 or > 4 or 5 > just in case) to get the full record length of the record, > assuming 1-3 > bytes max for the size field, so we read "A3" + size encoded in > 1 or 2 > or 3 bytes + "80"); and once we know the whole record size, read the > exact list size. > > > Yeah, I thought about this, but had hoped to avoid it (If the record > is present at all, there will be a minimum of 7 bytes - > A3058003FF - so I think that's the right amount for an initial > read). > > > Here's a version that does the 7-then-more retry. It works on my SIM > (retrying from 7 to 34 bytes, even though the entries are all FF); > see what you think. > That worked very well for me. Now that we have the 3 values we needed from the SIM card (2 flags + SPDI list), we could now also implement the "RequiredNameDisplay" property which contains the whole logic for us, as Dan suggested earlier. Given that this value depends on the current 3GPP operator ID, I would really include that new property in the 3GPP interface. Will try to implement this later on today. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Fri, Mar 9, 2012 at 9:30 AM, Nathan Williams wrote: > On Fri, Mar 9, 2012 at 8:19 AM, Aleksander Morgado > wrote: > >> A possible fix to handle the case where we don't know how much we can > > read would be to try to read the first bytes of the record (3 or 4 or 5 >> just in case) to get the full record length of the record, assuming 1-3 >> bytes max for the size field, so we read "A3" + size encoded in 1 or 2 >> or 3 bytes + "80"); and once we know the whole record size, read the >> exact list size. >> > > Yeah, I thought about this, but had hoped to avoid it (If the record is > present at all, there will be a minimum of 7 bytes - A3058003FF - so I > think that's the right amount for an initial read). > > Here's a version that does the 7-then-more retry. It works on my SIM (retrying from 7 to 34 bytes, even though the entries are all FF); see what you think. - Nathan 0001-Fetch-parse-and-plumb-up-the-SPDI-information-from-t.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Fri, Mar 9, 2012 at 8:19 AM, Aleksander Morgado wrote: > Hey Nathan, > The command to get the SPDI in the code didn't work for me: > --> AT+CRSM=176,28621,0,0,255 > <-- +CRSM: 103,0 >OK > Ah, bummer. With that change on, the list is properly parsed: > $ mmcli -i 0 > SIM '/org/freedesktop/ModemManager1/SIM/0' > - > Properties | imsi : '214040106373910' > | id : '8934041110059281105' > | operator id : '21404' > |operator name : 'Yoigo' > | operator SPDI list : '21401,21407' > |show PLMN at home : no > | show op name roaming : no > > My operator is Yoigo (21404), and I get 2 operators in the SPDI list: > 21401 (Vodafone) and 21407 (Movistar). But, I'm not sure about the > flags, I believe I should have gotten a 'yes' in 'show PLMN at home', > will check that later. > > For a quick check, grep for the 28486 query - if 'show PLMN at home' is true, the first byte of the response will be 01; this is reporting that the first byte of the response is 00. > A possible fix to handle the case where we don't know how much we can > read would be to try to read the first bytes of the record (3 or 4 or 5 > just in case) to get the full record length of the record, assuming 1-3 > bytes max for the size field, so we read "A3" + size encoded in 1 or 2 > or 3 bytes + "80"); and once we know the whole record size, read the > exact list size. > Yeah, I thought about this, but had hoped to avoid it (If the record is present at all, there will be a minimum of 7 bytes - A3058003FF - so I think that's the right amount for an initial read). > Don't know, but that very first read may fail I guess, if an empty SPDI > list is found (not sure if that will be "A3028000" or "A300") and we try > to read more than that and the modem doesn't allow it. > > On some cards the SPDI just isn't present and the whole thing returns an error (the same can happen with the SPN). It's a tiny bit noisy in the logs, but the correct (empty) results show up in the properties. > And a side note; it seems that the SIM initialization sequence is not > properly run after getting SIM-PIN unlocked, will take care of that myself. > > OK, I'm glad this wasn't just me. I'll hold off on reporting my crashes until you hit this. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey Nathan, > Also, if we do expose these two properties we also need to load and > expose the SPDI network list, or the properties will be useless. > > > Here's a patch to do that. There's a bit of annoying fighting with gchar > ** and gdbus's idea of constness, but it seems reasonable otherwise. > It works for me on SIMs with no SPDI information at all and on those > with extant empty lists; I'd appreciate a test on a SIM known to have a > non-empty list. > The command to get the SPDI in the code didn't work for me: --> AT+CRSM=176,28621,0,0,255 <-- +CRSM: 103,0 OK I can get the SPDI list here (Cinterion modem) using a shorter length to read, even if it's not the exact one; so instead of 255 I can use 60, 40, 30, 15... If I modify that in the code: --> AT+CRSM=176,28621,0,0,15 <-- +CRSM: 144,0,A308800612F41012F470FF OK With that change on, the list is properly parsed: $ mmcli -i 0 SIM '/org/freedesktop/ModemManager1/SIM/0' - Properties | imsi : '214040106373910' | id : '8934041110059281105' | operator id : '21404' |operator name : 'Yoigo' | operator SPDI list : '21401,21407' |show PLMN at home : no | show op name roaming : no My operator is Yoigo (21404), and I get 2 operators in the SPDI list: 21401 (Vodafone) and 21407 (Movistar). But, I'm not sure about the flags, I believe I should have gotten a 'yes' in 'show PLMN at home', will check that later. A possible fix to handle the case where we don't know how much we can read would be to try to read the first bytes of the record (3 or 4 or 5 just in case) to get the full record length of the record, assuming 1-3 bytes max for the size field, so we read "A3" + size encoded in 1 or 2 or 3 bytes + "80"); and once we know the whole record size, read the exact list size. Don't know, but that very first read may fail I guess, if an empty SPDI list is found (not sure if that will be "A3028000" or "A300") and we try to read more than that and the modem doesn't allow it. --- And a side note; it seems that the SIM initialization sequence is not properly run after getting SIM-PIN unlocked, will take care of that myself. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On 03/09/2012 12:16 AM, Nathan Williams wrote: > There's a bit of annoying fighting with gchar ** and gdbus's idea of > constness, but it seems reasonable otherwise. Just modify load_spdi_finish() (and parse_spdi()) to return a gchar ** (without any const); and then explicitly cast to (const gchar *const *) or (gchar *const *) in mm_gdbus_sim_set_spdi(): gchar **val; val = MM_SIM_GET_CLASS (ctx->self)->load_spdi_finish (self, res, &error); mm_gdbus_sim_set_spdi (MM_GDBUS_SIM (self), (const gchar *const *)val); g_strfreev (val); That should do it. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
> > Also, if we do expose these two properties we also need to load and > expose the SPDI network list, or the properties will be useless. > > Here's a patch to do that. There's a bit of annoying fighting with gchar ** and gdbus's idea of constness, but it seems reasonable otherwise. It works for me on SIMs with no SPDI information at all and on those with extant empty lists; I'd appreciate a test on a SIM known to have a non-empty list. - Nathan 0001-Fetch-parse-and-plumb-up-the-SPDI-information-from-t.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey Dan & Nathan,
> If we did combine both bits into one property, then we'd get the
> following logic:
>
> enum {
> DISPLAY_UNRESTRICTED = 0,
> DISPLAY_REGISTERED = 1,
> DISPLAY_SPN = 2
> } DisplayName;
>
> display = DISPLAY_UNRESTRICTED
> if (registered network is well-known) {
>if (b1 == 1)
> display = DISPLAY_REGISTERED
> } else {
>if (b2 == 0)
> display = DISPLAY_SPN
> }
>
This logic gets aligned more or less with some piece of code I found
from Android sources:
/**
* Returns the SpnDisplayRule based on settings on the SIM and the
* specified plmn (currently-registered PLMN). See TS 22.101 AnnexA
* and TS 51.011 10.3.11 for details.
*
* If the SPN is not found on the SIM, the rule is always PLMN_ONLY.
*/
protected int getDisplayRule(String plmn) {
int rule;
if (spn == null || spnDisplayCondition == -1) {
// EF_SPN was not found on the SIM, or not yet loaded. Just show ONS.
rule = SPN_RULE_SHOW_PLMN;
} else if (isOnMatchingPlmn(plmn)) {
// (Checks if plmn is HPLMN or on the spdiNetworks list.)
rule = SPN_RULE_SHOW_SPN;
if ((spnDisplayCondition & 0x01) == 0x01)
// ONS required when registered to HPLMN or PLMN in EF_SPDI
rule |= SPN_RULE_SHOW_PLMN;
}
} else {
rule = SPN_RULE_SHOW_PLMN;
if ((spnDisplayCondition & 0x02) == 0x00) {
// SPN required if not registered to HPLMN or PLMN in EF_SPDI
rule |= SPN_RULE_SHOW_SPN;
}
}
return rule;
}
Regardless of the meaning of the SPDI Networks list, it's probably a
good approach to follow. Nathan, what do you think?
Also, if we do expose these two properties we also need to load and
expose the SPDI network list, or the properties will be useless.
--
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Thu, 2012-03-01 at 14:28 +0100, Aleksander Morgado wrote:
> Hey,
>
> > This is required for properly displaying
> > local-operator-vs-home-provider information, per 3GPP
> > (31.102 section 4.1.2 on EF_SPN and 22.101 Annex A).
> >
>
> For anyone else checking, that's section 4.2.11 in release 11 of the
> document.
>
> > Suggestions welcome on the long and somewhat unwieldy property/function
> > names.
> >
> > - Nathan
> >
> >
> > 0001-Retrieve-and-plumb-up-the-SIM-SPN-bits-that-set-oper.patch
> >
> >
> > From 96ce78202344bd928bf602874a087a0adb383cbe Mon Sep 17 00:00:00 2001
> > From: Nathan Williams
> > Date: Wed, 29 Feb 2012 16:25:03 -0500
> > Subject: [PATCH] Retrieve and plumb up the SIM SPN bits that set operator
> > name display rules.
> >
> > BUG=chromium-os:21522
> > TEST=Insert SIMs from various operators (T-Mobile, MaxROAM), run mmcli -i 0
> > Varying conditions include no SPN (AT&T), all-FF SPN data (3 Italy),
> > SPN with neither display bit set (3 UK), SPN with a display bit set
> > (MaxROAM)
> >
> > Change-Id: Id83da0e094efe52922dcc21f1420d3f5db5883e3
> > ---
> > cli/mmcli-sim.c| 14 --
> > .../org.freedesktop.ModemManager1.Sim.xml | 17 +++
> > libmm-glib/mm-sim.c| 30
> > libmm-glib/mm-sim.h|2 +
> > src/mm-sim.c | 49
> > ++-
> > src/mm-sim.h |2 +
> > 6 files changed, 106 insertions(+), 8 deletions(-)
> >
> > diff --git a/cli/mmcli-sim.c b/cli/mmcli-sim.c
> > index aa39a91..89ceeed 100644
> > --- a/cli/mmcli-sim.c
> > +++ b/cli/mmcli-sim.c
> > @@ -161,14 +161,18 @@ print_sim_info (MMSim *sim)
> > g_print ("SIM '%s'\n",
> > mm_sim_get_path (sim));
> > g_print (" -\n"
> > - " Properties | imsi : '%s'\n"
> > - " |id : '%s'\n"
> > - " | operator id : '%s'\n"
> > - " | operator name : '%s'\n",
> > + " Properties | imsi : '%s'\n"
> > + " | id : '%s'\n"
> > + " | operator id : '%s'\n"
> > + " |operator name : '%s'\n"
> > + " |show PLMN at home : %s\n"
> > + " | show op name roaming : %s\n",
> > VALIDATE (mm_sim_get_imsi (sim)),
> > VALIDATE (mm_sim_get_identifier (sim)),
> > VALIDATE (mm_sim_get_operator_identifier (sim)),
> > - VALIDATE (mm_sim_get_operator_name (sim)));
> > + VALIDATE (mm_sim_get_operator_name (sim)),
> > + mm_sim_get_display_registered_network_name_at_home (sim) ?
> > "yes" : "no",
> > + mm_sim_get_display_operator_name_while_roaming (sim) ? "yes"
> > : "no");
> > }
> >
> > static void
> > diff --git a/introspection/org.freedesktop.ModemManager1.Sim.xml
> > b/introspection/org.freedesktop.ModemManager1.Sim.xml
> > index 14f9077..5833838 100644
> > --- a/introspection/org.freedesktop.ModemManager1.Sim.xml
> > +++ b/introspection/org.freedesktop.ModemManager1.Sim.xml
> > @@ -99,5 +99,22 @@
> > -->
> >
> >
> > +
> > + > access="read" />
>
>
> Quoting from the TS:
> "b1=0: display of registered PLMN name not required when registered PLMN
> is either HPLMN or a PLMN in the service provider PLMN list.
> b1=1: display of registered PLMN name required when registered PLMN is
> either HPLMN or a PLMN in the service provider PLMN list."
So let me think this through... bit 1 is about what to display when the
registered network is a "well-known" network, ie a PLMN known to the
SIM.
0 means that the phone does not need to show the registered network name
if it's "well-known" network. They probably should have just said "0
means the opposite of 1", the terminology here is kinda confusing.
1 means that the registered network name is required to be shown if the
network is a well-known network. I guess b1=1 would force showing a
roaming partner's name instead of the SPN if the roaming partner is
known to the SIM?
> I don't think that "DisplayRegisteredNetworkNameAtHome" covers
> everything the property is meant to say. Actually, it hides the main
> purpose of the property, which is the fact that the registered PLMN name
> should be displayed even if the network is not the home network, but a
> network allowed in the PLMN list. E.g. I have a card from the 'Yoigo'
> operator, and when using 2G my phone connects to the 'Movistar'network:
> but my phone still needs to display 'Yoigo' instead of 'Movistar'. The
> fact that the device should display the name of the registered PLMN when
> in the same home PLMN is quite obvious already.
AT&T in the US was notorious for playing ga
Re: [MM 0.6] Plumb up the SPN display-rule bits
>> + > access="read" /> > > > Quoting from the TS: > "b1=0: display of registered PLMN name not required when registered PLMN > is either HPLMN or a PLMN in the service provider PLMN list. > b1=1: display of registered PLMN name required when registered PLMN is > either HPLMN or a PLMN in the service provider PLMN list." > > I don't think that "DisplayRegisteredNetworkNameAtHome" covers > everything the property is meant to say. Actually, it hides the main > purpose of the property, which is the fact that the registered PLMN name > should be displayed even if the network is not the home network, but a > network allowed in the PLMN list. E.g. I have a card from the 'Yoigo' > operator, and when using 2G my phone connects to the 'Movistar'network: > but my phone still needs to display 'Yoigo' instead of 'Movistar'. The > fact that the device should display the name of the registered PLMN when > in the same home PLMN is quite obvious already. ... > The name "DisplayOperatorNameWhileRoaming" is also not fully clear. > 'Roaming' means for the modem/phone 'not in the home network', and that > covers both being in a network allowed in the list stored in the SIM > card, or really roaming in another not-listed network. Following my > example before, when I connect to the Movistar network with a Yoigo SIM > card, I will be reported as being roaming, even if the network is one of > the allowed networks in the list stored in the SIM card. I don't think this is right - the "service provider PLMN list", EF_SPDI, referred to in 31.102 is not the list of all possible networks to roam on; it's a separate list that exists purely for fine-tuning this display. If the card from 'Yoigo' doesn't list 'Movistar', then bit 1 is irrelevant, we always display 'Movistar', and bit 2 controls whether we display 'Yoigo' as well. (If the card from 'Yoigo' did list the 'Movistar' PLMN on its (E)HPLMN list, or has it in the EF_SPDI list, then bit 1 controls whether we need to mention 'Movistar' at all (we always need to mention 'Yoigo' when on a home network)). I admit that the inclusion of the EF_SPDI list in the discussion makes the home/roaming distinction a bit fuzzier (though I have yet to see a non-empty EF_SPDI list), but I think that's roughly the right division. >From Annex A.4 of 22.101: When registered on the HPLMN, or one of the PLMN Identifications used for Service Provider Name display: (i) The SP Name shall be displayed; (ii) Display of the PLMN Name is an operator"s option by setting the appropriate fields in the USIM (i.e. the Service Provider name shall be displayed either in parallel to the PLMN Name or instead of the PLMN Name). When registered on neither the HPLMN, nor one of the PLMN Identifications used for Service Provider Name display: (i) The PLMN name shall be displayed; (ii) Display of the SP Name is an operator"s option by setting the appropriate fields in the USIM. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey,
> This is required for properly displaying
> local-operator-vs-home-provider information, per 3GPP
> (31.102 section 4.1.2 on EF_SPN and 22.101 Annex A).
>
For anyone else checking, that's section 4.2.11 in release 11 of the
document.
> Suggestions welcome on the long and somewhat unwieldy property/function names.
>
> - Nathan
>
>
> 0001-Retrieve-and-plumb-up-the-SIM-SPN-bits-that-set-oper.patch
>
>
> From 96ce78202344bd928bf602874a087a0adb383cbe Mon Sep 17 00:00:00 2001
> From: Nathan Williams
> Date: Wed, 29 Feb 2012 16:25:03 -0500
> Subject: [PATCH] Retrieve and plumb up the SIM SPN bits that set operator
> name display rules.
>
> BUG=chromium-os:21522
> TEST=Insert SIMs from various operators (T-Mobile, MaxROAM), run mmcli -i 0
> Varying conditions include no SPN (AT&T), all-FF SPN data (3 Italy),
> SPN with neither display bit set (3 UK), SPN with a display bit set (MaxROAM)
>
> Change-Id: Id83da0e094efe52922dcc21f1420d3f5db5883e3
> ---
> cli/mmcli-sim.c| 14 --
> .../org.freedesktop.ModemManager1.Sim.xml | 17 +++
> libmm-glib/mm-sim.c| 30
> libmm-glib/mm-sim.h|2 +
> src/mm-sim.c | 49 ++-
> src/mm-sim.h |2 +
> 6 files changed, 106 insertions(+), 8 deletions(-)
>
> diff --git a/cli/mmcli-sim.c b/cli/mmcli-sim.c
> index aa39a91..89ceeed 100644
> --- a/cli/mmcli-sim.c
> +++ b/cli/mmcli-sim.c
> @@ -161,14 +161,18 @@ print_sim_info (MMSim *sim)
> g_print ("SIM '%s'\n",
> mm_sim_get_path (sim));
> g_print (" -\n"
> - " Properties | imsi : '%s'\n"
> - " |id : '%s'\n"
> - " | operator id : '%s'\n"
> - " | operator name : '%s'\n",
> + " Properties | imsi : '%s'\n"
> + " | id : '%s'\n"
> + " | operator id : '%s'\n"
> + " |operator name : '%s'\n"
> + " |show PLMN at home : %s\n"
> + " | show op name roaming : %s\n",
> VALIDATE (mm_sim_get_imsi (sim)),
> VALIDATE (mm_sim_get_identifier (sim)),
> VALIDATE (mm_sim_get_operator_identifier (sim)),
> - VALIDATE (mm_sim_get_operator_name (sim)));
> + VALIDATE (mm_sim_get_operator_name (sim)),
> + mm_sim_get_display_registered_network_name_at_home (sim) ?
> "yes" : "no",
> + mm_sim_get_display_operator_name_while_roaming (sim) ? "yes" :
> "no");
> }
>
> static void
> diff --git a/introspection/org.freedesktop.ModemManager1.Sim.xml
> b/introspection/org.freedesktop.ModemManager1.Sim.xml
> index 14f9077..5833838 100644
> --- a/introspection/org.freedesktop.ModemManager1.Sim.xml
> +++ b/introspection/org.freedesktop.ModemManager1.Sim.xml
> @@ -99,5 +99,22 @@
> -->
>
>
> +
> + access="read" />
Quoting from the TS:
"b1=0: display of registered PLMN name not required when registered PLMN
is either HPLMN or a PLMN in the service provider PLMN list.
b1=1: display of registered PLMN name required when registered PLMN is
either HPLMN or a PLMN in the service provider PLMN list."
I don't think that "DisplayRegisteredNetworkNameAtHome" covers
everything the property is meant to say. Actually, it hides the main
purpose of the property, which is the fact that the registered PLMN name
should be displayed even if the network is not the home network, but a
network allowed in the PLMN list. E.g. I have a card from the 'Yoigo'
operator, and when using 2G my phone connects to the 'Movistar'network:
but my phone still needs to display 'Yoigo' instead of 'Movistar'. The
fact that the device should display the name of the registered PLMN when
in the same home PLMN is quite obvious already.
But, I can't think of a better or shorter name...
"DisplayRegisteredNetworkNameAtHomeOrAllowed" is even longer... :-)
> +
> +
> + />
> +
Quoting from the TS:
"b2=0: display of the service provider name is required when registered
PLMN is neither HPLMN nor a PLMN in the service provider PLMN list.
b2=1: display of the service provider name is not required when
registered PLMN is neither HPLMN nor a PLMN in the service provider PLMN
list."
The name "DisplayOperatorNameWhileRoaming" is also not fully clear.
'Roaming' means for the modem/phone 'not in the home network', and that
covers both being in a network allowed in the list stored in the SIM
card, or really roaming in another not-listed network. Following my
example before, when I connect to the Movistar network with a Yoigo SIM
card, I will be reported as being roaming, even if the network is one of
the allowed networks in
