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
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
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
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
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, 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 Fri, Mar 9, 2012 at 8:19 AM, Aleksander Morgado aleksan...@lanedo.comwrote: 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
On Fri, Mar 9, 2012 at 9:30 AM, Nathan Williams n...@google.com wrote: On Fri, Mar 9, 2012 at 8:19 AM, Aleksander Morgado aleksan...@lanedo.comwrote: 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
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
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
Fwd: [MM 0.6] Plumb up the SPN display-rule bits
[I accidentially sent this reply just to Dan; I wondered why it hadn't
gotten any traction on the list. Resending]
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.
Right.
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?
It's in addition to the SPN. When registered on the HPLMN [...] The
SP Name shall be displayed (122.101 A.4)
Perhaps combining both bits into a RequiredNameDisplay (?) property is
the right way to go? We already know what PLMN we're registered with,
and we can access the PLMN list to figure out if the registered network
is, in fact, a well-known network or not.
So here, when the network is not a well-known network, b2=0 means SPN
name display is required, while b2=1 means you can display the
registered network name.
Similarly, here, the registered network name must be displayed, and
the bit controls whether to additionally display the SPN.
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
}
And then the UI client can use that hint to figure out whether it is
required to display the SPN or the registered name. Thoughts?
That logic involves mixing bits read from the SIM (static) with the
registered state (dynamic). We could do that, but it would have to be
somewhere other than the SIM interface, I think. I'm happier just
exporting the bits and punting the logic upstream. Partly I think
that's the safer choice since the logic is, as you note, so confusing.
- 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 n...@chromium.org 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 (ATT), 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 @@ -- property name=OperatorName type=s access=read / +!-- + DisplayRegisteredNetworkNameAtHome + + If true, the user interface is required to display the name of + the registered PLMN while registered on a home network (non-roaming). +-- +property name=DisplayRegisteredNetworkNameAtHome type=b 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... :-) + +!-- + DisplayOperatorNameWhileRoaming + + If true, the user interface is required to display the operator + name from the SIM (the OperatorName) when registered on a + non-home network (roaming). +-- +property name=DisplayOperatorNameWhileRoaming type=b access=read / + 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
Re: [MM 0.6] Plumb up the SPN display-rule bits
+ property name=DisplayRegisteredNetworkNameAtHome type=b 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 operators 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 operators 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
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 n...@chromium.org 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 (ATT), 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 @@ -- property name=OperatorName type=s access=read / +!-- + DisplayRegisteredNetworkNameAtHome + + If true, the user interface is required to display the name of + the registered PLMN while registered on a home network (non-roaming). +-- +property name=DisplayRegisteredNetworkNameAtHome type=b 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
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
[MM 0.6] Plumb up the SPN display-rule bits
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). 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 Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
