EFecc has different formats in G2 and G3 UICC specs.
---
src/voicecall.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/src/voicecall.c b/src/voicecall.c
index e52ca66..52383e7 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -1663,8 +1663,42 @@ static void set_new_ecc(struct ofono_voicecall *vc)
emit_en_list_changed(vc);
}
-static void ecc_read_cb(int ok, int total_length, int record, const unsigned char *data,
- int record_length, void *userdata)
+static void ecc_g2_read_cb(int ok, int total_length, int record,
+ const unsigned char *data,
+ int record_length, void *userdata)
+{
+ struct ofono_voicecall *vc = userdata;
+ char en[7];
+
+ DBG("%d", ok);
+
+ if (!ok)
+ return;
+
+ if (total_length < 3) {
+ ofono_error("Unable to read emergency numbers from SIM");
+ return;
+ }
+
+ total_length /= 3;
+ while (total_length--) {
+ extract_bcd_number(data, 3, en);
+ data += 3;
+
+ if (en[0] != '\0')
+ vc->new_en_list = g_slist_prepend(vc->new_en_list,
+ g_strdup(en));
+ }
+
+ if (vc->new_en_list == NULL)
+ return;
+
+ set_new_ecc(vc);
+}
+
+static void ecc_g3_read_cb(int ok, int total_length, int record,
+ const unsigned char *data,
+ int record_length, void *userdata)
{
struct ofono_voicecall *vc = userdata;
int total;
@@ -1821,8 +1855,13 @@ static void sim_watch(struct ofono_atom *atom,
return;
}
- ofono_sim_read(sim, SIM_EFECC_FILEID, OFONO_SIM_FILE_STRUCTURE_FIXED,
- ecc_read_cb, vc);
+ /* Try both formats, only one or none will work */
+ ofono_sim_read(sim, SIM_EFECC_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
+ ecc_g2_read_cb, vc);
+ ofono_sim_read(sim, SIM_EFECC_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_FIXED,
+ ecc_g3_read_cb, vc);
}
void ofono_voicecall_register(struct ofono_voicecall *vc)
--
1.6.1
Show replies by date
Hi Andrew,
EFecc has different formats in G2 and G3 UICC specs.
I applied this patch. However, the way the code works today EFecc will be
read after IMSI if the SIM is not locked and thus cached normally. I won't
mention other possible race conditions here resulting from different driver
combinations.
This means that any subsequent reads on a device/sim combination of a different
generation will give potentially different results. I'd still like us to cache
SIM files according to phase if possible. This seems to be the safest / sanest
approach.
It might also be a good idea to never cache EFecc, if we want to be ultra
paranoid.
Regards,
-Denis
Hi,
2009/12/16 Denis Kenzior <denkenz(a)gmail.com>:
I applied this patch. However, the way the code works today EFecc
will be
read after IMSI if the SIM is not locked and thus cached normally. I won't
mention other possible race conditions here resulting from different driver
combinations.
This means that any subsequent reads on a device/sim combination of a different
generation will give potentially different results. I'd still like us to cache
SIM files according to phase if possible. This seems to be the safest / sanest
approach.
You're right. Attached patch adds the SIM phase to the index of the
cache. I used EFphase to figure out the SIM phase becuase this way
seems the least hacky. This lets us remove some of the autodetection
of things that depend on the phase in other places in ofono, but right
now the autodetection can only be a gain for us so I'm not touching
it.
Do you see any way caching EFecc could have unwanted consequences?
Regards
2009/12/17 Andrzej Zaborowski <andrew.zaborowski(a)intel.com>:
Attached patch adds the SIM phase to the index
Now with the attachment..
Hi Andrew,
Now with the attachment..
Some comments:
struct ofono_sim {
char *imsi;
+ int phase;
unsigned char mnc_length;
GSList *own_numbers;
GSList *new_numbers;
Enum or an unsigned char for phase please.
+ sim->phase = (ok && length == 1) ? data[0] == 0x00 ? 1 : 2 : 3;
+
This seriously makes my brain hurt. Don't do this.
Regards,
-Denis
Hi Andrew,
> This means that any subsequent reads on a device/sim combination
of a
> different generation will give potentially different results. I'd still
> like us to cache SIM files according to phase if possible. This seems to
> be the safest / sanest approach.
You're right. Attached patch adds the SIM phase to the index of the
cache. I used EFphase to figure out the SIM phase becuase this way
seems the least hacky. This lets us remove some of the autodetection
of things that depend on the phase in other places in ofono, but right
now the autodetection can only be a gain for us so I'm not touching
it.
So I think this is the right approach, but lets tweak it a bit. According to
51.011 EFphase can always be read. So even if 51.011 tells us to read it
after PIN has been verified there's nothing (theoretically) preventing us from
doing so earlier.
Thus we can do it in one of two ways
1. Read EFphase on startup and block the rest of the sim file queue until we
determined the phase. Then kick off the sim file ops queue as normal. Here we
can even shortcut the 'select' operation since we always know the length of
the file. Just use read_binary straight away here.
2. Proceed as we do today, but do not cache any file until we know EFphase.
For EFecc we make sure that EFphase is read after EFecc. This results in us
always reading EFecc at startup.
It is important to note that in both approaches we get rid of the race
conditions of running the sim ops queue and querying cpin & imsi in parallel.
Do you see any way caching EFecc could have unwanted consequences?
Personally I don't see foresee any issues with us doing so, but in the end it
might be up to the carriers to tell us what they prefer.
Regards,
-Denis
Hi Denis,
2009/12/18 Denis Kenzior <denkenz(a)gmail.com>:
So I think this is the right approach, but lets tweak it a bit.
According to
51.011 EFphase can always be read. So even if 51.011 tells us to read it
after PIN has been verified there's nothing (theoretically) preventing us from
doing so earlier.
Thus we can do it in one of two ways
1. Read EFphase on startup and block the rest of the sim file queue until we
determined the phase. Then kick off the sim file ops queue as normal. Here we
can even shortcut the 'select' operation since we always know the length of
the file. Just use read_binary straight away here.
2. Proceed as we do today, but do not cache any file until we know EFphase.
For EFecc we make sure that EFphase is read after EFecc. This results in us
always reading EFecc at startup.
It is important to note that in both approaches we get rid of the race
conditions of running the sim ops queue and querying cpin & imsi in parallel.
Here's a patch following 1. but I think you can take either patch.
Note that we already know that no file gets cached until imsi is
retrieved, imsi doesn't get retrieved before EFphase and EFphase
isn't read before our PIN situation is sorted out.
Regards
Hi Andrew,
Here's a patch following 1. but I think you can take either
patch.
Note that we already know that no file gets cached until imsi is
retrieved, imsi doesn't get retrieved before EFphase and EFphase
isn't read before our PIN situation is sorted out.
Patch has been applied, thanks.
Regards,
-Denis