1:17 a.m.
First patch checks if Fixed Dialing is enabled in the SIM-card
by reading FD-activated bit from EFsst or EFest. If FDN is enabled,
SIM initialization procedure is stopped, and modem will stay in the PRE-SIM state.
If FD is enabled, this is signaled via DBUS.
I haven't been abled to test this in my 2G-modem properly. Response for
EF-phase is 3. So oFono-API starts to access EFust/EFest files.
But reading of EFest gives next error:
'technical problem with no diagnostic given'.
So FD-status is no reachable, although I have activated it in the SIM-card.
I also checked if the FD-status could be located in EFsst (well, accessed with same code
as with EFust),
but I couldn't give any change for allocated/activated bits for FDN,
even though I enabled/disabled FDN.
Please comment/test.
1:17 a.m.
New subject: [RFC PATCH 1/3] sim: check if Fixed Dialing is enabled in the SIM-card
If FD is enabled, halt SIM initialization procedure.
---
src/sim.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index 6f10d4c..930d6bf 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -71,6 +71,7 @@ struct ofono_sim {
unsigned char efest_length;
unsigned char *efsst;
unsigned char efsst_length;
+ gboolean fixed_dialing;
char *imsi;
@@ -307,6 +308,9 @@ static DBusMessage *sim_get_properties(DBusConnection *conn,
ofono_dbus_dict_append(&dict, "SubscriberIdentity",
DBUS_TYPE_STRING, &sim->imsi);
+ ofono_dbus_dict_append(&dict, "FixedDialing", DBUS_TYPE_BOOLEAN,
+ &sim->fixed_dialing);
+
if (sim->mnc_length) {
char mcc[OFONO_MAX_MCC_LENGTH + 1];
char mnc[OFONO_MAX_MNC_LENGTH + 1];
@@ -1066,6 +1070,10 @@ static void sim_efsst_read_cb(int ok, int length, int record,
int record_length, void *userdata)
{
struct ofono_sim *sim = userdata;
+ DBusConnection *conn = ofono_dbus_get_connection();
+ const char *path = __ofono_atom_get_path(sim->atom);
+
+ sim->fixed_dialing = FALSE;
if (!ok)
goto out;
@@ -1078,6 +1086,19 @@ static void sim_efsst_read_cb(int ok, int length, int record,
sim->efsst = g_memdup(data, length);
sim->efsst_length = length;
+ if (sim_sst_is_active(sim->efsst, sim->efsst_length,
+ SIM_SST_SERVICE_FDN)) {
+
+ sim->fixed_dialing = TRUE;
+
+ ofono_dbus_signal_property_changed(conn, path,
+ OFONO_SIM_MANAGER_INTERFACE,
+ "FixedDialing",
+ DBUS_TYPE_BOOLEAN,
+ &sim->fixed_dialing);
+ return;
+ }
+
out:
sim_retrieve_imsi(sim);
}
@@ -1087,6 +1108,8 @@ static void sim_efest_read_cb(int ok, int length, int record,
int record_length, void *userdata)
{
struct ofono_sim *sim = userdata;
+ DBusConnection *conn = ofono_dbus_get_connection();
+ const char *path = __ofono_atom_get_path(sim->atom);
if (!ok)
goto out;
@@ -1099,6 +1122,19 @@ static void sim_efest_read_cb(int ok, int length, int record,
sim->efest = g_memdup(data, length);
sim->efest_length = length;
+ if (sim_est_is_active(sim->efest, sim->efest_length,
+ SIM_EST_SERVICE_FDN)) {
+
+ sim->fixed_dialing = TRUE;
+
+ ofono_dbus_signal_property_changed(conn, path,
+ OFONO_SIM_MANAGER_INTERFACE,
+ "FixedDialing",
+ DBUS_TYPE_BOOLEAN,
+ &sim->fixed_dialing);
+ return;
+ }
+
out:
sim_retrieve_imsi(sim);
}
@@ -1109,6 +1145,8 @@ static void sim_efust_read_cb(int ok, int length, int record,
{
struct ofono_sim *sim = userdata;
+ sim->fixed_dialing = FALSE;
+
if (!ok)
goto out;
@@ -1665,6 +1703,8 @@ static void sim_free_state(struct ofono_sim *sim)
sim->efimg = NULL;
sim->efimg_length = 0;
}
+
+ sim->fixed_dialing = FALSE;
}
void ofono_sim_inserted_notify(struct ofono_sim *sim, ofono_bool_t inserted)
--
1.6.3.3
1:17 a.m.
New subject: [RFC PATCH 2/3] modem: some debugs added for indicating modem state change
---
src/modem.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/modem.c b/src/modem.c
index 7a29edf..583b79f 100644
--- a/src/modem.c
+++ b/src/modem.c
@@ -330,6 +330,8 @@ static void flush_atoms(struct ofono_modem *modem, enum modem_state
new_state)
GSList *prev;
GSList *tmp;
+ DBG("");
+
prev = NULL;
cur = modem->atoms;
@@ -367,6 +369,8 @@ static void modem_change_state(struct ofono_modem *modem,
enum modem_state old_state = modem->modem_state;
ofono_bool_t new_online = new_state == MODEM_STATE_ONLINE;
+ DBG("old state: %d, new state: %d", old_state, new_state);
+
if (old_state == new_state)
return;
--
1.6.3.3
1:17 a.m.
New subject: [RFC PATCH 3/3] sim: ensure existence of imsi-code when handling sim_get_properties
---
src/sim.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index 930d6bf..5f4f90e 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -311,7 +311,7 @@ static DBusMessage *sim_get_properties(DBusConnection *conn,
ofono_dbus_dict_append(&dict, "FixedDialing", DBUS_TYPE_BOOLEAN,
&sim->fixed_dialing);
- if (sim->mnc_length) {
+ if (sim->mnc_length && sim->imsi) {
char mcc[OFONO_MAX_MCC_LENGTH + 1];
char mnc[OFONO_MAX_MNC_LENGTH + 1];
const char *str;
--
1.6.3.3
2:29 a.m.
Hi Petteri,
First patch checks if Fixed Dialing is enabled in the SIM-card
by reading FD-activated bit from EFsst or EFest. If FDN is enabled,
SIM initialization procedure is stopped, and modem will stay in the PRE-SIM state.
If FD is enabled, this is signaled via DBUS.
don't forget to update the documentation with the new D-Bus property.
Regards
Marcel
2:36 a.m.
Hi Petteri,
First patch checks if Fixed Dialing is enabled in the SIM-card by
reading FD-activated bit from EFsst or EFest. If FDN is enabled, SIM
initialization procedure is stopped, > and modem will stay in the
PRE-SIM state.
If FD is enabled, this is signaled via DBUS.
I haven't been abled to test this in my 2G-modem properly.
Response
for EF-phase is 3. So oFono-API starts to access EFust/EFest files.
But reading of EFest gives next error:
'technical problem with no diagnostic given'.
So FD-status is no reachable, although I have activated it in the
SIM-card.
I also checked if the FD-status could be located in EFsst (well,
accessed with same code as with EFust), but I couldn't give any change
for allocated/activated bits for
FDN, even though I enabled/disabled FDN.
Please comment/test.
I had a discussion with Denis today about both FDN and BDN status.
GSM SIM Card:(EFsst)
In this case, FDN service status depends on the bits in EFsst and
EFadn invalidation information.( invalidation information is part of the
"Get RESPONSE" response data)
EFsst - FDN is allocated and activated in the SIM:
FDN is enabled - When EFadn is invalidated or not activated.
FDN is disabled - When EFadn is validated.
EFsst - FDN is not allocated or not activated in the SIM:
FDN is disabled
Note: This information can be found in the 3GPP 11.11 specification
section 11.5.1. Paragraph starts with "FDN capability request".
Invalidation information bits information can be found in the 3GPP
51.011 specification section 9.2.1(Response parameters/data in case of
an EF:) and section 9.3
USIM Card:(EFust, EFest)
In USIM case, FDN enabled/disabled dependents on the bits in the EFust
and EFest.
Let me know if something is unclear
Thanks and Regards,
jeevaka
2:28 a.m.
Hi Jeevaka and Denis,
and thanks for the comments.
I checked the invalidated-flag of EFadn (from file status-byte of GET RESPONSE)
and it actually changed according to FDN-enabling/disabling. But for some
reason I didn't got any change in EFsst for FDN/ADN-services. Could it be a
good idea to add also reading of EFadn in the SIM-initialization routine,
check invalidated-flag, and make decision of continuing initialization routine
based on that?
The other issue was that selection of service table (SIM/USIM) based on
EFphase. So SIM returns '3' in my tests. But the SIM-card seems to be of type
SIM (not USIM), because I accessed some USIM-type elementary files (EFest,
EFpbr) and those returned only error-codes. Like phase (3g) wouldn't actually
be exactly the same thing than USIM-type. What about doing the next change in
the SIM-init routine (not trusting to EFphase response when accessing the
correct service tables):
- read first EFest
- if EFest-access gives a valid response, read EFust
- if EFest-access doesn't give a valid response, read EFsst
Br, Petteri
I had a discussion with Denis today about both FDN and BDN status.
GSM SIM Card:(EFsst)
In this case, FDN service status depends on the bits in EFsst and
EFadn invalidation information.( invalidation information is part of the
"Get RESPONSE" response data)
EFsst - FDN is allocated and activated in the SIM:
FDN is enabled - When EFadn is invalidated or not activated.
FDN is disabled - When EFadn is validated.
EFsst - FDN is not allocated or not activated in the SIM:
FDN is disabled
Note: This information can be found in the 3GPP 11.11 specification
section 11.5.1. Paragraph starts with "FDN capability request".
Invalidation information bits information can be found in the 3GPP
51.011 specification section 9.2.1(Response parameters/data in case of
an EF:) and section 9.3
USIM Card:(EFust, EFest)
In USIM case, FDN enabled/disabled dependents on the bits in the EFust
and EFest.
Let me know if something is unclear
Thanks and Regards,
jeevaka
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
3:40 a.m.
Hi Petteri,
and thanks for the comments.
I checked the invalidated-flag of EFadn (from file status-byte of GET
RESPONSE) and it actually changed according to FDN-enabling/disabling.
But for some reason I didn't
got any change in EFsst for FDN/ADN-services. Could it be a good idea
to add also reading of EFadn in the SIM-initialization routine, check
invalidated-flag, and make
decision of continuing initialization routine based on that?
Exactly, thats what the specification also says. EFsst will inform 2
things: SIM's capabilty to support the service and service's
availability for the card holder. EFadn's file status is the one we need
to depend on for FDN enabled/disabled status.
The other issue was that selection of service table (SIM/USIM) based
on EFphase. So SIM returns '3' in my tests. But the SIM-card seems to be
of type SIM (not USIM),
because I accessed some USIM-type elementary files (EFest,
EFpbr) and those returned only error-codes. Like phase (3g) wouldn't
actually
be exactly the same thing than USIM-type. What about doing the
next change in the SIM-init
routine (not trusting to EFphase response when accessing the correct
service tables):
- read first EFest
- if EFest-access gives a valid response, read EFust
- if EFest-access doesn't give a valid response, read EFsst
EFphase information is not the correct way to determine the SIM card
type(SIM/USIM).
In most of the message based modems(eg: isimodem), there exists a
mechanism to get the type of the card.
AT based modem is the issue. Since most of the AT based modems doesn't
support AT+CSIM, its difficult to determine the card type.
I still believe that we need to determine the card type during the SIM
initialization itself for reading the right SIM files.
Regards,
jeevaka
4364
days inactive
4365
days old
8 comments
3 participants
participants (3)
-
Jeevaka.Badrappan＠elektrobit.com -
Marcel Holtmann -
Petteri Tikander