RE: [PATCH] doc: add emergency-call-handling.txt
Hi Bertrand, ofono-boun...@ofono.org wrote: Hi Jeevaka, One 'minor bug', I guess that there is a missing 'Post SIM and Post online atoms are not created.' For case 2. Good catch. And one question. For case 2 and 3, the 'Modem remains in online mode but the functionalities will be limited.'. What is the procedure to activate all functionalities? Do we just have to enter the PIN, to create post SIM and post online atoms? Full funcationality will be activated by entering the correct PIN. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Retrieve ofono_sim_password_type
Hi Christophe, Hi, I need to map ofono_sim_password_type according to h24 AT command manual. Can somebody check if I mapped correctly enum with documentation definition. OFONO_SIM_PASSWORD_SIM_PIN : PIN attempts OFONO_SIM_PASSWORD_SIM_PUK, : PUK attempts OFONO_SIM_PASSWORD_SIM_PIN2,: PIN2 attempts OFONO_SIM_PASSWORD_SIM_PUK2,: PUK2 attempts OFONO_SIM_PASSWORD_PHNET_PIN, : NETWORK PERSONALIZATION PIN attempts OFONO_SIM_PASSWORD_PHNET_PUK, : NETWORK PERSONALIZATION PUK attempts OFONO_SIM_PASSWORD_PHNETSUB_PIN,: NETWORK SUBSET PERSONALIZATION PIN attempts OFONO_SIM_PASSWORD_PHNETSUB_PUK,: NETWORK SUBSET PERSONALIZATION PUK attempts OFONO_SIM_PASSWORD_PHSP_PIN,: SERVICE PROVIDER PERSONALIZATION PIN attempts OFONO_SIM_PASSWORD_PHSP_PUK,: SERVICE PROVIDER PERSONALIZATION PUK attempts OFONO_SIM_PASSWORD_PHCORP_PIN, : CORPORATE PERSONALIZATION PIN attempts OFONO_SIM_PASSWORD_PHCORP_PUK, : CORPORATE PERSONALIZATION PUK attempts OFONO_SIM_PASSWORD_PHFSIM_PIN, : SIM PERSONALIZATION PIN attempts OFONO_SIM_PASSWORD_PHFSIM_PUK, : SIM PERSONALIZATION PUK attempts enum value is based on the 27.007 section 8.3 code values. If the h24 values are as per 27.007 specification, then its correct. Atleast based on the description, mapping seems to be correct. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 0/9] Emergency Mode
Hi Marcel, ofono-boun...@ofono.org wrote: Hi Jeevaka, Following patch is a proposal for emergency mode. Test has been done with the phonesim. Listed down few important cases to give an overview of the state changes that happen in each case. and I think we should turn this into a doc/emergency-call-handling.txt and extend a bit. Especially with what is expected from the user/UI to be done and what oFono will do for the user/UI. agreed. Will be done with next version of this patch set. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH v2 2/4] voicecall: refactor emergency number list handling
Hi Denis,
Denis Kenzior wrote:
Hi Jeevaka,
void emit_en_list_changed(struct ofono_voicecall *vc) static void
set_new_ecc(struct ofono_voicecall *vc) {
int i = 0;
+GSList *l;
g_slist_foreach(vc-en_list, (GFunc) g_free, NULL);
g_slist_free(vc-en_list); @@ -2079,6 +2081,12 @@ static void
set_new_ecc(struct ofono_voicecall *vc) vc-en_list =
vc-new_en_list; vc-new_en_list = NULL;
+for (l = vc-sim_en_list; l; l = l-next) {
+if (!g_slist_find_custom(vc-en_list, l-data,
number_compare))
+vc-en_list = g_slist_prepend(vc-en_list,
+
g_strdup(l-data));
+}
+
while (default_en_list[i]) {
GSList *l;
@@ -2120,10 +2128,11 @@ static void ecc_g2_read_cb(int ok, int
total_length, int record,data += 3;
if (en[0] != '\0')
-vc-new_en_list =
g_slist_prepend(vc-new_en_list,
+vc-sim_en_list =
g_slist_prepend(vc-sim_en_list,
g_strdup(en));
To preserve the old behavior, can we also check that the
number is not on the default_en_list?
SIM ecc number check with default_en_list is already taken care inside
set_new_ecc function.
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/2] stk: fix issue with null data object
Hi Andrew,
Andrzej Zaborowski wrote:
Hi Jeevaka
On 7 March 2011 16:35, Jeevaka Badrappan
jeevaka.badrap...@elektrobit.com wrote:
As per the specification, if alphad identifier is provided and is a
null data object, no information should be given to the user.
What do do you think of the following change?
diff --git a/src/stkutil.c b/src/stkutil.c index
abd1c99..c64cb7a 100644
--- a/src/stkutil.c
+++ b/src/stkutil.c
@@ -309,7 +309,7 @@ static gboolean
parse_dataobj_alpha_id(struct comprehension_tlv_iter *iter,
len = comprehension_tlv_iter_get_length(iter); if
(len == 0) { - *alpha_id = g_try_malloc0(1);
+ *alpha_id = NULL;
return TRUE;
}
This actually lets the caller detect a NULL alpha identifier
and then, as far as I can see, the stk.c code will not give
any information to the user if either the alpha_id is NULL or not
provided.
Change is fine with me.
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] atmodem: Enable network time for AT modem
Hi Antti, ofono-boun...@ofono.org wrote: --- drivers/atmodem/network-registration.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 4913611..2d589f0 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -722,6 +722,8 @@ static void ifx_ctzv_notify(GAtResult *result, gpointer user_data) nd-time.mday = mday; nd-time.mon = mon; nd-time.year = 2000 + year; + + ofono_netreg_time_notify(netreg, nd-time); } static void ifx_ctzdst_notify(GAtResult *result, gpointer user_data) Since the fix is more to do with the ifx modem, it would be nice if we have the commit message changed to reflect that. Whenever there is a timezone change, CTZV, CTZDST and XNITZINFO URCs will be reported. That is the main reason behind calling the ofono_netreg_time_notify from CTZDST. Are you pretty sure this is not the case? Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] atmodem: Enable network time for AT modem
Hi Antti, ofono-boun...@ofono.org wrote: Hi Jeevaka, On Tue, 2011-03-08 at 10:59 +0200, ext jeevaka.badrap...@elektrobit.com wrote: Hi Antti, ofono-boun...@ofono.org wrote: --- drivers/atmodem/network-registration.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 4913611..2d589f0 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -722,6 +722,8 @@ static void ifx_ctzv_notify(GAtResult *result, gpointer user_data) nd-time.mday = mday; nd-time.mon = mon; nd-time.year = 2000 + year; + + ofono_netreg_time_notify(netreg, nd-time); } static void ifx_ctzdst_notify(GAtResult *result, gpointer user_data) Whenever there is a timezone change, CTZV, CTZDST and XNITZINFO URCs will be reported. That is the main reason behind calling the ofono_netreg_time_notify from CTZDST. Are you pretty sure this is not the case? I don't know the details of ifx modem internals. If the time changes, is it always guaranteed that CTZDST is sent and that CTZDST comes after the CTZV? All I know that when testing NITZ with ifx modem, the time notification is not emitted without my fix. ofonod[454]: Net: \r\n+XNITZINFO: GMT+00:00,08/01/01,13:00:00\r\n\r\n+CTZDST: 0\r\n ofonod[454]: drivers/atmodem/network-registration.c:ifx_ctzdst_notify() dst 0 ofonod[454]: examples/nettime.c:example_nettime_info_received() Received a network time notification on modem: 0x83fc058 ofonod[454]: examples/nettime.c:example_nettime_info_received() Time: 2008-01-01 13:00:00-00:00 (DST=0) ofonod[454]: Net: \r\n+CTZV: +00,11/01/27,14:24:43\r\n ofonod[454]: drivers/atmodem/network-registration.c:ifx_ctzv_notify() tz +00 time 11/01/27,14:24:43 ofonod[454]: Net: \r\n+XNITZINFO: GMT+00:00,11/01/27,14:24:43\r\n\r\n+CTZDST: 0\r\n ofonod[454]: drivers/atmodem/network-registration.c:ifx_ctzdst_notify() dst 0 ofonod[454]: examples/nettime.c:example_nettime_info_received() Received a network time notification on modem: 0x83fc058 ofonod[454]: examples/nettime.c:example_nettime_info_received() Time: 2011-01-27 14:24:43-00:00 (DST=0) .. ofonod[454]: Net: \r\n+CTZV: +04,11/01/27,15:24:43\r\n ofonod[454]: drivers/atmodem/network-registration.c:ifx_ctzv_notify() tz +04 time 11/01/27,15:24:43 ofonod[454]: Net: \r\n+XNITZINFO: GMT+00:00,11/01/27,15:24:43\r\n\r\n+CTZDST: 1\r\n ofonod[454]: drivers/atmodem/network-registration.c:ifx_ctzdst_notify() dst 1 ofonod[454]: examples/nettime.c:example_nettime_info_received() Received a network time notification on modem: 0x83fc058 ofonod[454]: examples/nettime.c:example_nettime_info_received() Time: 2011-01-27 15:24:43-00:00 (DST=0) From the logs, it can be seen that we receive CTZV, XNITZINFO and CTZDST when the time changes. This log is taken some time back. Possible that Network Daylight Saving Time is received as part of the MM information message whereas it may not be in your case. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] atmodem: Enable network time for AT modem
Hi Aki, ofono-boun...@ofono.org wrote: Hi Jeevaka, On Tue, 2011-03-08 at 12:35 +0200, ext jeevaka.badrap...@elektrobit.com wrote: This log is taken some time back. Possible that Network Daylight Saving Time is received as part of the MM information message whereas it may not be in your case. If my memory serves, DST is optional in NITZ; only the UTC offset is mandatory content. Thats what I was referring to in my previous mail indirectly. Possible that Network Daylight Saving Time is received as part of the MM information message whereas it may not be in your case. This is due to the fact that DST is optional element. CTZDST will be reported only when the Network Daylight Saving Time is received as part of the MM information message. So, the fix seems to be correct. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] atmodem: Enable network time for AT modem
Hi Marcel, ofono-boun...@ofono.org wrote: Hi Antti, drivers/atmodem/network-registration.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 4913611..2d589f0 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -722,6 +722,8 @@ static void ifx_ctzv_notify(GAtResult *result, gpointer user_data) nd-time.mday = mday; nd-time.mon = mon; nd-time.year = 2000 + year; + +ofono_netreg_time_notify(netreg, nd-time); } static void ifx_ctzdst_notify(GAtResult *result, gpointer user_data) actually this time notification is a bad idea since you will notify twice now. With the firmware that I tested this with, it is guaranteed to always get CTZV and CTZDST and in that order. As said in the other mail, CTZDST will be reported only when the Network Daylight Saving Time information element is received as part of the MM information message. If DST information element is received, then the CTZDST will be received after the CTZV. I suppose in your case, DST information element is received with the MM information message. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] stkutil: fix issue with null data object
Hi Andrew,
ofono-boun...@ofono.org wrote:
Hi Jeevaka,
On 7 March 2011 16:35, Jeevaka Badrappan
jeevaka.badrap...@elektrobit.com wrote:
---
src/stkutil.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/stkutil.c b/src/stkutil.c index abd1c99..66b2924
100644 --- a/src/stkutil.c
+++ b/src/stkutil.c
@@ -308,7 +308,7 @@ static gboolean parse_dataobj_alpha_id(struct
comprehension_tlv_iter *iter, char *utf8;
len = comprehension_tlv_iter_get_length(iter); - if
(len == 0) { + if (len = 1) {
*alpha_id = g_try_malloc0(1);
In the description you talk about Length == 00 and no value
part but this change affects the case of Length == 1, which I
think we're handling correctly already. What is the exact problem
case?
I'm not sure but I think we already considered an identical
patch, but in the spec there's nothing special about this
case so I think the zero-length string needs to be sent to
the user like any other string.
Agree, empty string case is already covered. Just confused myself.
Patch can be ignored as this is already covered.
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC] doc: Add support for CMAS/EU-Alert
Hi Rajesh, ofono-boun...@ofono.org wrote: Hi Jeeva, Is this WarningType really required on the App side ? Irrespective of the warning type, the emergency broadcast message handling won't change on the apps side (i.e, its going to be displayed immediately to the user). This can be achieved by the old boolean variable EmergencyAlert only ? Its Popup property which is used for displaying the messages immediately to the user. EmergencyAlert Property is used to hint whether an emergency indicator(Vibration, emergency tone) should be activated. Yes, agree that the WarningType is not really required. May be it was there for some reason. This RFC patch just extends the existing EmergencyType property. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] plugin: add plugin for Linktop/Teracom LW273 data card
Hi Amit, ofono-boun...@ofono.org wrote: Hi Amit, On 02/09/2011 10:56 AM, Amit Mendapara wrote: Hi Danis, I have submitted three patches as you suggested but no one has reviewed it. Would you tell me what else I can do to ensure it's been integrated in ofono? So it looks like GMail is losing patches again. Your patches do show up on the mailing list archives but not in my mailbox. Can you resend them again, and CC my private Email as well: denk...@gmail.com. Your patches neither showed up in my GMail nor in my company outlook. Only place it can be seen is in ofono mail archives. :( Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH v3 4/4] ifxmodem: move call creation to xcallstat_notify
Hi Denis, Denis Kenzior wrote: So if you really insist on creating the call with a particular id, you might as well make that a parameter of the create_call function. However, do note that you still have one potential problem. If the ATD callback returns before the call is signaled, then oFono synthesizes an outgoing call and picks an ID for you (according to the rules I outlined). If the ID that oFono picked doesn't match the ID you have, you're in trouble. So I'm not sure if you still want to go through all this trouble or not... Yep, agreed. Atleast with ifx I can confirm that ATD callback returns before the call is signalled. I still want to have the call creation done inside the xcallstat_notify so that call creation remains in one place and also done in a place which has call id information. /* Assume the CLIP always arrives, and we signal the call there */ DBG(cring_notify); @@ -617,13 +636,16 @@ static void ccwa_notify(GAtResult *result, gpointer user_data) GAtResultIter iter; const char *num; int num_type, validity, cls; +GSList *l; struct ofono_call *call; -/* Some modems resend CCWA, ignore it the second time around */ -if (g_slist_find_custom(vd-calls, +l = g_slist_find_custom(vd-calls, Can CCWA repeat on IFX? CCWA comes only one time in IFX. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifxmodem: refactor call status notifications
Hi all, Badrappan Jeevaka wrote: --- drivers/ifxmodem/voicecall.c | 197 +++--- 1 files changed, 90 insertions(+), 107 deletions(-) Ignore this patch. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/2] Fix issue with DST
ofono-boun...@ofono.org wrote: On Tuesday 01 February 2011 13:44:03 ext Jeevaka Badrappan, you wrote: Hi, Following patch converts the DST from hours to seconds which is the expected outcome. Is it? I think DST is just a boolean. Refere 3GPP TS 24.008 section 10.5.3.12 Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 3/4] nettime: Documentation
Hi Antti, ofono-boun...@ofono.org wrote: --- doc/network-time-api.txt | 36 1 files changed, 36 insertions(+), 0 deletions(-) create mode 100644 doc/network-time-api.txt diff --git a/doc/network-time-api.txt b/doc/network-time-api.txt new file mode 100644 index 000..9133a73 --- /dev/null +++ b/doc/network-time-api.txt @@ -0,0 +1,36 @@ +Network time hierarchy +== + +Interfacecom.meego.NetworkTime +Object path [variable] + +Methods void Notify(dict info) + + Notifies the service of current time and date + as notified by the cellular network. The info + argument contains a dictionary with the + following possible keys: + + int64 UTC [optional] + Network time in seconds from epoch + normalized to device boot time. + Reveicing entity obtains current real + time by adding the value from monotonic + clock e.g. + clock_gettime(CLOCK_MONOTONIC,...). + + int32 Timezone [optional] + Current timezone offset in seconds from + UTC. + + int32 DST [optional] + Current daylight saving setting in + hours. few hours back I delivered a patch for converting the DST from hours to seconds in ofono driver code. are we going to take that into consideration? Aki?? Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 4/4] atmodem: sim-auth atom driver.
Hi Andrzej,
ofono-boun...@ofono.org wrote:
+static void at_discover_apps_cb(gboolean ok, GAtResult *result,
+ gpointer user_data) +{
+ struct cb_data *cbd = user_data;
+ GAtResultIter iter;
+ ofono_sim_list_apps_cb_t cb = cbd-cb;
+ struct ofono_error error;
+ const unsigned char *dataobj;
+ gint linelen;
+ unsigned char *buffer;
+ int len;
+
+ decode_at_error(error, g_at_result_final_response(result)); +
+ if (!ok) {
+ cb(error, NULL, 0, cbd-data);
+ return;
+ }
+
+ g_at_result_iter_init(iter, result);
+
+ len = 0;
+ while (g_at_result_iter_next(iter, +CUAD:)) {
+ if (!g_at_result_iter_next_hexstring(iter,
NULL, linelen))
+ goto error;
+
+ len += linelen;
+ }
+
+ g_at_result_iter_init(iter, result);
+
+ buffer = g_malloc(len);
+ len = 0;
+ while (g_at_result_iter_next(iter, +CUAD:)) {
+ g_at_result_iter_next_hexstring(iter,
dataobj, linelen);
+ memcpy(buffer + len, dataobj, linelen);
+ len += linelen;
+ }
missing check for buffer memory allocation failure
+
+static int at_sim_auth_probe(struct ofono_sim_auth *sa,
unsigned int vendor,
+ void *data)
+{
+ GAtChat *chat = data;
+ struct sim_auth_data *sad;
+
+ sad = g_new0(struct sim_auth_data, 1);
+ sad-chat = g_at_chat_clone(chat);
+ sad-vendor = vendor;
missing check for sad memory allocation failure
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/1] atmodem: add ifx support for pin retries query
Hi Lucas,
Lucas De Marchi wrote:
this happens to work for -1, but bear in mind memset fills
the first n bytes of the memory area. Considering
sizeof(int) == 4, it will set each byte to -1, which happens
to be -1 considering all 4 bytes too. But imo this is just
being lucky.
In my first version I had the same as you and Denis asked me
to use a for loop.
I'll use for loop instead of using memset.
+ if (cbd == NULL) {
+ CALLBACK_WITH_FAILURE(cb, NULL, data); +
return; + }
- if (cbd == NULL) {
- CALLBACK_WITH_FAILURE(cb, NULL, data); +
switch (sd-vendor) { + case OFONO_VENDOR_IFX:
+ if (g_at_chat_send(sd-chat, AT+XPINCNT, +
xpincnt_prefix, + xpincnt_cb,
cbd, g_free) 0) return;
- }
+ break;
+ case OFONO_VENDOR_HUAWEI:
if (g_at_chat_send(sd-chat, AT^CPIN?,
huawei_cpin_prefix,
huawei_cpin_cb, cbd, g_free) 0) return;
- g_free(cbd);
-
- CALLBACK_WITH_FAILURE(cb, NULL, data);
break;
-
default:
- for(i = 0; i OFONO_SIM_PASSWORD_INVALID; i++)
- retries[i] = -1;
-
- CALLBACK_WITH_SUCCESS(cb, retries, data); +
break; }
+
+ g_free(cbd);
+
+ CALLBACK_WITH_FAILURE(cb, NULL, data);
If vendor is not huawei nor ifx, why are we bothering to
allocate cbd and free it afterwards without using?
Most of the vendors provide own commands for reading the sim pin
retry count. Currently, we are handling 2vendors. If the number grows,
then we will end up in having allocation code for each case. If its not
going to be the case, then I can move the code inside each case.
This also changes the semantics to return a failure if it's
not implemented. I'm not against since this version seems to
be clearer.
However you might want to change src/sim.c:sim_pin_retries_query_cb()
so it doesn't call ofono_error() in this case.
If its not implemented, then we should term it as error. I don't see
any change needed in the current src/sim.c:sim_pin_retries_query_cb() code.
Regards,
jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC 2/4] stk: Handle Launch Browser proactive command
Hi, So a question about this. Why are we checking the netreg atom? Shouldn't we be checking the gprs atom's attached property? But this brings up an even more interesting question, do we even need to assume that we have to be attached to the cellular network to perform these operations? We could in theory go over wifi. I agree that the modem online property is unrelated to this. Also the card may in theory specify a URL that designates a local file or something on a local network, not the internet. Agree. It can be anything not only cellular network. Do we need to check the bearer parameters in that case or can I just remove the current check code? Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH v3 2/2] plugins: add ctm create to ifx plugin
Hi Marcel, ofono-boun...@ofono.org wrote: Hi Jeevaka, plugins/ifx.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/plugins/ifx.c b/plugins/ifx.c index c0a69c2..08b0001 100644 --- a/plugins/ifx.c +++ b/plugins/ifx.c @@ -57,6 +57,7 @@ #include ofono/radio-settings.h #include ofono/audio-settings.h #include ofono/stk.h +#include ofono/ctm.h #include ofono/log.h #include drivers/atmodem/atutil.h @@ -700,6 +701,7 @@ static void ifx_post_sim(struct ofono_modem *modem) DBG(%p, modem); +ofono_ctm_create(modem, 0, ifxmodem, data-dlcs[AUX_DLC]); so no emergency calls with CTM are possible? Or do we have to potentially also handle that? Emergency calls are possible. I'll move the ctm_create to pre_sim state. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] ifxmodem: add enable/disable ctm support
Hi Marcel,
ofono-boun...@ofono.org wrote:
+static void xctms_modify_cb(gboolean ok, GAtResult *result,
gpointer +user_data) { + struct cb_data *cbd = user_data;
+ofono_ctm_set_cb_t cb = cbd-cb;
+struct ofono_error error;
+const char *setting = NULL;
+struct ofono_ctm *ctm = cbd-user;
+struct ctm_data *ctmd = ofono_ctm_get_data(ctm);
+ofono_bool_t enable = ctmd-enable;
+
+decode_at_error(error, g_at_result_final_response(result)); +
+if (!ok) {
+cb(error, cbd-data);
+return;
+}
+
+if (g_strcmp0(ctmd-audio_setting, FULL_DUPLEX) == 0) +
setting
= 0,0,0,0,0,0,0; + else if (g_strcmp0(ctmd-audio_setting,
BURSTMODE_48KHZ) == 0) + setting = 0,0,8,0,2,0,0; +
else if
(g_strcmp0(ctmd-audio_setting, BURSTMODE_96KHZ) == 0) +
setting
= 0,0,9,0,2,0,0; + + if (setting) {
+char xdrv_buf[64];
+
+/* configure source */
+snprintf(xdrv_buf, sizeof(xdrv_buf),
AT+XDRV=40,4,%d,%d,%s,%s,
+4, +
0,
+setting,
+enable ? 2,5 : 0,0);
+g_at_chat_send(ctmd-chat, xdrv_buf, xdrv_prefix, NULL,
NULL,
+NULL); +
+/* configure destination */
+snprintf(xdrv_buf, sizeof(xdrv_buf),
AT+XDRV=40,5,%d,%d,%s,%s,
+3, +
0,
+setting,
+enable ? 2,6 : 0,0);
+
+g_at_chat_send(ctmd-chat, xdrv_buf, xdrv_prefix, NULL,
NULL,
+NULL); +}
Now this is something I don't like at all. It is copied code from the
modem plugin.
Its the same audio configuration code except that there is a new
parameter added
at the end of the parameter list for TTY case.
The initial discussion was that we need to configure XDRV
only once during init and never have to touch it again. That
seems to be not true anymore. So what is the deal here?
Audio source/destination parameter includes configuration and transducer
mode
TRANSDUCER is the difference. Incase of voice call it is set to
default(0) whereas
for TTY call it is set to TRANSDUCER TTY( 5 for source and 6 for
destination).
TTY call - Last 2 parameters are 2,5 and 2,6 for the source(uplink) and
destination(downlink) respectively.
Voice call - Last 2 parameters are 0,0.
Also if this is required, we might need to figure out a
complete different way of handling this. We can't have this
in two places since that means a full disconnect. Maybe
putting this into the audio settings atom might be better.
However before we can do anything, I have to understand the
semantics behind XDRV, normal voice calls and TTY calls.
Correct me if I'm wrong. If we move this to the audio settings atom,
then I'm
afraid that it will end up in used by only ifx modem.
We wanna be consistent, so pleace do ifx_ctm_init(void) here.
+ofono_ctm_driver_register(driver);
+}
+
+void ifx_ctm_exit()
+{
Same here. And for extra bonus points, I accept patches that
fixes this inside the whole oFono tree ;)
It is coding style rule M15 now.
Separate set of patches sent for the M15 coding style rule fix for the
whole oFono tree.
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api
Hi Marcel, ofono-boun...@ofono.org wrote: Main reason for separate notification function is to avoid going through all the cases handled inside voicecall_notify. TTY field in ofono_call is basically for the GetProperties. I see. So here is the main question that comes from this now. This seems to be a bit IFX specific driven API. I still have no idea why they can not just indicate this via +CRING and have to use CTM CALL for it. Are we expecting that all modems will just establish a normal voice call and only later on signal that it is a TTY call? Any input from different vendors other than IFX. What about STE, ISI? This notification is to inform the ME that the call is accepted as a TTY call on the remote side. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/7] call-forwarding: Read/Write cfis/cphs-cff
Hi Denis, + ofono_bool_t online; Why do you need to track this variable? Can't you simply call ofono_modem_get_online()? This way calling of ofono_modem_get_online for each get or set request can be avoided. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] stkutil: fix crash issue cause by null length of text string
Hi Guillaume, According to 3GPP TS 31.124 a null length for the text string should be allowed. An empty string must be returned to the user in this case. --- src/stkutil.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) Agree. As per the 3GPP TS 31.124 null text string will be indicated with length 0. So, in first place if (text == NULL) check in handle_command_get_input, handle_command_get_inkey has to be removed. Removing this check will result in crash due to the fact that we are not handling this case properly neither in parse_dataobj_text nor in corresponding stkagent functions. There are 2ways to solve this issue: First option - Fix provided in the function parse_dataobj_text( e.g. *text = ) Second option - In all the stk_agent_ function which has this text string we need to check for NULL and assign it to empty string if it is NULL. First option seems to be right and also better one. In both the cases, if (text == NULL) check in handle_command_get_inkey, handle_command_get_input etc needs to be removed. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 4/4] TODO: Marking the Barred Dialing task as done
Hi Sankar, Then as per your email, the support provided in Ofono seems to be limited. If there is no enable or disable is allowed, I am not sure, how we can we have a card in which FDN enabled, which will force the ofono to enter presim state. Unless there is no option to disable at, forever with that sim card, the phone will be in presim state,leading to only placing of emergency calls. Support for disabling FDN was discussed earlier. Denis/Pessi could you confirm what was the decision made on FDN disable support? Thanks for confirming. Then in this case, are we not forcing the mobile to go in a state, where if FDN is already enabled in the sim card( may be from a different phone), user allowed with no option rather than making an emergency call. Yes, we are forcing the mobile into presim state where only emergency calls are allowed. We have already discussed this many times in irc and its been agreed that only emergency calls are allowed when FDN or BDN enabled SIM used. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] stk: Add busy error for the display text command
Hi Guillaume, Denis on IRC also wondered if this response should be allowed when the message is flagged urgent. According to the spec I think no, this type of response is not allowed when the message is fluffed urgent. As per the ETSI TS 102 223 V9.0.0 section 6.4.1, screen is busy applies to high priority text as well. If urgent refers to higher priority text which is the case, then I think screen busy is possible. Find below the information from specification. High priority text shall be displayed on the screen immediately, except if there is a conflict of priority level of alerting such as incoming calls or a low battery warning. In that situation, the resolution is left to the terminal. If the command is rejected in spite of the high priority, the terminal shall inform the UICC using TERMINAL RESPONSE (terminal currently unable to process command - screen is busy). Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 3/3] stk: Handle provide local info proactive command
Hi Yang,
+static void get_time(struct stk_response *rsp) {
+ time_t now;
+ struct tm *t;
+
+ time(now);
+ t = localtime(now);
+
+ rsp-result.type = STK_RESULT_TYPE_SUCCESS;
+
+ if (t-tm_year 100)
+ rsp-provide_local_info.datetime.year =
t-tm_year - 100;
+ else
+ rsp-provide_local_info.datetime.year = t-tm_year;
+
Incase of error, localtime shall return a null pointer. I think its
better to add the NULL check.
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC 7/7] doc: Add new property to call forwarding
Hi Sankar, As per the specification, querying of group of supplementary services is not allowed. Do you propose a solution where core queries all the three call forwardings namely CF busy, CF Not Reachable, CF noreply and updating the clients with the status using the above property after receiving the status for all the three? Query logic is already taken care in the oFono core. Check the get_query_next_cf_cond function in src/call-forwarding.c. VoiceUnconditionalStatus property is only about the VoiceUnconditional call forwarding rule. VoiceUnconditional status can be also known from the sim files EFcfis and EFcphs-cff(Note: Files are optional). This patch reads the SIM files(if present) and updates the status. Patch also takes care of updating the sim files when the user activates VoiceUnconditional call forwarding rule. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/2] stk: provide access technology info
Hi Yang,
+
+unsigned int __ofono_netreg_get_tech(struct ofono_netreg *netreg) {
+ GSList *o;
+ unsigned int techs = 0;
+ struct network_operator_data *opd;
+
+ for (o = netreg-operator_list; o; o = o-next) {
+ opd = o-data;
+ techs |= opd-techs;
+ }
+
+ return techs;
+}
Is this function intended to get the current access technology?
As per the ETSI TS 102 223 specification 4.12 section, when the SAT
issues Provide Local Information proactive command with Access
Technology(0x06) as the command qualifier, we should provide the current
access technology . So, as per my understanding we need to use
netreg-technology.
void __ofono_netreg_set_base_station_name(struct ofono_netreg *netreg,
const char *name);
+unsigned int __ofono_netreg_get_tech(struct ofono_netreg *netreg);
Empty line needed between __ofono_netreg_set_base_station_name and
__ofono_netreg_get_tech
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Identification of Active Application in UICC card
Hi, According to 3GPP specification 3GPP TS 31.102 section 5.1.1 USIM application selection, After UICC activation, the ME selects a USIM application. If no EFDIR file is found or no USIM applications are listed in the EFDIR file, the ME may then try to select the GSM application as specified in TS 51.011. If EFdir is present and if AID present is matching with the USIM AID(RID = A00087, Application Code = 1002), then the selected/active application is 3G USIM. If EFdir is not present or the AID present is matching with the SIM AID(RID = A9, ETSI application code = 0001), then the selected/active application is GSM. Information on the AID and RID can be found in the specification 3GPP TS 31.110. RID - Registered application provider identifier AID - Application Identifier Since almost all the cards nowdays are UICC cards and EFdir is also a mandatory file, can we rely on the EFdir to confirm the active application? This way, we can avoid reading of files which are not present in the active application and also we can avoid issuing of multiple read requests for the same file(eg: EFecc) Thanks and Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Handling of Fixed Dialing
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 1/4] sim: check if FD is enabled in the SIM-card
Hi Petteri,
+static void at_barring_query_enabled(struct ofono_sim *sim,
+ ofono_sim_locked_cb_t cb, void *data) {
+ struct sim_data *sd = ofono_sim_get_data(sim);
+ struct cb_data *cbd = cb_data_new(cb, data);
+ char buf[64];
+
+ if (!cbd)
+ goto error;
+
+ snprintf(buf, sizeof(buf), AT+CLCK=\FD\,2);
+
+ if (g_at_chat_send(sd-chat, buf, clck_prefix,
+ at_lock_status_cb, cbd, g_free) 0)
+ return;
+
+error:
+ g_free(cbd);
+
+ CALLBACK_WITH_FAILURE(cb, -1, data);
+}
+
static gboolean at_sim_register(gpointer user) {
struct ofono_sim *sim = user;
@@ -898,6 +920,7 @@ static struct ofono_sim_driver driver = {
.lock = at_pin_enable,
.change_passwd = at_change_passwd,
.query_locked = at_pin_query_enabled,
+ .query_call_barred = at_barring_query_enabled,
};
@@ -156,6 +157,8 @@ struct ofono_sim_driver {
void (*query_locked)(struct ofono_sim *sim,
enum ofono_sim_password_type type,
ofono_sim_locked_cb_t cb, void *data);
+ void (*query_call_barred)(struct ofono_sim *sim,
+ ofono_sim_locked_cb_t cb, void *data);
};
+static void sim_call_barred_query_cb(const struct ofono_error *error,
+ int locked,
+ gpointer data)
+{
+ struct ofono_sim *sim = data;
+
+ if (error-type != OFONO_ERROR_TYPE_NO_ERROR || locked) {
+
+ ofono_error(Fixed Dialing is enabled, emergency calls
only);
+ sim_set_not_ready(sim);
+ }
+}
+
+static void sim_call_barring_check(struct ofono_sim *sim) {
+ if (!sim-driver-query_call_barred)
+ return;
+
+ sim-driver-query_call_barred(sim, sim_call_barred_query_cb,
sim); }
+
Function names are misleading(eg: query_call_barred,
sim_call_barring_check). Is it better to use the function name like
query_fdn_status??
Regards,
jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] phonesim: simulate Send USSD in sim app
Hi Denis, Marcel, what was wrong with the clear indication that this patch is messed up. This patch comes from a stupid Windows system that tries to change every single mode to 0755. Please fix this. Whoops, my fault totally missed this. I wonder if there are git settings that can warn about this... Sorry for this mess. I'll make sure this doesn't happen again. Thanks and Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 5/5] cf: Handle send ss proactive command
Hi Yang, --- a/src/stk.c +++ b/src/stk.c + unsigned char addnl[2]; + + default: + DBG(Send ss finishes with error type: %d, error-type); + rsp.result.type = STK_RESULT_TYPE_SS_RETURN_ERROR; + addnl[0] = (unsigned char) error-error; + addnl[1] = STK_RESULT_ADDNL_SS_PB_NO_SPECIFIC_CAUSE; + rsp.result.additional = addnl; + rsp.result.additional_len = 2; + break; + } + Isn't the above code, has to be something like unsigned char addnl; default: rsp.result.type = STK_RESULT_TYPE_SS_RETURN_ERROR; addnl = STK_RESULT_ADDNL_SS_PB_NO_SPECIFIC_CAUSE; rsp.result.additional = addnl; rsp.result.additional_len = 1; Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Reg: Memory capacity exceeded
Hi, Of course, one can argue whether this feature really has some real world relevance or is purely theoretical. I wonder if it is a type approval requirement to support? I'm afraid there is a PICS case for this thing. I cannot recall how we got N900 through this particular hoop, but probably we just waived this particular test case irrelevant. correct. There is a USIM conformance case on this message capacitiy exceeded information. As per the 3GPP 31.121 specification section 8.2: If all SMS data field are full and furthermore all memory capacity reserved for SMS inside the ME is filled up to maximum and a SM(Short Message) was rejected, then this shall be indicated in the SMS Status file.(EFsmss) For more information on this, refer 3GPP TS 31.121 section 8.2 There is also test cases related to SMS read from USIM. Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/1] stk: Handle send ss proactive command
Hi Yang, Below is the description: This patch is to handle send ss proactive command from SIM. Currently when sending a supplementary service control string via D-Bus, a series of functions would be called. For example, if we want to send a call barring activatioin string via D-Bus, these functions would be called: ussd_initiate()-recognized_control_string()-cb_ss_control()-cb_ss_set _lock_callback()-cb_ss_query_next_lock()-cb_ss_query_next_lock_callbac k(). To handle send ss command from SIM needs to follow the same way as D-Bus, so my target is to try the best to reuse these functions. However, currently these functions take the assumption that the calling is from D-Bus. My solution is to introduce a data structure named ofono_ss_req to replace original DBusMessage * parameter. Other main changes are to unify the return code of these functions and handle them centrally. Comments are welcome! Following the same control flow as normal case, requires rewriting some of the existing functions to deal with both the cases like what you have done now. Isn't it better to keep it separate? So that we won't end up in introducing SAT specific handling in the normal use case also. Proposed solution: SS(eg: call forwarding, call barring) registers to the USSD by calling __ofono_ussd_ssc_register with the service code, call back function(normal_callback) and few other parameters. SS can also register to the STK by calling __ofono_ussd_ssc_register with the service code, call back function(stk_callback). normal_callback and stk_callback can handle normal and stk use case respectively. More generic handling can be moved to a separate function which normal_callback and stk_callback functions can make use of. Also parsing/matching of the service strings can be moved to utility. STK, USSD or anyother atoms can make use of the parsing/matching(of service string) utility function. Let me know your views on this. Thanks and Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/2] Internal and Driver API changes for Send USSD proactive command
Hi Denis,
- else if (charset == SMS_CHARSET_8BIT) {
- /* TODO: Figure out what to do with 8 bit data */
+ if (charset == SMS_CHARSET_7BIT) {
+ switch (data-charset) {
+ case AT_UTIL_CHARSET_GSM:
+ msg = convert_gsm_to_utf8((const guint8 *)
content,
+ strlen(content), NULL, msg_len,
0);
+ break;
+ case AT_UTIL_CHARSET_PCCP437:
+ case AT_UTIL_CHARSET_PCDN:
+ case AT_UTIL_CHARSET_8859_1:
+ case AT_UTIL_CHARSET_IRA:
+ default:
+ DBG(charset:%d not supported, data-charset);
+ status = 4; /* Not supported */
+ }
+ } else if (charset == SMS_CHARSET_8BIT) {
+ /* MT/TA converts each 8 bit octet into two IRA
character
+ * long hexadecimal number (e.g. octet with integer value
42
+ * is presented to TE as two characters 2A (IRA 50 and
65))
+ */
ofono_error(8-bit coded USSD response received);
status = 4; /* Not supported */
If we're not handling 8BIT USSDs, what exactly is the point of this
exercise?
Based on the dcs received from network and TE character set chosen,
modem converts the received ussd response string.
DCS_from_networkTE_char_set
Conversion done by Modem
GSM 7-bit default
PCCP437 GSM 7-bit
default alphabet to PCCP437
PCDNGSM
7-bit default alphabet to PCDN
ISO8859-1 GSM
7-bit default alphabet to 8859-1
IRA GSM
7-bit default alphabet to IRA
GSM 7-bit None
8-bit - In this case, modem doesn't relay on the chosen TE
character set. Modem converts each 8-bit octet into
two IRA character long hexadecimal number
I left the 8-bit USSD case unhandled, as I didn't find the conversion
function for converting the IRA to the 8-bit data.
Also 3GPP TS Specification, doesn't have any information on what needs
to be done if the dcs received is UCS2.
- g_free(converted);
+ ofono_ussd_notify(ussd, status, -1, (const guint8 *) msg, (int)
+msg_len);
Err, why are we passing UTF8 text as binary data + len? I'm lost.
You either do UTF8 always, or full binary always.
- converted = convert_utf8_to_gsm(str, strlen(str), NULL,
written, 0);
+ if (dcs == -1) {
+ converted = convert_utf8_to_gsm((const char *) str,
str_len, NULL,
+written, 0);
Get rid of this. The core either passes a raw USSD data or UTF8.
There's no mix and match here.
As you know, USSD string coming via dbus interface will be in UTF8
format. Whereas, USSD string
coming from the USAT will be in binary data + len.
Do you mean to say that the core will convert the UTF-8 USSD string
coming from the user(dbus interface) into GSM 8-bit and send it to the
driver side?
- if (written max_len)
- goto error;
+ /* As per 3GPP TS 23.038, When this character set is
used,
+ * the characters of the message are packed in octets as
shown in section 6.1.2.1.1,
+ * and the message can consist of up to 160 characters.
+ */
+ pack_7bit_own_buf(converted, written, 0, TRUE,
+ num_packed, 0, coded_str);
CUSD does not take packed GSM data, so I'm lost here
As you know, when a message is coded in 7-bit default alphabet, the
message can then consists of upto 182 user charcters.
I just packed it so that the maximum message length will be 160
characters for all the cases. Do you mean, CUSD won't take packed GSM
data?
enum sms_charset {
- SMS_CHARSET_7BIT = 0,
- SMS_CHARSET_8BIT = 1,
- SMS_CHARSET_UCS2 = 2,
+ SMS_CHARSET_7BIT = 0x00,
+ SMS_CHARSET_8BIT = 0x04,
+ SMS_CHARSET_UCS2 = 0x08,
Please don't mess with this enum, the USSD DCS has nothing to do with
SMS.
I agree the SMS dcs is different from the CBS dcs. But this enumeration
is just used within ofono for knowing the coding scheme used.
Currently, we are using this enumeration in SMS, CBS and USSD as well. I
have just changed the values so that it matches with the USAT
values. Since, this enumeration is used to just determine the character
sets, I didn't find any valid reason why we have to introduce a
new enumeration just with the USAT specific values.
Thanks and Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: Patch: Added missing DCS handling in stkutil and stk Description
Hi Denis, Andrzej, Actually the spec is deviating from the intended purpose of the Text data object (which should contain Text), so handling it specifically is actually better. I have incorported the comments as part of the Patch stk and stkutil changes for Send USSD proactive command. As per your comments, I have also grouped the Send USSD proactive command into 2 compilable patches [PATCH 1/2] Internal and Driver API changes for Send USSD proactive command and [PATCH 2/2] stk and stkutil changes for Send USSD proactive command. Thanks and Regards, Jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] stk and stkutil changes for Send USSD proactivecommand
Hi Andrew,
What is the meaning of that -1? I don't see this value handled in
stkutil.
If dcs is -1, then the text is assumed to be in UTF-8. Will add the
-1 handling in stkutil.h
The rest of this patch looks okay to me, but you have some formatting
issues: space after '(' above, and the first hunk removes empty lines.
Other than that I think Denis might want you to split this patch into
stk patch and stkutil patch
With regards to 1/2 he'll probably want one patch for atmodem, one for
isimodem, one for include, one for plugin, etc. Also I think it's fair
to assume that the charset is IRA and there's not need to account for
other possibilities, but other might have different opinions. And I'm
not sure if the enum sms_charset values change should be
global, or translation should be done here in stk.c.
Since the USSD driver API is changed, its not possible to split the 1st
patch into one for atmodem, one for isimodem, one for include. Changes
in plugin and atutil can be delivered as a separate patch.
Thanks and Regards,
jeevaka
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH 02/11] Changes done as per the changed driver API
Hi Pekka, I thought the modem already unpacks the ussd message to 8-bit gsm and the dcs parameter is rather meaningless in that case. Perhaps the atmodem ussd should re-pack the string in order to achieve the desired symmetry on the API? Agree that the modem already unpacks the string received from the network to the character set set by TE(UCS2 or UTF-8 or ...). Atom driver will do the conversion to UTF-8 based on active character set supported by modem, so it should have information of the active character set. At present, we read and set the character set in the phonebook atom driver. USSD atom driver could to do the same or the reading/setting of character set can be done during the modem initialisation (eg: atgen.c). I would prefer to have the reading and setting of character set during the modem initialisation. I hope the character set is not set by some other component apart from ofono :-) Regards, jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Patch: Added missing DCS handling in stkutil and stk Description
Hi, The following patch Added missing DCS handling in stkutil and stk handles the missing dcs case as: As per 3GPP TS 31.111 section 8.15 Text string structure requires dcs and text string to be sent. Current stkutil function and data structure is missing the dcs information. In this patch, we handle the case where dcs will be a value other than -1, yesno and packed values are false. This text string structure is used in Terminal response of Get Inkey, Get Input and Send USSD. Regards, jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Denis, Can you send what you have so far to the list? Andrew and Yang are actually already looking into this, so it might be nice for the three of you to be on the same page and not duplicate effort. I'm sending the patches for the Send USSD proactive command handling. I have tested the changes with the modified phonesim. Let me know if you need the modified phonesim files. Thanks and Regards, Jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Marcel,
Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver
- AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet
and sends it to the network. In this way, we will always send the data
coding scheme as GSM 7-bit default alphabet or whatever the character
set modem is configured. Why are we not sending the USSD string with
DCS(Data coding scheme) as is to the network? There are USIM
conformance test cases which expects the DCS(Data coding scheme) and
USSD string sent as it is to the network. Also, as per the 3GPP TS
24.090, DCS and USSD string are sent as part of UnstructuredSS-Request
to the network and MT is not expected to interpret the string.
But ,here oFono doesn't have the interface to accept DCS(Data coding
scheme) and also it expects the USSD string to be in UTF-8.
the one main design goal behind oFono's D-Bus APIs is to make them
useful for users. This means that the main input data type are strings
and they are UTF-8.
If you need magic binary APIs that are only used by specific
application or even purely for conformance testing, then you need to
propose an interface for these. By default we will not make application
to any kind of conversation.
Every single nasty conversion that has to be done by every single
application using such an interface is wrong. Complexity belongs into
oFono and not the application. The idea of just pushing complex
tasks up into the application so that oFono doesn't have to deal with
it is a really bad idea. Remember that one main goal of oFono is to make
the usage of standard telephony functionality as easy as
possible when you are developing telephony applications.
I'm not proposing any changes to the dbus interface and I completely
understand that its a very bad idea to push the conversions to the
application side. USAT conformance specification expects that the
information sent by the application toolkit to be sent as it is to the
network. Conformance test setup is such that if the data received at the
network doesn't match with the data sent by the application toolkit then
the conformance test case is considered to be a failure case.
When a Send USSD proactive command is received, STK atom sends an
internal request to the USSD atom to send the string along with the DCS
supplied. So, for sending the USSD string and dcs received from the
proactive command, support needs to be added to the USSD driver
interface.
What I meant was to provide a driver API which will take both the dcs
and string as parameter. something like the following:
enum ofono_dcs{
OFONO_DCS_UNKNOWN,
OFONO_DCS_GSM_7BIT,
OFONO_DCS_8BIT,
OFONO_DCS_UCS2,
};
void (*request)(struct ofono_ussd *ussd, int dcs, const char *str,
ofono_ussd_cb_t, void *data);
If the dcs is set to OFONO_DCS_UNKNOWN, then the conversion from UTF-8
to GSM 7 bit default alphabet needs to be done. Anything other than
OFONO_DCS_UNKNOWN, modem driver doesn't need to do any conversion and
sends the dcs and string as it is to the network.
Regards,
jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Marcel you have me confused now. Are you talking about the D-Bus based API towards applications or the SIM Toolkit support? SIM Toolkit is something totally different. Even for SMS we just deal with raw PDUs there. While the user side applications over D-Bus will never get access to the raw PDUs. I think I was not clear in my first mail:-). I'm talking about the driver API( Modifications to the ofono_ussd_driver:request). No changes to the D-Bus interface based API towards applications. Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi, Yes, the driver api may need a change like this. The current API was created based on the fact that many modems don't understand anything other than DCS = 15. However with STK's Send USSD command, sending the requested DCS as-is is probably our best bet. There is a hope that most modems implement Send USSD in their firmware so that ofono doesn't have to do anything (this is the case on the Texas Instruments Calypso modem), do you have a modem that you know does not handle Send USSD internally? Of course it makes sense to implement the fallback in ofono anyway. Have you been working on implementation of this command? I'm asking to avoid duplicating the effort. No, I dont have any modem which doesn't handle the Send USSD command internally. Yes, I have done some implementation. Planning to test it with the phonesim. If needed, I can do the implementation of the Send USSD command. Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi Denis, The original USSD API actually did look like this. It used binary data + dcs field. However, we quickly found that all modems are screwed up in this area. The specification added binary PDU mode to SMS and CBS, but never bothered with USSD. So all modems get this part wrong. Currently about the best we can do is pass UTF8 around. If you have a modem that gets this part right, we'd like to hear about it. If the Send USSD proactive command is not handled by the modem, then oFono will try to do its best. However, we make no guarantees ;) I think its better to send the dcs and the binary data to the atom driver. If the modem doesn't support other than GSM 7-bit alphabet, then the conversion can be done in the atom driver. This way it will be general to any modem. Let me know your views on this. Regards, jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
Hi, Can you send what you have so far to the list? Andrew and Yang are actually already looking into this, so it might be nice for the three of you to be on the same page and not duplicate effort. Ok, I'll try to send the patch by today. Thanks and Regards, Jeevaka Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] sim: Ensure to call sim_pin_check
Hi Yang Gu,
In current code, sim_pin_check() is called inside sim_efpl_read_cb().
However, there may be a chance it would never be called, thus the
modem won't be initialized correctly.
---
src/sim.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index a450b30..9bc9906 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -1380,8 +1380,6 @@ skip_efpl:
PreferredLanguages,
DBUS_TYPE_STRING,
sim-language_prefs);
-
- sim_pin_check(sim);
}
static void sim_iccid_read_cb(int ok, int length, int record, @@
-1454,6 +1452,8 @@ static void sim_initialize(struct ofono_sim *sim)
ofono_sim_read(sim, SIM_EFPL_FILEID,
OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
sim_efpl_read_cb, sim);
+
+ sim_pin_check(sim);
}
static void sim_op_error(struct ofono_sim *sim)
--
1.7.0.4
As per the 3GPP 31.102 section 5.1.1.2, CHV1 verification procedure will
be done after reading of EFli and EFpl. Earlier( before sim: Reorder
SIM initialization patch) src/sim.c had the sim_pin_check()called from
sim_efphase_read_cb() where it called after issuing EFli and EFpl file
read request. The patch sim: Reorder SIM initialization changed it to
call from sim_efpl_read_cb() which is as per the specification.If the
reading of EFli and EFpl fails, then sim_pin_check is not getting called
because we are returning from if (sim-language_prefs == NULL). In
your patch, you are moving it to be called after the EFpl read request
which is same as what we had before sim: Reorder SIM initialization
patch. I believe the right place to call the sim_pin_check() will be
before the if condition(if (sim-language_prefs == NULL)) in
sim_efpl_read_cb(), like shown below
if (efpl) {
g_slist_foreach(efpl, (GFunc)g_free, NULL);
g_slist_free(efpl);
}
sim_pin_check(sim);
if (sim-language_prefs == NULL)
return;
ofono_dbus_signal_array_property_changed(conn, path,
OFONO_SIM_MANAGER_INTERFACE,
PreferredLanguages,
DBUS_TYPE_STRING,
sim-language_prefs);
Let me know your views on this.
Thanks and Regards,
jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
