Re: [PATCH] unit: Add unit test for stemodem driver
Hi Marcel, On Mon, 2011-03-14 at 18:35 +0200, Marcel Holtmann wrote: Hi Lass,e Here is an updated version of STE unit test, originally done by Marit (sent on 15th of Feb). This one should apply smoothly one question ahead of time. Are you guys up to the task to maintain this unit test? Since it is clearly out of the scope of Denis and I to make sure it will never break. Probably STE would take care of breaks caused by changes in the driver. If the unit tests break someday due to changes in Core, you could drop out the code. I am not in a position to declare any commitment, so cannot promise we are going to maintain these unit tests. BR, -Lasse Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] unit: Add unit test for stemodem driver
From: Marit Henriksen marit.henrik...@stericsson.com
---
Hi,
Here is an updated version of STE unit test, originally done by Marit (sent on
15th of Feb).
This one should apply smoothly
BR,
Lasse
Makefile.am | 17 +-
unit/test-ste.c | 1165 +++
2 files changed, 1181 insertions(+), 1 deletions(-)
create mode 100644 unit/test-ste.c
diff --git a/Makefile.am b/Makefile.am
index a784636..65a5e67 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -515,7 +515,7 @@ dist_man_MANS = doc/ofonod.8
noinst_PROGRAMS = unit/test-common unit/test-util unit/test-idmap \
unit/test-sms unit/test-simutil \
unit/test-mux unit/test-caif \
- unit/test-stkutil
+ unit/test-stkutil unit/test-ste
unit_objects =
@@ -556,6 +556,21 @@ unit_test_caif_SOURCES = unit/test-caif.c
$(gatchat_sources) \
unit_test_caif_LDADD = @GLIB_LIBS@
unit_objects += $(unit_test_caif_OBJECTS)
+unit_test_ste_SOURCES = unit/test-ste.c $(gatchat_sources) \
+ $(gdbus_sources) $(local_headers) \
+ src/common.c src/util.c \
+ drivers/stemodem/stemodem.h \
+ drivers/atmodem/atutil.h \
+ drivers/atmodem/atutil.c \
+ drivers/stemodem/radio-settings.c \
+ drivers/stemodem/gprs-context.c \
+ drivers/stemodem/voicecall.c \
+ drivers/stemodem/caif_socket.h \
+ drivers/stemodem/if_caif.h
+
+unit_test_ste_LDADD = @GLIB_LIBS@ @DBUS_LIBS@
+unit_objects += $(unit_test_ste_OBJECTS)
+
if TOOLS
noinst_PROGRAMS += tools/huawei-audio tools/auto-enable tools/get-location
diff --git a/unit/test-ste.c b/unit/test-ste.c
new file mode 100644
index 000..20434b4
--- /dev/null
+++ b/unit/test-ste.c
@@ -0,0 +1,1165 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2011 ST-Ericsson AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+#include unistd.h
+#include stdio.h
+#include string.h
+#include sys/socket.h
+#include glib.h
+#include gatchat.h
+#include gatresult.h
+#include log.h
+#include ofono/modem.h
+#include ofono/voicecall.h
+#include ofono/radio-settings.h
+#include ofono/gprs-context.h
+#include drivers/stemodem/stemodem.h
+#include drivers/stemodem/caif_rtnl.h
+#include common.h
+
+/* Generic test code decls */
+static GAtChat *chat;
+static GMainLoop *event_loop;
+static int phone_fd;
+
+#define ASSERT_AT(s) g_assert(assert_at(s));
+#define QUERY_RAT()\
+ do {\
+ radio_settings_driver- \
+ query_rat_mode(0, \
+ (ofono_radio_settings_rat_mode_query_cb_t)\
+ radio_rat_mode_query_callback, 0); \
+ ASSERT_AT(AT+CFUN?); \
+ } while (0)
+
+/* Send a simulated AT response */
+static void at_response(char *resp)
+{
+ int r;
+
+ /*
+* Send AT response to g_at_chat and give main look a kick to run
+* one iteration.
+*/
+ r = write(phone_fd, resp, strlen(resp));
+ g_assert(r 0);
+ (void)g_main_context_iteration(NULL, TRUE);
+}
+
+static gboolean assert_at(char *match)
+{
+ char req[256];
+ int r;
+
+ if (g_main_context_iteration(NULL, TRUE) == TRUE) {
+
+ /* Read what g_at_chan has written to modem */
+ r = read(phone_fd, req, sizeof(req));
+
+ if (r 1)
+ req[r-1] = 0;
+
+ if (strcmp(match, req) == 0)
+ return TRUE;
+ }
+
+ g_print(AT request did not match:%s != %s\n, match, req);
+ return FALSE;
+}
+
+/* Stubs from src/voicecall.c */
+struct ofono_voicecall;
+const struct
[PATCH v2] ste: Add support for multiple AT channels
---
Hi,
Updated according to valuable comments from Denis.
BR,
Lasse
plugins/ste.c | 145 -
1 files changed, 92 insertions(+), 53 deletions(-)
diff --git a/plugins/ste.c b/plugins/ste.c
index b786571..488a3e2 100644
--- a/plugins/ste.c
+++ b/plugins/ste.c
@@ -65,13 +65,20 @@
#include drivers/stemodem/caif_socket.h
#include drivers/stemodem/if_caif.h
-#define NUM_CHAT 1
+#define NUM_CHAT 5
+#define AT_DEFAULT 0
+#define AT_NET 1
+#define AT_VOICE 2
+#define AT_GPRS3
+#define AT_SIM 4
+
#define MAX_PDP_CONTEXTS 4
-static char *chat_prefixes[NUM_CHAT] = { Default: };
+static char *chat_prefixes[NUM_CHAT] = { Default: , Net: , Voice: ,
+ GPRS: , SIM: };
struct ste_data {
- GAtChat *chat;
+ GAtChat *chat[NUM_CHAT];
gboolean have_sim;
struct ofono_sim *sim;
};
@@ -105,12 +112,14 @@ static int ste_probe(struct ofono_modem *modem)
static void ste_remove(struct ofono_modem *modem)
{
struct ste_data *data = ofono_modem_get_data(modem);
+ int i;
DBG(%p, modem);
ofono_modem_set_data(modem, NULL);
- g_at_chat_unref(data-chat);
+ for (i = 0; i NUM_CHAT; i++)
+ g_at_chat_unref(data-chat[i]);
g_free(data);
}
@@ -185,7 +194,7 @@ static gboolean init_sim_reporting(gpointer user_data)
struct ofono_modem *modem = user_data;
struct ste_data *data = ofono_modem_get_data(modem);
- g_at_chat_send(data-chat, AT*ESIMSR=1;*ESIMSR?, NULL,
+ g_at_chat_send(data-chat[AT_SIM], AT*ESIMSR=1;*ESIMSR?, NULL,
handle_sim_state,
modem, NULL);
@@ -195,11 +204,21 @@ static gboolean init_sim_reporting(gpointer user_data)
static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
{
struct ofono_modem *modem = user_data;
+ struct ste_data *data = ofono_modem_get_data(modem);
+ int i;
DBG();
if (!ok) {
ofono_modem_set_powered(modem, FALSE);
+
+ for (i = 0; i NUM_CHAT; i++) {
+ g_at_chat_cancel_all(data-chat[i]);
+ g_at_chat_unregister_all(data-chat[i]);
+ g_at_chat_unref(data-chat[i]);
+ data-chat[i] = NULL;
+ }
+
return;
}
@@ -297,47 +316,64 @@ static int ste_enable(struct ofono_modem *modem)
struct ste_data *data = ofono_modem_get_data(modem);
GIOChannel *channel;
GAtSyntax *syntax;
+ int i;
- syntax = g_at_syntax_new_gsm_permissive();
-
- channel = ste_create_channel(modem);
- if (!channel)
- return -EIO;
-
- data-chat = g_at_chat_new_blocking(channel, syntax);
- g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1,
- NULL, NULL, NULL, NULL);
+ for (i = 0; i NUM_CHAT; i++) {
+ channel = ste_create_channel(modem);
+ syntax = g_at_syntax_new_gsm_permissive();
+ data-chat[i] = g_at_chat_new_blocking(channel, syntax);
+ if (data-chat[i] == NULL) {
+ g_io_channel_unref(channel);
+ g_at_syntax_unref(syntax);
+ DBG(Failed to create AT chat %s, chat_prefixes[i]);
+ goto error;
+ }
- /* All STE modems support UTF-8 */
- g_at_chat_send(data-chat, AT+CSCS=\UTF-8\,
- NULL, NULL, NULL, NULL);
+ if (getenv(OFONO_AT_DEBUG))
+ g_at_chat_set_debug(data-chat[i], ste_debug,
+ chat_prefixes[i]);
- g_io_channel_unref(channel);
- g_at_syntax_unref(syntax);
+ g_at_chat_send(data-chat[i], ATF E0 V1 X4 C1 +CMEE=1,
+ NULL, NULL, NULL, NULL);
- if (data-chat == NULL)
- return -ENOMEM;
+ /* All STE modems support UTF-8 */
+ g_at_chat_send(data-chat[i], AT+CSCS=\UTF-8\,
+ NULL, NULL, NULL, NULL);
- if (getenv(OFONO_AT_DEBUG))
- g_at_chat_set_debug(data-chat, ste_debug, chat_prefixes[0]);
+ g_io_channel_unref(channel);
+ g_at_syntax_unref(syntax);
+ }
- g_at_chat_send(data-chat, AT+CFUN=4, NULL, cfun_enable, modem, NULL);
+ g_at_chat_send(data-chat[AT_DEFAULT], AT+CFUN=4, NULL, cfun_enable,
+ modem, NULL);
- g_at_chat_register(data-chat, *ESIMSR:, esimsr_notify,
+ g_at_chat_register(data-chat[AT_SIM], *ESIMSR:, esimsr_notify,
FALSE, modem, NULL);
return -EINPROGRESS;
+
+error:
+ /* Unref open chats if any */
+ while (i--) {
+
[PATCH] ste: Add support for multiple AT channels
---
plugins/ste.c | 138 -
1 files changed, 87 insertions(+), 51 deletions(-)
diff --git a/plugins/ste.c b/plugins/ste.c
index b786571..9a1d3d3 100644
--- a/plugins/ste.c
+++ b/plugins/ste.c
@@ -65,13 +65,19 @@
#include drivers/stemodem/caif_socket.h
#include drivers/stemodem/if_caif.h
-#define NUM_CHAT 1
+#define NUM_CHAT 5
+#define AT_DEFAULT 0
+#define AT_NET 1
+#define AT_VOICE 2
+#define AT_GPRS3
+#define AT_SIM 4
#define MAX_PDP_CONTEXTS 4
-static char *chat_prefixes[NUM_CHAT] = { Default: };
+static char *chat_prefixes[NUM_CHAT] = { Default: , Net: , Voice: ,
+ GPRS: , SIM: };
struct ste_data {
- GAtChat *chat;
+ GAtChat *chat[NUM_CHAT];
gboolean have_sim;
struct ofono_sim *sim;
};
@@ -105,12 +111,14 @@ static int ste_probe(struct ofono_modem *modem)
static void ste_remove(struct ofono_modem *modem)
{
struct ste_data *data = ofono_modem_get_data(modem);
+ int i;
DBG(%p, modem);
ofono_modem_set_data(modem, NULL);
- g_at_chat_unref(data-chat);
+ for (i = 0; i NUM_CHAT; i++)
+ g_at_chat_unref(data-chat[i]);
g_free(data);
}
@@ -185,7 +193,7 @@ static gboolean init_sim_reporting(gpointer user_data)
struct ofono_modem *modem = user_data;
struct ste_data *data = ofono_modem_get_data(modem);
- g_at_chat_send(data-chat, AT*ESIMSR=1;*ESIMSR?, NULL,
+ g_at_chat_send(data-chat[AT_SIM], AT*ESIMSR=1;*ESIMSR?, NULL,
handle_sim_state,
modem, NULL);
@@ -195,11 +203,21 @@ static gboolean init_sim_reporting(gpointer user_data)
static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
{
struct ofono_modem *modem = user_data;
+ struct ste_data *data = ofono_modem_get_data(modem);
+ int i;
DBG();
if (!ok) {
ofono_modem_set_powered(modem, FALSE);
+
+ for (i = 0; i NUM_CHAT; i++) {
+ g_at_chat_cancel_all(data-chat[i]);
+ g_at_chat_unregister_all(data-chat[i]);
+ g_at_chat_unref(data-chat[i]);
+ data-chat[i] = NULL;
+ }
+
return;
}
@@ -295,35 +313,47 @@ static void esimsr_notify(GAtResult *result, gpointer
user_data)
static int ste_enable(struct ofono_modem *modem)
{
struct ste_data *data = ofono_modem_get_data(modem);
- GIOChannel *channel;
GAtSyntax *syntax;
+ int i;
syntax = g_at_syntax_new_gsm_permissive();
- channel = ste_create_channel(modem);
- if (!channel)
- return -EIO;
+ for (i = 0; i NUM_CHAT; i++) {
+ GIOChannel *channel = ste_create_channel(modem);
- data-chat = g_at_chat_new_blocking(channel, syntax);
- g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1,
- NULL, NULL, NULL, NULL);
+ data-chat[i] = g_at_chat_new_blocking(channel, syntax);
+ if (data-chat[i] == NULL)
+ return -EIO;
- /* All STE modems support UTF-8 */
- g_at_chat_send(data-chat, AT+CSCS=\UTF-8\,
- NULL, NULL, NULL, NULL);
+ g_at_chat_send(data-chat[i], ATF E0 V1 X4 C1 +CMEE=1,
+ NULL, NULL, NULL, NULL);
- g_io_channel_unref(channel);
- g_at_syntax_unref(syntax);
+ /* All STE modems support UTF-8 */
+ g_at_chat_send(data-chat[i], AT+CSCS=\UTF-8\,
+ NULL, NULL, NULL, NULL);
- if (data-chat == NULL)
- return -ENOMEM;
+ g_io_channel_unref(channel);
+ }
- if (getenv(OFONO_AT_DEBUG))
- g_at_chat_set_debug(data-chat, ste_debug, chat_prefixes[0]);
+ g_at_syntax_unref(syntax);
- g_at_chat_send(data-chat, AT+CFUN=4, NULL, cfun_enable, modem, NULL);
+ if (getenv(OFONO_AT_DEBUG)) {
+ g_at_chat_set_debug(data-chat[AT_DEFAULT], ste_debug,
+ chat_prefixes[0]);
+ g_at_chat_set_debug(data-chat[AT_NET], ste_debug,
+ chat_prefixes[1]);
+ g_at_chat_set_debug(data-chat[AT_VOICE], ste_debug,
+ chat_prefixes[2]);
+ g_at_chat_set_debug(data-chat[AT_GPRS], ste_debug,
+ chat_prefixes[3]);
+ g_at_chat_set_debug(data-chat[AT_SIM], ste_debug,
+ chat_prefixes[4]);
+ }
- g_at_chat_register(data-chat, *ESIMSR:, esimsr_notify,
+ g_at_chat_send(data-chat[AT_DEFAULT], AT+CFUN=4, NULL, cfun_enable,
+ modem, NULL);
+
+
Re: [PATCH] stk: Add null pointer check
Hi, On Fri, 2011-02-25 at 19:58 +0200, Denis Kenzior wrote: Hi Andrew / Lasse, diff --git a/src/stk.c b/src/stk.c index bc46b2f..c4e988b 100644 --- a/src/stk.c +++ b/src/stk.c @@ -2514,6 +2514,7 @@ static void stk_proactive_command_cancel(struct ofono_stk *stk) stk_command_free(stk-pending_cmd); stk-pending_cmd = NULL; stk-cancel_cmd = NULL; + stk-respond_on_exit = FALSE; } } Patch looks good to me, however I'd like it in something I can actually apply. Andrew can probably provide a patch for this? Lasse, can you confirm this patch solves your issue? Yes, it solves the issue. The null pointer check would be good to have as well, but not mandatory if this is taken in BR, -Lasse Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] stk: Add null pointer check
Fixes a crash when SIM Session End is received while waiting for user response to SELECT ITEM command. --- src/stk.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/stk.c b/src/stk.c index bc46b2f..cda378f 100644 --- a/src/stk.c +++ b/src/stk.c @@ -115,6 +115,9 @@ static int stk_respond(struct ofono_stk *stk, struct stk_response *rsp, if (stk-driver-terminal_response == NULL) return -ENOSYS; + if (stk-pending_cmd == NULL) + return -EINVAL; + rsp-src = STK_DEVICE_IDENTITY_TYPE_TERMINAL; rsp-dst = STK_DEVICE_IDENTITY_TYPE_UICC; rsp-number = stk-pending_cmd-number; -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] stk: Add null pointer check
Hi Andrzej, On Fri, 2011-02-25 at 14:39 +0200, Andrzej Zaborowski wrote: Hi Lasse, On 25 February 2011 11:39, Lasse Kunnasluoto lasse.kunnaslu...@tieto.com wrote: Fixes a crash when SIM Session End is received while waiting for user response to SELECT ITEM command. Can you post the ofono debug log for example? It sounds like something else is wrong because stk_respond should not be called when the session is ended by the card. Sure, log below. For me it looks like modem times out after 1 min if no response given. I don't think the session was terminated by SIM. Usually SIM cards wait for TERMINAL RESPONSE basically forever. SIM has no mechanism to terminate ongoing proactive command (well, except reset itself) ofonod[3228]: src/stk.c:stk_select_item() ofonod[3228]: src/stk.c:stk_select_item() ofonod[3228]: src/stk.c:stk_send_envelope() ofonod[3228]: drivers/mbmmodem/stk.c:mbm_stk_envelope() ofonod[3228]: drivers/mbmmodem/stk.c:mbm_stk_envelope() AT*STKE=D30782020181900101 ofonod[3228]: SIM: AT*STKE=D30782020181900101\r ofonod[3228]: SIM: \r\nOK\r\n ofonod[3228]: drivers/mbmmodem/stk.c:stke_cb() ofonod[3228]: src/stk.c:envelope_cb() length 0 ofonod[3228]: src/stk.c:menu_selection_envelope_cb() ofonod[3228]: src/stk.c:menu_selection_envelope_cb() Menu Selection envelope submission gave no error ofonod[3228]: SIM: \r \n*STKI:D05681030124808202818205083E507265706169640F10224372656469742072656368617267650F07234372656469740F0B245361756E616C616874690F09254C616E67756167650F072650726963657318052313101324\r\n ofonod[3228]: drivers/mbmmodem/stk.c:stki_notify() ofonod[3228]: src/stk.c:stk_menu_create() ofonod[3228]: SIM: \r\n*STKEND\r\n ofonod[3228]: drivers/mbmmodem/stk.c:stkend_notify() ofonod[3228]: src/stk.c:session_agent_notify() Session Agent removed ofonod[3228]: src/stk.c:session_agent_notify() Sending Terminate response for session agent ofonod[3228]: src/stk.c:send_simple_response() result 16 ofonod[3228]: src/stk.c:stk_respond() ofonod[3228]: Aborting (signal 11) ofonod[3228]: backtrace ofonod[3228]: [0]: [0x4fe400] ofonod[3228]: [1]: src/ofonod() [0x80dcfb8] ofonod[3228]: [2]: src/ofonod() [0x80dd495] ofonod[3228]: [3]: src/ofonod() [0x80f6e10] ofonod[3228]: [4]: /lib/libglib-2.0.so.0(g_slist_foreach+0x27) [0xe6b3d7] ofonod[3228]: [5]: src/ofonod() [0x806fbe6] ofonod[3228]: [6]: src/ofonod() [0x8071c17] ofonod[3228]: [7]: /lib/libglib-2.0.so.0(+0x7fefb) [0xe8fefb] ofonod[3228]: [8]: /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1d5) [0xe4b5e5] ofonod[3228]: [9]: /lib/libglib-2.0.so.0(+0x3f2d8) [0xe4f2d8] ofonod[3228]: [10]: /lib/libglib-2.0.so.0(g_main_loop_run+0x187) [0xe4f817] ofonod[3228]: [11]: src/ofonod() [0x80b5791] ofonod[3228]: [12]: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x2d1bd6] ofonod[3228]: [13]: src/ofonod() [0x8052f91] ofonod[3228]: +++ BR, -Lasse Best regards ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: gatchat looses UR code if received while waiting a response
Hi Denis, On Mon, 2011-02-21 at 17:14 +0200, Denis Kenzior wrote: Hi Lasse, On 02/21/2011 05:01 AM, Lasse Kunnasluoto wrote: Hi Marcel, On Mon, 2011-02-21 at 12:04 +0200, Marcel Holtmann wrote: Hi Lasse, I've seen an issue in Unsolicited Result code handling in gatchat. If ofono has sent an AT command and is waiting for a response, but modem has sent an UR code just before the AT command reached the modem, gatchat does not handle that UR code correctly (it drops it). 27.007 does not restrict UR-sending in the time between AT command and sending final response. Even modem would not send an UR while an active AT command, this may happen as a command may be on its way to ofono (e.g. in kernel). actually GAtChat handles this correctly. Important is what you give as valid_resp to g_at_chat_send. If this is NULL, then all lines between the command and OK are consumed by the callback of the send command. agree, but it would require a quite effort to change all the NULLs to something meaningful + test with various modems. You should not be passing NULL in the first place. The reason CGMM does so is that it has no prefix in the spec (a hold over from V.250). So if you have not been using proper prefixes, I'm afraid you have to fix them properly. The spec mandates the prefixes to expect, so this shouldn't be so hard anyway. STE modems mainly use the code in the atmodem driver. If the prefixes are correct there we shouldn't have an issue with prefixes. Real example of this happening: ofonod[1388]: Default: AT+CGMM\r ofonod[1388]: Default: \r \n*STKI:D027810301258082028182850A5361756E616C616874698F09013E507265706169641801241F020103\r\n ofonod[1388]: Default: \r\nST-Ericsson Mobile Broadband\r\n\r\nOK\r \n In this case the call back of *STKI was never called. This is not a modem issue as it has been verified the modem has sent *STKI before AT+CGMM was received. I consider this a modem issue. It should not send *STKI during a AT+CGMM command to avoid any kind of confusion of the parser. This specific case is not a modem issue. Modem has not received AT+CGMM when it sent *STKI (This was verified from modem logs). Modem cannot predict that there is AT+CGMM coming. Command was sent exactly same time on modem and ofono side. This is timing depend issue and in my opinion may occur with any AT modem. Ofono and Modem states are not always the same as there is certain delay when commands are exchanged between ofono and modem. These issues may be hidden most of the time but may cause some nasty errors some day. Sounds like the read watch priority should be higher than the write watch priority to avoid this specific example. Care to send a patch? I tried this. I put G_PRIORITY_HIGH to the read watch and G_PRIORITY_DEFAULT/LOW to write watch. No improvement on my environment. Changing the priorities may break other use cases, e.g. the one with IFX modems: gatchat: improve large file downlink data transfer This patch changed the priority of write watch to HIGH. One way to solve this is to change the sequence in gatchat.c/have_line() a bit and check first if this is UR code and then proceeding to response handling. Would this be acceptable solution for this issue or would it cause some drawbacks? If it is okay I can submit a patch See my command above. GAtChat is operating just fine. More robust solution would be to change GAtChat than defining and finding valid_resps for tens or hundreds of AT commands. I want to point out that this is not only an issue with CGMM but may occur with any AT command when the timing matches. There's nothing you can do in GAtChat at this point. Having the unsolicited response handler fire and consume lines before the pending AT command handler won't work either. If you're not convinced, try handling solicited / unsolicited CREG/CGREG and friends. Okay, good to know this, I was not aware. Perhaps I need to reconsider the way forward with this issue, we could change the startup sequence of different drivers and that way get around this issue. BR, -Lasse Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
gatchat looses UR code if received while waiting a response
Hi, I've seen an issue in Unsolicited Result code handling in gatchat. If ofono has sent an AT command and is waiting for a response, but modem has sent an UR code just before the AT command reached the modem, gatchat does not handle that UR code correctly (it drops it). 27.007 does not restrict UR-sending in the time between AT command and sending final response. Even modem would not send an UR while an active AT command, this may happen as a command may be on its way to ofono (e.g. in kernel). Real example of this happening: ofonod[1388]: Default: AT+CGMM\r ofonod[1388]: Default: \r \n*STKI:D027810301258082028182850A5361756E616C616874698F09013E507265706169641801241F020103\r\n ofonod[1388]: Default: \r\nST-Ericsson Mobile Broadband\r\n\r\nOK\r \n In this case the call back of *STKI was never called. This is not a modem issue as it has been verified the modem has sent *STKI before AT+CGMM was received. One way to solve this is to change the sequence in gatchat.c/have_line() a bit and check first if this is UR code and then proceeding to response handling. Would this be acceptable solution for this issue or would it cause some drawbacks? If it is okay I can submit a patch BR, -Lasse ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: gatchat looses UR code if received while waiting a response
Hi Marcel, On Mon, 2011-02-21 at 12:04 +0200, Marcel Holtmann wrote: Hi Lasse, I've seen an issue in Unsolicited Result code handling in gatchat. If ofono has sent an AT command and is waiting for a response, but modem has sent an UR code just before the AT command reached the modem, gatchat does not handle that UR code correctly (it drops it). 27.007 does not restrict UR-sending in the time between AT command and sending final response. Even modem would not send an UR while an active AT command, this may happen as a command may be on its way to ofono (e.g. in kernel). actually GAtChat handles this correctly. Important is what you give as valid_resp to g_at_chat_send. If this is NULL, then all lines between the command and OK are consumed by the callback of the send command. agree, but it would require a quite effort to change all the NULLs to something meaningful + test with various modems. Real example of this happening: ofonod[1388]: Default: AT+CGMM\r ofonod[1388]: Default: \r \n*STKI:D027810301258082028182850A5361756E616C616874698F09013E507265706169641801241F020103\r\n ofonod[1388]: Default: \r\nST-Ericsson Mobile Broadband\r\n\r\nOK\r \n In this case the call back of *STKI was never called. This is not a modem issue as it has been verified the modem has sent *STKI before AT+CGMM was received. I consider this a modem issue. It should not send *STKI during a AT+CGMM command to avoid any kind of confusion of the parser. This specific case is not a modem issue. Modem has not received AT+CGMM when it sent *STKI (This was verified from modem logs). Modem cannot predict that there is AT+CGMM coming. Command was sent exactly same time on modem and ofono side. This is timing depend issue and in my opinion may occur with any AT modem. Ofono and Modem states are not always the same as there is certain delay when commands are exchanged between ofono and modem. These issues may be hidden most of the time but may cause some nasty errors some day. One way to solve this is to change the sequence in gatchat.c/have_line() a bit and check first if this is UR code and then proceeding to response handling. Would this be acceptable solution for this issue or would it cause some drawbacks? If it is okay I can submit a patch See my command above. GAtChat is operating just fine. More robust solution would be to change GAtChat than defining and finding valid_resps for tens or hundreds of AT commands. I want to point out that this is not only an issue with CGMM but may occur with any AT command when the timing matches. BR, -Lasse Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] ste: Add support for CBS interface
STE modems support standard AT commands in CBS --- plugins/ste.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/plugins/ste.c b/plugins/ste.c index 0b02a0d..cf8aed8 100644 --- a/plugins/ste.c +++ b/plugins/ste.c @@ -48,6 +48,7 @@ #include ofono/netreg.h #include ofono/phonebook.h #include ofono/sim.h +#include ofono/cbs.h #include ofono/sms.h #include ofono/ssn.h #include ofono/ussd.h @@ -373,6 +374,7 @@ static void ste_post_online(struct ofono_modem *modem) ofono_call_barring_create(modem, 0, atmodem, data-chat); ofono_ssn_create(modem, 0, atmodem, data-chat); ofono_call_volume_create(modem, 0, atmodem, data-chat); + ofono_cbs_create(modem, 0, atmodem, data-chat); gprs = ofono_gprs_create(modem, OFONO_VENDOR_MBM, atmodem, data-chat); -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hi Marcel, On Mon, 2011-01-24 at 12:49 +0200, Marcel Holtmann wrote: Hi Lasse, I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list. Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111): - Call control by USIM - MO SMS Control by USIM Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. show us modem hardware where this is needed. At some point we just had to be realistic here in what can be tested with real hardware. And thus is really required to be supported and what makes sense in a smartphone environment. Understand. Sorry, cannot give an example of such HW. But if we would follow the 31.111 literally the alpha id should be displayed to user. - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA BIP is on many operators' wish list of supported SAT features. Even it is optional in 3GPP, some market areas will probably require BIP. I don't have an example to give right now. I think the important phrase is wish list. So far nobody could really showed me the exact use case for BIP. I am actually really interested in understanding what the operators wanna use it for. I prefer to have hard facts here and not just wish list and probably. If this is not a requirement for certification and the operator is not actually using such a feature at all, then why bother. Feel free to convince me otherwise here. Main use case is that operator can update the SAT applet on the SIM remotely. Operators cannot really advertise or productize usage of BIP before enough terminals support it. SCWS introduces new ways of using SAT, you could build better UIs using a web browser to access SIM applets. This is the use case Jukka Saunamaki mentioned. While we can certainly look into supporting BIP at some point, but from where I am standing it is pretty clear; first get all mandatory STK features sorted out, before trying to work on optional ones. What is the 3GPP release you are aiming in STK support? Release 99, 4, 5 6,7? As it defines what is mandatory to support and to be tested in GCF. - Extend support in PROVIDE LOCAL INFO What support are you looking for? Most of the information that is asked by provide local info is implemented in the modem firmware. We have only included support for items which are not covered by the firmware. If aiming GCF approval support should contain: IMEI, location info, network measurementsBCCH channel list, timing advance, access technology, IMEISV, Inter-frequency UTRAN measurements. As you said these are often handled by modem, but isn't possible that modem can be configured in a way it leaves the full control of SAT to the host? Although certain AT command based modems would require proprietary commands to fetch all the needed information. So in that sense it is more logical for modem to handle these commands what requires low level interfaces. What we have seen so far is that all of these are handled by the modem. If the modem has all information available, then why bother waking up the host CPU for this. It does make a lot of sense to keep the host CPU asleep if possible. I am pretty pragmatic here; if we have to support a modem that does not handle these, then we have to do it. So if you have more information about other modem types, please let us know. And patches are always welcome. - EVENT DOWNLOAD / SET UP EVENT LIST Again, which ones are you looking for? oFono explicitly ignores the following two events as these make no sense in the smartphone context: - Idle Screen Available - User Activity It looks like Idle Screen Available and User Activity User Activity are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability table. Rest of the sub-features are listed there. Don't they depend on the STK profile that you are using? No. If a terminal claims to support USAT and be compliant with 3GPP e.g. Rel-7 or any other, certain features become mandatory, depending
Re: SAT support in oFono
Hi all, On Fri, 2011-01-21 at 18:13 +0200, Denis Kenzior wrote: Hi Lasse, On 01/21/2011 02:44 AM, lasse.kunnaslu...@tieto.com wrote: Hi I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list. Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111): - Call control by USIM - MO SMS Control by USIM Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA BIP is on many operators' wish list of supported SAT features. Even it is optional in 3GPP, some market areas will probably require BIP. I don't have an example to give right now. Please feel free to add a new TODO item adding these features and send us patches :) - Extend support in PROVIDE LOCAL INFO What support are you looking for? Most of the information that is asked by provide local info is implemented in the modem firmware. We have only included support for items which are not covered by the firmware. If aiming GCF approval support should contain: IMEI, location info, network measurementsBCCH channel list, timing advance, access technology, IMEISV, Inter-frequency UTRAN measurements. As you said these are often handled by modem, but isn't possible that modem can be configured in a way it leaves the full control of SAT to the host? Although certain AT command based modems would require proprietary commands to fetch all the needed information. So in that sense it is more logical for modem to handle these commands what requires low level interfaces. - EVENT DOWNLOAD / SET UP EVENT LIST Again, which ones are you looking for? oFono explicitly ignores the following two events as these make no sense in the smartphone context: - Idle Screen Available - User Activity It looks like Idle Screen Available and User Activity User Activity are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability table. Rest of the sub-features are listed there. BR, -Lasse Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] atmodem: move USSD quirk to probe and use it also for STE modems
Hi Denis, On Mon, 2011-01-17 at 17:58 +0200, Denis Kenzior wrote: Hi Lasse, On 01/17/2011 02:42 AM, Lasse Kunnasluoto wrote: Hi Marcel, Supporting IRA character set is not really an option since IRA and GSM 7bit have disjoint sets of characters. The best you can really do is: - If your modem supports UTF8, then set that for all multiplexer channels in the modem driver. Yes, it supports UTF8. I'll send a new patch for this. Thanks. - Otherwise set the character set to GSM and do your best to put ussd and phonebook on separate multiplexer channels. That is of course assuming that the CSCS setting is handled per channel. The best is if the STE modem would provide access to the USSD in PDU mode and we can then decode it properly. Using text mode for USSD is not the best idea actually. Same as text mode for SMS is utterly broken ;) Don't know if this is possible. USSD PDU mode is the ideal solution. If this is not available, then you will have to jump through all kinds of hoops to get this done properly. Regards, -Denis -Lasse ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] ste: Use UTF-8 as a default character set
--- plugins/ste.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugins/ste.c b/plugins/ste.c index 7bb7232..cc01f7b 100644 --- a/plugins/ste.c +++ b/plugins/ste.c @@ -247,7 +247,7 @@ static int ste_enable(struct ofono_modem *modem) return -EIO; data-chat = g_at_chat_new_blocking(channel, syntax); - g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1, + g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1;+CSCS=\UTF-8\, NULL, NULL, NULL, NULL); g_io_channel_unref(channel); -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] ste: Use UTF-8 as a default character set
Hi Marcel, On Tue, 2011-01-18 at 16:32 +0200, Marcel Holtmann wrote: Hi Lasse, plugins/ste.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugins/ste.c b/plugins/ste.c index 7bb7232..cc01f7b 100644 --- a/plugins/ste.c +++ b/plugins/ste.c @@ -247,7 +247,7 @@ static int ste_enable(struct ofono_modem *modem) return -EIO; data-chat = g_at_chat_new_blocking(channel, syntax); - g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1, + g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1;+CSCS=\UTF-8\, NULL, NULL, NULL, NULL); is it guaranteed that every single STE modem supports UTF-8 character set? Based on information I have, yes, every single ste modem support UTF-8. I would rather see a new command checking for supported character sets and then picking the default. And intermixing with ATE is not really clean from my perspective. You want this to be changed accordingly? I tried to to follow minimalism in this simple change and not to introduce new functions. If command fails for some reason, modem uses its default value, which is IRA. It could be on a separate line, but still I would not add a call back for it, nothing to do if the command fails. I prefer the patch I sent, but you can decide Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2] ste: Use UTF-8 as a default character set
--- plugins/ste.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/plugins/ste.c b/plugins/ste.c index 7bb7232..44cfc14 100644 --- a/plugins/ste.c +++ b/plugins/ste.c @@ -250,6 +250,10 @@ static int ste_enable(struct ofono_modem *modem) g_at_chat_send(data-chat, ATF E0 V1 X4 C1 +CMEE=1, NULL, NULL, NULL, NULL); + /* All STE modems support UTF-8 */ + g_at_chat_send(data-chat, AT+CSCS=\UTF-8\, NULL, NULL, NULL, + NULL); + g_io_channel_unref(channel); g_at_syntax_unref(syntax); -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] atmodem: move USSD quirk to probe and use it also for STE modems
Hi Marcel,
On Fri, 2011-01-14 at 16:20 +0200, Marcel Holtmann wrote:
Hi Lasse,
@@ -314,6 +305,18 @@ static int at_ussd_probe(struct ofono_ussd *ussd,
unsigned int vendor,
ofono_ussd_set_data(ussd, data);
+ switch (data-vendor) {
+ case OFONO_VENDOR_QUALCOMM_MSM:
+ case OFONO_VENDOR_STE:
+ /*
+ * Ensure that the modem is using GSM character set. It
+ * seems it defaults to IRA and then umlauts are not
+ * properly encoded. The modem returns some weird from
+ * of Latin-1, but it is not really Latin-1 either.
+ */
+ g_at_chat_send(data-chat, AT+CSCS=\GSM\, none_prefix,
+ NULL, NULL, NULL);
+ break;
+ }
+
g_at_chat_send(chat, AT+CSCS?, cscs_prefix, read_charset_cb, data,
NULL);
so we don't really wanna do it this way since other atoms like the
phonebook can switch the character sets as well.
Yes, seems so. If phonebook switches the character set USSD won't get
notified and vice versa. So in general this should be somehow
centralized in ofono.
What about supporting the IRA character set in ofono? It would get us a
bit forward compared to current situation. Currently USSD functionality
is quite broken with AT modems having IRA character set, all strings
sent from NW are ignored in cusd_parse().
The best is if the STE modem would provide access to the USSD in PDU
mode and we can then decode it properly. Using text mode for USSD is not
the best idea actually. Same as text mode for SMS is utterly broken ;)
Don't know if this is possible.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 1/2] atmodem: move USSD quirk to probe and use it also for STE modems
Fixing issues in USSD quirk:
1) MT USSD are not handled correctly if modem uses IRA character set (change
character set to GSM already in probe)
2) Responses from NW to MO USSD are not hadled as internal variable is not
updated after cscs= command (Query right after setting)
3) Use the same quirk for STE modems
---
drivers/atmodem/ussd.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/atmodem/ussd.c b/drivers/atmodem/ussd.c
index 651b6af..411b1de 100644
--- a/drivers/atmodem/ussd.c
+++ b/drivers/atmodem/ussd.c
@@ -219,15 +219,6 @@ static void at_ussd_request(struct ofono_ussd *ussd, int
dcs,
converted, dcs);
}
- if (data-vendor == OFONO_VENDOR_QUALCOMM_MSM) {
- /* Ensure that the modem is using GSM character set. It
-* seems it defaults to IRA and then umlauts are not
-* properly encoded. The modem returns some weird from
-* of Latin-1, but it is not really Latin-1 either. */
- g_at_chat_send(data-chat, AT+CSCS=\GSM\, none_prefix,
- NULL, NULL, NULL);
- }
-
if (g_at_chat_send(data-chat, buf, cusd_prefix,
cusd_request_cb, cbd, g_free) 0)
return;
@@ -314,6 +305,18 @@ static int at_ussd_probe(struct ofono_ussd *ussd, unsigned
int vendor,
ofono_ussd_set_data(ussd, data);
+ switch (data-vendor) {
+ case OFONO_VENDOR_QUALCOMM_MSM:
+ case OFONO_VENDOR_STE:
+ /*
+ * Ensure that the modem is using GSM character set. It
+ * seems it defaults to IRA and then umlauts are not
+ * properly encoded. The modem returns some weird from
+ * of Latin-1, but it is not really Latin-1 either.
+ */
+ g_at_chat_send(data-chat, AT+CSCS=\GSM\, none_prefix,
+ NULL, NULL, NULL);
+ break;
+ }
+
g_at_chat_send(chat, AT+CSCS?, cscs_prefix, read_charset_cb, data,
NULL);
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 2/2] ste: Enable vendor quirk for USSD
This USSD quirk won't work for MT USSD --- plugins/ste.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/plugins/ste.c b/plugins/ste.c index 7bb7232..3ede210 100644 --- a/plugins/ste.c +++ b/plugins/ste.c @@ -363,7 +363,7 @@ static void ste_post_online(struct ofono_modem *modem) DBG(%p, modem); - ofono_ussd_create(modem, 0, atmodem, data-chat); + ofono_ussd_create(modem, OFONO_VENDOR_STE, atmodem, data-chat); ofono_call_forwarding_create(modem, 0, atmodem, data-chat); ofono_call_settings_create(modem, 0, atmodem, data-chat); ofono_netreg_create(modem, OFONO_VENDOR_MBM, atmodem, data-chat); -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
