1:38 a.m.
Read out Intergrated Cicruit Card Identifier from SIM.
---
v0: initial version
doc/sim-api.txt | 5 +++++
include/types.h | 2 ++
src/sim.c | 29 +++++++++++++++++++++++++++++
src/simutil.h | 1 +
4 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/doc/sim-api.txt b/doc/sim-api.txt
index fd02396..d608205 100644
--- a/doc/sim-api.txt
+++ b/doc/sim-api.txt
@@ -115,3 +115,8 @@ Properties string SubscriberIdentity [readonly, optional]
The list contains elements of the same format as the
PinRequired property.
+
+ string IntegratedCircuitCardIdentifier [readonly]
+
+ Contains the Intergrated Circuit Card Identifer (ICCID)
+ and is read directly from the SIM.
diff --git a/include/types.h b/include/types.h
index 7b08b8c..7b903bb 100644
--- a/include/types.h
+++ b/include/types.h
@@ -36,6 +36,8 @@ extern "C" {
typedef int ofono_bool_t;
+#define OFONO_MAX_ICCID_LENGTH 20
+
/* MCC is always three digits. MNC is either two or three digits */
#define OFONO_MAX_MCC_LENGTH 3
#define OFONO_MAX_MNC_LENGTH 3
diff --git a/src/sim.c b/src/sim.c
index bf28f1e..1ce5751 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -70,6 +70,7 @@ struct sim_file_op {
};
struct ofono_sim {
+ char *iccid;
char *imsi;
enum ofono_sim_phase phase;
unsigned char mnc_length;
@@ -288,6 +289,10 @@ static DBusMessage *sim_get_properties(DBusConnection *conn,
if (!present)
goto done;
+ if (sim->iccid)
+ ofono_dbus_dict_append(&dict, "IntegratedCircuitCardIdentifier",
+ DBUS_TYPE_STRING, &sim->iccid);
+
if (sim->imsi)
ofono_dbus_dict_append(&dict, "SubscriberIdentity",
DBUS_TYPE_STRING, &sim->imsi);
@@ -1292,6 +1297,22 @@ static void sim_retrieve_efli_and_efpl(struct ofono_sim *sim)
sim_efpl_read_cb, sim);
}
+static void sim_iccid_read_cb(const struct ofono_error *error,
+ const unsigned char *data, int len, void *user)
+{
+ struct ofono_sim *sim = user;
+ char number[OFONO_MAX_ICCID_LENGTH+ 1];
+
+ if (!error || error->type != OFONO_ERROR_TYPE_NO_ERROR || len != 10)
+ return;
+
+ extract_bcd_number(data, len, number);
+ number[OFONO_MAX_ICCID_LENGTH] = '\0';
+ sim->iccid = g_strdup(number);
+
+ DBG("ICCID %s", sim->iccid);
+}
+
static void sim_efphase_read_cb(const struct ofono_error *error,
const unsigned char *data, int len, void *user)
{
@@ -1320,6 +1341,9 @@ static void sim_determine_phase(struct ofono_sim *sim)
static void sim_initialize(struct ofono_sim *sim)
{
+ sim->driver->read_file_transparent(sim, SIM_EF_ICCID_FILEID, 0, 10,
+ sim_iccid_read_cb, sim);
+
/* Perform SIM initialization according to 3GPP 31.102 Section 5.1.1.2
* The assumption here is that if sim manager is being initialized,
* then sim commands are implemented, and the sim manager is then
@@ -1843,6 +1867,11 @@ static void sim_free_state(struct ofono_sim *sim)
sim->simop_q = NULL;
}
+ if (sim->iccid) {
+ g_free(sim->iccid);
+ sim->iccid = NULL;
+ }
+
if (sim->imsi) {
g_free(sim->imsi);
sim->imsi = NULL;
diff --git a/src/simutil.h b/src/simutil.h
index 7590cca..d6c52fc 100644
--- a/src/simutil.h
+++ b/src/simutil.h
@@ -21,6 +21,7 @@
enum sim_fileid {
SIM_EFPL_FILEID = 0x2f05,
+ SIM_EF_ICCID_FILEID = 0x2fe2,
SIM_EFLI_FILEID = 0x6f05,
SIM_EF_CPHS_MWIS_FILEID = 0x6f11,
SIM_EF_CPHS_INFORMATION_FILEID = 0x6f16,
--
1.6.6.1
3:11 a.m.
Hi Daniel,
Read out Intergrated Cicruit Card Identifier from SIM.
---
v0: initial version
doc/sim-api.txt | 5 +++++
include/types.h | 2 ++
src/sim.c | 29 +++++++++++++++++++++++++++++
src/simutil.h | 1 +
4 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/doc/sim-api.txt b/doc/sim-api.txt
index fd02396..d608205 100644
--- a/doc/sim-api.txt
+++ b/doc/sim-api.txt
@@ -115,3 +115,8 @@ Properties string SubscriberIdentity [readonly,
optional]
The list contains elements of the same format as the
PinRequired property.
+
+ string IntegratedCircuitCardIdentifier [readonly]
I'd like to name this CardIdentifier, ICCID is too ugly and the full name is
just too long.
+static void sim_iccid_read_cb(const struct ofono_error *error,
+ const unsigned char *data, int len, void *user)
+{
+ struct ofono_sim *sim = user;
+ char number[OFONO_MAX_ICCID_LENGTH+ 1];
+
+ if (!error || error->type != OFONO_ERROR_TYPE_NO_ERROR || len != 10)
+ return;
No need to check for error being NULL, we don't allow that.
+
+ extract_bcd_number(data, len, number);
+ number[OFONO_MAX_ICCID_LENGTH] = '\0';
+ sim->iccid = g_strdup(number);
+
+ DBG("ICCID %s", sim->iccid);
+}
+
You might want to emit the property changed signal with the new ICCID value
here.
static void sim_efphase_read_cb(const struct ofono_error *error,
const unsigned char *data, int len, void *user)
{
@@ -1320,6 +1341,9 @@ static void sim_determine_phase(struct ofono_sim
*sim)
static void sim_initialize(struct ofono_sim *sim)
{
+ sim->driver->read_file_transparent(sim, SIM_EF_ICCID_FILEID, 0, 10,
+ sim_iccid_read_cb, sim);
+
Please use the sim file queue like EFpl does, no need to invent your own
solution. The phase check is a very specific case because we cache SIM files by
phase of the SIM, so it needs to be known / guessed before the rest of sim file
queue runs.
Regards,
-Denis
4:36 p.m.
Hi Denis,
> +
> + extract_bcd_number(data, len, number);
> + number[OFONO_MAX_ICCID_LENGTH] = '\0';
> + sim->iccid = g_strdup(number);
> +
> + DBG("ICCID %s", sim->iccid);
> +}
> +
You might want to emit the property changed signal with the new ICCID value
here.
I had already the property update code there but there was some
problem with dbus. I figured that it wasn't setup correctly yet. I'll
look into that.
> static void sim_efphase_read_cb(const struct ofono_error
*error,
> const unsigned char *data, int len, void *user)
> {
> @@ -1320,6 +1341,9 @@ static void sim_determine_phase(struct ofono_sim
> *sim)
>
> static void sim_initialize(struct ofono_sim *sim)
> {
> + sim->driver->read_file_transparent(sim, SIM_EF_ICCID_FILEID, 0, 10,
> + sim_iccid_read_cb, sim);
> +
Please use the sim file queue like EFpl does, no need to invent your own
solution.
I used the ofono_sim_read function but that didn't work. On the
terminal I saw only:
CRSM=192,12258
With read_file_transparent it is:
ofonod[2048]: Control:> AT+CRSM=176,12258,0,0,10\r
ofonod[2048]: Control:< \r\r\n+CRSM:
144,0,"989422024754212460F6"\r\n\r\nOK\r\n
The phase check is a very specific case because we cache SIM files by
phase of the SIM, so it needs to be known / guessed before the rest of sim file
queue runs.
Thanks for the info. I'll update the patch.
daniel
6:09 p.m.
On Tue, Apr 27, 2010 at 08:36:31AM +0200, Daniel Wagner wrote:
> Please use the sim file queue like EFpl does, no need to invent
your own
> solution.
I used the ofono_sim_read function but that didn't work. On the
terminal I saw only:
CRSM=192,12258
With read_file_transparent it is:
ofonod[2048]: Control:> AT+CRSM=176,12258,0,0,10\r
ofonod[2048]: Control:< \r\r\n+CRSM:
144,0,"989422024754212460F6"\r\n\r\nOK\r\n
I looked into this. It comes down to:
ofono_sim_read -> sim_op_next -> read_file_info
and since sim_op_next does not check what structure type it is, it
always calles read_file_info (CRSM=192).
I'm not sure how to resolve this here. The problem is the callback
given to sim_op_next has of course a different signature than
read_file_transparent wants (ofono_sim_read_file_cb_t vs
ofono_sim_read_cb_t)
Should I add something like:
int ofono_sim_read_transparent(struct ofono_sim *sim, int id,
enum ofono_sim_file_structure expected_type,
ofono_sim_read_cb_t cb, void *data)
thanks,
daniel
12:21 a.m.
Hi Daniel,
On Tue, Apr 27, 2010 at 08:36:31AM +0200, Daniel Wagner wrote:
> > Please use the sim file queue like EFpl does, no need to invent your
> > own solution.
>
> I used the ofono_sim_read function but that didn't work. On the
> terminal I saw only:
>
> CRSM=192,12258
>
> With read_file_transparent it is:
>
> ofonod[2048]: Control:> AT+CRSM=176,12258,0,0,10\r
> ofonod[2048]: Control:< \r\r\n+CRSM:
> 144,0,"989422024754212460F6"\r\n\r\nOK\r\n
I looked into this. It comes down to:
ofono_sim_read -> sim_op_next -> read_file_info
and since sim_op_next does not check what structure type it is, it
always calles read_file_info (CRSM=192).
I'm not sure how to resolve this here. The problem is the callback
given to sim_op_next has of course a different signature than
read_file_transparent wants (ofono_sim_read_file_cb_t vs
ofono_sim_read_cb_t)
Should I add something like:
int ofono_sim_read_transparent(struct ofono_sim *sim, int id,
enum ofono_sim_file_structure expected_type,
ofono_sim_read_cb_t cb, void *data)
ofono_sim_read handles transparent, cyclic and record based files. There
should be no need to add anything. Just do exactly what e.g. EFli / EFpl
functions do.
What modem are you using? Some of them are dumb and don't implement +CRSM 'GET
RESPONSE' properly.
Regards,
-Denis
1:43 a.m.
Hi Denis,
On Tue, Apr 27, 2010 at 04:21:21PM +0200, Denis Kenzior wrote:
Hi Daniel,
> On Tue, Apr 27, 2010 at 08:36:31AM +0200, Daniel Wagner wrote:
> > > Please use the sim file queue like EFpl does, no need to invent your
> > > own solution.
> >
> > I used the ofono_sim_read function but that didn't work. On the
> > terminal I saw only:
> >
> > CRSM=192,12258
> >
> > With read_file_transparent it is:
> >
> > ofonod[2048]: Control:> AT+CRSM=176,12258,0,0,10\r
> > ofonod[2048]: Control:< \r\r\n+CRSM:
> > 144,0,"989422024754212460F6"\r\n\r\nOK\r\n
>
> I looked into this. It comes down to:
>
> ofono_sim_read -> sim_op_next -> read_file_info
>
> and since sim_op_next does not check what structure type it is, it
> always calles read_file_info (CRSM=192).
>
> I'm not sure how to resolve this here. The problem is the callback
> given to sim_op_next has of course a different signature than
> read_file_transparent wants (ofono_sim_read_file_cb_t vs
> ofono_sim_read_cb_t)
>
> Should I add something like:
>
> int ofono_sim_read_transparent(struct ofono_sim *sim, int id,
> enum ofono_sim_file_structure expected_type,
> ofono_sim_read_cb_t cb, void *data)
>
ofono_sim_read handles transparent, cyclic and record based files. There
should be no need to add anything. Just do exactly what e.g. EFli / EFpl
functions do.
Ah, that's good to know. I following the EFli / EFpl templates:
static void sim_initialize(struct ofono_sim *sim)
{
ofono_sim_read(sim, SIM_EF_ICCID_FILEID,
OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
sim_iccid_read_cb, sim);
...
I have not moved the call to
another place as you have suggested yet.
The debug output is:
ofonod[18879]: src/modem.c:ofono_modem_create() name: (null), type: hso
ofonod[18879]: src/modem.c:set_modem_property() modem 0xc0f260 property Path
ofonod[18879]: src/modem.c:set_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ApplicationPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ControlPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property NetworkInterface
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Path
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: src/modem.c:set_modem_property() modem 0xc0f260 property ApplicationPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ApplicationPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ControlPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property NetworkInterface
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Path
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: src/modem.c:set_modem_property() modem 0xc0f260 property ControlPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ApplicationPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ControlPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property NetworkInterface
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Path
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: src/modem.c:set_modem_property() modem 0xc0f260 property NetworkInterface
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ApplicationPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ControlPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property NetworkInterface
ofonod[18879]: src/modem.c:set_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: src/modem.c:unregister_property() property 0xc0ffb0
ofonod[18879]: plugins/hso.c:hso_probe() 0xc0f260
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Path
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property Registered
ofonod[18879]: plugins/hso.c:hso_enable() 0xc0f260
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ControlPort
ofonod[18879]: src/modem.c:get_modem_property() modem 0xc0f260 property ApplicationPort
ofonod[18879]: Control:> ATE0\r
ofonod[18879]: App:> ATE0\r
ofonod[18879]: App:< \r\nOK\r\n
ofonod[18879]: Control:< \r\nOK\r\n
ofonod[18879]: Control:> AT+CFUN=1\r
ofonod[18879]: Control:< \r\nOK\r\n
ofonod[18879]: plugins/hso.c:cfun_enable()
ofonod[18879]: plugins/hso.c:hso_pre_sim() 0xc0f260
ofonod[18879]: src/sim.c:ofono_sim_add_state_watch() 0xc0f500
ofonod[18879]: src/sim.c:ofono_sim_add_state_watch() 0xc0f500
ofonod[18879]: Control:> AT+CGMI\r
ofonod[18879]: Control:< \r\nOption N.V.\r\n\r\nOK\r\n
ofonod[18879]: Control:> AT+CRSM=176,28590,0,0,1\r
ofonod[18879]: Control:< \r\r\n+CRSM: 144,0,"03"\r\n\r\nOK\r\n
ofonod[18879]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 1
ofonod[18879]: Control:> AT+CRSM=192,12258\r
ofonod[18879]: Control:< \r\r\n+CRSM: 111,0\r\n\r\nOK\r\n
ofonod[18879]: Control:> AT+CGMM\r
ofonod[18879]: Control:< \r\nGlobeTrotter HSUPA Modem\r\n\r\nOK\r\n
ofonod[18879]: Control:> AT+CPIN?\r
ofonod[18879]: Control:< \r\n+CPIN: SIM PIN\r\n\r\nOK\r\n
ofonod[18879]: drivers/atmodem/sim.c:at_cpin_cb() crsm_pin_cb: SIM PIN
ofonod[18879]: Control:> AT+CRSM=192,28421\r
ofonod[18879]: Control:< \r\r\n+CRSM: 111,0\r\n\r\nOK\r\n
ofonod[18879]: Control:> AT+CGMR\r
ofonod[18879]: Control:< \r\n2.12.0.0Hd (Date: Oct 29 2009, Time:
09:56:48)\r\n\r\nOK\r\n
ofonod[18879]: Control:> AT+CRSM=192,12037\r
ofonod[18879]: Control:< \r\r\n+CRSM: 111,0\r\n\r\nOK\r\n
ofonod[18879]: Control:> AT+CGSN\r
ofonod[18879]: Control:< \r\n351721030157214,PK29997020\r\n\r\nOK\r\n
What modem are you using? Some of them are dumb and don't
implement +CRSM 'GET
RESPONSE' properly.
It's a Option iCON 451. I didn't check what "\r\r\n+CRSM:
144,0,"03"\r\n\r\nOK\r\n" exaclty means. I guess I have to check the
standard.
cheers,
daniel
1:53 a.m.
Hi Daniel,
> It's a Option iCON 451. I didn't check what
"\r\r\n+CRSM:
> 144,0,"03"\r\n\r\nOK\r\n" exaclty means. I guess I have to check the
> standard.
(of course I did copy the wrong line)
ofonod[18879]: Control:< \r\r\n+CRSM: 111,0\r\n\r\nOK\r\n
Yes the Option Modems always return +CRSM: 111 -> Unspecified Error whenever we
use 'GET RESPONSE'. It seems that this function is simply not implemented in
their firmware, even though reading files directly from the SIM (in the case of
EFphase or EFiccid) seems to work.
Unfortunately, with a few exceptions, we actually need to call 'GET RESPONSE'
first to find the record size / file size before we can attempt to read the file.
One way to do this might be to use +CSIM to walk the EF tree, but that is
quite nasty.
This needs to be fixed for the Option driver. Perhaps someone here knows a
way...
Regards,
-Denis
2:06 a.m.
Hi Denis,
> > It's a Option iCON 451. I didn't check what
"\r\r\n+CRSM:
> > 144,0,"03"\r\n\r\nOK\r\n" exaclty means. I guess I have to check
the
> > standard.
>
> (of course I did copy the wrong line)
>
> ofonod[18879]: Control:< \r\r\n+CRSM: 111,0\r\n\r\nOK\r\n
>
Yes the Option Modems always return +CRSM: 111 -> Unspecified Error whenever we
use 'GET RESPONSE'. It seems that this function is simply not implemented in
their firmware, even though reading files directly from the SIM (in the case of
EFphase or EFiccid) seems to work.
Aside from the Option modem I have a Huawei E160 around for testing:
ofonod[19115]: > AT+CRSM=192,12258\r
ofonod[19115]: < AT+CRSM=192,12258\r
ofonod[19115]: < \r\n+CME ERROR: SIM PIN required\r\n
Looks like it doesn't like the 'GET RESPONSE' either.
Unfortunately, with a few exceptions, we actually need to call
'GET RESPONSE'
first to find the record size / file size before we can attempt to read the file.
One way to do this might be to use +CSIM to walk the EF tree, but that is
quite nasty.
To be honest I have not the slighest idea what you mean :)
This needs to be fixed for the Option driver. Perhaps someone here
knows a
way...
Well, if some one tells me what to do I work on it. But I'm a bit lost
without help.
cheers,
daniel
2:19 a.m.
Hi Daniel,
Hi Denis,
> > > It's a Option iCON 451. I didn't check what "\r\r\n+CRSM:
> > > 144,0,"03"\r\n\r\nOK\r\n" exaclty means. I guess I have to
check the
> > > standard.
> >
> > (of course I did copy the wrong line)
> >
> > ofonod[18879]: Control:< \r\r\n+CRSM: 111,0\r\n\r\nOK\r\n
>
> Yes the Option Modems always return +CRSM: 111 -> Unspecified Error
> whenever we use 'GET RESPONSE'. It seems that this function is simply
> not implemented in their firmware, even though reading files directly
> from the SIM (in the case of EFphase or EFiccid) seems to work.
Aside from the Option modem I have a Huawei E160 around for testing:
ofonod[19115]: > AT+CRSM=192,12258\r
ofonod[19115]: < AT+CRSM=192,12258\r
ofonod[19115]: < \r\n+CME ERROR: SIM PIN required\r\n
Looks like it doesn't like the 'GET RESPONSE' either.
There are two possibilities here:
- The SIM is not per spec and actually requires PIN to be entered before
reading the EFiccid
- The Huawei firmware is not per spec and blocks the reading of EFiccid before
the SIM PIN has been entered
Since you managed to read the EFiccid on the Option hardware, I assume that
this is a Huawei firmware bug...
Not really oFono's fault, welcome to the wonderful world of GSM hardware. Get
yourself an MBM F3507/F3607, their firmware usually gets this right...
> This needs to be fixed for the Option driver. Perhaps someone
here knows
> a way...
Well, if some one tells me what to do I work on it. But I'm a bit lost
without help.
Me too ;)
Regards,
-Denis
4527
days inactive
4528
days old
9 comments
2 participants
participants (2)
-
Daniel Wagner -
Denis Kenzior