[PATCH 5/7] cdmamodem: add CDMA Connection Manager support
From: Christian Lam
---
Makefile.am |3 +-
drivers/cdmamodem/cdmamodem.c |4 +-
drivers/cdmamodem/cdmamodem.h |4 +-
drivers/cdmamodem/connman.c | 283 +
4 files changed, 291 insertions(+), 3 deletions(-)
create mode 100644 drivers/cdmamodem/connman.c
diff --git a/Makefile.am b/Makefile.am
index dc50a83..e077557 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -254,7 +254,8 @@ builtin_modules += cdmamodem
builtin_sources += drivers/cdmamodem/cdmamodem.h \
drivers/cdmamodem/cdmamodem.c \
drivers/cdmamodem/voicecall.c \
- drivers/cdmamodem/devinfo.c
+ drivers/cdmamodem/devinfo.c \
+ drivers/cdmamodem/connman.c
endif
builtin_modules += g1
diff --git a/drivers/cdmamodem/cdmamodem.c b/drivers/cdmamodem/cdmamodem.c
index 9eddd88..1b19a4a 100644
--- a/drivers/cdmamodem/cdmamodem.c
+++ b/drivers/cdmamodem/cdmamodem.c
@@ -2,7 +2,7 @@
*
* oFono - Open Source Telephony
*
- * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2010-2011 Nokia Corporation. All rights reserved.
*
* 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
@@ -36,6 +36,7 @@ static int cdmamodem_init(void)
{
cdma_voicecall_init();
cdma_devinfo_init();
+ cdma_connman_init();
return 0;
}
@@ -44,6 +45,7 @@ static void cdmamodem_exit(void)
{
cdma_voicecall_exit();
cdma_devinfo_exit();
+ cdma_connman_exit();
}
OFONO_PLUGIN_DEFINE(cdmamodem, "CDMA AT modem driver", VERSION,
diff --git a/drivers/cdmamodem/cdmamodem.h b/drivers/cdmamodem/cdmamodem.h
index 4365bec..90e2848 100644
--- a/drivers/cdmamodem/cdmamodem.h
+++ b/drivers/cdmamodem/cdmamodem.h
@@ -2,7 +2,7 @@
*
* oFono - Open Source Telephony
*
- * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2010-2011 Nokia Corporation. All rights reserved.
*
* 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
@@ -25,3 +25,5 @@ extern void cdma_voicecall_init(void);
extern void cdma_voicecall_exit(void);
extern void cdma_devinfo_init(void);
extern void cdma_devinfo_exit(void);
+extern void cdma_connman_init(void);
+extern void cdma_connman_exit(void);
diff --git a/drivers/cdmamodem/connman.c b/drivers/cdmamodem/connman.c
new file mode 100644
index 000..d563413
--- /dev/null
+++ b/drivers/cdmamodem/connman.c
@@ -0,0 +1,283 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010-2011 Nokia Corporation. All rights reserved.
+ *
+ * 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
+#endif
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include "gatchat.h"
+#include "gatresult.h"
+#include "gatppp.h"
+
+#include "cdmamodem.h"
+
+#define STATIC_IP_NETMASK "255.255.255.255"
+
+static const char *none_prefix[] = { NULL };
+
+enum state {
+ STATE_IDLE,
+ STATE_ENABLING,
+ STATE_DISABLING,
+ STATE_ACTIVE,
+};
+
+struct connman_data {
+ GAtChat *chat;
+ GAtPPP *ppp;
+ enum state state;
+ union {
+ ofono_cdma_connman_cb_t down_cb;/* Down callback */
+ ofono_cdma_connman_up_cb_t up_cb; /* Up callback */
+ };
+ void *cb_data; /* Callback data */
+};
+
+static void ppp_debug(const char *str, void *data)
+{
+ ofono_info("%s: %s", (const char *) data, str);
+}
+
+static void ppp_connect(const char *interface, const char *local,
+ const char *remote,
+ const char *dns1, const char *dns2,
+ gpointer user_data)
+{
+ struct ofono_cdma_connman *cm = user_data;
+ struct connman_data *cd = ofono_cdma_connman_get_data(cm);
+ const char *dns[3];
+
+ DBG("");
+
+ dns[0] = dns1;
+ dns[1] = dns2;
+ dns[2] = 0;
+
+ ofono_info("IP: %s", local);
+ ofono_info("DNS: %s, %s", dns1, dns2);
+
+
[PATCH 7/7] test: add Settings dict parsing for CDMA ConnMan
From: Christian Lam
---
test/list-modems | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/test/list-modems b/test/list-modems
index 249ae15..662a3c7 100755
--- a/test/list-modems
+++ b/test/list-modems
@@ -62,6 +62,16 @@ for path, properties in modems:
for i in properties[key]:
val += "[" + i + " = "
val += str(int(properties[key][i])) +
"] "
+ elif key in ["Settings"]:
+ val = "{"
+ for i in properties[key].keys():
+ val += " " + i + "="
+ if i in ["DomainNameServers"]:
+ for n in properties[key][i]:
+ val += n + ","
+ else:
+ val += properties[key][i]
+ val += " }"
else:
val = str(properties[key])
print "%s = %s" % (key, val)
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 6/7] test: add CDMA Connection Manager support scripts
From: Christian Lam
---
test/disable-cdma-connman | 20
test/enable-cdma-connman | 20
2 files changed, 40 insertions(+), 0 deletions(-)
create mode 100755 test/disable-cdma-connman
create mode 100755 test/enable-cdma-connman
diff --git a/test/disable-cdma-connman b/test/disable-cdma-connman
new file mode 100755
index 000..a1c9568
--- /dev/null
+++ b/test/disable-cdma-connman
@@ -0,0 +1,20 @@
+#!/usr/bin/python
+
+import dbus
+import sys
+
+bus = dbus.SystemBus()
+
+if len(sys.argv) == 2:
+ path = sys.argv[1]
+else:
+ manager = dbus.Interface(bus.get_object('org.ofono', '/'),
+ 'org.ofono.Manager')
+ modems = manager.GetModems()
+ path = modems[0][0]
+
+print "Disconnecting CDMA Packet Data Service on modem %s..." % path
+cm = dbus.Interface(bus.get_object('org.ofono', path),
+ 'org.ofono.cdma.ConnectionManager')
+
+cm.SetProperty("Powered", dbus.Boolean(0))
diff --git a/test/enable-cdma-connman b/test/enable-cdma-connman
new file mode 100755
index 000..699240d
--- /dev/null
+++ b/test/enable-cdma-connman
@@ -0,0 +1,20 @@
+#!/usr/bin/python
+
+import dbus
+import sys
+
+bus = dbus.SystemBus()
+
+if len(sys.argv) == 2:
+ path = sys.argv[1]
+else:
+ manager = dbus.Interface(bus.get_object('org.ofono', '/'),
+ 'org.ofono.Manager')
+ modems = manager.GetModems()
+ path = modems[0][0]
+
+print "Connecting CDMA Packet Data Service on modem %s..." % path
+cm = dbus.Interface(bus.get_object('org.ofono', path),
+ 'org.ofono.cdma.ConnectionManager')
+
+cm.SetProperty("Powered", dbus.Boolean(1))
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 3/7] src: add CDMA Connection Manager support
From: Christian Lam
---
Makefile.am|3 +-
src/cdma-connman.c | 571
src/ofono.h|2 +
3 files changed, 575 insertions(+), 1 deletions(-)
create mode 100644 src/cdma-connman.c
diff --git a/Makefile.am b/Makefile.am
index c4f5983..dc50a83 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -356,7 +356,8 @@ src_ofonod_SOURCES = $(gdbus_sources) $(builtin_sources)
src/ofono.ver \
src/simfs.c src/simfs.h src/audio-settings.c \
src/smsagent.c src/smsagent.h src/ctm.c \
src/cdma-voicecall.c src/sim-auth.c \
- src/message.h src/message.c
+ src/message.h src/message.c \
+ src/cdma-connman.c
src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ -ldl
diff --git a/src/cdma-connman.c b/src/cdma-connman.c
new file mode 100644
index 000..ca8499d
--- /dev/null
+++ b/src/cdma-connman.c
@@ -0,0 +1,571 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010-2011 Nokia Corporation. All rights reserved.
+ *
+ * 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
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "ofono.h"
+#include "common.h"
+
+static GSList *g_drivers;
+
+struct cdma_connman_settings {
+ char *interface;
+ gboolean static_ip;
+ char *ip;
+ char *netmask;
+ char *gateway;
+ char **dns;
+};
+
+struct ofono_cdma_connman {
+ ofono_bool_t powered;
+ ofono_bool_t dormant;
+ struct cdma_connman_settings *settings;
+ DBusMessage *pending;
+ const struct ofono_cdma_connman_driver *driver;
+ void *driver_data;
+ struct ofono_atom *atom;
+};
+
+static void cdma_connman_settings_free(struct cdma_connman_settings *settings)
+{
+ DBG("");
+
+ g_free(settings->interface);
+ g_free(settings->ip);
+ g_free(settings->netmask);
+ g_free(settings->gateway);
+ g_strfreev(settings->dns);
+
+ g_free(settings);
+}
+
+static void cdma_connman_ifupdown(const char *interface, ofono_bool_t active)
+{
+ struct ifreq ifr;
+ int sk;
+
+ DBG("");
+
+ if (interface == NULL)
+ return;
+
+ sk = socket(PF_INET, SOCK_DGRAM, 0);
+ if (sk < 0)
+ return;
+
+ memset(&ifr, 0, sizeof(ifr));
+ strncpy(ifr.ifr_name, interface, IFNAMSIZ);
+
+ if (ioctl(sk, SIOCGIFFLAGS, &ifr) < 0)
+ goto done;
+
+ if (active == TRUE) {
+ if (ifr.ifr_flags & IFF_UP)
+ goto done;
+ ifr.ifr_flags |= IFF_UP;
+ } else {
+ if (!(ifr.ifr_flags & IFF_UP))
+ goto done;
+ ifr.ifr_flags &= ~IFF_UP;
+ }
+
+ if (ioctl(sk, SIOCSIFFLAGS, &ifr) < 0)
+ ofono_error("Failed to change interface flags");
+
+done:
+ close(sk);
+}
+
+static void cdma_connman_settings_append_variant(
+ struct cdma_connman_settings *settings,
+ DBusMessageIter *iter)
+{
+ DBusMessageIter variant;
+ DBusMessageIter array;
+ char typesig[5];
+ char arraysig[6];
+ const char *method;
+
+ DBG("");
+
+ arraysig[0] = DBUS_TYPE_ARRAY;
+ arraysig[1] = typesig[0] = DBUS_DICT_ENTRY_BEGIN_CHAR;
+ arraysig[2] = typesig[1] = DBUS_TYPE_STRING;
+ arraysig[3] = typesig[2] = DBUS_TYPE_VARIANT;
+ arraysig[4] = typesig[3] = DBUS_DICT_ENTRY_END_CHAR;
+ arraysig[5] = typesig[4] = '\0';
+
+ dbus_message_iter_open_container(iter, DBUS_TYPE_VARIANT,
+ arraysig, &variant);
+
+ dbus_message_iter_open_container(&variant, DBUS_TYPE_ARRAY,
+ typesig, &array);
+
+ if (settings == NULL)
+ goto done;
+
+ ofono_dbus_dict_append(&array, "Interface",
+ DBUS_TYPE_STRING, &settings->interface);
+
+ if (settings->static_ip == TRUE)
+ method = "static";
+ else
+ method =
[PATCH 4/7] nokiacdma: add CDMA Connection Manager support
From: Christian Lam
---
plugins/nokiacdma.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/plugins/nokiacdma.c b/plugins/nokiacdma.c
index 7bd224d..808341c 100644
--- a/plugins/nokiacdma.c
+++ b/plugins/nokiacdma.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "common.h"
@@ -147,7 +148,10 @@ static void nokiacdma_post_sim(struct ofono_modem *modem)
static void nokiacdma_post_online(struct ofono_modem *modem)
{
+ struct nokiacdma_data *data = ofono_modem_get_data(modem);
+
DBG("%p", modem);
+ ofono_cdma_connman_create(modem, 0, "cdmamodem", data->chat);
}
static struct ofono_modem_driver nokiacdma_driver = {
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 1/7] dbus: add CDMA Connection Manager interface
From: Christian Lam
---
include/dbus.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/dbus.h b/include/dbus.h
index 83a0590..6f436ca 100644
--- a/include/dbus.h
+++ b/include/dbus.h
@@ -59,6 +59,7 @@ extern "C" {
/* CDMA Interfaces */
#define OFONO_CDMA_VOICECALL_MANAGER_INTERFACE
"org.ofono.cdma.VoiceCallManager"
#define OFONO_CDMA_MESSAGE_MANAGER_INTERFACE "org.ofono.cdma.MessageManager"
+#define OFONO_CDMA_CONNECTION_MANAGER_INTERFACE
"org.ofono.cdma.ConnectionManager"
/* Essentially a{sv} */
#define OFONO_PROPERTIES_ARRAY_SIGNATURE DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING \
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 2/7] cdma-connman: add CDMA Connection Manager support
From: Christian Lam
---
Makefile.am|3 +-
include/cdma-connman.h | 79
2 files changed, 81 insertions(+), 1 deletions(-)
create mode 100644 include/cdma-connman.h
diff --git a/Makefile.am b/Makefile.am
index 9933e32..c4f5983 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -13,7 +13,8 @@ pkginclude_HEADERS = include/log.h include/plugin.h
include/history.h \
include/radio-settings.h include/stk.h \
include/audio-settings.h include/nettime.h \
include/ctm.h include/cdma-voicecall.h \
- include/cdma-sms.h include/sim-auth.h
+ include/cdma-sms.h include/sim-auth.h \
+ include/cdma-connman.h
nodist_pkginclude_HEADERS = include/version.h
diff --git a/include/cdma-connman.h b/include/cdma-connman.h
new file mode 100644
index 000..22252e0
--- /dev/null
+++ b/include/cdma-connman.h
@@ -0,0 +1,79 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010-2011 Nokia Corporation. All rights reserved.
+ *
+ * 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
+ *
+ */
+
+#ifndef __OFONO_CDMA_CONNMAN_H
+#define __OFONO_CDMA_CONNMAN_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+
+struct ofono_cdma_connman;
+
+typedef void (*ofono_cdma_connman_cb_t)(const struct ofono_error *error,
+ void *data);
+typedef void (*ofono_cdma_connman_up_cb_t)(const struct ofono_error *error,
+ const char *interface,
+ ofono_bool_t static_ip,
+ const char *address,
+ const char *netmask,
+ const char *gw,
+ const char **dns,
+ void *data);
+
+struct ofono_cdma_connman_driver {
+ const char *name;
+ int (*probe)(struct ofono_cdma_connman *cm, unsigned int vendor,
+ void *data);
+ void (*remove)(struct ofono_cdma_connman *cm);
+ void (*activate)(struct ofono_cdma_connman *cm,
+ ofono_cdma_connman_up_cb_t cb,
+ void *data);
+ void (*deactivate)(struct ofono_cdma_connman *cm,
+ ofono_cdma_connman_cb_t cb,
+ void *data);
+};
+
+int ofono_cdma_connman_driver_register(
+ const struct ofono_cdma_connman_driver *d);
+void ofono_cdma_connman_driver_unregister(
+ const struct ofono_cdma_connman_driver *d);
+
+struct ofono_cdma_connman *ofono_cdma_connman_create(
+ struct ofono_modem *modem,
+ unsigned int vendor,
+ const char *driver,
+ void *data);
+
+void ofono_cdma_connman_register(struct ofono_cdma_connman *cm);
+void ofono_cdma_connman_remove(struct ofono_cdma_connman *cm);
+
+void ofono_cdma_connman_set_data(struct ofono_cdma_connman *cm,
+ void *data);
+void *ofono_cdma_connman_get_data(struct ofono_cdma_connman *cm);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_CDMA_CONNMAN_H */
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 0/7] Add CDMA Connection Manager support
From: Christian Lam This series of patches provides the support for the CDMA Connection Manager, cdma-connman, atom. This includes Mobile Originated connection and disconnection features of Packet Data Service over CDMA (1xRTT and 1xEV-DO) systems. This implementation do not yet handle the CDMA Network Registration which is future work. These patches have been tested against the Nokia 7705 CDMA device in a tethered mode. Limitations --- The Nokia 7705 device does not support an AT interface for reporting request responses, such as the remote/network disconnect reasons, so these are currently untested. Christian Lam (7): dbus: add CDMA Connection Manager interface cdma-connman: add CDMA Connection Manager support src: add CDMA Connection Manager support nokiacdma: add CDMA Connection Manager support cdmamodem: add CDMA Connection Manager support test: add CDMA Connection Manager support scripts test: add Settings dict parsing for CDMA ConnMan Makefile.am |9 +- drivers/cdmamodem/cdmamodem.c |4 +- drivers/cdmamodem/cdmamodem.h |4 +- drivers/cdmamodem/connman.c | 283 include/cdma-connman.h| 79 ++ include/dbus.h|1 + plugins/nokiacdma.c |4 + src/cdma-connman.c| 571 + src/ofono.h |2 + test/disable-cdma-connman | 20 ++ test/enable-cdma-connman | 20 ++ test/list-modems | 10 + 12 files changed, 1002 insertions(+), 5 deletions(-) create mode 100644 drivers/cdmamodem/connman.c create mode 100644 include/cdma-connman.h create mode 100644 src/cdma-connman.c create mode 100755 test/disable-cdma-connman create mode 100755 test/enable-cdma-connman ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Denis, On 01/21/2011 02:04 PM, ext Denis Kenzior wrote: Hi Lei, On 01/21/2011 03:48 PM, Lei Yu wrote: Hi Denis, On 01/21/2011 01:04 PM, ext Denis Kenzior wrote: Hi Lei, +string Type [readonly, optional, experimental] + +String representing the type of the modem device. + +The possible values are: +"gsm" Modem supports one or more of the 3GPP +family of technologies including GSM, +EDGE, UMTS, HSPA, LTE. +"cdma" Modem supports one or more of the 3GPP2 +family of technologies including CDMA 1x, +EVDO. +"hfp"Bluetooth hands-free profile (HFP) modem + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... We understand that the decision during the CDMA workshop but as we explained one use case in the cover letter (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for this RFC, there will be cases where atom's D-Bus I/F is not suitable (or as a reliable way) for telling what is current mode (CDMA or GSM). E.g., in the case of retrieving serial number from modem. Currently both CDMA and GSM shares the same I/F (ofono.org.modem) rather than having separate (ofono.org.cdma.modem). And, further if no other atom has been instantiated, then, there will be no other way to tell which mode (CDMA or GSM) the modem is. And, further for displaying serial number, upper layer will need to know it is CDMA or GSM. In case of CDMA, the serial number is MEID and GSM it is IMEI. As explained in cover letter, we anticipate more cases like this. So let us say I have a dual-mode modem. Are there now two serial numbers? One for MEID and one for IMEI? Are there now two Manufacturers? Two Revisions? Try to clarify what you try to ask first. Let's start with the dual-mode case where the modem is integrated modem (one piece of HW) where it supports both CDMA and GSM. Then, there is case where the phone actually has both MEID and IMEI. And, these two numbers are actually the same (note, per IMEI's assignment there is a pre-arranged segment for this kind of world phone). And, in which case, one manufacture, one revision. Per the other thread, in which case the "Type" will be something like "gsm_cdma". So how does the modem type help you here if you have 'gsm_cdma'? Is the modem giving you a MEID? An IMEI? I'm not convinced the Type helps you in any way. It might help you for HFP, but certainly not the dual mode case. First, our original use case is really for a single mode case, not dual mode. Please see our cover letter in our original RFC. Please do let us know if you agree or disagree whether there is a problem needing to be solved for single mode case. Second, in case of the example I gave above, modem will provide one serial number which is both MEID and IMEI since they are identical. In which case based on "Type" setting to "cdma_gsm", it will be upper layer's choice to do the processing. E.g., upper layer can do something like: MEID/IMEI: xxx. Of course, there can be case where two physical modems are in the device in which case there will be two separate serial numbers and two manufacturers and revisions. I am assuming you are not asking for this case. Yes, I'm ignoring the true dual-mode dual-radio case right now. Regards, -Denis Regards, -Lei ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Lei, On 01/21/2011 03:48 PM, Lei Yu wrote: > Hi Denis, > > On 01/21/2011 01:04 PM, ext Denis Kenzior wrote: >> Hi Lei, >> > +string Type [readonly, optional, experimental] > + > +String representing the type of the modem device. > + > +The possible values are: > +"gsm" Modem supports one or more of the 3GPP > +family of technologies including GSM, > +EDGE, UMTS, HSPA, LTE. > +"cdma" Modem supports one or more of the 3GPP2 > +family of technologies including CDMA 1x, > +EVDO. > +"hfp"Bluetooth hands-free profile (HFP) modem > + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... >>> >>> We understand that the decision during the CDMA workshop but as we >>> explained one use case in the cover letter >>> (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for >>> this RFC, there will be cases where atom's D-Bus I/F is not suitable (or >>> as a reliable way) for telling what is current mode (CDMA or GSM). E.g., >>> in the case of retrieving serial number from modem. Currently both CDMA >>> and GSM shares the same I/F (ofono.org.modem) rather than having >>> separate (ofono.org.cdma.modem). And, further if no other atom has been >>> instantiated, then, there will be no other way to tell which mode (CDMA >>> or GSM) the modem is. And, further for displaying serial number, upper >>> layer will need to know it is CDMA or GSM. In case of CDMA, the serial >>> number is MEID and GSM it is IMEI. As explained in cover letter, we >>> anticipate more cases like this. >> >> So let us say I have a dual-mode modem. Are there now two serial >> numbers? One for MEID and one for IMEI? Are there now two >> Manufacturers? Two Revisions? > > Try to clarify what you try to ask first. Let's start with the dual-mode > case where the modem is integrated modem (one piece of HW) where it > supports both CDMA and GSM. Then, there is case where the phone actually > has both MEID and IMEI. And, these two numbers are actually the same > (note, per IMEI's assignment there is a pre-arranged segment for this > kind of world phone). And, in which case, one manufacture, one revision. > Per the other thread, in which case the "Type" will be something like > "gsm_cdma". So how does the modem type help you here if you have 'gsm_cdma'? Is the modem giving you a MEID? An IMEI? I'm not convinced the Type helps you in any way. It might help you for HFP, but certainly not the dual mode case. > Of course, there can be case where two physical modems are in the device > in which case there will be two separate serial numbers and two > manufacturers and revisions. I am assuming you are not asking for this > case. Yes, I'm ignoring the true dual-mode dual-radio case right now. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Denis, On 01/21/2011 01:04 PM, ext Denis Kenzior wrote: Hi Lei, +string Type [readonly, optional, experimental] + +String representing the type of the modem device. + +The possible values are: +"gsm" Modem supports one or more of the 3GPP +family of technologies including GSM, +EDGE, UMTS, HSPA, LTE. +"cdma" Modem supports one or more of the 3GPP2 +family of technologies including CDMA 1x, +EVDO. +"hfp"Bluetooth hands-free profile (HFP) modem + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... We understand that the decision during the CDMA workshop but as we explained one use case in the cover letter (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for this RFC, there will be cases where atom's D-Bus I/F is not suitable (or as a reliable way) for telling what is current mode (CDMA or GSM). E.g., in the case of retrieving serial number from modem. Currently both CDMA and GSM shares the same I/F (ofono.org.modem) rather than having separate (ofono.org.cdma.modem). And, further if no other atom has been instantiated, then, there will be no other way to tell which mode (CDMA or GSM) the modem is. And, further for displaying serial number, upper layer will need to know it is CDMA or GSM. In case of CDMA, the serial number is MEID and GSM it is IMEI. As explained in cover letter, we anticipate more cases like this. So let us say I have a dual-mode modem. Are there now two serial numbers? One for MEID and one for IMEI? Are there now two Manufacturers? Two Revisions? Try to clarify what you try to ask first. Let's start with the dual-mode case where the modem is integrated modem (one piece of HW) where it supports both CDMA and GSM. Then, there is case where the phone actually has both MEID and IMEI. And, these two numbers are actually the same (note, per IMEI's assignment there is a pre-arranged segment for this kind of world phone). And, in which case, one manufacture, one revision. Per the other thread, in which case the "Type" will be something like "gsm_cdma". Of course, there can be case where two physical modems are in the device in which case there will be two separate serial numbers and two manufacturers and revisions. I am assuming you are not asking for this case. Again, the problem we try to solve is single mode case. Regards, -Denis Regards, - Lei ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] bluetooth: Add bluetooth server support
Hi Frédéric,
* Frédéric Danis [2011-01-21 16:07:41 +0100]:
> Based on patches from: Zhenhua Zhang
>
> It watches Bluetooth adapter property changes and adds SDP record to
> listen client connection request.
> It supports multiple servers and multiple client connections for each
> server.
> ---
> Authorization code will be added in next patch
You can send all patches together, review goes faster this way. ;)
>
> Makefile.am |1 +
> plugins/bluetooth.c | 247
> +++
> plugins/bluetooth.h |9 ++
> 3 files changed, 257 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9933e32..abd5d11 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -317,6 +317,7 @@ builtin_sources += plugins/bluetooth.c plugins/bluetooth.h
> builtin_modules += hfp
> builtin_sources += plugins/hfp.c plugins/bluetooth.h
>
> +builtin_sources += $(btio_sources)
> builtin_cflags += @BLUEZ_CFLAGS@
> builtin_libadd += @BLUEZ_LIBS@
> endif
> diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
> index 93dd7a1..56e22c6 100644
> --- a/plugins/bluetooth.c
> +++ b/plugins/bluetooth.c
> @@ -35,12 +35,30 @@
>
> #include
>
> +#include
> #include "bluetooth.h"
>
> static DBusConnection *connection;
> static GHashTable *uuid_hash = NULL;
> static GHashTable *adapter_address_hash = NULL;
> static gint bluetooth_refcount;
> +static GSList *server_list = NULL;
> +
> +struct server {
> + guint8 channel;
> + char*sdp_record;
> + GIOChannel *io;
> + char*adapter;
> + guint handle;
> + ConnectFunc connect_cb;
> + gpointeruser_data;
> + GSList *client_list;
> +};
> +
> +struct client_data {
> + struct server *server;
> + guint source;
> +};
>
> void bluetooth_create_path(const char *dev_addr, const char *adapter_addr,
> char *buf, int size)
> @@ -371,6 +389,161 @@ static gboolean property_changed(DBusConnection
> *connection, DBusMessage *msg,
> return TRUE;
> }
>
> +static void server_stop(gpointer data, gpointer user_data)
> +{
> + struct server *server = data;
> + DBusMessage *msg;
> +
> + /* calling g_source_remove will also remove it from client list */
> + while (server->client_list)
> + g_source_remove((guint) server->client_list->data);
> +
> + if (server->handle == 0)
> + goto out;
> +
> + msg = dbus_message_new_method_call(BLUEZ_SERVICE, server->adapter,
> + BLUEZ_SERVICE_INTERFACE,
> + "RemoveRecord");
> + if (msg == NULL) {
> + ofono_error("Unable to allocate D-Bus RemoveRecord message");
> + goto out;
> + }
> +
> + dbus_message_append_args(msg, DBUS_TYPE_UINT32, &server->handle,
> + DBUS_TYPE_INVALID);
> + g_dbus_send_message(connection, msg);
> +
> + server->handle = 0;
> +
> +out:
> + if (server->io != NULL) {
> + g_io_channel_shutdown(server->io, TRUE, NULL);
> + g_io_channel_unref(server->io);
> + server->io = NULL;
> + }
> +
> + g_free(server->adapter);
> + server->adapter = NULL;
> +}
> +
> +static void client_remove(struct client_data *cl)
> +{
> + cl->server->client_list = g_slist_remove(cl->server->client_list,
> + (void *) cl->source);
> + g_free(cl);
> +}
> +
> +static gboolean client_event(GIOChannel *chan, GIOCondition cond, gpointer
> data)
> +{
> + return FALSE;
What is that function for?
> +}
> +
> +static void confirm_event(GIOChannel *io, gpointer user_data)
> +{
> + struct server *server = user_data;
> + GError *err = NULL;
> + char address[18];
> + guint8 channel;
> + struct client_data *cl;
> +
> + bt_io_get(io, BT_IO_RFCOMM, &err, BT_IO_OPT_DEST, address,
> + BT_IO_OPT_CHANNEL, &channel,
> + BT_IO_OPT_INVALID);
> + if (err) {
> + ofono_error("%s", err->message);
> + g_error_free(err);
> + return;
> + }
> +
> + ofono_info("New connection from: %s, channel %u", address, channel);
> +
> + if (!bt_io_accept(io, server->connect_cb, server->user_data,
> + NULL, &err)) {
> + ofono_error("%s", err->message);
> + g_error_free(err);
> + g_io_channel_unref(io);
> + return;
> + }
> +
> + cl = g_try_new0(struct client_data, 1);
> + if (cl == NULL) {
> + ofono_error("Unable to allocate new client event structure");
> + return;
> + }
> +
> + cl->server = server;
> + cl->source = g_io_add_watch_full(io, G_PRIORITY_DEFAULT,
> + G_IO_HUP | G_IO_ERR
Re: [PATCH] doc: Add modem Type property
Hi Lei, >>> +string Type [readonly, optional, experimental] >>> + >>> +String representing the type of the modem device. >>> + >>> +The possible values are: >>> +"gsm" Modem supports one or more of the 3GPP >>> +family of technologies including GSM, >>> +EDGE, UMTS, HSPA, LTE. >>> +"cdma" Modem supports one or more of the 3GPP2 >>> +family of technologies including CDMA 1x, >>> +EVDO. >>> +"hfp"Bluetooth hands-free profile (HFP) modem >>> + >> >> So one pointed question: >> >> How are we planning to support dual-mode devices with this property? I >> believe during the CDMA workshop we decided that the clients should >> simply look at the set of interfaces, not a semi-static property... > > We understand that the decision during the CDMA workshop but as we > explained one use case in the cover letter > (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for > this RFC, there will be cases where atom's D-Bus I/F is not suitable (or > as a reliable way) for telling what is current mode (CDMA or GSM). E.g., > in the case of retrieving serial number from modem. Currently both CDMA > and GSM shares the same I/F (ofono.org.modem) rather than having > separate (ofono.org.cdma.modem). And, further if no other atom has been > instantiated, then, there will be no other way to tell which mode (CDMA > or GSM) the modem is. And, further for displaying serial number, upper > layer will need to know it is CDMA or GSM. In case of CDMA, the serial > number is MEID and GSM it is IMEI. As explained in cover letter, we > anticipate more cases like this. So let us say I have a dual-mode modem. Are there now two serial numbers? One for MEID and one for IMEI? Are there now two Manufacturers? Two Revisions? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Denis, On 01/21/2011 12:15 PM, ext Denis Kenzior wrote: Hi Dara, On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote: Add support for providing the type of the attached modem device including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP. --- doc/modem-api.txt | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/doc/modem-api.txt b/doc/modem-api.txt index 45043b0..fe806c8 100644 --- a/doc/modem-api.txt +++ b/doc/modem-api.txt @@ -82,6 +82,19 @@ Properties boolean Powered [readwrite] This is usually obtained by using the +CGSN AT command. + string Type [readonly, optional, experimental] + + String representing the type of the modem device. + + The possible values are: + "gsm" Modem supports one or more of the 3GPP + family of technologies including GSM, + EDGE, UMTS, HSPA, LTE. + "cdma" Modem supports one or more of the 3GPP2 + family of technologies including CDMA 1x, + EVDO. + "hfp" Bluetooth hands-free profile (HFP) modem + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... Also, it is my understanding that the reason we create org.ofono.cdma interfaces during CDMA workshop are to make sure CDMA interfaces and logics do not "pollute" GSM interfaces and logics which are very different anyway. We have not ruled out the case where there may be shared interfaces as we see a need. Currently, org.ofono.modem is this case. Unless we would go ahead creating org.ofono.cdma.modem, we discussed that option internally but feel that is less preferable than the "Type" property we proposed here. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Regards, -Lei ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Gustavo and Denis On 01/21/2011 12:25 PM, ext Gustavo F. Padovan wrote: Hi Denis, * Denis Kenzior [2011-01-21 14:15:46 -0600]: Hi Dara, On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote: Add support for providing the type of the attached modem device including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP. --- doc/modem-api.txt | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/doc/modem-api.txt b/doc/modem-api.txt index 45043b0..fe806c8 100644 --- a/doc/modem-api.txt +++ b/doc/modem-api.txt @@ -82,6 +82,19 @@ Properties boolean Powered [readwrite] This is usually obtained by using the +CGSN AT command. + string Type [readonly, optional, experimental] + + String representing the type of the modem device. + + The possible values are: + "gsm" Modem supports one or more of the 3GPP + family of technologies including GSM, + EDGE, UMTS, HSPA, LTE. + "cdma" Modem supports one or more of the 3GPP2 + family of technologies including CDMA 1x, + EVDO. + "hfp" Bluetooth hands-free profile (HFP) modem + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... We can have a value that is "gsm& cdma". This fits for now, but won't scale. And this list won't increase in the near future I think. This is along the lines of my thoughts for future support of a multi-mode device- but I left it out for now as a value as it's future work. Denis - Lei's about to pop in and answer your questions as he was actually at the workshop! :) Cheers Dara ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Denis, On 01/21/2011 12:15 PM, ext Denis Kenzior wrote: Hi Dara, On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote: Add support for providing the type of the attached modem device including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP. --- doc/modem-api.txt | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/doc/modem-api.txt b/doc/modem-api.txt index 45043b0..fe806c8 100644 --- a/doc/modem-api.txt +++ b/doc/modem-api.txt @@ -82,6 +82,19 @@ Properties boolean Powered [readwrite] This is usually obtained by using the +CGSN AT command. + string Type [readonly, optional, experimental] + + String representing the type of the modem device. + + The possible values are: + "gsm" Modem supports one or more of the 3GPP + family of technologies including GSM, + EDGE, UMTS, HSPA, LTE. + "cdma" Modem supports one or more of the 3GPP2 + family of technologies including CDMA 1x, + EVDO. + "hfp" Bluetooth hands-free profile (HFP) modem + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... We understand that the decision during the CDMA workshop but as we explained one use case in the cover letter (http://lists.ofono.org/pipermail/ofono/2011-January/007890.html) for this RFC, there will be cases where atom's D-Bus I/F is not suitable (or as a reliable way) for telling what is current mode (CDMA or GSM). E.g., in the case of retrieving serial number from modem. Currently both CDMA and GSM shares the same I/F (ofono.org.modem) rather than having separate (ofono.org.cdma.modem). And, further if no other atom has been instantiated, then, there will be no other way to tell which mode (CDMA or GSM) the modem is. And, further for displaying serial number, upper layer will need to know it is CDMA or GSM. In case of CDMA, the serial number is MEID and GSM it is IMEI. As explained in cover letter, we anticipate more cases like this. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Regards Lei ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Denis, * Denis Kenzior [2011-01-21 14:15:46 -0600]: > Hi Dara, > > On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote: > > Add support for providing the type of the attached modem device > > including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP. > > --- > > doc/modem-api.txt | 13 + > > 1 files changed, 13 insertions(+), 0 deletions(-) > > > > diff --git a/doc/modem-api.txt b/doc/modem-api.txt > > index 45043b0..fe806c8 100644 > > --- a/doc/modem-api.txt > > +++ b/doc/modem-api.txt > > @@ -82,6 +82,19 @@ Properties boolean Powered [readwrite] > > > > This is usually obtained by using the +CGSN AT command. > > > > + string Type [readonly, optional, experimental] > > + > > + String representing the type of the modem device. > > + > > + The possible values are: > > + "gsm" Modem supports one or more of the 3GPP > > + family of technologies including GSM, > > + EDGE, UMTS, HSPA, LTE. > > + "cdma" Modem supports one or more of the 3GPP2 > > + family of technologies including CDMA > > 1x, > > + EVDO. > > + "hfp" Bluetooth hands-free profile (HFP) modem > > + > > So one pointed question: > > How are we planning to support dual-mode devices with this property? I > believe during the CDMA workshop we decided that the clients should > simply look at the set of interfaces, not a semi-static property... We can have a value that is "gsm & cdma". This fits for now, but won't scale. And this list won't increase in the near future I think. -- Gustavo F. Padovan http://profusion.mobi ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add modem Type property
Hi Dara, On 01/20/2011 04:48 PM, Dara Spieker-Doyle wrote: > Add support for providing the type of the attached modem device > including GSM (3GPP), CDMA (3GPP2) and Bluetooth HFP. > --- > doc/modem-api.txt | 13 + > 1 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/doc/modem-api.txt b/doc/modem-api.txt > index 45043b0..fe806c8 100644 > --- a/doc/modem-api.txt > +++ b/doc/modem-api.txt > @@ -82,6 +82,19 @@ Properties boolean Powered [readwrite] > > This is usually obtained by using the +CGSN AT command. > > + string Type [readonly, optional, experimental] > + > + String representing the type of the modem device. > + > + The possible values are: > + "gsm" Modem supports one or more of the 3GPP > + family of technologies including GSM, > + EDGE, UMTS, HSPA, LTE. > + "cdma" Modem supports one or more of the 3GPP2 > + family of technologies including CDMA > 1x, > + EVDO. > + "hfp" Bluetooth hands-free profile (HFP) modem > + So one pointed question: How are we planning to support dual-mode devices with this property? I believe during the CDMA workshop we decided that the clients should simply look at the set of interfaces, not a semi-static property... Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/3] PPP: Fix transmit ACCM and receive ACCM setting issue
Hi Martin, >> You still forgot to apply my earlier comment. The recv ACCM should be >> set to what is acked by the peer. e.g.: > That is not this patch want to resolve. This patch is just used to fix the > mixing up of setting recv ACCM and transit ACCM, And fix Huawei modem issue. > > 1. Currently, it is just ACKed by peer. You know It is called at lcp_rca, and > here the code always use ACCM as 0x0. So that is just the acked ACCM. Then please send a 2nd patch that just sets the recv ACCM to the one acked by the peer if you want to be pedantic. But changing the chunk once, then changing it in the second chunk to some other value will only serve to confuse me or anyone who reviews your patch submissions. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/3] Use default ACCM (0xffffffff) to trasmit package
Hi Martin, On 01/20/2011 07:51 PM, Xu, Martin wrote: >> -Original Message- >> From: Denis Kenzior [mailto:denk...@gmail.com] >> Sent: Friday, January 21, 2011 3:11 AM >> To: ofono@ofono.org >> Cc: Xu, Martin >> Subject: Re: [PATCH 2/3] Use default ACCM (0x) to trasmit package >> >> Hi Martin, >> >> On 01/19/2011 11:45 PM, martin...@intel.com wrote: >>> From: Martin Xu >>> >>> Using my Huawei EM770W modem, if set ACCM as 0x, RXJ- >>> event breaks PPP link, after IP package transmit for a while. >>> Using default ACCM, the issue can be fixed. >>> I tested it at China Unicom networks. >> >> Does the Huawei NAK our ACCM by any chance? > The modem can accept our 0x0 ACCM. But with the ACCM, PPP does not work. > If there is not any issue at the modem firmware, can we understand it as: > Modem can transmit ACCM with 0x0, but we have no capability to receive it, so > we can't ask modem transmit as 0x0 ACCM? > We should be able to receive ACCM of 0 just fine. I double checked the code, but maybe you want to put a pair of eyeballs on it as well. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] stk: change timeout from 10 to 3mintues
--- src/stk.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/stk.c b/src/stk.c index 80edc25..29d2087 100644 --- a/src/stk.c +++ b/src/stk.c @@ -2839,7 +2839,7 @@ void ofono_stk_register(struct ofono_stk *stk) __ofono_atom_register(stk->atom, stk_unregister); - stk->timeout = 600; /* 10 minutes */ + stk->timeout = 180; /* 3 minutes */ stk->short_timeout = 20; /* 20 seconds */ stk->envelope_q = g_queue_new(); } -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/6] gprs-provision: add driver API header
Hi Jukka, On 01/21/2011 01:39 AM, Jukka Saunamaki wrote: > Hi > > On Thu, 2011-01-20 at 15:51 -0600, Denis Kenzior wrote: >> So I don't really see the point in an asynchronous provisioning driver. >> If you want to do this over D-Bus or something then you might as well >> provision via the ConnectionManager interface. The other problem with >> being async is that is nearly impossible to support multiple >> provisioning plugins properly. I'd rather not deal with the race >> conditions. >> >> If we can't make the lookup fast enough to be done synchronously, then I >> think we should give up. > > The reason for asyncronous API is still that SPN value reading from SIM. > Is there any way to make sure it is available synchronously when > provisioning is run? Not really. So you're introducing a boatload of extra complexity just because of the need for EFspn? Are you 100% sure that you really need this? Can some of these corner cases be covered differently? > And what do you mean with it being impossible to support multiple > provisioning plugins properly? Plugins are run one after another until > first returns something. > Race conditions I tried to address in gprs, so if gprs atom goes away > while provisioning is running nothing bad should happen. But sure, there > might something else, and hopefully someone could point them. How exactly are you guaranteeing that 'nothing bad should happen'? There is no cancellation mechanism that I see. Not to mention that the current ofono_sim_read API is not even safe either. For exactly the same reasons. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
test script to establish 3G connection
Hi All,
I'm looking for an example how to active 3G connection(ppp) with Huawei
E180.
not sure if these step's should work:
1)/ofono-0.39/test# ./enable-modem
Connecting modem /huawei0...
2)/ofono-0.39/test# ./online-modem
Setting modem /huawei0 online...
3)/ofono-0.39/test# ./list-modems
[ /huawei0 ]
Features = sms gprs cbs net rat sim
Powered = 1
Lockdown = 0
Interfaces = org.ofono.SmartMessaging org.ofono.PushNotification
org.ofono.MessageManager org.ofono.ConnectionManager
org.ofono.CellBroadcast org.ofono.NetworkRegistration
org.ofono.SupplementaryServices org.ofono.Phonebook
org.ofono.RadioSettings org.ofono.SimManager
Online = 1
4)./create-internet-context internet
5)./list-contexts
[ /huawei0 ]./list-contexts
[ /huawei0 ]
[ /huawei0/context1 ]
Username =
Protocol = ip
Name = Internet
Settings = { }
Active = 0
AccessPointName = internet
Password =
Type = internet
6)./process-context-settings , no output
[ /huawei0/context1 ]
Username =
Protocol = ip
Name = Internet
Settings = { }
Active = 0
AccessPointName = internet
Password =
Type = internet
./process-context-settings "Receive no output here??"
Thanks
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 4/4] atmodem: sim-auth atom driver.
Hi Pekka, On 01/21/2011 11:07 AM, Pekka Pessi wrote: > Hi Denis, > > 2011/1/20 Denis Kenzior : >> My view is that checking mallocs of small structures is pretty much >> pointless on Linux. > > > The glib functions that ofono uses extensively don't do any malloc > checking, and it makes checking on the ofono side bit pointless. If > malloc fails, ofono will crash. If it has not get killed by oom > police. > Well the g_try_ series do allow you to recover from a bad malloc, which is what we generally use. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 4/4] atmodem: sim-auth atom driver.
Hi Denis, 2011/1/20 Denis Kenzior : > My view is that checking mallocs of small structures is pretty much > pointless on Linux. The glib functions that ofono uses extensively don't do any malloc checking, and it makes checking on the ofono side bit pointless. If malloc fails, ofono will crash. If it has not get killed by oom police. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Problem configuring Longsung U6300
Hello, all. I have a little question - which driver should I use for modem Longsung U6300 based on Qualcomm MSM6290? I know that Huawei uses qualcomm chips, so I tried to add udev rule like for huawei modem, but it did not work. list-modes shows modem (online=0, powered=0, lockdown=0), but enable-modem fails with timeout exception. vendorId - 1c9e, productId - 9603. Could you help me, please? ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
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. > - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, > CLOSE CHANNEL, SEND/RECEIVE DATA 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. > - 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 Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hi Jeevaka, Lasse, On 21 January 2011 10:12, wrote: > ofono-boun...@ofono.org 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 > > Most of the modems support call control, MO SMS control on the firmware > side itself. > Open for adding support in ofono. > >> - BIP (Bearer independent protocol), including commands like >> OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA > > Inorder to support class e fully, changes are required in connman and > ofono. > Since class e is an optional one, I dont think we need to support this > inorder to get GCF certified. > > for your question, is there any plan to support this in oFono core, > I would leave it to Denis, Andre and Marcel to comment on this. Currently the plan was to leave these BIP-related commands out, as Jeevaka says they would require connman support and we didn't have a particular use case. Do you have practical uses for supporting these commands in oFono core? Same question for the call control and better ProvideLocalInfo support (which Local Info types?). Best regards ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] bluetooth: Add bluetooth server support
Based on patches from: Zhenhua Zhang
It watches Bluetooth adapter property changes and adds SDP record to
listen client connection request.
It supports multiple servers and multiple client connections for each
server.
---
Authorization code will be added in next patch
Makefile.am |1 +
plugins/bluetooth.c | 247 +++
plugins/bluetooth.h |9 ++
3 files changed, 257 insertions(+), 0 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 9933e32..abd5d11 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -317,6 +317,7 @@ builtin_sources += plugins/bluetooth.c plugins/bluetooth.h
builtin_modules += hfp
builtin_sources += plugins/hfp.c plugins/bluetooth.h
+builtin_sources += $(btio_sources)
builtin_cflags += @BLUEZ_CFLAGS@
builtin_libadd += @BLUEZ_LIBS@
endif
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 93dd7a1..56e22c6 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -35,12 +35,30 @@
#include
+#include
#include "bluetooth.h"
static DBusConnection *connection;
static GHashTable *uuid_hash = NULL;
static GHashTable *adapter_address_hash = NULL;
static gint bluetooth_refcount;
+static GSList *server_list = NULL;
+
+struct server {
+ guint8 channel;
+ char*sdp_record;
+ GIOChannel *io;
+ char*adapter;
+ guint handle;
+ ConnectFunc connect_cb;
+ gpointeruser_data;
+ GSList *client_list;
+};
+
+struct client_data {
+ struct server *server;
+ guint source;
+};
void bluetooth_create_path(const char *dev_addr, const char *adapter_addr,
char *buf, int size)
@@ -371,6 +389,161 @@ static gboolean property_changed(DBusConnection
*connection, DBusMessage *msg,
return TRUE;
}
+static void server_stop(gpointer data, gpointer user_data)
+{
+ struct server *server = data;
+ DBusMessage *msg;
+
+ /* calling g_source_remove will also remove it from client list */
+ while (server->client_list)
+ g_source_remove((guint) server->client_list->data);
+
+ if (server->handle == 0)
+ goto out;
+
+ msg = dbus_message_new_method_call(BLUEZ_SERVICE, server->adapter,
+ BLUEZ_SERVICE_INTERFACE,
+ "RemoveRecord");
+ if (msg == NULL) {
+ ofono_error("Unable to allocate D-Bus RemoveRecord message");
+ goto out;
+ }
+
+ dbus_message_append_args(msg, DBUS_TYPE_UINT32, &server->handle,
+ DBUS_TYPE_INVALID);
+ g_dbus_send_message(connection, msg);
+
+ server->handle = 0;
+
+out:
+ if (server->io != NULL) {
+ g_io_channel_shutdown(server->io, TRUE, NULL);
+ g_io_channel_unref(server->io);
+ server->io = NULL;
+ }
+
+ g_free(server->adapter);
+ server->adapter = NULL;
+}
+
+static void client_remove(struct client_data *cl)
+{
+ cl->server->client_list = g_slist_remove(cl->server->client_list,
+ (void *) cl->source);
+ g_free(cl);
+}
+
+static gboolean client_event(GIOChannel *chan, GIOCondition cond, gpointer
data)
+{
+ return FALSE;
+}
+
+static void confirm_event(GIOChannel *io, gpointer user_data)
+{
+ struct server *server = user_data;
+ GError *err = NULL;
+ char address[18];
+ guint8 channel;
+ struct client_data *cl;
+
+ bt_io_get(io, BT_IO_RFCOMM, &err, BT_IO_OPT_DEST, address,
+ BT_IO_OPT_CHANNEL, &channel,
+ BT_IO_OPT_INVALID);
+ if (err) {
+ ofono_error("%s", err->message);
+ g_error_free(err);
+ return;
+ }
+
+ ofono_info("New connection from: %s, channel %u", address, channel);
+
+ if (!bt_io_accept(io, server->connect_cb, server->user_data,
+ NULL, &err)) {
+ ofono_error("%s", err->message);
+ g_error_free(err);
+ g_io_channel_unref(io);
+ return;
+ }
+
+ cl = g_try_new0(struct client_data, 1);
+ if (cl == NULL) {
+ ofono_error("Unable to allocate new client event structure");
+ return;
+ }
+
+ cl->server = server;
+ cl->source = g_io_add_watch_full(io, G_PRIORITY_DEFAULT,
+ G_IO_HUP | G_IO_ERR | G_IO_NVAL,
+ client_event, cl,
+ (GDestroyNotify) client_remove);
+ server->client_list = g_slist_prepend(server->client_list,
+ (void *)cl->source);
+}
+
+static void add_record_cb(DBusPendingCall
Re: oFono exits on new voicecall with disconnected system bus
On Fri, Jan 21, 2011 at 1:10 PM, Marcel Holtmann wrote: Hi Marcel, [...] >> ofonod[5771]: src/voicecall.c:ofono_voicecall_notify() Did not find a >> call with id: 1 >> ofonod[5771]: src/voicecall.c:append_voicecall_properties() name ��+@ >> call->name ��+@ >> ofonod[5771]: System bus has disconnected! > > I think that I found the problem. Pushed a patch for it. Please re-test > if this helps. The Calypso driver was using stack memory for the call > object. Yes, it works fine now, going further ;) Regards Niko ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/5 v3] nettime: DBUS and compilation configuration
Hi Antti, > > > > please don't implement org.ofono interface in timed. Just implement a > > > > timed specific (com.nokia.time) interface and punch the whole for that > > > > in the timed D-Bus policy. > > > > > > I think there is some disconnect here. The intention is to implement a > > > similar agent interface as PushNotification and SmartMessaging already > > > do, with the exception that the one and only agent is known beforehand > > > and "hard-coded" to the plugin. > > > > that is not what I said and that is clearly not the intent here. > > > > > This is a generic interface that some other time information sink > > > could also implement, so it makes sense to have it in the org.ofono > > > namespace. Regardless of which namespace we use, though, it is oFono > > > that will be calling methods on this interface, and thus it needs to > > > have this interface opened in its D-Bus config. > > > > They will be always specific to the target daemon and that is fine. This > > is not up to oFono to define and that is point here. > > > > > > The plugin is timed specific since it monitors com.nokia.time and thus > > > > should also target a timed specific API. Not a generic oFono API > > > > description. > > > > > > This is really just another agent API in oFono, just one with a > > > build-time registration mechanism for agents. > > > > It is not. This is timed exposing an API to get notifications from a > > cellular stack and then a timed specific plugin inside oFono. It has > > nothing to do with an oFono defined D-Bus API. > > As I see, the question at the moment is where to punch the hole in D-Bus > configuration; alternatives being either in ofono or in timed side. I > can see the rationale and reasoning behind both approaches, but in order > to make some progress with this matter we need a decision. So, should we > take a vote or what? After all isn't this a non-functional, > matter-of-taste type of question? since it should be com.nokia.timed interface, it should be done all by timed. The timed plugin inside oFono is just a user. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/5 v3] nettime: DBUS and compilation configuration
Hi, On Thu, 2011-01-20 at 12:19 +0100, ext Marcel Holtmann wrote: > Hi Aki, > > > > please don't implement org.ofono interface in timed. Just implement a > > > timed specific (com.nokia.time) interface and punch the whole for that > > > in the timed D-Bus policy. > > > > I think there is some disconnect here. The intention is to implement a > > similar agent interface as PushNotification and SmartMessaging already > > do, with the exception that the one and only agent is known beforehand > > and "hard-coded" to the plugin. > > that is not what I said and that is clearly not the intent here. > > > This is a generic interface that some other time information sink > > could also implement, so it makes sense to have it in the org.ofono > > namespace. Regardless of which namespace we use, though, it is oFono > > that will be calling methods on this interface, and thus it needs to > > have this interface opened in its D-Bus config. > > They will be always specific to the target daemon and that is fine. This > is not up to oFono to define and that is point here. > > > > The plugin is timed specific since it monitors com.nokia.time and thus > > > should also target a timed specific API. Not a generic oFono API > > > description. > > > > This is really just another agent API in oFono, just one with a > > build-time registration mechanism for agents. > > It is not. This is timed exposing an API to get notifications from a > cellular stack and then a timed specific plugin inside oFono. It has > nothing to do with an oFono defined D-Bus API. As I see, the question at the moment is where to punch the hole in D-Bus configuration; alternatives being either in ofono or in timed side. I can see the rationale and reasoning behind both approaches, but in order to make some progress with this matter we need a decision. So, should we take a vote or what? After all isn't this a non-functional, matter-of-taste type of question? Best Regards, Antti ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] isimodem: fix sending DTMF
Hi Kai, 2011/1/20 Kai Vehmanen : > isi_call_dtmf_send_resp() handles the success case incorrectly, and > thus all send_tones attempts fail with bogus error codes. > --- > drivers/isimodem/voicecall.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Patch has been pushed, thanks! Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] isimodem: fix issue with user busy release
Hi Jeevaka, 2011/1/21 Jeevaka Badrappan : > when the user rejects the incoming call, hangup_active > will get called on the driver side whereas when the user > rejects the waiting call, set_udub will get called on the > driver side. > --- > drivers/isimodem/voicecall.c | 13 + > 1 files changed, 9 insertions(+), 4 deletions(-) Patch has been pushed, thanks! Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/3] doc: fix a kill-yank error
Hi Pekka, > doc/smartmessaging-api.txt |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 2/3] message-waiting: add allocation checks
From: Pekka Pessi
---
src/message-waiting.c | 45 ++---
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/src/message-waiting.c b/src/message-waiting.c
index 0e376b6..5d1126b 100644
--- a/src/message-waiting.c
+++ b/src/message-waiting.c
@@ -179,20 +179,22 @@ static DBusMessage *set_cphs_mbdn(struct
ofono_message_waiting *mw,
if ((mw->ef_cphs_mbdn_length && !mw_mailbox_to_cphs_record[mailbox]) ||
mw->cphs_mbdn_not_provided == TRUE) {
- if (msg)
+ if (msg != NULL)
return __ofono_error_not_supported(msg);
return NULL;
}
if (mw->ef_cphs_mbdn_length == 0) {
- if (msg)
+ if (msg != NULL)
return __ofono_error_sim_not_ready(msg);
return NULL;
}
req = g_new0(struct mbdn_set_request, 1);
+ if (req == NULL)
+ goto error;
req->mw = mw;
req->mailbox = mailbox;
@@ -206,13 +208,17 @@ static DBusMessage *set_cphs_mbdn(struct
ofono_message_waiting *mw,
sync ? cphs_mbdn_sync_cb : mbdn_set_cb,
OFONO_SIM_FILE_STRUCTURE_FIXED,
mw_mailbox_to_cphs_record[mailbox],
- efmbdn, mw->ef_cphs_mbdn_length, req) == -1) {
- g_free(req);
+ efmbdn, mw->ef_cphs_mbdn_length, req) == -1)
+ goto error;
- if (msg)
- return __ofono_error_failed(msg);
- } else
- req->msg = msg ? dbus_message_ref(msg) : NULL;
+ req->msg = msg ? dbus_message_ref(msg) : NULL;
+ return NULL;
+
+error:
+ g_free(req);
+
+ if (msg != NULL)
+ return __ofono_error_failed(msg);
return NULL;
}
@@ -292,6 +298,8 @@ static DBusMessage *set_mbdn(struct ofono_message_waiting
*mw, int mailbox,
}
req = g_new0(struct mbdn_set_request, 1);
+ if (req == NULL)
+ goto error;
req->mw = mw;
req->mailbox = mailbox;
@@ -303,13 +311,17 @@ static DBusMessage *set_mbdn(struct ofono_message_waiting
*mw, int mailbox,
if (ofono_sim_write(req->mw->sim, SIM_EFMBDN_FILEID, mbdn_set_cb,
OFONO_SIM_FILE_STRUCTURE_FIXED,
req->mw->efmbdn_record_id[mailbox],
- efmbdn, req->mw->efmbdn_length, req) == -1) {
- g_free(req);
+ efmbdn, req->mw->efmbdn_length, req) == -1)
+ goto error;
- if (msg)
- return __ofono_error_failed(msg);
- } else
- req->msg = msg ? dbus_message_ref(msg) : NULL;
+ req->msg = msg ? dbus_message_ref(msg) : NULL;
+ return NULL;
+
+error:
+ g_free(req);
+
+ if (msg)
+ return __ofono_error_failed(msg);
return NULL;
}
@@ -990,13 +1002,16 @@ struct ofono_message_waiting
*ofono_message_waiting_create(struct ofono_modem *m
struct ofono_message_waiting *mw;
mw = g_try_new0(struct ofono_message_waiting, 1);
-
if (mw == NULL)
return NULL;
mw->atom = __ofono_modem_add_atom(modem,
OFONO_ATOM_TYPE_MESSAGE_WAITING,
mw_remove, mw);
+ if (mw->atom == NULL) {
+ g_free(mw);
+ return NULL;
+ }
return mw;
}
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 1/3] message-waiting: check for NULL argument
From: Pekka Pessi
---
src/message-waiting.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/message-waiting.c b/src/message-waiting.c
index d8bfe34..0e376b6 100644
--- a/src/message-waiting.c
+++ b/src/message-waiting.c
@@ -926,11 +926,18 @@ static void message_waiting_unregister(struct ofono_atom
*atom)
void ofono_message_waiting_register(struct ofono_message_waiting *mw)
{
- DBusConnection *conn = ofono_dbus_get_connection();
- const char *path = __ofono_atom_get_path(mw->atom);
- struct ofono_modem *modem = __ofono_atom_get_modem(mw->atom);
+ DBusConnection *conn;
+ const char *path;
+ struct ofono_modem *modem;
struct ofono_atom *sim_atom;
+ if (mw == NULL)
+ return;
+
+ conn = ofono_dbus_get_connection();
+ modem = __ofono_atom_get_modem(mw->atom);
+ path = __ofono_atom_get_path(mw->atom);
+
if (!g_dbus_register_interface(conn, path,
OFONO_MESSAGE_WAITING_INTERFACE,
message_waiting_methods,
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 3/3] doc: fix a kill-yank error
From: Pekka Pessi
---
doc/smartmessaging-api.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/smartmessaging-api.txt b/doc/smartmessaging-api.txt
index 36065b4..637a5ef 100644
--- a/doc/smartmessaging-api.txt
+++ b/doc/smartmessaging-api.txt
@@ -50,7 +50,7 @@ Methods void ReceiveAppointment(array{byte}
appointment, dict info)
void ReceiveBusinessCard(array{byte} card, dict info)
Requests the agent to process a new SMS that has
- arrived containing a vCalendar object. The info
+ arrived containing a vCard object. The info
dictionary contains 'Sender', 'LocalSentTime' and
'SentTime' properties.
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: oFono exits on new voicecall with disconnected system bus
Hi Nicola,
> >> It seems that in src/voicecall.c/append_voicecall_properties "name"
> >> points to garbage as commenting the line:
> >> ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name);
> >> fixes the problem.
> >
> > can you print the content of name and call->name fields as part of a
> > debug statement. I like to see what is in there.
> >
> > At least the pointer should be valid since it pointers to call->name
> > array. Maybe the content is just not UTF-8 string.
>
>
> ofono_dbus_dict_append(dict, "LineIdentification",
> DBUS_TYPE_STRING, &callerid);
>
> DBG("name %s call->name %s", name, call->name);
> ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name);
>
>
> ofonod[5771]: src/voicecall.c:ofono_voicecall_notify() Did not find a
> call with id: 1
> ofonod[5771]: src/voicecall.c:append_voicecall_properties() name ��+@
> call->name ��+@
> ofonod[5771]: System bus has disconnected!
I think that I found the problem. Pushed a patch for it. Please re-test
if this helps. The Calypso driver was using stack memory for the call
object.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: oFono exits on new voicecall with disconnected system bus
Hi Nicola,
> >> It seems that in src/voicecall.c/append_voicecall_properties "name"
> >> points to garbage as commenting the line:
> >> ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name);
> >> fixes the problem.
> >
> > can you print the content of name and call->name fields as part of a
> > debug statement. I like to see what is in there.
> >
> > At least the pointer should be valid since it pointers to call->name
> > array. Maybe the content is just not UTF-8 string.
>
>
> ofono_dbus_dict_append(dict, "LineIdentification",
> DBUS_TYPE_STRING, &callerid);
>
> DBG("name %s call->name %s", name, call->name);
> ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name);
>
>
> ofonod[5771]: src/voicecall.c:ofono_voicecall_notify() Did not find a
> call with id: 1
> ofonod[5771]: src/voicecall.c:append_voicecall_properties() name ��+@
> call->name ��+@
> ofonod[5771]: System bus has disconnected!
I bet this is not a valid UTF-8 string. So somewhere along the code the
call->name array got not initialized as 0.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: oFono exits on new voicecall with disconnected system bus
On Fri, Jan 21, 2011 at 11:29 AM, Marcel Holtmann wrote:
[...]
>> It seems that in src/voicecall.c/append_voicecall_properties "name"
>> points to garbage as commenting the line:
>> ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name);
>> fixes the problem.
>
> can you print the content of name and call->name fields as part of a
> debug statement. I like to see what is in there.
>
> At least the pointer should be valid since it pointers to call->name
> array. Maybe the content is just not UTF-8 string.
ofono_dbus_dict_append(dict, "LineIdentification",
DBUS_TYPE_STRING, &callerid);
DBG("name %s call->name %s", name, call->name);
ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name);
ofonod[5771]: src/voicecall.c:ofono_voicecall_notify() Did not find a
call with id: 1
ofonod[5771]: src/voicecall.c:append_voicecall_properties() name ��+@
call->name ��+@
ofonod[5771]: System bus has disconnected!
Niko
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: oFono exits on new voicecall with disconnected system bus
Hi Nicola, > >> ofonod[6232]: src/voicecall.c:ofono_voicecall_notify() Did not find a > >> call with id: 1 > >> ofonod[6232]: System bus has disconnected! > > > > this happens if something in a D-Bus message is corrupted and the D-Bus > > daemon complains. The result is that it kicks us off the bus. > > > > You need to track down which D-Bus API call causes this. Wild assumption > > is that it is either a wrong message parameter or an invalid object > > path. > > It seems that in src/voicecall.c/append_voicecall_properties "name" > points to garbage as commenting the line: > ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name); > fixes the problem. can you print the content of name and call->name fields as part of a debug statement. I like to see what is in there. At least the pointer should be valid since it pointers to call->name array. Maybe the content is just not UTF-8 string. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: SAT support in oFono
Hi Lasse, ofono-boun...@ofono.org 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 Most of the modems support call control, MO SMS control on the firmware side itself. Open for adding support in ofono. > - BIP (Bearer independent protocol), including commands like > OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA Inorder to support class e fully, changes are required in connman and ofono. Since class e is an optional one, I dont think we need to support this inorder to get GCF certified. for your question, is there any plan to support this in oFono core, I would leave it to Denis, Andre and Marcel to comment on this. > - Extend support in PROVIDE LOCAL INFO Same here, don't need to support this inorder to get GCF certified. > - EVENT DOWNLOAD / SET UP EVENT LIST > Most of the modem firwares support the event download of MT CALL, connected, disconnected etc. Its been discussed in irc, that there is no plans to add support for UserActivity, IdleScreen available events. Denis can confirm this. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: oFono exits on new voicecall with disconnected system bus
On Thu, Jan 20, 2011 at 3:55 PM, Marcel Holtmann wrote: > Hi Nicola, Hi Marcel, [...] >> ofonod[6232]: src/voicecall.c:ofono_voicecall_notify() Did not find a >> call with id: 1 >> ofonod[6232]: System bus has disconnected! > > this happens if something in a D-Bus message is corrupted and the D-Bus > daemon complains. The result is that it kicks us off the bus. > > You need to track down which D-Bus API call causes this. Wild assumption > is that it is either a wrong message parameter or an invalid object > path. It seems that in src/voicecall.c/append_voicecall_properties "name" points to garbage as commenting the line: ofono_dbus_dict_append(dict, "Name", DBUS_TYPE_STRING, &name); fixes the problem. Regards Niko ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
SAT support in oFono
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 - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA - Extend support in PROVIDE LOCAL INFO - EVENT DOWNLOAD / SET UP EVENT LIST Or is some of these assumed to be handled in modem or driver side? BR, -Lasse ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] isimodem: fix issue with user busy release
when the user rejects the incoming call, hangup_active
will get called on the driver side whereas when the user
rejects the waiting call, set_udub will get called on the
driver side.
---
drivers/isimodem/voicecall.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/isimodem/voicecall.c b/drivers/isimodem/voicecall.c
index e5842aa..9aa9454 100644
--- a/drivers/isimodem/voicecall.c
+++ b/drivers/isimodem/voicecall.c
@@ -973,6 +973,7 @@ static void isi_hangup_current(struct ofono_voicecall *ovc,
*/
struct isi_voicecall *ivc = ofono_voicecall_get_data(ovc);
int id = 0;
+ uint8_t cause = CALL_CAUSE_RELEASE_BY_USER;
for (id = 1; id <= 7; id++) {
if (ivc->calls[id].call_id & CALL_ID_WAITING)
@@ -983,19 +984,23 @@ static void isi_hangup_current(struct ofono_voicecall
*ovc,
switch (ivc->calls[id].status) {
case CALL_STATUS_CREATE:
case CALL_STATUS_COMING:
- case CALL_STATUS_PROCEEDING:
case CALL_STATUS_MO_ALERTING:
- case CALL_STATUS_MT_ALERTING:
case CALL_STATUS_ANSWERED:
goto release_by_id;
+ case CALL_STATUS_MT_ALERTING:
+ cause = CALL_CAUSE_BUSY_USER_REQUEST;
+ goto release_by_id;
+ case CALL_STATUS_PROCEEDING:
+ if (ivc->calls[id].mode_info & CALL_MODE_ORIGINATOR)
+ cause = CALL_CAUSE_BUSY_USER_REQUEST;
+ goto release_by_id;
}
}
id = CALL_ID_ACTIVE;
release_by_id:
- isi_call_release_req(ovc, id, CALL_CAUSE_TYPE_CLIENT,
- CALL_CAUSE_RELEASE_BY_USER, cb, data);
+ isi_call_release_req(ovc, id, CALL_CAUSE_TYPE_CLIENT, cause, cb, data);
}
static void isi_release_all_held(struct ofono_voicecall *ovc,
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
