Handling of Fixed Dialing

Handling of Fixed Dialing

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

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.

[RFC PATCH 1/3] sim: check if Fixed Dialing is enabled in the SIM-card

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]

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

[RFC PATCH 2/3] modem: some debugs added for indicating modem state change

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

---
 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

[RFC PATCH 3/3] sim: ensure existence of imsi-code when handling sim_get_properties

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

---
 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

Re: Handling of Fixed Dialing

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

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

RE: Handling of Fixed Dialing

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

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

Re: Handling of Fixed Dialing

[Petteri Tikander]

[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]

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
> 

Re: Handling of Fixed Dialing

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

Hi Petteri,

> and thanks for the comments.

please stop top posting on this mailing list. Please don't have me to
repeat this over and over again.

Regards

Marcel

RE: Handling of Fixed Dialing

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

 
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